节点有延迟但网页打不开是什么原因

“延迟 45ms” 和”网页无法访问”同时出现在一台设备上，看起来自相矛盾，实际上却是排查求助中出现频率很高的一类问题。矛盾的根源在于：延迟测试通过所证明的东西，比大多数人以为的要少得多。理解延迟测试到底测了什么，是解决这类问题的起点。

延迟测试到底验证了什么

多数客户端的延迟测试，是经节点向一个固定测试地址（常见为返回 204 状态码的检测页）发起一次轻量 HTTP 请求并计时。它验证的只是”客户端 → 节点 → 测试地址”这一条具体链路，而且只需要一次成功的 TCP 握手加一个极小的响应就能得出数值。因此延迟通过只能说明这一小段链路此刻可用，既不代表节点访问其他网站也畅通，也不代表带宽、稳定性和域名解析都正常。延迟这个指标的准确含义，以及它与抖动、丢包、带宽的关系，可参见延迟、抖动、丢包与带宽分别说明什么。

可能原因（按概率排序）

1. 出口 IP 被目标网站限制：不少网站会对数据中心 IP 或被大量用户共享的出口 IP 返回人机验证、拒绝访问或直接不响应。典型表现是个别网站打不开、其余网站正常。
2. DNS 解析问题：目标域名被解析到错误的地址，或解析请求被污染、被劫持，连接从一开始就建立在错误的目标上。
3. 分流规则把目标域名走了直连：规则模式下，未被规则集覆盖的域名可能按兜底规则直连，而该网站直连本来就无法访问。
4. 系统代理未生效：浏览器根本没有把流量交给客户端。延迟测试是客户端自己发起的，不依赖系统代理，所以数值照常显示正常，具有很强的迷惑性。
5. 节点只测通了握手但实际转发失败：服务端配置异常，或线路对真实网页流量的转发存在问题时，会出现小请求能过、正常浏览过不去的情况。
6. UDP 需求未满足：部分应用和启用 QUIC/HTTP3 的站点依赖 UDP 转发，节点或协议不支持时会出现异常。浏览器大多会自动回退到 TCP，但个别场景仍会失败，两种传输方式的差异见 TCP 与 UDP 在代理中的区别。

按顺序排查

第一步：换节点

换两三个不同地区的节点访问同一个网页。换节点后恢复正常，基本可以断定是原节点的出口 IP 被目标网站限制，或该节点转发异常，弃用即可；如果换到哪个节点都一样，继续下一步。

第二步：切换全局模式

把客户端从规则模式切换到全局模式，再访问一次。全局模式下恢复正常，说明问题出在分流规则上——目标域名被规则送去了直连或错误的出站。规则模式与全局模式的行为差异，见代理运行模式的区别。

第三步：检查规则命中

切回规则模式，打开 Clash Verge Rev 的”连接”页面，刷新打不开的网页，在列表中找到对应域名的连接记录，查看它命中的规则名称与实际走的出站。显示 DIRECT 时，在配置中为该域名补充代理规则，或更新订阅自带的规则集。

第四步：检查 DNS

同样在连接页面查看目标域名解析到的 IP 是否明显异常，例如保留地址、或与网站实际所在地区完全不符的地址。可在客户端 DNS 设置中启用加密 DNS 或更换上游后重试。各类 DNS 层故障的识别与处理，详见 DNS 污染、泄漏与劫持的区别。

第五步：确认系统代理

在 Windows 的”设置 → 网络和 Internet → 代理”中确认手动代理指向客户端监听端口且已开启；再回到客户端确认”系统代理”开关处于打开状态。部分下载工具或其他代理软件会覆盖系统代理设置，关闭它们后重新打开开关。浏览器若装有代理类扩展，也要检查扩展是否把流量指向了别处。判断流量是否真的经过客户端，最直接的方法仍是刷新网页时观察连接页面有无新增记录。

区分网络侧与客户端侧

这类问题的分界线在于：流量有没有正常交给客户端并经过节点、节点有没有把流量正常送达目标。系统代理、分流规则、DNS 设置属于客户端侧，自己动手就能修好；出口 IP 被限制、节点转发异常、UDP 不支持属于网络侧或服务侧，个人能做的只有换节点或向服务方反馈。为了让每次判断都有可对比的基准，建议建立一套固定的对照测试习惯，具体做法参考可复现的节点测试流程。

什么时候应该联系服务方

如果在多台设备、多个网络下，所有节点访问大量常见网站都失败，而延迟测试始终正常，多半是服务端配置或线路转发出现了整体性问题，应当向服务方反馈并附上测试记录。若只是某一个网站对所有节点都拒绝访问，可以询问服务方是否提供适合该网站的出口（例如原生 IP 节点），但需要理解：目标网站侧的限制本身并不在服务方的控制范围内，这类问题未必有彻底的解决方案。