代理已连接但打不开网页?DNS、路由规则与系统代理逐项排查清单

客户端显示“已连接”、延迟测试出现数字，并不等于浏览器流量已经完整通过代理链路。一次网页访问至少会经过域名解析、路由匹配、入站监听、出站连接和系统应用接管几个环节。任意一环配置错误，都可能出现客户端看似正常、网页却持续加载或直接报错的情况。

排查时不要同时修改节点、DNS、路由和系统设置。一次改动多个变量，即使网络恢复，也很难确认真正原因。更稳妥的顺序是先验证节点本身，再检查 DNS，随后缩减路由规则，最后确认系统代理或 VPN 接管状态。每完成一步都使用同一个测试网页复测，并记录结果。

先确认“已连接”到底表示什么

v2rayN、v2rayNG 或 v2flyNG 中出现运行状态，通常只能说明本地核心已经启动，或者本地代理入口已经建立。它不能单独证明远端节点可达，也不能证明浏览器正在使用该入口。延迟测试同样有局限：部分测试只测量到服务器的连接时间，实际网页请求还会受到协议握手、域名解析、路由规则和远端出口状态影响。

先把现象分成下面几类。不同现象对应的检查重点不同：

第一步：检查节点是否真正可用

节点是整条链路的上游。节点失效时，反复调整本机 DNS 或路由通常没有作用。最有效的验证方式不是只看延迟，而是使用同一客户端切换到另一个已知可用节点，再执行真实网页访问。如果新节点立即恢复，问题大概率集中在原节点或其参数。

逐项核对节点信息

1. 检查地址和端口。确认服务器地址没有多余空格，端口是有效数字，并且导入后没有被手动改错。
2. 检查协议类型。VMess 与 VLESS 是不同协议，不能只保留地址和端口后互换。客户端中显示的协议必须与节点原始配置一致。
3. 检查用户标识。UUID、用户 ID 等认证字段必须完整。复制过程中缺少字符，会导致握手失败。
4. 检查传输参数。TCP、WebSocket、gRPC 等传输方式，以及 Host、路径、serviceName 等字段，需要与服务端配置匹配。
5. 检查安全参数。启用 TLS 或 REALITY 的 VLESS 节点需要正确的服务器名称、公钥、短标识等参数。参数缺失时，本地核心可能仍能启动，但远端握手无法完成。
6. 检查设备时间。系统日期、时间和时区明显错误时，证书验证和部分协议认证可能失败。先启用系统自动校时，再重新连接。

如果节点来自订阅，先更新一次订阅，再确认当前选中的节点仍存在。订阅地址返回空内容、节点被移除或旧配置长期未更新，都可能让客户端继续保留一条已经失效的记录。更新后不要只看节点数量，应重新选中节点并执行一次真实连接测试。

第二步：判断是否为 DNS 解析故障

浏览器访问域名时，必须先把域名解析为地址。DNS 查询失败时，代理核心可能处于运行状态，但网页会显示“找不到服务器”“无法解析地址”或长时间停留在连接阶段。若只有域名访问失败，而已经建立的连接或直接使用地址的服务仍有响应，DNS 应作为首要检查项。

先做最小化判断

• 观察错误信息中是否出现域名解析、名称解析或 DNS 相关提示。
• 切换到另一个节点后复测。如果所有节点都出现相同的域名错误，本机 DNS 配置更值得怀疑。
• 暂时恢复客户端默认 DNS 配置，停用自行添加的复杂分流解析规则。
• 确认 DNS 查询使用的出口可达。指定代理查询时，代理节点必须先能连接；指定直连查询时，本地网络必须允许访问该解析服务。

DNS 与路由存在先后依赖。路由规则如果按 IP 匹配，核心可能需要先解析域名；但 DNS 查询本身又需要选择直连或代理出口。配置中同时存在多套 DNS、域名分流和地址分流时，很容易形成“解析结果决定路由，路由又影响解析”的复杂链条。故障排查阶段应先减少策略数量，确认基础解析可用后，再逐项恢复。

缓存也是常见干扰。客户端更换 DNS 后，浏览器、操作系统和代理核心可能仍持有旧解析结果。修改设置后应完全关闭再启动客户端，并重新打开浏览器。仅刷新网页未必会触发新的 DNS 查询。

DNS 结果正常仍打不开怎么办

解析成功只说明获得了地址，不代表该地址一定能通过当前出口访问。某个域名可能返回多个 IPv4 或 IPv6 地址，而本地网络、节点出口或路由规则只对其中一部分有效。若日志显示解析完成，但随后连接超时，可以暂时使用更简单的地址策略或关闭自定义的 IPv6 优先设置进行对照测试。确认问题后，再根据实际网络能力选择地址族策略。

第三步：排除路由规则误拦与走错出口

路由规则负责决定一条连接走代理、直连还是拦截。规则通常从上到下匹配，命中后不再继续检查后续规则。一个范围过大的直连规则放在前面，可能让本应走代理的网站直接连接；一个范围过大的拦截规则，则会让请求在本机被终止。

使用“全局代理”做对照测试

在节点已经确认可用的前提下，可以短时间切换到全局代理模式。如果全局模式能打开网页，而规则模式不能，问题基本位于路由配置。此时不需要继续改节点参数，应集中检查规则顺序、匹配范围与出站标签。

