代理已连接但无法上网:v2rayN 与 v2rayNG 逐项排查清单

客户端显示运行中，并不等于远端节点已经完成一次可用的数据交换。v2rayN 启动 Xray 或 V2Fly 内核后，只能说明本机进程已运行、配置文件通过了基本解析；v2rayNG 顶部出现钥匙状态或系统显示 VPN 连接，也只说明 Android 的流量接管服务已经建立。远端地址能否解析、端口是否可达、协议参数是否匹配，还需要通过真实连接验证。

一次网页请求需要依次经过应用、本地代理入口、路由规则、代理出站和远端响应。任意一段失败，表面现象都可能是浏览器一直加载、立即显示连接被重置，或者只有部分网站打不开。因此不要看到客户端托盘图标变色就直接修改 DNS，也不要在节点尚未确认可用时连续切换路由模式。

记录正在使用的节点名称、路由模式和本地端口。每次只修改一项，修改后重启内核并重新打开测试页面，否则无法判断是哪一项产生了变化。

第一步：验证节点可用性与系统时间

先在 v2rayN 节点列表中选中当前节点，执行真连接延迟测试。普通 Ping 只检查目标主机是否响应 ICMP，不能证明 VMess、VLESS 或其他代理连接能够完成握手。真连接测试会通过当前核心实际建立出站连接，更适合作为第一道筛选。若同一订阅内多个节点都显示超时，应先更新订阅，再挑选两个不同地址和端口的节点交叉测试。

测试时可记录具体数值。比如节点 A 真连接延迟为 186 ms、连续三次都能返回，节点 B 三次均超过 5000 ms 超时，那么应先使用节点 A 排查后续环节。延迟高不一定完全无法使用，但连续超时、连接被拒绝或握手立即失败，通常不能靠修改浏览器设置解决。

1. 在 v2rayN 主界面选中节点，执行真连接延迟测试，不以 Ping 结果代替。
2. 切换至少两个订阅节点，每次等待测试完成，避免同时批量启动过多连接。
3. 打开运行日志，确认测试时确实出现新的出站记录，而不是读取旧结果。
4. 在 v2rayNG 中点击当前配置的测试功能，再切换另一个节点重复一次。
5. 如果 Wi-Fi 下全部失败，改用另一条可用网络测试，以区分节点问题与当前网络限制。

系统时间偏差也会影响需要时间校验的连接。Windows 可进入「设置」→「时间和语言」→「日期和时间」，开启自动设置时间并立即同步；Android 可进入系统的日期与时间设置，启用网络提供的时间。若设备时间与标准时间相差数分钟，先校正时间，再完全停止并重新启动客户端核心。

第二步：定位 DNS 解析故障

节点测试成功但输入域名后网页一直等待，DNS 是下一项检查重点。DNS 的任务是把域名转换为可连接的地址；代理出站正常，并不保证本地 DNS、核心 DNS 与系统私有 DNS 的组合一定正确。尤其是在导入自定义配置、修改过分流规则或启用了加密 DNS 后，域名查询可能被发送到不适合当前网络的出口。

在 v2rayN 7.x 中，可从「设置」→「参数设置」检查基础设置与 DNS 相关选项。若使用自定义 DNS 配置，先保存原内容，然后恢复为客户端默认配置进行对照。修改后要重启核心，仅关闭浏览器标签页不足以让核心重新加载配置。Windows 还可在终端执行系统自带的查询命令，观察本机是否能获得解析结果。

nslookup example.com
ipconfig /flushdns

nslookup 返回地址只证明系统查询链路有结果，不代表核心内部采用相同的 DNS。若系统查询成功，而 v2rayN 日志持续报告域名解析失败，应检查核心 DNS 配置和路由规则；若系统查询本身超时，可先把网络适配器 DNS 恢复为自动获取，清理缓存后再测。

v2rayNG 已建立 VPN 接管但所有域名都失败时，可暂时把 Android 的私有 DNS 调整为自动模式进行测试。确认问题后再决定最终设置，不要同时修改节点、路由和私有 DNS。

第三步：用全局代理排除路由规则误判

路由规则决定请求走代理、直连还是阻断。自定义规则中的域名、IP 段、端口和入站标签如果匹配错误，会出现节点本身可用，但特定网站或特定应用始终无法访问的情况。规则通常按既定顺序匹配，一条范围过大的直连规则可能在后续代理规则之前截获请求。

