中国联通跨网限速10M，存在黑白名单机制，测速根本看不出来

今天从 NAS 拷一个文件，P2P 传输，任务中心里的速度一直贴在 930.0 KB/s 上，38 个分片走到 95% 就开始磨，磨到最后也没上去。这条线是联通 2000M 下行、100M 上行，理论上的事儿不用再算了，按 2000M 的水平看这个数字，我实在没什么好解释的。

任务中心里 PR 2023 文件下载到 38 个分片的 95%，速度显示 930.0 KB/s — 图 1：930.0 KB/s，38 个分片走到 95%，然后就没有然后了

930KB/s 换算过来是 7.4Mbps。2000M 的宽带跑出 7Mbps，差了两百多倍，而且它不是忽快忽慢——它是稳的，稳到像有人用手按着。如果这是典型的网络拥塞，速度该是一道锯齿，上去一点、掉下来、再上去；可它就是一条直线。拥塞不会画直线，只有配置会。

我盯着那个数字看了几分钟，确认不是自己看错了，然后拿关键词去搜。Bing 上「中国联通跨网限速」有 12100 条结果，第一页翻下来，就没一条是好消息。

Bing 搜索「中国联通跨网限速」返回 12100 条结果，多条帖子反馈跨网、跨运营商限速 — 图 2：搜索框里打下"中国联通跨网限速"，12100 条结果，右侧相关搜索全是"联通宽带限速""中国联通解除限速"

先说结论

限的是 10Mbps，不是 10MB/s。930KB/s 折合 7.4Mbps，扣掉 TCP/IP 头和各种协议开销，正好顶在 10Mbps 这块天花板上。标题里那个"10M"，单位是 bit，换算成大家习惯的字节是 1.25MB/s。
测速网站是被放行的那一类。同一分钟、同一个出口，Speedtest 走 HTTPS 能跑 80.9Mbps，P2P 只有 930KB/s，差 11 倍。这个差距不是链路质量能解释的，链路要是有问题，那 80.9 又是从哪儿冒出来的。
这不是故障，是策略。千兆时代限 5M，2000M 时代限 10M，刚好翻一倍，占下行带宽的比例都停在 0.5%。故障不会按套餐比例长个子，会按比例长的只有配置。
10M 这个数字有来路。它大概等于"让 TCP 的 ACK 勉强跑得动"的下限，带宽翻倍、限速翻倍，这两件事是绑在一起的。这是我自己的推算，过程下面摊开，认同不认同另说。
测不出来，是因为工具选错了。测速网站测的是"我和测速服务器之间那条被放行的路"，不是你的带宽。想看见真实情况，得拿一个它不认识的应用去跑。
能投诉，但期望值别太高。上次 IPv6 入站是配置问题，能修；限速是写进策略里的东西，最多问出一句解释。两者的差别，我后面再说。

不测不知道，一测更气

光看别人的帖子不算证据，别人家的线路、别人家的设备、别人家的对端，变量太多，看完了只能得到一个"好像大家都有这毛病"的印象。所以我先在本地跑了一个 LibreSpeed——开源的那套网页测速，服务端自己架，跟运营商自己的测速平台没有关系，也不用担心它给我开后门。

LibreSpeed 自建测速结果：Ping 82.7 毫秒，抖动 4.10 毫秒，下行 80.9 Mbps，上行 47.5 Mbps — 图 3：自建 LibreSpeed，Ping 82.7 ms、抖动 4.10 ms、下行 80.9 Mbps、上行 47.5 Mbps

80.9Mbps，也就是 10.1MB/s；Ping 82.7 毫秒、抖动 4.10 毫秒，链路干净得很，一点都不像有拥塞的样子。把这两组数字并排放，问题就直白得没什么可争的了：

测试项	走的路	实测速率
LibreSpeed 自建测速	HTTPS 短连接，测的是自己和测速服务器之间	80.9 Mbps ≈ 10.1 MB/s
NAS 的 P2P 传输	P2P 长连接，对端 IP 分散、双向小包多	930 KB/s ≈ 7.4 Mbps

表 1：同一个出口、同一段时间，两条路的速率差了一个数量级

差 11 倍。这就不是"你家网络有问题"能解释的事了：同一条物理链路、同一个光猫、同一个小区接入设备，换个应用就从 80.9Mbps 掉到 7.4Mbps，说明问题不在"能不能跑"，在"让不让跑"。

这就是我标题里说的黑白名单：对测速类流量放行，对 P2P 类型的应用限速。你要问为什么偏偏是这两类，其实不难理解：测速站的流量特征太好认了，目标域名和 IP 就那么几个，HTTPS 短时突发，几十秒跑完就走，识别成本低、误伤成本也低。

P2P 正好反过来，对端 IP 满地散，连接一挂几个小时，上下行小包不断，这种流量在限速器眼里，跟白纸黑字写着"我是 P2P"没什么区别。一边是几秒钟就能判定的朋友，一边是浑身写着可疑的陌生人，谁被放行谁被掐，本来就不难选。

