· 故障排查 · 约 9 分钟

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

浏览器不走代理多与插件和 PAC 有关,终端不走代理则要手动设置环境变量。本文按两条线分别给出检查步骤,并说明 TUN 模式何时更省事。

本文速览

系统代理只是向应用提供代理入口，并不接管所有连接。本文面向 Windows 上“v2rayN 已启动，但浏览器或终端仍然直连”的情况：先验证本地监听，再检查浏览器代理来源，最后为终端单独指定代理。通过同一地址、同一入口和内核日志对照，可以区分应用未使用代理、路由选择直连与节点连接失败。

先分清：系统代理、应用代理和路由分流

开启系统代理，不等于所有程序都经过 v2rayN。Windows 的代理设置需要应用主动读取；浏览器通常会读取系统配置，许多命令行工具则依赖自己的参数或环境变量。浏览器能访问而终端失败，并不能直接说明节点有问题。

层次负责什么重点检查
系统代理向遵循系统配置的应用提供代理地址Windows 代理地址、端口与绕过列表
应用代理由浏览器扩展、命令行参数等指定入口是否覆盖系统设置、是否残留旧端口
内核路由决定进入内核的请求走直连还是代理出站规则顺序、命中规则与出站标签
TUN 模式通过虚拟网络接口接收符合接管条件的流量权限、路由、DNS 与排除项

排查时要先固定变量。暂时关闭 TUN，只保留一个正在运行的代理客户端，选择一个节点和一个测试网址。这里使用 https://example.com 演示请求方法，它不是判断地区访问能力的专用测试站；检查实际故障时，应再用原来失败的网址重复测试。

第一步：本地代理端口真的在监听吗？

先确认本地入口，再修改浏览器。下文以已确认支持 HTTP 代理的 127.0.0.1:10808 为示例；这不是对所有版本默认端口的承诺。如果客户端显示其他端口，所有命令都要同步替换，不能把旧教程中的 HTTP 与 SOCKS 端口混用。

127.0.0.1
本机回环地址，不是远端节点地址
10808
本文示例 HTTP 代理入口端口
10 秒
示例命令的连接超时上限

  1. 核对入口

    打开 v2rayN「设置」→「参数设置」，在基础设置中的本地监听相关项目核对端口和入口协议。不同界面版本可能调整分组名称；同时查看主界面状态与内核启动日志，不凭端口数字猜协议。

  2. 确认监听

    在 PowerShell 执行下面的 Test-NetConnection。若 TcpTestSucceeded 为 False，先检查内核是否退出、端口是否填错，再看启动日志。

  3. 核对进程

    用 netstat 找出监听记录和 PID，再到任务管理器「详细信息」核对进程。端口能连接只代表有程序接收连接，不代表接收者一定是当前 v2rayN 启动的内核。

  4. 显式发请求

    使用后文的 curl.exe --proxy 直接指定入口。若这一步成功，再处理系统代理；若失败，优先检查入口协议、节点参数及内核错误。

Test-NetConnection -ComputerName 127.0.0.1 -Port 10808
netstat -ano | findstr ":10808"

内核日志出现 address already in use 时，要先解决端口冲突。不要直接结束不认识的进程；确认所属程序后关闭重复实例，或修改本地端口，并重新应用系统代理设置。

浏览器不走代理：检查系统设置、扩展与 PAC

浏览器排查的关键，是找出当前真正生效的代理来源。以 Edge 或 Chrome 为例，系统设置、代理扩展、启动参数和组织策略都可能影响连接；只看到 v2rayN 的托盘图标，不能证明浏览器正在使用它。

  1. 应用系统代理

    在 v2rayN 托盘菜单进入「系统代理」→「自动配置系统代理」。随后打开 Windows「设置」→「网络和 Internet」→「代理」，核对手动代理的地址与端口是否对应当前本地入口。

  2. 停用代理扩展

    在浏览器「扩展」→「管理扩展」暂时停用管理代理的扩展，再重新启动浏览器。不要只依赖无痕窗口，因为部分扩展被允许在无痕窗口运行，浏览器策略也仍会生效。

  3. 检查自动脚本

    在 Windows 的同一「代理」页面检查「使用设置脚本」。若已启用，核对脚本地址与规则；排查时记录原值，暂时改为单一的手动代理入口，避免 PAC 返回 DIRECT 干扰判断。

  4. 复测并看日志

    关闭并重新打开浏览器，访问同一测试地址，同时观察内核访问日志。请求进入内核后还要检查出站标签；命中直连规则属于路由选择，并不是系统代理失效。

PAC 决定的是“应用把请求交给谁”，内核路由决定的是“收到请求后往哪里发”。这两层都可能让流量直连，但修复位置不同。不要为了让单个网站走代理，就同时重写 PAC、DNS 与全部路由规则。

判断：显式代理成功，优先检查浏览器入口

若同一网址通过指定代理的 curl 请求成功，而浏览器请求没有出现在已启用的访问日志中，下一步应检查扩展、PAC 和浏览器策略；暂时不要更换 VMess、VLESS 或传输参数。

终端不走代理：先用 curl 参数，再设环境变量

命令行程序通常不会因为 Windows 开启系统代理就自动改道。先用显式参数验证，再考虑环境变量。PowerShell 中建议写完整的 curl.exe，避免 Windows PowerShell 里的 curl 别名调用了其他命令，导致参数含义不同。

用一个请求验证 HTTP 代理入口

下面的命令不依赖系统代理。--noproxy 在本次请求中把绕过目标限定为保留测试域名 unused.invalid，避免已有 NO_PROXY 让 example.com 意外直连。该命令不会修改持久设置。

