v2rayN 系统代理不生效排查:浏览器与命令行终端分开检查

一、先区分系统代理、路由与 TUN

v2rayN 的“系统代理”用于向操作系统写入代理设置，并不等于接管所有网络连接。应用必须主动读取这些设置，才会把请求交给本地代理端口。浏览器通常支持系统代理；命令行工具是否读取系统代理、环境变量或自己的配置文件，则取决于工具本身。

排查时先关闭 TUN 模式，避免虚拟网卡接管流量后掩盖系统代理问题。已有其他隧道或企业网络软件时，先记录状态，不要直接删除其配置。本文所有端口都只是测试示例，应替换为当前 v2rayN 实际显示的监听端口。

二、核对本地端口，再测试显式代理

先在 v2rayN 的「设置」→「参数设置」中核对本地监听设置，并查看主界面底部的端口信息。不同版本可能提供独立 HTTP、SOCKS 端口或混合端口，名称与布局也会变化。混合端口可以同时接收相应协议；仅支持 SOCKS 的端口不能直接当 HTTP 代理使用。

这两个数字不是所有版本的固定默认值，也不要求同时监听。以下在 PowerShell 中执行，假设已经确认 127.0.0.1:10808 支持 HTTP 与 SOCKS。使用 curl.exe 而不是 curl，可以避开部分 Windows PowerShell 环境中同名别名带来的参数差异。

# 检查 TCP 端口是否接受连接
Test-NetConnection 127.0.0.1 -Port 10808

# 查看监听进程，核对是否属于当前内核
Get-NetTCPConnection -State Listen -LocalPort 10808 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# 显式指定 HTTP 代理；排除列表只包含本机地址
curl.exe --proxy http://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.com

# 显式指定 SOCKS，并把目标域名交给代理端解析
curl.exe --proxy socks5h://127.0.0.1:10808 --noproxy "localhost,127.0.0.1" --connect-timeout 10 --max-time 20 -I https://example.com

TcpTestSucceeded : True 只说明 TCP 端口能连接。HTTP 代理测试出现 200 Connection established，也只说明 CONNECT 隧道已获准建立；还要继续看后面的 TLS 过程与目标站响应。即使目标返回 403 或 405，也应先辨认它是目标站、代理服务还是中间网络设备返回的，不能只凭状态码判断系统代理失败。

三、浏览器不生效：查扩展和独立代理设置

浏览器扩展可以覆盖系统代理。一个窗口能访问、另一个窗口不能访问时，应先比较浏览器配置文件和扩展状态，而不是把差异直接归因于节点。隐私窗口也不是可靠的“无扩展测试环境”：被允许在隐私窗口运行的扩展仍然可能生效。

1. 启用系统代理

   在 Windows 版 v2rayN 主界面底部「系统代理」菜单选择「自动配置系统代理」。这里的名称是客户端写入系统代理的操作，不应直接理解成 PAC 脚本模式。

2. 核对系统入口

   打开 Windows「设置」→「网络和 Internet」→「代理」，检查手动代理的地址与端口。回环地址应指向本机，端口应与上一步验证成功的 HTTP 或混合入口一致。

3. 停用代理扩展

   在 Chrome「扩展程序」→「管理扩展程序」中暂时停用控制代理的扩展。Edge 可在「扩展」→「管理扩展」操作。随后关闭相关浏览器进程并重新打开，再访问同一个测试地址。

4. 检查独立设置

   Firefox 可在「设置」→「常规」→「网络设置」→「设置」中选择「使用系统代理设置」。若选择了手动代理，先核对其中的端口，不要假定它会跟随 Windows 自动更新。

如果系统代理地址刚被写入就发生变化，可能有另一个程序或组织策略在管理它。关闭重复运行的代理程序后再观察；受管理的设备应联系管理员确认策略。为了让本机浏览器连接代理，无需把监听地址改成 0.0.0.0，也不应以关闭整套防火墙作为首选排查步骤。