话说回来，我没办法证明它是按域名做的白名单，手里没有运营商的配置，也没有那段链路上的镜像流量。我能证明的只有一件事：同一分钟、同一个出口，一个跑满 80.9Mbps，一个卡在 930KB/s。剩下的都是推断，但推断到这个份上，够让人不舒服了。

而且这种"测速好看、用起来难看"的组合，比明着限速还让人火大。你去投诉，客服让你先测个速，你测出来 80.9Mbps，人家一句"您这边网络正常"，工单就关掉了。你手里的证据，恰好是从那条被放行的路上测出来的。这不叫提供服务，这叫给你发了一把量不准的尺子，还告诉你刻度是对的。

为什么测速网站一定跑得满

这里多说两句，因为我一开始也没想明白：既然跨网被限了，为什么测速还能跑出 80.9Mbps？限速器难道是只认 P2P、不认 HTTPS 的瞎子？后来把三件事分开看，就通了。

第一层，或者说最浅的一层，在节点位置。测速平台的节点绝大多数就架在运营商的省级出口、或者网内 CDN 上，它压根不跨网。你从家里测速，路径是"家 → 本地城域网 → 省级出口 → 测速服务器"，很多时候根本没出过这张网；跨网限速发生在两张网交接的地方，你测的那条路连那个口都没经过，自然不会掉速。

再深一层，是流量特征。测速是一次性的短时大流量，几十秒结束，单流为主，目标 IP 固定，协议就是干干净净的 HTTPS。对一个做了 DPI 的设备来说，识别这种流量需要看的字段很少，而放行它的收益很大——测速结果是运营商对外宣传的指标，也是用户投诉时唯一会用的证据，把它做得好看，等于同时解决了营销和售后两个问题。

最后一层更朴素，也最容易被忽略：测速测的是下行。你点一下开始，浏览器拼命从服务器往下拉数据，可这条路上真正被手掐着的是上行——ACK 从你家往上走，回给服务器。下行带宽再大，ACK 过不去，窗口就推不上去。

测速只有几十秒，前期那点初始窗口足够把数字顶到 80.9；P2P 是要连着跑几小时、跑几百 GB 的，ACK 一堵，它就现原形。这也解释了那个最气人的现象：你越是用测速证明自己没被限，越说明不了任何问题。

限速器是怎么认出 P2P 的

有人可能会想，现在什么流量都加密了，它凭什么知道我在 P2P？这个问题我一开始也有，后来想明白：它不需要知道你在传什么，只需要知道你长什么样。加密能藏住内容，藏不住形状。

形状指的是这些：目标 IP 有多少个、分布在哪几家运营商、连接同时开着几条、每条活多久、上下行比例是多少、包长是不是整齐地贴着 MSS。这几样东西凑在一起，识别难度并不高，也完全不需要解密。

特征	测速类流量	P2P 类流量
目标 IP 数量	一两个，且集中在测速/CDN 节点	几十到几百个，散落在各运营商
连接数	单流或少量并发	几十上百条同时在线
连接时长	几十秒，跑完就断	几小时到几天，长期挂着
上下行比例	几乎全是下行，上行只有 ACK	上行占比明显更高，做种时甚至是纯上行
包长分布	满载大包为主	小包、控制包、心跳包混杂

表 2：不用解密也能区分的五组特征

所以改端口没用，套一层加密也没用，把 P2P 伪装成 443 更没用——它看的不是端口号，是行为。这也解释了一个很多人踩过的坑：以为换个客户端、换个协议就能绕过去，结果速度一点没变，因为对端那边的判定标准压根没动过。

为什么偏偏是 10M

不把这个说清楚，"为什么是 10M 而不是 50M"这个问题就永远圆不上，而它恰恰是最能说明问题的一个数字。

TCP 有个常识，但平时没人会往这上头想：下载不是只下载不上传。你每收到一批数据，都要回一个 ACK 告诉对方"我收到了"，发送方靠这些 ACK 往前推滑动窗口，窗口推不动，速率就上不去。ACK 包本身很小，几十个字节，可它是按包数算的，下行越快、每秒要回的 ACK 越多——千兆带宽满速下载，每秒几十万个 ACK，全都要走上行。

所以上行被掐住，下行一定跟着塌，链条短得很：上行一堵，ACK 排队，往返时间变长，发送方算出来的窗口收缩，下行速率跟着掉。用户坐在那儿只能看到"下载慢"，看不到"我的上行被掐了"，中间这几步全在协议栈里，没有一个地方会报警，也没有一个界面会告诉你。

按这个逻辑倒推回去，5M 差不多就是"能让千兆下行的 ACK 勉强过得去"的那条线。给得再少，ACK 排队会把下行拖死，用户随便一测就能发现不对；给到这个数，测速能跑出个像样的成绩、刷视频也不卡，只有 P2P 这种靠着大窗口和长 RTT 撑着的传输会先崩。这个平衡点选得太准了，准到不像巧合。

套餐	跨网限速值	占下行带宽的比例
1000M 下行（当年投诉过的那档）	5M	0.5%
2000M 下行（现在这档）	10M	0.5%

