起初，是我发现了一个“Bug”。
At first, I discovered a “Bug”.
前前后后折腾了快一个月，终于把这个"Bug"修复了。
什么 Bug?
大概在一个月之前，我本来想把一个文件传到公司的电脑里。于是我就把它放在了我的 AList 服务器上。
https://list.wgxls.eu.org:8443/
并且拷贝了下载链接。
但是当我在公司电脑上下载这个文件时，发现速度非常慢，只有 50 KB/s 左右。
我起初还以为是公司的网络不好，因为我们在 VPN 环境下工作，VPN 的速度本来就不快。
然后我用我的手机也尝试了一下，发现速度也很慢。
自此，对这个问题的调查就正式开始了。
怀疑对象一：Alist 服务器
因为我的 Alist 是用 docker 安装的，同时我的电脑里还安装了一个自动升级 docker 镜像的容器。
所以我首先怀疑是 Alist 在某个版本之后出现了 regression。因为速度差这件事在以前是没有的。
第一个对比试验开始。
降级 Alist 到一个古老的版本，发现速度依然很慢。
怀疑对象二：1Panel 的反向代理
既然 Alist 没问题，那么接下来就开始怀疑下一个流量的中转站：1Panel 的反向代理。
这里做了很多测试，首先，我测试了一下通过 1Panel 的反向代理下载 Alist 的文件，速度很慢。🆖
通过 1Panel 的文件预览下载服务器上的一个文件，速度正常。🆗
此时，我以为问题已经初步定位。
Just in case，
我又测试了一下直接访问 Alist 的端口，速度正常。🆗
下一项测试就是准备降级 1Panel 版本了，但此时我发现我的两个 OK 的测试都是通过 http 协议进行的。
而失败的测试是通过 https 协议进行的。
于是我就测试了一下反向代理不开启 https 的情况，发现速度正常。🆗
我认为此时问题已经被定位，于是有了文章开头的那个 issue。
那个 issue 在发起后第二天就被转成 Discussion 了，维护者表示默认的 https 设置不会影响速度，建议排查其他原因。
嗯…
其实他说的也没错，因为我发现在我的局域网内的另一个电脑用 https 协议下载 Alist 的文件速度也是正常的。
怀疑对象三：运营商的限速
此时，我开始渐渐怀疑是不是我的网络出口被限速了，因为在局域网内的电脑速度正常。
但从测网速的结果看，完全发现不了问题。
在外网下载家里的文件速度跟协议有关，http 协议速度正常，https 协议速度慢。
难道运营商仅仅对 https 协议限速？
要怎么证明这件事？
因为国内网盘、邮箱、微信、测速网站等上传一切正常。这里自然有很多 https 协议的流量。
打开 Google 搜索了一下，搜索出了很多新文章。
B 站再搜索一下运营商限速，也有很多相关的视频。
只是大家的现象在细节上有所不同，有的人是 http 协议限速，有的人是 https 协议限速。
可能是政策传达时听反了吧😂
验证方法
按照互联网大神的方法，检查传输的 MTU 可以帮助我们验证运营商是否限速。
在我的环境下(辽宁联通)，如果 ICMP 的 MTU 大于 1452 字节，就会被分片。
出现这种情况就可以判断是运营商限速了。
1 | PS C:\Users\wgxls> ping www.baidu.com -l 1453 -f |
解决方案
按照前文的介绍，运营商限速是有白名单的，对测速网站的上传流量是不限速的。
按照这种思路，解决方案就是如何骗过运营商的限速检测。
FakeHTTP 诞生了！
它的原理是在 TCP 三次握手之后，立即发送一个 HTTP GET 请求，Host 为指定域名(speedtest.cn)。使用 NFQUEUE 实现。
一些说明：
- iptables （ iptables-legacy 或者 iptables-nft 都行）规则都在 mangle 表内。
- FakeHTTP 检查入站的第一个 ACK 或者 SYN-ACK ，后续数据包打上 fwmark 不再检查。
- TTL 值默认为 3 ，可以通过 -t
调整。要让这个 HTTP 数据包刚好通过限速检查，但不被目标服务器收到。 - 精简的 OpenWRT 可能需要 opkg install kmod-…，主要是要有 nfqueue 、conntrack 功能。
- 不支持 WSL （比较麻烦）
后记
经过一个月的折腾，终于把这个"Bug"修复了。
我只能说我们的世界太魔幻了，上有防火长城阻碍信息的自由流通，中有内容审查社交平台限制言论的自由表达，下有运营商限速阻碍网络的自由使用。
而且为了不让你找到限速的证据，还精心设计了一个白名单机制。
一个字: 绝！
After nearly a month of tinkering, I finally “fixed” this “Bug”.
What Bug?
About a month ago, I wanted to transfer a file to my work computer, so I put it on my AList server.
https://list.wgxls.eu.org:8443/
And copied the download link.
But when I downloaded the file on my work computer, the speed was terribly slow — only about 50 KB/s.
At first I thought it was just a bad corporate network, since we work in a VPN environment and VPN speeds are never fast anyway.
Then I tried with my phone too, and it was also slow.
From then on, the investigation officially began.
Suspect #1: The AList Server
Since my AList was installed via docker, and my computer also runs a container that auto-updates docker images, I first suspected that AList had a regression in some recent version, because this slow speed never happened before.
Time for the first comparison test.
I downgraded AList to a very old version — still slow.
Suspect #2: 1Panel’s Reverse Proxy
Since AList wasn’t the problem, the next hop in the traffic path became suspect: 1Panel’s reverse proxy.
I ran many tests here. First, I downloaded a file from AList through the 1Panel reverse proxy — slow. 🆖
Downloading a file directly from the server via 1Panel’s file preview — normal speed. 🆗
At this point, I thought the problem was initially located.
Just in case,
I also tested accessing AList’s port directly — normal speed. 🆗
The next test was going to be downgrading 1Panel, but then I noticed that my two OK tests were both over HTTP.
And the failed test was over HTTPS.
So I tested the reverse proxy without HTTPS enabled — normal speed. 🆗
I thought the problem was located, so I opened the issue shown at the top of this article.
The issue was converted to a Discussion the very next day; the maintainer said the default HTTPS settings don’t affect speed and suggested investigating other causes.
Hmm…
Actually, he wasn’t wrong — I found that another computer on my LAN downloading from AList over HTTPS also ran at normal speed.
Suspect #3: ISP Throttling
At this point, I started to suspect my network egress was being throttled, because LAN computers were fine.
But speed test results showed absolutely nothing wrong.
Downloading files from home over the external network depended on the protocol — HTTP was normal, HTTPS was slow.
Could the ISP really be throttling only HTTPS traffic?
How to prove it?
Domestic cloud drives, email, WeChat, speed test sites, etc. all upload fine — and there’s plenty of HTTPS traffic in there.
A Google search turned up many articles.
Mobile whitelist upload throttling mechanism and solutions
Searching “ISP throttling” on Bilibili also surfaces many related videos.
The details differ from person to person — some get throttled on HTTP, some on HTTPS.
Maybe someone misheard when the policy was being communicated😂
Verification Method
Following the method of the internet gurus, checking the MTU of transmitted packets can help verify whether the ISP is throttling.
In my environment (Liaoning China Unicom), if the ICMP MTU exceeds 1452 bytes, packets get fragmented.
If that happens, you can conclude the ISP is throttling.
1 | PS C:\Users\wgxls> ping www.baidu.com -l 1453 -f |
Solution
As described earlier, the ISP’s throttling has a whitelist — upload traffic to speed test sites is not throttled.
Following that idea, the solution is how to trick the ISP’s throttling detection.
FakeHTTP was born!
Its principle: immediately after the TCP three-way handshake, send an HTTP GET request with the Host set to a whitelisted domain (speedtest.cn), implemented via NFQUEUE.
Some notes:
- iptables (either iptables-legacy or iptables-nft) rules all go in the mangle table.
- FakeHTTP checks the first inbound ACK or SYN-ACK; subsequent packets are marked with fwmark and not checked again.
- The TTL defaults to 3 and can be adjusted with -t
. The HTTP packet should just pass the throttling check but not be received by the target server. - A stripped-down OpenWRT may need
opkg install kmod-...; mainly you need nfqueue and conntrack support.- WSL is not supported (too troublesome)
Afterword
After a month of tinkering, I finally “fixed” this “Bug”.
All I can say is our world is too surreal: above, the Great Firewall blocks the free flow of information; in the middle, content-reviewed social platforms restrict free expression; below, ISPs throttle to hinder free use of the network.
And to keep you from finding evidence of throttling, they even carefully designed a whitelist mechanism.
One word: brilliant!
