v2rayN 显示已连接却打不开网页:八步逐项排查清单

第一步：区分节点选中、内核启动和请求成功

v2rayN 是图形客户端，实际代理请求由所选内核处理。界面里节点高亮、系统代理已设置，或者延迟测试有数字，都不能单独证明浏览器的 HTTPS 请求已经通过节点完成。TCP 延迟测试通常只能证明某个地址与端口可达，不能验证认证、TLS、REALITY 和最终目标网站的整条链路。

先退出其他会接管网络的程序，暂时关闭 v2rayN 的 TUN 模式，以“系统代理加本地入口”作为测试基线。系统代理模式和 TUN 模式的接管范围不同，同时开启时会多出路由与 DNS 变量。若所在网络要求企业代理或认证，先完成原网络登录，不要直接移除组织要求的设置。

1. 暂时清除系统代理，打开一个平时能直连的网站，确认底层网络本来可用。
2. 选中要排查的节点，设为活动服务器，再查看内核启动日志是否出现配置或监听错误。
3. 记录当前客户端版本、实际内核名称和版本、测试网址与时间，后续复测保持一致。

如果清除系统代理后依旧完全不能上网，先查 Wi-Fi、网关、网络认证与系统 DNS。这时继续切换 VLESS、VMess 或订阅分组，通常无法修复基础网络。

第二步：核对系统代理地址和本地入口

在 v2rayN 托盘菜单中找到“系统代理”，选择“自动配置系统代理”。不同版本的文字可能略有变化，重点是让 Windows 的代理服务器地址指向正在运行的本地入口，而不是只选中节点。随后到 Windows“设置”→“网络和 Internet”→“代理”，检查手动代理的地址与端口。

这里的 10808 是演示值，不是所有版本的固定默认值。到“设置”→“参数设置”中核对本地监听相关选项，再以启动日志或实际配置为准。有些版本区分 SOCKS 和 HTTP 入口，有些使用混合入口；Windows 手动代理需要可接受 HTTP 代理请求的入口，不能随手填一个仅支持 SOCKS 的端口。

• 代理地址填本机回环地址，不填远端节点域名，也不填订阅链接。
• 本地入口端口与节点服务器端口是两回事，二者不要求相同。
• 检查自动配置脚本与手动代理是否留下了其他程序的设置，避免浏览器继续使用旧脚本。
• 命令行工具和部分应用不跟随 Windows 系统代理，需要单独指定代理，不能据此判定节点失效。

第三步：检查端口监听和进程占用

系统代理写对了，但本地端口没有服务接收，网页仍然打不开。打开 PowerShell，执行下面的查询。若实际端口不是 10808，先替换命令中的数字。

netstat -ano | findstr ":10808"
Get-NetTCPConnection -LocalPort 10808 -State Listen

重点看本地地址、LISTENING 状态和进程 ID。查询不到监听，优先查看内核是否退出；查到了监听，也要确认它属于当前 v2rayN 调用的内核，而不是另一份客户端实例。在任务管理器“详细信息”中按 PID 核对，必要时打开“命令行”列确认程序路径。

不要直接结束名称陌生的系统进程。端口冲突解决后，重新启动当前内核，再检查一次监听；只改系统代理而不让内核成功绑定端口，问题会原样保留。

第四步：同步时间并核对节点握手参数

本地入口正常，但所有请求都在建立连接阶段失败，就该查节点参数与设备时间。Windows 11 可到“设置”→“时间和语言”→“日期和时间”，启用自动设置时间并点击“立即同步”。核对实际日期与时钟，单纯改时区显示并不等于系统时间已经准确。

订阅更新成功只说明配置被取回，不代表节点仍在服务，也不代表当前内核支持其中全部字段。遇到导入后字段缺失，先核对客户端实际调用的内核与配置格式，再向配置提供方确认。REALITY 等能力应按 Xray 对应版本的支持范围检查，不能把 V2Fly 与 Xray 当成完全等价的内核。

• 从可信配置源重新导入一条节点，与旧条目对照，避免手工修改时漏字段。
• 不要把关闭证书验证当成通用修复。证书报错应先查时间、服务器名称和服务端证书链。
• 若同一节点在另一台设备可用，对照实际参数和内核版本，而不是仅比较节点名称。

第五步：把 DNS 问题与代理链路问题分开

