背景

移动开始对白名单以外的域名、网络协议进行上传限速。

具体表现在：

• 国内网盘、邮箱、微信、测速网站等上传一切正常。
• 使用 IPv6 公网回家连 NAS ，或者 IPv4 打洞回家，读取文件异常缓慢。
• BT 没有上传流量。
• iperf3 测速只有 1 Mbps 左右。
• 上传被限速，达到 1 Mbps 峰值时，时有丢包现象或者 ping 值上升。

除了移动以外，其他运营商也有类似表现：

• /t/1112956 北京移动 测速正常但上传看着确实变小了
• /t/1057505 移动似乎对非常用端口上传进行了限速
• /t/1063534 电信宽带测速正常，NAS 上传被限速
• /t/1108373 上海电信上传限速
• /t/1081007 上海电信上传限速
• ...

限速机制

深度包检测。默认限速 1 Mbps （ 125 kB/s ），检测到白名单协议、域名之后，放开至正常速（我测得 100 Mbps ）。

以下均是我在移动宽带下测得的结果。

TCP

• HTTPS：TCP 443 端口，SNI 探测

  目标端口为 443 的 TCP 连接建立成功，客户端发送的 TLS Client Hello 包含白名单域名，解除限速。

  比如，在 TCP 建立时，使用下方二进制串，即可解除限速。虽然很多字段是不合法的，比如长度填了 0 ，域名直接放在了最后。但是不影响上游匹配到了 TLS 特征，并命中了域名关键字，放开限速。

  "\x16"         // Handshake
  "\x03\x00"     // TLS version
  "\x00\x00"     // Length (0)
  "\x01"         // Client Hello
  "\x00\x00\x00" // Length (0)
  "\x03\x00"     // TLS version
  "speedtest.cn"
  

  这个检测仅适用于 443 端口。其他端口使用 HTTPS 依然保持限速。

• HTTP：所有 TCP 端口，HTTP 头 Host 字段检测

  同样地，只要匹配到关键特征即可解除限速。

  "HTTP/\r\n"
  "Host: speedtest.cn\r\n"
  "\r\n"
  

UDP

• DNS：53 端口，首个 UDP 包含有 DNS 协议特征

  目标端口为 53 端口，只要第一个 UDP 包发送含有如下 DNS 特征的请求，就可以解除限速。同样是特征匹配，不需要合法。

  "\0\0\1\0\0\1\0\0\0\0\0\0\0\0\0\1\0\1"
  

• 待发现

  尚未找出对其他 UDP 端口解除限速的方法。

补充

该检测会追踪整个 TCP 的状态。在已建立的 TCP 连接中，构造 SYN 之后再发 SNI 或者 HTTP 特征并不会骗过检测机制，达成解除限速的效果。

话说，这个探测方式是不是很眼熟。我怀疑是不是某个神秘技术下放到了运营商，区别只在：一个是检测到就断流，一个是检测到就恢复上传速度。

解决方案

这里介绍除了投诉以外的规避方案。

带 HTTP 混淆的网络工具

设置混淆的 host 为白名单网站即可。

udp2raw 中加上 HTTP 特征

使用 TCP 协议作为隧道可能不是最佳，因此我 fork 了 udp2raw ，在上面加上了 HTTP 特征： https://github.com/MikeWang000000/udp2raw

这个特征很明显的通过了运营商的检测，上传速度恢复到 100 Mbps 。

可以参考这个提交：commit c4995ea

使用方法是在参数后加上 --fake-http speedtest.cn 这样就会混淆为在访问测速网站。

对于一般的 TCP 连接

（理论上，未验证）可以使用 eBPF 等手段，在 TCP 连接建立时，使用较小的 TTL 发送 HTTP 特征。这样既通过了运营商的检测，又不会到达服务器。

后记

因为省间结算，运营商费尽心机限制用户上传。这种白名单机制也让用户难以投诉：常见网站、测速网站的上传检测都是正常。运营商可以直接不承认有限速行为，而归结为用户问题。不知道以后还有什么新的手段呢？