四、PAC 模式：检查脚本地址与返回结果

PAC 是自动代理配置脚本。浏览器调用脚本中的 FindProxyForURL(url, host)，根据返回值决定使用代理还是直连。它与 v2rayN 内核中的 routing.rules 是不同层的规则：PAC 可以让请求根本不进入内核；内核路由只能处理已经到达本地入站的请求。

• 检查是否启用脚本：在 Windows「设置」→「网络和 Internet」→「代理」→「使用设置脚本」中查看地址。若当前只打算使用手动系统代理，可在记录原地址后暂时关闭脚本测试。
• 检查脚本可达性：若脚本指向本机端口，应确认对应服务仍在运行。旧客户端退出后留下的脚本地址，可能已无法读取。
• 检查返回值：DIRECT 表示直连，PROXY 127.0.0.1:10808 表示交给该 HTTP 代理入口。脚本引用旧端口时，即使当前内核工作正常也会失败。
• 检查回退逻辑：PROXY 127.0.0.1:10808; DIRECT 包含直连回退。在代理不可用时，浏览器可能尝试直连，表现为部分站点仍能打开。

五、终端不生效：检查环境变量与工具配置

浏览器可用而终端不可用，是常见的设置来源差异。许多命令行工具不会自动读取 Windows 的用户代理设置；另一些工具有自己的配置文件。先用第二节的显式代理命令测试，再决定是否给当前终端会话设置环境变量，不要立刻修改全局环境。

# 查看当前 PowerShell 进程继承的代理环境变量
Get-ChildItem Env: |
  Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }

# 设置当前会话及其后续启动的子进程使用的代理
$env:http_proxy = "http://127.0.0.1:10808"
$env:https_proxy = "http://127.0.0.1:10808"
$env:no_proxy = "localhost,127.0.0.1,::1"

# 不指定 --proxy，验证 curl.exe 是否读取当前环境变量
curl.exe --connect-timeout 10 --max-time 20 -I https://example.com

https_proxy 的名称表示“用于 HTTPS 目标的代理”，其值仍可使用 http://，由 HTTP CONNECT 建立隧道；不应仅因目标是 HTTPS 就把本地入口改成 https://。是否支持环境变量、支持哪些名称，应以具体工具文档为准。curl 对 HTTP 代理变量的大小写有特殊规则，跨平台脚本优先使用小写 http_proxy。

WSL、容器和远程终端具有各自的网络环境。其中的 127.0.0.1 不一定指向 Windows 上的监听入口，不能把这些环境的失败直接当作 Windows 系统代理失败。先在 Windows 本机完成基线测试，再单独核对虚拟网络与宿主地址。不要为此直接开放面向所有网卡的代理端口。

上述赋值只影响当前 PowerShell 会话和之后由它启动的子进程。关闭该会话即可结束这次临时设置；如果原会话已有工作用代理变量，应先记录原值，并在测试结束后恢复。

六、根据报错和日志定位剩余问题

显式代理也失败时，按“本地监听→协议匹配→远端连接→目标响应”顺序检查。以下是可能看到的 curl 报错片段，具体措辞会随版本和系统变化。错误码能够缩小范围，但单条报错通常不足以确定唯一原因。

日志没有新记录不一定代表请求未进入内核：当前日志级别可能不记录每次访问。可在 v2rayN「设置」→「参数设置」中检查日志相关选项，短时启用更详细的日志后重启内核，再发起一次带时间记录的测试。完成后恢复原级别，分享日志前移除订阅地址、身份凭据和其他敏感信息。

• 显式代理成功，浏览器失败：查扩展、独立代理设置、PAC 与组织策略。
• 浏览器成功，终端失败：查环境变量、进程继承和工具自己的配置。
• 端口可连，代理请求失败：查入站协议、出站日志、服务器配置和 DNS。
• 请求可达但出口不符合预期：查 PAC 是否返回直连，以及内核路由实际选择的出站。