检查路由时重点查看以下项目：

1. 兜底出口是否存在。未命中任何规则的流量需要有明确的默认出口，不能指向不存在的出站标签。
2. 规则顺序是否合理。精确域名和小范围规则通常放在宽泛规则之前，避免提前命中。
3. 域名与地址条件是否混用。按地址匹配可能触发 DNS 解析，解析策略会影响最终结果。
4. 拦截范围是否过大。测试期间暂时停用最近添加的拦截项，逐条恢复并复测。
5. 直连规则是否覆盖目标。若目标域名或解析地址被划入直连范围，网页可能绕过代理并连接失败。
6. 出站标签是否一致。规则里的 outboundTag 必须与实际出站配置中的标签完全对应。

排查用决策顺序：
1. 节点真实访问是否成功
2. 全局代理是否成功
3. 规则模式是否失败
4. 查看目标域名命中的规则
5. 确认该规则指向 proxy、direct 还是 block
6. 调整一条规则后立即复测

不要在故障期间一次导入多份规则集。规则来源不同，可能包含相互覆盖的域名与地址范围。先使用客户端默认规则完成验证，再添加一份自定义规则并测试。通过这种增量方式，可以准确定位是哪条规则改变了出口。

第四步：确认系统代理或 VPN 接管已经生效

代理核心启动后，应用流量还需要进入它的本地入站端口。桌面端通常通过系统代理、应用内代理或其他接管方式完成；安卓端的 v2rayNG 与 v2flyNG 通常通过 VPN 模式接管设备流量。本地核心运行与流量接管是两个独立状态，不能只看启动按钮。

v2rayN 桌面端检查

• 确认已选择当前要使用的节点，而不是只启动了客户端窗口。
• 确认系统代理模式已经开启，并检查操作系统代理设置中是否出现对应的本地地址和端口。
• 若浏览器手动填写过代理，先改回“使用系统代理”或清除旧端口，避免浏览器继续连接已经失效的本地端口。
• 检查其他代理程序是否占用了相同端口。端口冲突时，核心日志通常会出现监听失败或地址已被占用。
• 退出客户端后确认系统代理被正确恢复，再重新启动。异常退出可能留下旧代理地址，导致所有请求继续发往不存在的端口。

v2rayNG 与 v2flyNG 安卓端检查

• 启动连接后确认系统状态区存在 VPN 连接状态，并允许客户端建立 VPN。
• 查看分应用代理设置。目标浏览器或应用如果被排除，其流量不会进入代理。
• 暂时关闭省电限制或后台活动限制进行测试，避免系统在锁屏或切换应用后停止核心进程。
• 若设备同时存在其他 VPN 连接，先断开其他连接再测试。系统通常不会让两条 VPN 接管链路同时正常工作。
• 从一个网络切换到另一个网络后，主动断开并重新连接，让核心重新建立底层连接。

“浏览器能上网，但某个软件不能”通常不是节点整体失效。部分软件不读取系统代理，部分应用有自己的代理设置，还有一些连接使用 UDP。此时应先确认该应用是否被接管、是否允许 UDP，以及路由中是否对其目标地址设置了不同出口。

第五步：从日志定位失败发生在哪一层

前四步仍未定位时，应打开客户端日志，并在清空旧日志后重新访问一次测试网页。这样可以减少历史记录干扰。关注请求发生时新增的几行，而不是只看核心启动阶段的信息。

日志中“没有请求”本身就是重要结果。若访问网页时日志没有新增任何入站记录，说明问题发生在核心之前，应回到系统代理或 VPN 接管检查。若能看到入站请求，但没有成功出站，则继续判断是 DNS、路由还是节点握手失败。通过“请求有没有进入”和“出站在哪一步停止”两个问题，可以快速缩小范围。

最终排查清单：按顺序逐项勾选

1. 确认普通网络连接本身可用，设备能访问本地网络允许的页面。
2. 同步系统日期、时间与时区。
3. 更新订阅，重新选择节点，不沿用已移除的旧记录。
4. 切换至少一个已知可用节点，使用真实网页访问验证。
5. 核对 VMess 或 VLESS 协议、地址、端口、UUID、传输与安全参数。
6. 恢复客户端默认 DNS，重启客户端与浏览器后复测。
7. 暂时切换全局代理。全局可用时，集中检查路由规则。
8. 检查规则顺序、直连范围、拦截范围和出站标签。
9. 桌面端确认系统代理地址与本地监听端口一致。
10. 安卓端确认 VPN 已建立，目标应用未被分应用规则排除。
11. 检查是否存在本地端口冲突或另一条 VPN 连接。
12. 清空日志后重现一次问题，根据新日志定位失败层级。

完成排查后，应把临时切换的全局模式恢复为日常需要的路由模式，并逐项恢复自定义 DNS、规则集和分应用设置。每恢复一项都执行一次访问测试。这样既能保留原有分流需求，也能明确哪项配置会重新触发故障。

如果重新导入节点后仍持续出现认证或握手错误，而其他节点正常，通常需要更新该节点的完整参数；如果所有节点在同一网络下均超时，但更换网络后恢复，则应检查当前网络对目标地址、端口或协议流量的限制。把问题固定到“单个节点”“单台设备”或“单个网络”之一，后续处理会更直接。