延迟 60ms，节点显示正常，客户端连接绿灯——但浏览器就是打不开网页。这个组合让很多人第一反应是”节点坏了”，然后开始一个个换节点，换了半天也没解决。
问题在于，延迟低只能说明一件事：你和节点之间的握手是通的。 它不能说明后面的环节是否正常。
一次网页访问要经过哪些环节
从你按下回车到页面显示，大致要过这几关：
- 域名解析：把网址变成 IP 地址；
- 分流判断：客户端决定这个请求走代理还是直连；
- 本地到节点：数据发到节点（延迟测的就是这一段）；
- 节点到目标服务器：节点代你去访问目标；
- 返回：数据原路返回并渲染。
延迟测试只覆盖第 3 步。第 1、2、4 步任何一个出问题，都会表现为”连着但打不开”。
成因一：分流规则不匹配（最常见）
现代客户端普遍使用分流规则：国内域名直连，其余走代理。规则本身是一份域名清单，不可能覆盖所有情况。
当某个域名没有被规则正确归类时，它可能被当作国内域名直连，结果自然打不开。
怎么判断
把客户端的模式临时切换到全局，然后重试。
- 全局模式下能打开 → 确认是分流规则的问题。
- 全局模式下仍然打不开 → 排除这一项，继续往下看。
怎么处理
- 更新订阅，规则通常会随配置一起更新；
- 在客户端里为该域名手动添加一条走代理的规则；
- 如果你要长期保留自定义规则，使用客户端的覆写 / 扩展脚本功能，不要直接改订阅生成的配置文件（更新时会被覆盖）。
成因二：DNS 解析异常
域名解析发生在实际连接之前。如果解析出的地址不对，后面所有步骤都建立在错误的基础上。
典型情况是 DNS 泄漏：本该由代理侧完成的解析，实际上用了本地网络的 DNS，得到的地址不适合从该节点访问。
怎么判断
- 用 IP 直接访问：IP 能通、域名不通 → 基本确认是解析问题。
- 命令行执行
nslookup 域名，看返回结果是否合理。
怎么处理
在客户端设置里开启 远程解析 / 防止 DNS 泄漏 / fake-ip 之类的选项，让解析在代理侧完成。改完之后清理系统 DNS 缓存并重启客户端。
完整说明见 DNS 问题排查。
成因三：节点出口受限
节点本身能连上（所以延迟正常），但它到目标服务器这一段不通，或者目标服务不接受来自该出口地址的访问。
怎么判断
换一个不同地区的节点测试同一个网址。如果换节点后正常，就是出口的问题。
怎么处理
固定使用表现正常的节点。选择依据见如何选择节点地区。
如果是流媒体平台提示地区不符，还需要清理该站点的缓存和 Cookie，见流媒体节点选择。
成因四：浏览器缓存
浏览器会缓存 DNS 结果、站点的地区判断结果、以及各类 Cookie。换了节点之后，这些旧数据可能还在生效。
怎么判断
用隐私 / 无痕窗口访问同一个网址。如果隐私窗口正常，就是缓存问题。
怎么处理
- 清理该站点的缓存与 Cookie；
- Chrome 类浏览器可以访问
chrome://net-internals/#dns清理内部 DNS 缓存； - 换一个浏览器交叉验证。
成因五：客户端配置问题
几种具体情况：
系统代理没有真正生效。 Windows 和 macOS 上，客户端连接成功不等于系统代理已开启。检查客户端的”设置为系统代理”开关。
应用不读系统代理。 部分软件（游戏客户端、命令行工具、某些下载器）不使用系统代理设置。解决方式是开启客户端的 TUN / 增强模式，或在该软件自己的设置里手动填写代理。
端口冲突。 本地监听端口被其他程序占用，导致部分请求失败。换一个端口试试。
配置未被选中。 Clash 类客户端需要显式选中配置文件，见 Clash 没有节点的排查。
快速排查顺序
按这个顺序试，通常几分钟就能定位：
- 切到全局模式 → 排除分流规则
- 换一个节点 → 排除节点出口
- 用隐私窗口 → 排除浏览器缓存
- 开启远程解析 + 清 DNS 缓存 → 排除解析问题
- 换一个客户端 → 排除客户端配置
每一步只改一个变量，不要几件事一起做，否则即使好了也不知道是哪一步起了作用。
一个反直觉的结论
延迟数字对判断”能不能用”的帮助其实很有限。它只反映握手速度，而”打不开网页”的原因大多分布在解析、规则和出口这几个环节上。
同样地，延迟低也不代表速度快——看视频、下载文件更依赖持续带宽。这两者的区别见测速应该关注哪些指标。