机场连上了打不开网页,问题多半出在分流而非节点

这是所有连接故障里最容易让人抓狂的一种,因为它同时给出了两个互相矛盾的信号:客户端那边一切正常,节点是绿的、延迟是两位数、测速能跑出速度;浏览器这边什么都没有,标签页转到超时,连报错文本都懒得给一个。

矛盾其实是假的。延迟测试和网页访问走的根本不是同一条路径——前者验证的是你的设备能不能和节点完成握手,后者验证的是一个具体请求能不能被正确地送到节点、再从节点送到目标网站。中间隔着分流判定、系统代理接管、网卡路由、域名解析好几个环节,任何一个环节把请求送错方向,握手照样成功,网页照样打不开。

所以这类问题的排查方向和「全部节点超时」完全相反:不要换节点,换多少个都一样。要检查的是流量在你自己设备里走的那一段。

节点是绿的、网页是白的,这个矛盾说明了什么?#

把一个网页请求的完整旅程拆开,大致经过五道关卡:

1. 应用发出请求,交给系统的网络栈。
2. 客户端拦截这个请求,按分流规则判定它该直连还是走代理。
3. 判定为代理的请求被发往本地监听端口,再由客户端转发到节点。
4. 域名在某处被解析成 IP,解析结果决定最终连去哪台服务器。
5. 节点把请求发出,拿到响应原路返回。

延迟测试只覆盖了第三步到第五步的一小段,而且用的是客户端内置的探测地址。真实网页请求要走完全部五步。故障出在第二步或第四步,延迟测试根本感知不到——这就是矛盾信号的来源。

分流规则的三种模式,分别在什么时候用?#

分流规则决定每一个请求走代理还是直连,它是这类故障里命中率最高的一层。主流客户端一般提供三种模式:

诊断方法很简单:临时切到全局模式试一次。切过去网页就能打开,说明节点没问题、系统代理也在工作,错的是规则集——某条规则把目标域名判成了直连。切过去依然打不开,说明问题在更下层,继续往后看。

规则集出错的常见原因是它很久没更新了。规则集本身是一份不断维护的域名清单,长期不刷新会导致新出现的域名落进错误的分类。多数客户端提供手动更新规则集的入口,更新一次的代价远低于逐条改规则。

全局模式只用于诊断,不建议长期开着。国内流量绕出境外再回来,路径变长、延迟变高,还会白白消耗套餐流量。

浏览器能用但其他软件不走代理,是哪一层没配好?#

这个现象非常有辨识度,它几乎可以直接定位到系统代理没有全局生效。

客户端接管流量有两种方式。一种是设置系统代理,由操作系统告诉各个应用「请求发到这个本地端口」——但这依赖应用自觉遵守系统设置,浏览器普遍遵守,很多桌面软件和命令行工具并不遵守。另一种是 TUN 模式,通过虚拟网卡在更底层接管,对应用无差别生效。

所以只有浏览器能用时,先确认系统代理开关的状态:

netsh winhttp show proxy

如果显示为直接访问,说明系统层面并没有设置代理,浏览器能用只是因为它读了另一套配置。macOS 可以在系统设置的网络代理面板里看到对应的开关状态。

想让所有应用都走代理,要么开启 TUN 模式,要么在那个具体应用里单独填写代理地址。两种做法都可行,但 TUN 有它自己的坑,下一节说。

TUN 模式开了反而断网,虚拟网卡冲突怎么确认?#

TUN 模式会创建一块虚拟网卡,把系统的路由表改写成让流量优先经过它。这个动作层级很低,好处是无差别接管所有应用,坏处是一旦和别的东西抢网络栈,结果不是部分失效,而是整台机器断网。

确认方法按顺序做,每步只改一件事:

1. 关掉 TUN,看是否恢复。恢复了,问题就锁定在这一层;没恢复,和 TUN 无关,回头查前面几层。
2. 确认客户端是否以管理员权限运行。创建虚拟网卡和改写路由表需要提权,权限不足时网卡可能建到一半,表现为连接建立但流量不通。
3. 排查其他占用网络栈的程序。其他代理工具、部分企业安全客户端、某些虚拟机的网络组件都可能和 TUN 抢路由。逐个退出,每退一个测一次。
4. 检查虚拟网卡是否残留。异常退出后,旧的虚拟网卡可能还留在系统里并保留着路由条目,重启客户端不一定清得掉。