最直接的诊断方法不是立即删除规则，而是暂时切换到全局代理模式，再访问同一个域名。如果全局代理可以打开，而原路由模式失败，故障范围就能缩小到分流配置。完成测试后恢复原模式，逐条检查自定义规则的匹配对象和出站动作。

VMess 与 VLESS 是节点连接协议，路由规则则负责决定哪些请求交给该节点，两者不能混为一项。更换协议参数无法修复一条错误的直连规则，反过来，切换全局代理也无法修复错误的用户标识、传输层参数或服务端端口。

第四步：检查 v2rayN 系统代理与本地端口

Windows、macOS 与 Linux 桌面应用是否进入代理链路，取决于应用是否读取系统代理、是否配置了独立代理，以及当前是否启用 TUN。v2rayN 核心正在运行时，本地通常会监听 SOCKS 或 HTTP 入口；如果系统代理没有指向实际监听端口，浏览器仍可能直接联网，或者因指向旧端口而完全打不开页面。

在 v2rayN 中先打开「设置」→「参数设置」，查看本地 SOCKS、HTTP 或混合入口端口。常见配置会使用 127.0.0.1:10808 作为 SOCKS 入口，并可能使用 127.0.0.1:10809 作为 HTTP 入口，但实际数值以当前界面为准。之后从托盘菜单选择自动配置系统代理，再检查系统代理地址是否与客户端当前端口一致。

• 本地地址应优先核对 127.0.0.1，不要把远端节点地址填入系统代理。
• 修改端口后必须重启核心，并重新应用系统代理设置。
• 浏览器若设置了手动代理，应确认协议类型与端口匹配，或暂时改为使用系统代理。
• 命令行程序不一定读取桌面系统代理，需要检查该程序支持的代理环境变量或配置项。
• 端口已被其他进程占用时，内核可能启动失败或无法创建对应入站。

第五步：检查 v2rayNG 的 VPN 接管与应用范围

v2rayNG 在 Android 上通常通过系统 VPN 接口接管流量。状态栏出现连接标记后，还要确认系统确实允许该服务运行，并检查分应用代理、绕过局域网、路由模式和电池管理设置。若只有某一个应用无法访问，而浏览器正常，问题通常不在节点本身，而在分应用选择或该应用自己的网络策略。

先在 v2rayNG 设置中确认本地端口与路由选项，再检查分应用代理是否启用。如果启用了“仅代理选中的应用”，目标应用必须在列表内；如果启用了相反的排除逻辑，则目标应用不应出现在排除列表。调整后断开连接，等待数秒再重新连接，让系统重新建立 VPN 路由。

v2flyNG 使用 V2Fly 内核时也遵循类似的 Android 流量接管逻辑，但内核支持范围与日志内容可能不同。不要把 v2rayNG 的 Xray 专用配置原样套入 v2flyNG；如果订阅包含依赖特定内核的参数，应选择与节点要求匹配的客户端和内核。

Windows、macOS 与 Linux 桌面端重点检查系统代理、本地监听端口和 TUN；Android 重点检查 VPN 接管、分应用范围和后台运行。节点、时间、DNS 与路由的检查顺序在四个平台上保持一致。

最后按固定顺序复测并读取日志

完成单项检查后，应回到同一个测试条件复测：使用同一网络、同一节点、同一域名和同一浏览器。若每次都更换测试对象，即使页面恢复，也难以判断真正原因。建议把日志窗口保持打开，从启动核心开始观察，而不是只截取最后一条红色信息。

日志应按时间顺序阅读。先找本地入口是否收到请求，再看路由选择了哪个出站，最后判断失败发生在解析、连接、握手还是远端返回阶段。一条 timeout 只能说明操作超过期限，前后几行中的目标地址、出站标签与 DNS 信息才决定处理方向。

1. 关闭系统代理或断开 Android VPN，确认设备本身的基础网络可以访问常规页面。
2. 校准系统时间，更新订阅，选取真连接测试成功的节点。
3. 启动核心后查看日志，确认没有配置解析失败或本地端口占用。
4. 临时使用全局代理测试同一域名，以排除自定义路由规则。
5. 恢复默认 DNS 做对照，重启核心后清理浏览器或系统 DNS 缓存。
6. 桌面端重新应用系统代理，核对 127.0.0.1 与实际监听端口。
7. Android 端重新建立 VPN，核对分应用范围、私有 DNS 和后台运行权限。
8. 确认恢复后逐项还原个性化设置，每还原一项就复测一次。