v2rayN 显示已连接却打不开网页:系统代理、端口与路由逐项排查

1. “已连接”不等于网页请求成功

v2rayN 的运行状态、节点延迟结果、网页可用性是三个不同层次。内核进程启动，只能说明程序能够运行；TCP 延迟有结果，通常只能说明远端端口能够建立连接。认证、传输层握手、DNS 解析和目标网站访问仍可能失败。排查时应看一次真实请求，而不是反复点击延迟测试。

新版配置可能使用同时接受 HTTP 与 SOCKS 的混合端口，旧配置也可能把两种入站分开。10808 不是所有安装的固定答案；如果界面显示 HTTP 为 10809，HTTP 测试就使用该端口。节点服务器端口则由服务端配置决定，不要为了与示例一致而改成 443。

1. 先确认关闭代理后，本地网络能打开通常可以直连的网站。
2. 记录当前节点、路由模式、本地端口和发生故障的时间。
3. 暂时只保留一种接管方式。排查系统代理时先关闭 TUN，避免两条路径互相干扰。
4. 打开客户端日志，再发起一次请求，对照同一时间段的错误。

2. 系统代理：确认浏览器把请求送到哪里

系统代理决定应用是否把请求交给本地端口，路由模式决定进入内核之后如何选出站，两者不能互相替代。选择了代理节点但没有设置系统代理，遵循系统设置的浏览器仍可能直连；反过来，系统代理指向已经停止的端口，也会让原本正常的网站打不开。

1. 核对入站

   打开 v2rayN「设置」→「参数设置」，查看本地监听地址、端口及入站协议。不同版本的分组名称可能不同，记录实际值，不凭旧教程猜端口。

2. 设置系统代理

   在主界面或托盘菜单「系统代理」中选择「自动配置系统代理」。这里指写入系统代理设置，不等于所有版本都会启用 PAC，也不代表全部应用流量都会被接管。

3. 检查系统值

   进入 Windows「设置」→「网络和 Internet」→「代理」，核对当前手动代理或设置脚本。手动代理地址应与本地监听匹配；HTTP 代理不能指向仅提供 SOCKS 的端口。

4. 排除浏览器覆盖

   临时关闭代理切换扩展，检查浏览器独立代理设置，关闭并重新打开测试页面。如果系统代理值反复变化，先退出其他会修改代理设置的程序。

命令行工具不一定读取 Windows 系统代理。终端请求成功或失败，不能直接代表浏览器配置正确。下面使用显式 --proxy 参数，就是为了绕过这层差异，单独检查本地入站与后续连接。

3. 本地端口：用显式请求区分入口与出口

在 PowerShell 中执行下列命令。明确写成 curl.exe，避免部分环境把 curl 解释成其他命令。第一条适用于 HTTP 或混合入站，第二条适用于 SOCKS 或混合入站；只运行符合当前入站类型的命令，不要求两个都成功。

curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

socks5h 会把目标域名交给 SOCKS 端处理，适合与本机解析路径作区分，但不自动证明请求一定使用远端 DNS。HTTP 测试若只出现 200 Connection established，还要继续看 TLS 与目标站响应，不能把建立代理隧道的中间响应当成网页请求完成。

若提示端口被占用，用下列命令查监听者。只看本地地址列与 LISTENING 状态，末列是 PID；再到「任务管理器」→「详细信息」核对进程。不要仅凭 PID 强制结束未知系统进程。

netstat -ano | findstr ":10808"

发现旧内核残留时，先正常退出对应客户端，再重新启动。若要更换本地端口，必须同步修改系统代理和应用手动代理；只改其中一处，会把占用问题变成连接拒绝。单机使用通常保持 127.0.0.1 监听，无需开放局域网访问。

4. 时间与握手：从日志区分认证和传输错误

系统时间偏差可能影响 VMess 认证，也可能让 TLS 证书被判定尚未生效或已经过期。Windows 可进入「设置」→「时间和语言」→「日期和时间」，开启自动设置时间并点击「立即同步」。同时核对日期与时区；关键是实际时间准确，不只是时钟外观看起来接近。

