手机流量连不上机场,Wi-Fi 却正常是什么原因

这类故障其实自带一个很干净的实验条件。设备没变、系统没变、客户端没变、订阅没变,唯一改动的是脚下这个网络——那么原因就只能在网络里。相比那些需要一层层猜的症状,它已经替你完成了一半的排查工作。

麻烦的地方在于,「网络环境」是个复合体。它至少包含运营商的路由策略、接入方式带来的链路特性、以及路由器或网关上的规则三层。三层各自会造成不同的现象,而它们在客户端界面上的表现却经常一模一样:红色的超时,或者绿色的延迟配上打不开的网页。

要把它们分开,靠的不是看报错,而是设计一组能复现的对照。下面先说实验怎么做,再说每一类网络的脾气,最后落到具体该改什么。

怎么设计一次真正能复现的网络对照实验#

对照实验的要求是一次只动一个变量。很多人排查失败,是因为换网络的同时也换了设备或换了节点,结果无论通不通都得不出结论。

按这个顺序做,全程不超过十分钟:

1. 锁定基准。在能正常使用的网络下选一个具体节点,记下它的地区、协议和延迟数值。这个节点是后面每一轮的参照物,中途不要更换。
2. 只切网络。手机关掉 Wi-Fi 走蜂窝,或者切到另一个热点。其他一切保持不变,再测同一个节点。
3. 横向扩一轮。在失效的那个网络下,把节点换成不同地区、不同协议的三到四个。目的是看失效是全面的还是选择性的。
4. 反向验证。回到原来能用的网络,确认故障消失。这一步防止你把一次偶发波动当成规律。

结果的组合直接指向不同的原因:

最后一行很关键。如果换回去也照样有问题,说明网络根本不是变量,应该转到设备对照法重新缩小范围。

五种网络环境各自的脾气#

不同接入方式的限制强度差异很大,先知道自己身处哪一类,能省掉一半猜测。

蜂窝网络还有一个容易被误判的特点:它的链路质量本身波动更大,信号从一格变三格,表现可能完全不同。所以在蜂窝下测试时,尽量在信号稳定的位置连续测两三轮,避免把信号问题当成机场问题。

公共 Wi-Fi 的认证门户会劫持首次 HTTP 请求。没完成认证就开客户端,会看到全部节点超时,这不是故障。先在浏览器里完成认证,再启动客户端。

MTU 太小:能握手,却传不动数据#

这是换网络失效里最有辨识度的一种,也是最容易被误判成「机场慢」的一种。

MTU 指一条链路单次能承载的最大数据包尺寸。以太网上的常见值是 1500 字节,而蜂窝网络、部分 PPPoE 拨号和一些企业网关会更小,1400 到 1450 是常见区间,这些是通用的参考值,实际数值随运营商和接入方式不同而变化。当代理封装再给数据包加上一层头部之后,原本合规的包就可能超出这条链路的上限。

正常情况下,链路会把「包太大了」这个消息回送给发送方,发送方随之减小尺寸。问题在于这个通知机制经常被中途丢掉,于是大包被静默丢弃,发送方毫不知情地一遍遍重发。

结果就是那组很奇怪的症状:

• 节点显示已连接,延迟测试有数值,因为握手包很小。
• 打开纯文本页面正常,打开带图片的页面卡死。
• 下载大文件时进度条走一小段就不动了。
• 同一个节点在 Wi-Fi 下毫无问题。

处置办法是在客户端或系统里把 MTU 调小,常见做法是从 1400 起步,不行再往下试 1360。多数桌面和移动客户端在网卡或 TUN 相关的设置里提供了这一项。

ping -M do -s 1372 example.invalid

这是 Linux 上探测路径 MTU 的结构示例:-M do 表示禁止分片,-s 后面是负载大小,加上固定的头部开销即为实际包尺寸。逐步调整这个数字,找到不再报「需要分片」的最大值,就是这条链路的上限。Windows 上对应的是 ping -f -l 参数组合。