表 3：限速值跟着下行带宽一起翻倍，比例一点没变

这张表是我最想让人看的地方。套餐从千兆换到 2000M，限速从 5M 变成 10M，刚好两倍，占下行带宽的比例停在 0.5% 上没动。要是网络拥塞、要是设备瓶颈、要是"临时优化"，没有任何一种情况会长得这么规整——拥塞是随机的，瓶颈是不规则的，只有配置才会老老实实按比例缩放。

我把这个推算和这两张图一起发了过去，问了三个问题：跨市、跨运营商存不存在 UDP 限速，存不存在 TCP 丢包限速，以及 HTTPS 的 Speedtest 测速是不是在白名单里。

聊天记录截图：向对方提出跨市是否存在 UDP 限速、TCP 丢包限速与 HTTPS 测速白名单三个问题，并推算从千兆限速 5M 到 2000M 限速 10M 刚好翻倍 — 图 4：问题问得很具体——UDP 限速、TCP 丢包限速、测速白名单，一个都没绕

我特意没绕弯子。问"你们是不是限速了"，得到的永远是"没有"，这句话可以背、也不留痕；问"跨市存不存在 UDP 限速、TCP 丢包限速、测速白名单"，这个问题要么答、要么不答，没法含糊过去。投诉这件事，问法比嗓门重要。

这不是第一次，上次是 IPv6

今年 8 月那轮折腾的是 IPv6 入站，外网打不进家里的 NAS，内网一切正常。那件事从报障一路走到工信部信访，前后拖了两个多月，最后按属地转办到省通信管理局，联通派人上门，一周之内把入站连通性解决了。

那次留下的结论，到现在我还记着：IPv6 入站能修，是因为它属于"配置"；NAT4 不给，是因为它属于"政策"。能改的改，不能改的给个说法。这条分界线当时我以为已经摸清了，现在看只摸清了一半——那两件事说到底还都在"功能有没有"的层面，而这次的跨网限速，落在"给你多少"的层面。

上一轮是入站被封，这一轮是跨网被限，一个往家里走不通，一个往外面走不快，方向不一样，性质是同一个：家宽的可用性在被一层一层往下削，每削一层，都会告诉你"这是正常的"。

而且这次的位置更难受。IPv6 入站不通，我还能查、能抓包、能在自己的设备上把"不是我家的问题"证出来，抓包里 SYN 进来、SYN+ACK 出不去，一个字节一个字节摆在那儿。

跨网限速反过来，它发生在两张网交接的那段链路上，我这边抓包只能看到"发出去很慢"，看不到任何具体的东西。手里唯一能拿来比的，就是测速和 P2P 这两个数字，而其中一个恰好是被放行的。

完整的取证路径和投诉流程写在《联通 NAT4+IPv6 投诉后续：问题已解决，沟通专业，值得表扬》里，有兴趣可以去翻，pcap 和命令都在。这次不用重复那套动作，因为性质不一样：上次是"该开的功能没开"，这次是"该给的速度不给"。前者叫故障，后者叫定价。

我能做的，和做不到的

先说做不到的，免得给人虚假希望，也免得有人照着我写的折腾一晚上，最后发现没用。

自己这边的整形改不了它。软路由上那套 SQM、CAKE 我也配过，做法还专门写过一篇（《iStoreOS 三个页签 22 项参数逐条讲解》）。但那玩意儿管的是"我家出门的队怎么排"，管不到对面收多少，你把自己这头的口子整得再漂亮，也影响不了别人的限速器，最多让自家几台设备别互相抢。
换协议也躲不掉。P2P 不行就换 HTTP 直链？那得看下载源在哪。跨网那一段路是一样的，走什么协议都是同一根管子，只是换了个被识别的特征而已。
测速网站给不了你要的证据。它跑得越好，你越说不清。想说明问题就必须做对照，而且得是同时刻的对照。

能做到的部分也不复杂，说到底就一件事：把两组数字按在同一分钟里。分开测出来的成绩没有说服力，对方一句"你这两次条件不一样"就能顶回来。

固定一个对端。别一会儿测家里 NAS、一会儿测公共网盘，对端一换，变量就说不清。选定一个跨网的对端，从第一次用到最后一次都别换。
同一时间段跑两组。先跑自建 Speedtest 记下数字，紧接着跑 P2P 或大文件下载记下数字，中间隔不超过两分钟，两条路的成绩必须落在同一个时间窗里。
换一条出口再跑一次。有手机就切蜂窝网络，或者换个别的运营商的热点，同样的对端再来一遍。如果换了出口速度就正常，那问题至少不在对端。
截图要带时间和数字。任务栏那个速率、测速页面那个数字，都得能看清。别拿"感觉很慢"去投诉，这四个字在工单系统里不值钱。
路径还是老一套。10010 报障，不给答复就 10015，15 个工作日没有实质进展，走省通信管理局 12300 申诉或工信部信访，材料一次给全。具体怎么走前面那篇写过了，不重复。