v2rayN 已连接但打不开网页：macOS 与 Windows 逐项排查清单

先区分节点选中与请求接通

v2rayN 选中了服务器，不代表浏览器已经经过代理。节点列表里的延迟结果也只对应某次检测，不能证明当前网站的解析、TLS 握手和页面资源都能完成。排查时先关闭重复运行的代理客户端，暂不启用 TUN，只保留系统代理这一条入口。

先记录当前节点、系统代理状态、路由模式和本地监听端口。打开客户端日志，再访问一次固定网址。日志完全没有相应连接时，优先查入口；已经出现目标域名或远端连接错误时，再查后半段链路。日志详细程度会影响可见内容，不能仅凭一条空白记录就断定浏览器没有发请求。

• 所有网站都失败：先查本地监听与系统代理，尤其是刚改过端口或退出过客户端的情况。
• 只有部分网站失败：记录域名，重点比较路由命中、DNS 结果和网站自身状态。
• 浏览器能用，其他应用不能用：检查该应用是否遵循系统代理，别直接认定节点异常。

第一步：确认系统代理指向当前端口

在 v2rayN 主界面或托盘菜单打开「系统代理」，选择「自动配置系统代理」。「清除系统代理」会移除相关入口；「不改变系统代理」则保留系统现状，不等于已经开启代理。各版本菜单位置可能不同，先按菜单文字定位，不要只看图标颜色。

本机代理地址通常填写 127.0.0.1，端口必须来自当前客户端配置。打开「设置」→「参数设置」，查找本地监听端口及其协议类型。不要把服务商节点的远端端口填到系统代理里，也不要把只接受 SOCKS 的端口填进 HTTP 代理字段。

第二步：检查本地端口是否真正监听

下面用 10808 演示检查过程，它不是所有版本都适用的固定值。只有客户端明确把该端口标为 HTTP 或混合监听时，才运行后面的 HTTP 代理测试；若配置不同，把命令中的端口替换成实际值。

在 macOS 终端检查

lsof -nP -iTCP:10808 -sTCP:LISTEN
curl -I --max-time 15 --proxy http://127.0.0.1:10808 https://example.com/

在 Windows PowerShell 检查

Get-NetTCPConnection -LocalPort 10808 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

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

Windows 里明确使用 curl.exe，避免旧版 PowerShell 把 curl 解释成其他命令。发现监听进程后，按进程编号在「任务管理器」核对名称；macOS 则查看 lsof 输出中的进程。端口已被其他进程占用时，先识别用途，再退出重复客户端或更换监听端口，不要直接结束陌生系统进程。

第三步：对照路由命中，不把全局当修复

系统代理只决定请求先交给谁，路由规则再决定它走直连、代理还是阻断。出现“国内网站能打开，其他网站失败”时，可能只是直连部分正常；出现“某个域名一直打不开”时，则应检查该域名是否命中了意外的直连或阻断规则。

1. 记录当前路由模式，并备份自行添加的规则。
2. 在 v2rayN 的「路由」菜单查看当前选项；需要查看规则时，从「设置」中进入路由设置，菜单名称以所装版本为准。
3. 临时选择将目标请求送往代理的全局路由模式，保持节点和测试网址不变。
4. 若恢复访问，回到原模式，检查目标域名、后缀规则以及规则顺序，修正后再测试。

全局路由仍然只处理已经进入客户端的请求，不会让忽略系统代理的应用自动接入。也不要直接删除全部规则：内网地址、公司服务或本地设备可能依赖直连。一次只调整与故障域名有关的规则，才能留下可复现的结果。

第四步：分清 DNS 在哪里失败

DNS 故障至少有两种：节点服务器地址无法解析，或者目标网站域名无法解析。前者会让代理出站本身失败；后者可能只影响某些网站。先在日志里找出报错对应的域名，再决定检查系统解析、内核 DNS，还是浏览器的安全 DNS。

macOS 可用下面的命令查看系统当前解析结果。它只能证明系统解析器这一路的状态，不能代替对内核 DNS 或代理端解析的检查。

dscacheutil -q host -a name example.com

Windows PowerShell 可查询同一个域名。修正系统 DNS 后，如需清理旧缓存，再执行第二条命令；涉及权限时按系统提示处理。

Resolve-DnsName example.com
ipconfig /flushdns

• 仅某个浏览器失败：临时关闭其「安全 DNS」或「通过 HTTPS 使用 DNS」选项做对照，完成测试后再决定是否保留。
• 使用 SOCKS 测试：socks5:// 与 socks5h:// 的域名解析位置不同。curl 的 socks5h:// 会把目标域名交给代理处理。
• 修改 DNS 后仍失败：检查 DNS 请求本身的路由。一个必须经过尚未接通的代理才能访问的解析器，可能形成依赖问题。

第五步：核对节点配置与系统时间

本地入口正常、路由也确实走代理后，再测试节点。先在同一订阅中切换一个已知可用的节点，保持浏览器、网址与路由模式不变。只有一个节点失败时，检查其服务状态和配置；全部节点都失败时，还要考虑当前网络限制、订阅是否过期及内核是否正确启动。

macOS 打开「系统设置」→「通用」→「日期与时间」，检查自动设置；Windows 打开「设置」→「时间和语言」→「日期和时间」，启用「自动设置时间」，必要时点击「立即同步」。明显的时钟偏差可能影响 TLS 证书有效期判断及部分认证流程，但不是所有超时的原因。

按复测结果处理剩余问题

完成上述步骤后，用原来的网址再测一次，记录改动与结果。如果需要求助，提供操作系统、客户端版本、所用内核、出错时间和脱敏日志。订阅链接、用户标识、密码与完整节点配置都不应出现在公开截图里。