同一个机场,为什么移动、电信、联通表现不同#

因为你和落地节点之间的那段跨境路径,并不是所有运营商都走同一条。三家的国际出口容量、拥塞时段和路由选择各不相同,同一个节点在不同运营商下走出的实际路径可能差很多跳。

机场这一侧的应对方式是在境内或边缘部署多台接入机器,让你先连到最近或最优的那一台,再由它转发出去。这就是常说的多入口或三网优化,原理在多入口与 BGP 接入里有完整说明。入口部署得好,换运营商时的体验波动会小很多;只有单一入口的服务,则很容易出现「电信好用、移动很卡」这类分裂表现。

这也解释了为什么换城市或换运营商之后体验会变。变的不是节点,而是你接入到入口那一段路。

端口和协议被针对时,换节点为什么没用#

因为限制作用在特征上,而不是作用在某台服务器上。当一个网络对非常规端口做过滤、或对某类流量特征做识别时,你换多少个节点都无所谓——它们在这个网络里呈现的是同一套特征。

判别方法是把变量从「节点」换成「协议」和「端口」:

1. 在失效的网络下,把节点切到走标准 HTTPS 端口的那一类。这类流量在观感上最接近普通网页访问,通过率通常最高。
2. 再试一个 UDP 类协议。如果 TCP 类正常而 UDP 类全废,基本可以判定本地对 UDP 做了限速或阻断,UDP 被限速的判断与回退里有完整流程。
3. 如果订阅里同时提供多种协议,逐类各试一个,记下哪些能通。能通的那一类就是这个网络里的可用方案。

哪些症状说明该换协议,而不是换机场#

换机场的成本比换协议高得多,而且很可能换完发现新机场在同一个网络里一样不通——因为限制来自网络,不来自服务方。

三条判据可以支持「换协议」这个决定:

• 同一网络下,不同协议的成功率有明显差异。这直接证明被针对的是协议特征。
• 故障只在特定网络出现,回到家里的宽带一切正常。这说明服务方提供的节点是可用的。
• 换协议之后现象改变,哪怕只是从「完全不通」变成「能连但慢」,也说明方向对了。

反过来,如果在两个以上完全不同的网络下都复现同样的全面失效,那才轮到怀疑服务方。UDP 系协议之间的取舍,比如高丢包链路和频繁切换网络时该选谁,可以参考Hysteria2 与 TUIC 的对比;而各类症状的整体分流框架在排查总览里。

出差和公共网络,提前准备什么更省事#

在陌生网络里现场排查是最费时间的做法,因为你既没有基准也没有退路。三样准备可以把大部分麻烦挡在门外。

1. 一套标准端口的备用配置。在客户端里预先建好一个分组,只放走常见端口、伪装度较高的节点,到了受限网络直接切过去,不必现场逐个试。
2. 手机热点作为退路。蜂窝网络的限制通常比酒店网和会场网宽松,用手机开热点给电脑用,是最快的绕行方案。
3. 出发前用蜂窝实测一次。在家里就把「关掉 Wi-Fi 走流量」这一轮跑通,确认你的主力节点在蜂窝下可用、MTU 也不需要调整。到了现场再发现问题,可选项会少很多。

节点分组怎么按用途组织、哪些标记值得留意,可以顺带看看节点该怎么选。

小结#

换网络才失效意味着变量已经被锁定在网络这一层,剩下的工作是分辨它属于运营商路径、链路特性还是网关规则。对照实验要一次只动一个变量,并且以固定节点为基准,顺序是先换网络、再换协议、最后换地区。能握手却传不动数据是 MTU 的典型指纹,把它调到 1400 附近往往立刻见效。端口和协议被针对时换节点没有意义,因为所有节点在这个网络里的特征是一样的;真正有效的是换协议、换端口或换入口。只有在两个以上完全不同的网络下都复现,才值得把怀疑对象转向服务方。