v2rayN 连接成功但不能上网怎么办？完整排查步骤
简答：v2rayN 显示已连接不等于应用流量已经经过代理。先选中节点并执行一次真实连接测试，再确认系统代理已开启且地址、端口与 v2rayN 当前本地监听一致；如果仍打不开网页，暂时关闭 TUN、浏览器代理插件和其他代理软件，用 curl.exe 验证本地代理入口，最后再排查 DNS、路由与日志。
定义：“v2rayN 连接成功但不能上网”通常指节点或核心看似已启动，但浏览器或其他应用没有正确接入本地代理，或请求在 DNS、路由、TLS、TUN 等环节失败。
先做首屏三步速查：不要先反复换节点
本文是独立的使用排查指南，bv2.best 不是 v2rayN 或任何相关服务的官方网站。v2rayN 官方项目将其定位为支持 Windows、Linux 和 macOS 的桌面客户端，并支持 Xray、sing-box 等核心；具体版本界面和可用选项应以当前项目说明为准，官方项目页和官方 Wiki是核对入口。
| 现象 | 先检查什么 | 判断结果 |
|---|---|---|
| 只有浏览器打不开 | 系统代理、浏览器独立代理、代理扩展 | 其他应用或 curl 能通，通常是浏览器没有使用同一代理 |
| 所有应用都打不开 | 节点真连接、本地监听端口、核心日志 | 本地代理入口或远端连接可能失败 |
| 关闭 TUN 后恢复 | TUN、DNS、路由和权限 | 先保留系统代理模式，避免同时修改多个变量 |
| 能测延迟但网页打不开 | 真实 HTTPS 请求、路由、DNS、TLS | 延迟测试不能单独证明网页请求完整可用 |
- 在 v2rayN 中明确选中一个节点，执行一次“真连接延迟”或同类真实连接测试；不要只看托盘图标或 TCP 延迟。
- 打开系统代理的自动配置选项，核对 Windows 代理地址是否为本机回环地址，端口必须与 v2rayN 当前显示的本地 HTTP 或 SOCKS 监听端口一致。v2rayN 官方说明指出，系统代理的作用是把部分应用流量转发到核心的入站入口，具体模式名称可能因版本不同而变化，参见系统代理与路由说明。
- 暂时关闭 TUN、浏览器代理扩展、其他代理软件和手动设置的浏览器代理，只保留 v2rayN 系统代理，再重新打开网页。
预期结果：至少有一个明确的 HTTPS 请求可以完成，而不是只看到“已连接”。如果三步后仍失败，按下面的症状分流。
浏览器打不开：核对系统代理和浏览器代理
v2rayN 的系统代理只会影响使用系统代理设置的应用。官方说明将系统代理分为清除、自动配置、不改变和 PAC 等模式；PAC 模式还会按照脚本决定请求直连还是转发。因此，浏览器打不开时，先确认 v2rayN 当前选择的模式，再检查 Windows 的代理页面是否被其他软件覆盖。
- 退出或暂停其他代理客户端、网络加速器和浏览器代理扩展。
- 在 Windows“设置”中搜索“代理”，检查手动代理、自动配置脚本和自动检测设置；不要同时保留多个互相冲突的代理入口。
- 回到 v2rayN，重新执行“自动配置系统代理”或当前版本对应的系统代理开关，然后关闭并重新打开浏览器。
- 如果只有 Firefox 或某个浏览器失败，检查该浏览器是否使用独立代理设置，或暂时关闭其安全 DNS、代理扩展后复测。
如果 v2rayN 的系统代理端口发生变化，Windows 仍可能保留旧端口，表现为浏览器无法连接本地代理。此时不要凭经验填写端口，直接复制 v2rayN 当前设置页显示的端口。
所有应用都打不开：验证节点、本地监听和核心日志
先把故障拆成两段：第一段是应用能否连到本机代理入口，第二段是核心能否通过节点完成远端请求。这样可以避免把“本地端口拒绝连接”和“节点或协议参数失败”混为一谈。
- 在 v2rayN 中确认节点处于选中状态，并重新执行真实连接测试。若多个节点均失败，先查看核心日志，不要立即修改 DNS。
- 查看 v2rayN 的本地 HTTP、SOCKS 或混合端口设置，确认没有与其他程序冲突。端口必须是当前界面显示的实际值。
- 在 PowerShell 中用真实端口测试本地代理入口。先把下方的“实际端口”替换成 v2rayN 当前显示的 HTTP 代理端口：
curl.exe -v -x http://127.0.0.1:实际端口 https://example.com/ - Windows PowerShell 5.1 可能把 curl 映射为 Invoke-WebRequest；微软建议需要调用真正的 curl 时使用
curl.exe，可参考Microsoft Learn 的 Windows curl 说明。
如果命令立即提示无法连接到 127.0.0.1，优先检查端口、核心是否启动和防火墙拦截；如果能够建立本地连接但 HTTPS 请求超时，再查看节点、协议、TLS、路由和 DNS 相关日志。v2rayN 官方 FAQ 区分了界面日志与核心日志：界面、设置和测速问题通常看 guiLogs，核心连接问题则看主界面的核心日志，详见官方 FAQ。
按日志关键词分流：DNS、TLS、超时和拒绝连接
| 日志或现象 | 优先检查 | 建议动作 |
|---|---|---|
| connection refused、无法连接本地端口 | 核心是否启动、端口是否匹配、端口是否被占用 | 停止其他代理软件，重新启动核心并核对实际端口 |
| timeout、dial failed | 节点地址、网络出口、协议参数和防火墙 | 用另一个已核实配置复测，并保留日志对比 |
| DNS failed、name resolution | DNS 设置、路由和浏览器安全 DNS | 先恢复默认 DNS 或暂时关闭自定义 DNS，单变量复测 |
| TLS、certificate、server name | 系统时间、证书校验和配置字段 | 校准系统时间，重新获取配置；不要自行猜改字段 |
| 只有部分网站失败 | 路由规则、域名解析、IPv6 或 QUIC | 先临时使用较简单的路由模式，再逐项恢复设置 |
v2rayN 官方界面说明显示，TUN、FakeIP、DNS 查询类型和路由策略可能受核心类型限制；例如 FakeIP 仅支持 sing-box 且只在 TUN 模式下有效。因此，不能把某个 DNS 或 FakeIP 选项当成所有版本、所有核心都适用的通用修复方案，遇到版本差异时应以当前界面和官方 Wiki 为准，参见官方界面说明。
TUN、DNS 和路由：恢复连接后的正确顺序
如果关闭 TUN 后系统代理可以正常访问，说明故障范围更可能集中在 TUN 的权限、路由、DNS 或核心兼容性，而不是简单断网。先保留能工作的系统代理模式，再逐项恢复。
- 先确认基础连接：关闭 TUN，只启用系统代理，完成一次浏览器访问和一次
curl.exeHTTPS 请求。 - 再单独开启 TUN：以管理员权限启动 v2rayN，确认 TUN 虚拟网卡和自动路由没有报错；不要同时更改 DNS、MTU 和路由规则。
- 出现异常就回滚：关闭 TUN，恢复默认 DNS 和原来的路由模式，再测试系统代理是否恢复。
- 最后处理 DNS：如果只有域名打不开而直接地址测试正常，再检查 DNS、FakeIP、浏览器安全 DNS 和分流规则。不要把“能解析域名”直接等同于“代理请求成功”。
官方 Wiki 对 TUN 栈、MTU、ICMP 路由和 FakeIP 都列出了核心或模式限制；因此本文不提供未经当前版本验证的固定 MTU、DNS 地址或配置字段。若修改后无法启动，优先恢复默认值，而不是继续叠加设置。
复测与回滚：什么结果才算排查完成
一次合格的复测至少应包含三项：第一，v2rayN 选中节点后真实连接测试不再立即失败；第二，使用实际本地端口的 curl.exe HTTPS 请求能够完成；第三，浏览器在关闭代理扩展和其他代理软件后可以打开目标页面。
- 如果 curl 成功、浏览器失败：检查浏览器独立代理、扩展、缓存和安全 DNS。
- 如果本地端口失败：回到核心启动、端口占用、权限和防火墙。
- 如果本地端口成功但 HTTPS 超时：回到节点、协议、TLS、路由和 DNS 日志。
- 如果只在 TUN 开启后失败：关闭 TUN 作为回滚状态，并记录当前核心类型、系统版本和日志，再查版本相关问题。
不要一次修改多个变量，也不要仅凭“托盘图标变色”“节点延迟有数值”宣布问题已解决。保存修改前后的设置和日志，后续才能判断究竟是哪一层发生变化。
常见问题
为什么 v2rayN 显示已连接，浏览器还是打不开？
“已连接”可能只表示核心或节点已启动，浏览器仍可能没有使用 v2rayN 的系统代理，或者使用了旧端口、独立代理或扩展。先关闭其他代理软件，重新配置系统代理，再用实际本地端口执行一次 curl.exe HTTPS 请求。
v2rayN 能测速是不是说明节点一定能上网？
不是。延迟或 TCP 测试只能说明某个测试路径有响应，不能单独证明 DNS、TLS、路由和完整 HTTPS 请求都正常。应以经过本地代理的实际 HTTPS 请求和浏览器复测作为验收依据。
要不要一遇到不能上网就开启 TUN？
不建议。TUN 会改变系统流量接管、路由和 DNS 范围，适合系统代理无法覆盖目标应用时使用。先关闭 TUN，用系统代理完成基线测试；若基线正常，再单独开启 TUN并观察日志，出现异常立即回滚。
curl.exe 测试时端口应该填多少？
不要套用固定端口。打开 v2rayN 当前设置，复制实际 HTTP 代理端口；若只有 SOCKS 端口，则使用对应的 SOCKS5 测试方式。端口随版本、配置和本地设置变化，无法从本文统一指定。
DNS、FakeIP 或路由改乱后怎么恢复？
先关闭 TUN，恢复默认 DNS、默认路由和原来的系统代理模式，再重启核心测试。如果系统代理恢复，说明问题集中在 TUN、DNS 或路由分支；之后一次只改一个选项，并记录每次复测结果。