本文适用于 v2rayN 显示“已启动”、v2rayNG 显示“已连接”，但浏览器仍然超时、部分网站无法打开或所有应用都无法联网的情况。排查从本机代理入口开始，依次检查节点握手、路由分流和 DNS，不需要反复删除订阅；完成十二项检查后，可以把故障收敛到客户端、节点参数、规则或解析链路中的具体一层。
先确认故障发生在哪一层
客户端显示已连接，只能说明界面已经向内核提交启动命令，不能证明浏览器流量进入了代理，也不能证明远端节点完成握手。一个完整请求至少要经过应用、系统代理或 TUN、路由判断、代理出站和 DNS 解析。任一环节失败，外观上都可能只是“网页一直转圈”。
开始前先固定测试条件：关闭正在下载的任务，只保留一个浏览器窗口，选择一个已知可访问的普通 HTTPS 网站测试。不要同时切换节点、路由模式和 DNS；一次只改一个变量，改动后重新加载同一页面并记录结果。
判断范围时可以做两个对照。第一组是在关闭系统代理后访问本地网络，再开启系统代理访问同一地址；第二组是在原节点与另一个确认可用的节点之间切换。如果所有节点都失败，更可能是本地入口、路由或 DNS；如果只有一个节点失败，应优先核对该节点状态和配置字段。
第一层：本地设置的三项检查
本地层负责把应用流量送进内核。这里最常见的问题是系统代理没有启用、监听端口被其他程序占用，或者浏览器保留了独立代理设置。以 v2rayN 7.x 为例，客户端启动后应同时确认内核状态和系统代理状态，而不是只看任务栏图标。
-
第 1 项：检查系统代理是否真正启用。
在 v2rayN 主窗口确认系统代理模式不是“清除系统代理”。随后进入 Windows 的“设置”→“网络和 Internet”→“代理”，检查手动代理是否指向本机地址。常见监听地址为
127.0.0.1，端口应以 v2rayN 当前日志或“设置”→“参数设置”中的本地端口为准。旧配置常见 SOCKS 端口为10808、HTTP 端口为10809，升级或迁移配置后不能假定端口保持不变。 -
第 2 项：确认内核正在监听对应端口。
Windows 可在 PowerShell 中测试本机端口。若结果中的
TcpTestSucceeded为False，说明浏览器即使写入了代理地址，也没有可接收连接的本地进程。先完全退出 v2rayN，再重新启动；仍失败时检查日志中的端口占用信息，并在“设置”→“参数设置”中换用未占用端口。 -
第 3 项：排除应用自己的代理覆盖。
某些浏览器或开发工具可以使用独立代理地址。若系统代理为
127.0.0.1:10809，应用却仍指向已经停用的127.0.0.1:7890，请求不会进入当前内核。把应用代理改为“使用系统代理”，重启应用后再测；命令行工具还应检查环境变量中是否残留旧的 HTTP 或 SOCKS 代理值。
Test-NetConnection 127.0.0.1 -Port 10808
Test-NetConnection 127.0.0.1 -Port 10809报错:failed to listen TCP on 127.0.0.1:10808
原因与解法:本地端口已被其他进程占用——退出旧内核进程，或在“设置”→“参数设置”中更换本地监听端口后重启。
报错:connectex: No connection could be made because the target machine actively refused it
原因与解法:应用连接的本地端口没有服务监听——核对系统代理端口与核心日志中的 inbound 端口是否一致。
安卓端使用 v2rayNG 或 v2flyNG 时，本地入口由系统 VPN 接口接管。若点击连接后状态很快回到未连接，先停止其他正在占用系统 VPN 接口的网络工具，再重新授权连接。若状态保持连接但只有个别应用失败，应检查该应用是否被加入“分应用代理”的绕过列表。
结论：本地端口失败时不要先换节点
连接 127.0.0.1 都失败，流量尚未到达远端节点；继续更新订阅或修改 VMess、VLESS 参数不会修复本地监听问题。
第二层：节点状态与握手参数的三项检查
本地端口正常后，下一步判断节点能否建立 TCP、TLS 或其他传输层连接。延迟测试不是最终可用性证明，但可以快速区分“地址完全不可达”和“握手后请求失败”。测试时应同时查看测试类型：仅有 ICMP 延迟、TCP 延迟或真实连接延迟中的一种结果，不能代替完整网页请求。
- 第 4 项：测试节点地址与端口的连通性。 在 v2rayN 节点列表中选择当前节点，执行真实连接延迟测试。正常家庭网络中，测试值可能为几十到数百毫秒；连续三次显示超时，且日志停在连接服务器阶段，应核对服务器域名和端口。可把超时阈值暂时设为 5000 毫秒再测，避免把高延迟误判为完全不可达。
- 第 5 项：校准系统时间并检查 TLS 握手。 TLS 证书验证依赖设备时间。系统时间偏差数分钟就可能造成证书尚未生效或已过期的判断。Windows 进入“设置”→“时间和语言”→“日期和时间”，开启自动设置时间并立即同步；安卓设备进入系统日期与时间设置，启用网络提供的时间。同步后完全停止内核，再重新连接。
- 第 6 项：逐字段核对节点配置。 VMess 重点检查地址、端口、用户 ID、传输方式、TLS 与路径；VLESS 还需核对 flow、安全类型、服务器名称和 Reality 相关公钥参数是否由节点配置提供。WebSocket 路径中的斜杠、gRPC serviceName 的大小写、TLS 服务器名称都必须精确一致。不要根据协议名称自行补字段，应以服务端实际配置或最新订阅内容为准。
| 观察结果 | 更可能的原因 | 下一步动作 |
|---|---|---|
| 所有节点均超时 | 本地网络限制、DNS 或客户端入口异常 | 换网络对照，并继续检查 DNS 层 |
| 只有单个节点超时 | 节点地址、端口或服务状态异常 | 更新订阅并核对该节点字段 |
| TCP 可达但 TLS 失败 | 时间、SNI 或证书链问题 | 同步时间并核对服务器名称 |
| 延迟正常但网页返回空白 | 路由、DNS 或目标站点响应异常 | 查看域名匹配与 DNS 日志 |
报错:context deadline exceeded
原因与解法:连接或握手在设定时间内未完成——先测试节点地址与端口，换网络对照；只有该节点失败时更新订阅或联系配置提供方确认服务状态。
报错:remote error: tls: handshake failure
原因与解法:TLS 参数与服务端不一致——同步系统时间，核对 TLS 开关、服务器名称和传输层参数。
报错:failed to find an available destination
原因与解法:出站服务器地址无法解析或没有可用目标——检查节点地址拼写，更换可用 DNS 后重启内核。
第三层：路由分流的三项检查
节点握手成功而网页仍打不开时，路由规则是重点。V2Ray 与 Xray 内核会根据域名、IP、端口、网络类型和入站标签选择出站。某条规则若把目标误送到直连或阻断出站，界面仍会显示连接正常，因为节点本身没有掉线。
- 第 7 项：切换到最简单的代理模式做对照。 暂时将路由切换为全部经代理的测试模式，重新打开失败网站。若立刻恢复，说明节点和本地入口正常，问题集中在分流规则。测试结束后再恢复原模式，逐条检查命中规则，不要长期依赖对照模式掩盖规则错误。
-
第 8 项：检查 GeoIP 与 GeoSite 数据是否缺失或过旧。
自定义规则常引用
geoip:cn、geosite:cn或其他分类集合。数据文件缺失时，核心可能提示规则加载失败；数据长期未更新时，新域名可能落入兜底规则。v2rayN 可在主界面的检查更新功能中更新 Geo 文件，完成后重启内核并确认日志没有资源加载错误。安卓端应使用客户端提供的数据更新入口，更新后重新连接。 - 第 9 项：检查域名嗅探与规则优先级。 浏览器请求如果先解析成 IP，而规则只按域名匹配，目标可能绕过预期出站。开启域名嗅探后，内核可从 HTTP Host 或 TLS Server Name 中恢复域名用于路由，但某些局域网服务不适合嗅探。先确认失败网站在日志中显示的是域名还是 IP，再调整嗅探设置。自定义规则通常按从上到下匹配，宽泛的直连规则不应放在更具体的代理规则之前。
域名规则：domain:example.com
后缀规则：domainSuffix:example.com
完整匹配：full:service.example.com
端口范围：80,443
兜底动作：proxy / direct / block只有某一个网站打不开，节点需要更换吗?
先在核心日志中搜索该域名，确认它被送往 proxy、direct 还是 block。其他网站正常时，优先修正规则命中或 DNS 结果，不要直接删除整个订阅。
切到全局代理后恢复，应该怎么修?
恢复原分流模式，把失败域名加入明确的代理规则，并放在宽泛直连规则之前。重启内核后再次确认日志中的最终出站标签。
更新 Geo 数据后仍然命中旧规则?
完全停止并重新启动内核，确认日志加载的是新文件路径。若客户端保留多套配置，还要检查当前启用的路由方案是否就是刚才修改的方案。
局域网地址被代理后无法访问?
为私有地址段和本地域名添加高优先级直连规则，并检查域名嗅探是否把局域网请求改写成了外部域名。
结论：全局可用、分流失败就是明确证据
同一节点、同一网络下，仅切换路由模式就恢复访问，说明无需改协议参数；应把时间集中在规则顺序、Geo 数据和最终出站标签上。
第四层：DNS 解析的三项检查
DNS 故障经常表现为节点有延迟、IP 地址可以连接，但域名网页打不开。还可能出现首页能打开、图片与登录接口超时，因为不同子域名返回了不同地址。排查时要区分“节点服务器域名解析”和“访问目标域名解析”：前者失败会阻止节点建立连接，后者失败则发生在节点已经连接之后。
- 第 10 项：确认 DNS 服务器本身可达。 若配置使用只能通过代理访问的解析服务，却把 DNS 查询路由到直连，查询会持续超时。反过来，本地域名若全部送到远端解析，也可能得到不适合当前网络的地址。先临时使用系统 DNS 做对照；恢复后再分别设置本地查询与代理查询的出站路径，并观察日志中查询耗时。普通查询通常应在数十到数百毫秒内返回，连续超过 2000 毫秒应视为异常。
- 第 11 项：清理缓存并核对 FakeDNS 使用范围。 浏览器、系统和内核可能各自缓存解析结果。修改 DNS 后若不重启相关进程，测试仍可能使用旧地址。Windows 可关闭浏览器后执行系统 DNS 缓存清理，再重启 v2rayN。使用 TUN 与 FakeDNS 时，应确认虚拟地址池只在对应流量链路中使用；如果应用拿到虚拟地址却绕过 TUN 直连，连接必然失败。
- 第 12 项：检查 IPv4 与 IPv6 返回结果。 某些网络能解析 AAAA 记录，却没有稳定的 IPv6 出口，浏览器会先尝试不可达地址并等待超时。日志若显示目标优先连接 IPv6，且每次都在数秒后回退到 IPv4，可暂时把域名策略调整为优先 IPv4 做对照。确认问题后再修复本地 IPv6 网络或保留适合当前环境的查询策略，不应把所有解析问题都归因于节点。
| 测试现象 | 判断依据 | 修复方向 |
|---|---|---|
| IP 可访问，域名失败 | 目标地址解析链路异常 | 检查 DNS 服务器与查询出站 |
| 节点域名无法解析 | 代理尚未建立前即失败 | 为节点地址配置可直达的引导 DNS |
| 部分子域名超时 | 缓存或分流结果不一致 | 清缓存并逐个查看域名命中 |
| 先等数秒再恢复 | IPv6 失败后回退 IPv4 | 对照测试 IPv4 优先策略 |
报错:failed to lookup ip for domain
原因与解法:目标域名未获得可用地址——检查 DNS 服务器可达性、查询出站和域名策略，清理缓存后重新测试。
报错:server misbehaving
原因与解法:上游 DNS 返回异常或响应格式无法使用——换用当前网络可达的解析服务器，并确认查询没有被错误路由到阻断出站。
报错:network is unreachable
原因与解法:解析结果指向当前设备没有可用路由的地址族——检查 IPv6 连通性，或临时改为优先 IPv4 进行对照。
按结果收敛问题并完成复测
十二项检查完成后，不要只以“某个首页打开了”作为恢复标准。至少测试一个普通 HTTPS 页面、一个包含多个子域名资源的页面，并执行一次订阅更新。桌面端还应重新启动浏览器，安卓端应断开再连接一次，确认系统代理或 VPN 接口能够稳定重建。
如果本地端口可用、多个节点真实连接测试正常、全局代理可访问，而原分流模式失败，故障可以明确归入路由层。如果节点域名无法解析，或者日志在建立连接前就出现 lookup 错误，则先处理引导 DNS。如果只有单个节点在不同网络下都握手失败，则应核对该节点配置和服务状态。
- 本地层通过标准：应用使用正确入口，核心监听端口存在，日志能看到新请求进入。
- 节点层通过标准：服务器地址可达，系统时间准确，VMess 或 VLESS 字段与实际配置一致。
- 路由层通过标准：失败域名命中预期出站，Geo 数据成功加载，规则优先级没有被宽泛规则覆盖。
- DNS 层通过标准：节点域名与目标域名都能在合理时间内返回当前网络可达的地址。
重启客户端后短暂恢复，过一会又失败?
记录恢复和失败两个时间点的日志，重点比较 DNS 响应、端口监听和路由命中。周期性复发通常与缓存过期、网络切换或上游解析超时有关。
浏览器可用，但命令行工具仍然超时?
命令行工具未必自动读取系统代理。检查其代理环境变量或显式代理参数，确认地址和端口与 v2rayN 当前监听值一致。
v2rayNG 显示连接，但只有部分应用没网络?
进入分应用代理设置，检查这些应用是否被排除；同时确认省电策略没有限制 v2rayNG 后台运行，并在修改后断开重连。
更新订阅后旧节点参数没有变化?
确认更新的是当前使用的订阅分组，并检查是否启用了保留本地修改的选项。重新选择更新后的节点，再查看核心日志中的实际地址和端口。
应该直接重置全部设置吗?
先导出当前配置并完成分层检查。只有确认多处本地设置相互冲突、且无法定位来源时再重建配置，避免丢失仍然有效的路由与订阅设置。