Get-NetAdapter | Where-Object { $_.InterfaceDescription -like "*TAP*" -or $_.InterfaceDescription -like "*TUN*" }

看到已断开却仍存在的适配器,禁用后重新启用客户端,通常能让路由表回到干净状态。

DNS 在哪里解析,决定了你会不会拿到被污染的结果#

DNS 是把域名翻译成 IP 地址的服务。这一层的问题最隐蔽,因为它不产生任何报错——你拿到了一个 IP,只是这个 IP 是错的。

关键在于解析发生在哪一端。如果域名在你本地解析,用的是运营商提供的 DNS,那么返回的可能是被污染的地址,即使后面的流量确实走了节点,连过去的也是一个错误目的地。如果解析交给节点那一端完成,拿到的就是干净结果。

快速验证的方法是对照两个解析结果:

nslookup www.google.com 8.8.8.8

本地默认解析和指定公共 DNS 解析出的地址差异巨大,尤其是解析出明显不合理的地址时,基本可以确认本地解析不可信。多数客户端在设置里提供了 DNS 相关选项,把远程域名的解析交给代理端处理,是这一层的标准做法。

有一个容易混淆的点:DNS 问题常常表现为「部分网站能开、部分打不开」,而不是全部失效。看到这种选择性失败,优先怀疑解析而不是节点。

为什么国内网站在开启代理后反而打不开?#

这个现象几乎可以断定是分流方向反了。正常规则下国内域名应当直连,如果它们也被送进代理通道,请求要先出境、再从境外访问国内服务器,路径长了好几倍。有些国内服务还会因为来源 IP 在境外而直接拒绝或触发验证。

三种常见成因:

• 当前处于全局模式,而你忘了切回来。
• 规则集损坏或未加载,客户端退化成了默认全部代理。
• 手动加过自定义规则,把某个通配范围写得太宽。

对应的处理是切回规则模式、手动更新规则集、检查自定义规则条目。这三步都属于可逆操作,试错成本很低。

退出客户端后整台机器没网,残留代理怎么清理?#

客户端崩溃或被强制结束进程时,来不及把系统代理设置改回去。结果是客户端已经不在了,系统还在忠实地把所有请求发往那个已经没人监听的本地端口——表现为整机断网,而且和代理软件看起来毫无关系。

处理方式是手动关闭系统代理:

netsh winhttp reset proxy

Windows 还需要在系统设置的代理面板里把「使用代理服务器」关掉,两处是独立的。macOS 在网络偏好设置对应网络的代理标签页里逐项取消勾选。

排查断网时,如果你刚刚强退过任何代理程序,先检查残留代理设置,再去怀疑网卡、路由器或宽带。这一步只要几秒钟。

四项检查按什么顺序做最省事?#

按改动代价从小到大排,不要一上来就改 DNS 或重装客户端。

前两项都是一个开关的事,合起来不到一分钟,却能覆盖大部分情况。第三、四项需要动系统层面的设置,放在后面。

四项全部通过、现象依旧,才需要把怀疑对象移出这台设备:换一个网络试、换一台设备试。两处都复现,才轮到联系商家。这套按症状分层的思路在排查总览里有完整版本;而各款客户端的开关名称与位置差别很大,具体到界面的核对步骤在客户端教程栏目。

小结#

能测速却打不开网页,是握手成功而流量走错路,换节点没有意义。诊断顺序是分流规则、系统代理、TUN 接管、DNS 落点四层,前两层各只需要拨一个开关,建议优先做。只有浏览器能用,指向系统代理未全局生效;国内网站变慢或打不开,指向分流方向反了;部分网站能开部分不能,优先怀疑域名解析。客户端被强退后整机断网,先清理残留的系统代理设置。四层都排除干净仍然复现,才需要把怀疑范围扩大到网络环境或服务端。