对于 VLESS、VMess 或 Trojan，导入节点后仍要核对地址、端口、认证信息与传输设置。TLS 的 serverName、WebSocket 路径、gRPC 的 serviceName 都需要与服务端对应；REALITY 还需要匹配服务端提供的公钥与 shortId 等参数。不要把改协议当成通用修复，客户端内核也必须支持该配置。

5. 路由与 DNS：检查请求是否选错出站

当日志能看到请求进入内核，但部分域名失败，应检查分流。V2Ray/Xray 的 routing.rules 按顺序匹配，命中后选择对应出站；outboundTag 必须引用实际存在的 outbounds[].tag。没有规则命中时的默认出站也要检查，不能假定一定走代理。

• 先做路由对照：记录当前模式，临时选择让普通目标请求走代理的路由模式，测试同一网址后恢复。v2rayN 的路由模式与系统代理菜单是不同入口。
• 再看拦截规则：如果普通网站可用、某一域名失败，检查它是否命中直连或阻断规则，尤其是宽泛域名规则与 IP 规则的位置。
• 辨认解析对象：节点使用域名时，连接节点之前就需要可用的解析路径；仅调整目标网站 DNS，可能无法解决节点域名解析失败。
• 理解字段作用：routing.domainStrategy 控制路由匹配中的域名解析行为，不是应用接管开关，也不能单独承诺避免所有 DNS 外发。
• 保留访问证据：临时查看日志中的目标地址和出站 tag；GUI 自动生成配置时，应改对应路由设置，直接编辑临时生成文件可能被覆盖。

浏览器安全 DNS、系统 DNS、内核 DNS 可能形成不同路径。使用 nslookup 能观察系统所用解析器，但不能据此证明代理内部解析正常，也不能单凭它判断浏览器全部 DNS 请求的去向。若只在浏览器失败，可暂时调整浏览器安全 DNS 设置作对照，测试后恢复原配置。

6. 节点可用性：区分端口可达与协议可用

本地监听正常、显式代理仍失败时，再验证远端。PowerShell 的端口测试只建立 TCP 连接，不验证 VMess、VLESS 或 Trojan 的认证与传输参数。因此 TcpTestSucceeded: True 只能缩小范围，不能替代真实网页请求。

$nodeHost = Read-Host "输入当前节点的服务器地址"
$nodePort = [int](Read-Host "输入当前节点的服务器端口")
Test-NetConnection -ComputerName $nodeHost -Port $nodePort

1. 核对配置来源：检查订阅是否已更新、账号是否到期、额度是否耗尽。不要向陌生人发送订阅链接、UUID、密码或完整配置。
2. 更换一个已知可用节点：保持同一本地端口和路由设置，用相同网址复测。只有某个节点失败时，优先核对它的参数与服务端状态。
3. 更换网络：用手机热点与当前网络对照。热点可用、原网络失败时，重点检查原网络的出口限制、DNS 和防火墙策略。
4. 查看拦截记录：安全软件可能允许界面程序却阻止内核进程联网。确认程序路径与日志后添加必要许可，不把永久关闭防火墙作为解决办法。

如果所有节点同时失败，而且日志显示内核无法启动，应先处理配置解析或内核兼容问题，而不是连续刷新订阅。升级前备份配置；升级后核对当前选用内核是否支持节点协议。软件升级不能修复远端证书、账号额度或服务端参数错误。

7. 常见追问与恢复后的检查

恢复访问后，撤销为排查临时添加的全局路由和调试设置，保留需要的系统代理模式。至少复测一个通常直连的网站、一个需要代理的网站，以及此前失败的应用。确认三者符合预期，再把有效修改记录下来。

• 提交问题时附上：客户端版本、内核版本、操作系统版本、实际本地端口、路由模式与测试时间。
• 日志保留范围：截取失败前后相关行即可；公开前遮盖订阅地址、认证信息与不希望公开的服务器信息。
• 继续查字段：需要确认入站、出站和路由的对应关系时，可查阅JSON 配置手册；基础设置路径见使用指南。