curl.exe --proxy http://127.0.0.1:10808 --noproxy unused.invalid --connect-timeout 10 --verbose --head https://example.com

详细输出中，连接到 127.0.0.1 以及 HTTPS 请求的 CONNECT 过程可用于确认入口；HTTP 响应码则反映后续请求结果。出现响应不等于一定经过远端代理节点，还要对照内核的出站记录。分享日志前应删去认证信息和敏感地址。

为当前 PowerShell 会话设置代理

$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"

curl.exe --connect-timeout 10 --head https://example.com

HTTPS_PROXY 中仍然写 http:// 是合理的：它描述终端到本地 HTTP 代理入口的连接方式，HTTPS 目标通常通过 CONNECT 隧道访问。不要仅因为目标网址使用 HTTPS，就把代理入口擅自改成 https://。

  • 生效范围：这些 PowerShell 赋值只影响当前会话及随后启动的子进程。已经运行的其他终端不会同步获得变量。
  • 工具差异：环境变量不是通用强制规则。具体工具可能要求小写变量、专用配置或命令行参数，需要核对该工具文档。
  • 终端差异：WSL 与容器可能拥有独立网络环境，其中的 127.0.0.1 不一定指向 Windows 主机入口，不能直接照抄地址。
  • SOCKS 入口：只有确认该端口支持 SOCKS5 时才使用对应参数；curl 的 socks5h:// 表示把目标域名交给代理端处理，不应拿它连接仅支持 HTTP 的端口。

测试结束后清除会话变量

Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:ALL_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

清除前请记下原值，已有代理环境的电脑应恢复原配置。尤其不要急着把测试变量写入系统级环境：退出 v2rayN 后，本地端口关闭，继承这些变量的程序可能持续报连接失败。

看到错误信息后，应该改哪一层？

错误信息要结合出现位置理解。同样是“超时”，可能发生在终端连接本地入口、内核连接远端服务器，或远端访问目标站的阶段。下面列出真实错误短语，不同版本可能在前后附加地址、端口和耗时。

报错：curl: (7) Failed to connect

原因：无法建立连接；显式代理测试中若后面指向本地地址，通常是入口未监听或端口错误。解法：核对 curl 输出中的地址，用监听检查确认端口及进程，再重新启动内核。

报错：curl: (5) Could not resolve proxy

原因：代理主机名无法解析，常见于代理变量拼写错误。解法：用 Get-ChildItem Env:*proxy* 检查变量，改为已确认的本机入口后再测试。

报错：curl: (28) Connection timed out

原因：连接阶段超过时间限制，不能单凭该提示判定节点失效。解法：先用详细输出定位停在哪一步，再对照同一时间的内核日志，检查远端连接与路由结果。

报错：ERR_PROXY_CONNECTION_FAILED

原因：浏览器无法建立到所配置代理的连接。解法：检查 Windows 代理与扩展中的旧端口，确认内核启动成功后重开浏览器；不要先修改网站 DNS。

TUN 模式什么时候更省事？

多个应用都不读取系统代理、也不方便单独配置时，TUN 才更值得尝试。它通过虚拟接口和路由接管流量，但仍受所用内核、DNS 策略和排除规则影响；并不意味着任意流量都会无条件进入远端节点。

  • 先留一个基线：确认显式 HTTP 代理测试能成功，记录当前节点和路由配置，再启用 TUN。否则会把入口问题与虚拟网卡问题叠在一起。
  • 按提示授予权限：在 v2rayN 主界面启用 TUN，若提示需要管理员权限，再按提示重新启动；观察虚拟接口、路由和 DNS 初始化日志。
  • 避免双重指定：首次对照测试先清除终端代理变量，并将「系统代理」切换为「清除系统代理」，单独验证 TUN 路径；不要同时改动多个入口。
  • 保留工作网络：测试局域网设备和单位内部域名能否正常访问。若与其他虚拟网卡或工作网络冲突，先关闭 TUN 恢复，再调整排除项。

选择：单个工具用参数，多应用再考虑 TUN

只有一个命令失败时，优先配置该工具的代理；多个应用都需要接管时，再评估 TUN。TUN 能减少逐个配置入口的工作，但不能修复错误的节点参数或不可达的服务器。

常见追问：已开启代理，为什么结果仍不同？

浏览器能用，PowerShell 还是连不上？

先执行带 --proxy 的 curl.exe 命令。若成功，再配置当前终端的代理变量；若仅某个工具失败，检查它自己的代理选项，不要据此更换节点。

日志里有请求，为什么出口没有变化？

检查该请求对应的出站标签。命中 direct 或其他直连出站说明入口已生效，应调整目标域名的路由规则及顺序，而不是反复开关系统代理。

关掉 v2rayN 后浏览器也打不开了？

退出前在托盘「系统代理」中选择「清除系统代理」。若程序已关闭，进入 Windows「设置」→「网络和 Internet」→「代理」恢复原配置，并检查是否残留自动设置脚本。

需要执行 netsh 的代理导入命令吗？

不应把它作为通用修复。WinHTTP 代理与浏览器常用的系统代理配置并不等同；只有确认目标服务使用 WinHTTP 后，才检查其代理状态，避免影响其他系统服务。

最终判断应落在三个可观察结果上：应用是否连接本地入口、内核是否收到请求、该请求选择了哪个出站。按这个顺序收集证据，比反复重装客户端或随机修改 DNS 更容易定位问题。需要重新梳理首次导入与代理设置时，可继续阅读快速上手教程。

下载v2rayN