“域名打不开”不一定就是 DNS 故障。连接节点域名需要解析，直连目标可能需要本地解析，代理目标的解析位置又受内核与出站配置影响。这几段可能使用不同上游；浏览器安全 DNS、Windows DNS 与内核 DNS 也不是同一个开关。

先用 Windows 自带的 curl.exe 显式指定代理，绕开浏览器设置。以下测试有 15 秒上限，目标只是观察响应与错误阶段，不承诺特定状态码，也不用于测速。请把端口改成实际支持 HTTP 代理的本地入口。

curl.exe -I --connect-timeout 10 --max-time 15 --proxy http://127.0.0.1:10808 https://www.example.com/

Resolve-DnsName www.example.com

第一条命令验证经指定入口的请求；第二条只观察 Windows 当前的系统解析路径，不能证明内核 DNS 工作正常。若要比较 SOCKS 的本地与代理侧解析，可在确认入口支持 SOCKS 后使用以下两条命令：

curl.exe -I --max-time 15 --socks5 127.0.0.1:10808 https://www.example.com/
curl.exe -I --max-time 15 --socks5-hostname 127.0.0.1:10808 https://www.example.com/

调整 DNS 后可执行 ipconfig /flushdns 清理 Windows 解析缓存，并重启浏览器和内核以排除各自缓存。不要把 HTTPS 目标随意换成 IP 测试：证书名称、SNI 与网站虚拟主机可能因此改变，反而引入新的错误。

第六步：检查路由分流与默认出站

同一个节点在显式代理测试中正常，浏览器却只有部分域名失败，常见原因是路由把这些请求分到了直连或阻断出站。打开 v2rayN 的路由设置，检查当前规则集、匹配顺序与默认出站。具体菜单位置随版本不同，以界面中的“路由设置”或路由配置入口为准。

1. 记录当前路由配置名称，先备份自定义规则。
2. 临时选择将目标请求交给代理出站的路由模式，使用同一网址复测。仅“自动配置系统代理”不等于所有请求都走代理。
3. 若恢复正常，回到原规则检查域名规则、IP 规则、阻断项和兜底出站。
4. 每次只恢复一组自定义规则，直到复现失败，定位具体匹配项后再修改。

域名策略也会影响何时解析。AsIs、IPIfNonMatch 与 IPOnDemand 的解析时机不同，不能理解成“越积极解析越稳定”。当 IP 规则需要解析结果时，DNS 的返回值会参与出站选择；解析错误与规则过宽可能共同把请求送错出口。

第七步：排除浏览器扩展与独立代理设置

如果显式代理的 curl.exe 能收到目标站响应，而只有浏览器失败，排查重点应转向浏览器。先用临时浏览器配置文件打开同一网址，比直接清空全部历史记录更容易保留现场。隐私窗口并非绝对干净，部分扩展被允许在其中运行。

• 代理扩展：暂时停用代理切换扩展，避免其覆盖 Windows 系统代理或沿用旧端口。
• 独立代理：Firefox 可检查“设置”→“常规”→“网络设置”→“设置”，确认没有指向失效的手动代理。
• 安全 DNS：记录当前模式，临时对照系统解析路径测试；不要同时更改内核 DNS 和浏览器 DNS。
• 缓存与连接：完全退出浏览器进程后重开。只刷新标签页可能继续复用旧连接或缓存结果。
• 安全软件：检查是否拦截内核程序或本机代理连接，优先核对日志与定向放行，不要长期关闭防护。

若只有某个网站失败，再比较其他 HTTPS 网站。网站自身故障、账户访问限制、出口地址限制或证书问题都可能表现成“打不开”，不能用单一站点代表节点整体状态。已经拿到网站返回的 HTTP 错误状态码，通常说明至少这一请求已走到能够返回响应的服务端或中间层。

第八步：按同一时间点关联日志，再做网络对照

最后才做较深入的日志定位。先记下点击网页的时间，再查看附近的内核输出。正常使用可保留 warning；排错时可临时提高到 info，必要时短暂使用 debug。日志级别提高后内容可能包含目标域名与连接信息，排查结束应恢复原设置。

下一轮对照只换一个条件：同一台电脑、同一节点改用手机热点；或者同一网络换一条已确认可用的节点。前者有助于判断原网络限制，后者有助于判断节点服务状态。不要同时切换网络、协议、DNS 和内核，否则即使恢复，也无法知道是哪一步起效。