v2rayN Windows 系统代理无法生效怎么办？按 7 步排查
简答：如果 v2rayN 已选中活动配置但系统代理不生效，先不要急着更换节点：打开 v2rayN 当前设置，记下实际 HTTP、SOCKS 或混合端口，再用 curl 显式指定该端口测试。显式代理能通而普通浏览器或终端不通，通常是应用没有读取 Windows 系统代理、环境变量仍指向旧端口，或请求被绕过；显式代理也不通，则继续检查核心、端口占用、路由和节点日志。本文只讲 Windows，不含 macOS、Linux 和移动端。
定义：v2rayN 系统代理是客户端把本机代理地址与端口写入 Windows 的系统代理设置，遵循该设置的应用可以通过本地 HTTP、SOCKS 或混合入口发送请求；它不等于所有软件都会自动使用代理。
先看 7 步总览：从本地端口开始，不要先换节点
本站是第三方使用指南站，不是任何客户端或品牌的官方网站。下面 7 个步骤与后文 7 个 H2 一一对应，建议每完成一步就记录结果。
- 第 1 步：确认活动配置、核心进程和日志状态。
- 第 2 步：读取 v2rayN 当前实际的 HTTP、SOCKS 或混合端口。
- 第 3 步：检查 Windows 系统代理、PAC 和“不改变系统代理”等模式。
- 第 4 步：用 Test-NetConnection 与 curl 显式验证本地代理入口。
- 第 5 步：定位端口占用、残留进程和其他代理软件冲突。
- 第 6 步：按浏览器、终端、Git、npm、pip、Docker 分别修复应用代理。
- 第 7 步：检查路由、DNS、直连规则，最后清理旧代理并复测。
最快的分流判断是：浏览器和显式 curl 都不通，优先查第 1、2、4、5 步；浏览器能通但终端不通，优先查第 6 步；只有部分域名不通，优先查第 7 步。
| 现象 | 优先判断 | 先做什么 |
|---|---|---|
| 浏览器、curl 都不通 | 本地端口、核心或节点出站 | 检查活动配置和监听端口 |
| curl 显式代理能通，浏览器不通 | 系统代理未写入、浏览器绕过或扩展冲突 | 检查 Windows 代理页并重启浏览器 |
| 浏览器能通，PowerShell 或 Git 不通 | 终端工具没有读取系统代理 | 设置工具自己的代理或环境变量 |
| 只有部分网站不通 | 规则模式、直连规则或 DNS | 查看日志中的出站与 DNS 结果 |
v2rayN 官方仓库说明其为支持 Windows、Linux 和 macOS 的图形客户端，并建议通过项目 Wiki 查看使用文档；本文只截取 Windows 系统代理排查范围，下载和版本请以v2rayN GitHub Releases及当前界面为准。
第 1 步：确认活动配置、核心和日志没有先失败
入口路径：打开 v2rayN 主界面或托盘菜单，确认目标节点已经设为活动配置，再查看当前核心、运行状态和日志窗口。不同版本的菜单名称可能变化，按当前界面显示为准。
- 先确认配置列表中确实有一个活动配置，而不是只导入了订阅但没有激活节点。
- 观察核心是否启动；如果启动失败，先处理配置格式、核心文件、权限或端口错误，不要先改 Windows 系统代理。
- 发起一次新的网页请求，同时观察 v2rayN 日志是否出现对应连接。
- 如果浏览器请求发生时日志完全没有新记录，问题更可能在应用没有使用本地代理；如果日志出现 DNS、直连、代理出站或连接超时，再按日志指向处理。
官方 FAQ 页面包含 Windows 运行环境和常见问题入口；对于具体版本的核心组合、菜单名称或日志位置，资料没有统一保证，遇到版本差异应以当前版本界面和项目文档为准。
不要把“节点延迟测试成功”直接等同于“浏览器请求已经进入代理”。延迟测试、核心启动、本地入站监听和应用是否读取系统代理是不同层次，必须分别验证。
第 2 步：读取当前实际的 HTTP、SOCKS 或混合端口
入口路径：进入 v2rayN 的设置、参数或监听端口相关页面，记录当前显示的本地地址和端口。常见示例可能是 127.0.0.1:端口，但不要把 10808、10809 当成固定值。
- 优先记录界面实际显示的 HTTP 端口；浏览器和 curl 的 HTTP 代理测试使用它。
- 如果应用只支持 SOCKS5，记录 SOCKS 端口；如果版本提供一个 mixed 或混合端口，确认它是否同时接受 HTTP 与 SOCKS5。
- 部分版本可能显示一个统一混合端口，旧版本或特定配置也可能分别显示 HTTP 与 SOCKS 端口。HTTP 端口不要填到 SOCKS 类型栏，反之亦然。
- 检查地址是否为
127.0.0.1或其他本机监听地址。若你没有明确开启局域网共享，不要擅自把地址改成局域网 IP。
v2rayN 源码中的 Windows 系统代理实现显示，客户端会写入 Windows 的代理服务器、绕过地址或自动配置脚本字段；这能说明系统代理写入机制，但不能据此推断每个应用都会遵循它。可查看v2rayN Windows 系统代理实现和v2rayN Global.cs中的当前代码。
结果判断：如果端口为空、端口随核心启动失败而消失，先回到第 1 步；如果端口已显示，继续第 3 步，不要凭旧截图配置应用。
第 3 步：检查 Windows 系统代理、PAC 和常见误操作
入口路径：Windows 设置 → 网络和 Internet → 代理，检查“自动检测设置”“使用设置脚本”和“手动设置代理”。微软支持文档说明，Windows 的手动代理需要填写代理地址和端口，自动配置脚本则使用脚本地址；可参考Microsoft Windows 代理设置说明。
- 回到 v2rayN，确认系统代理模式不是“清除系统代理”或“不改变系统代理”。不同版本的选项名称可能不同，以当前版本显示为准。
- 如果使用手动代理，确认地址和端口与第 2 步记录的 HTTP 或混合入口一致。
- 如果使用 PAC，确认自动配置脚本地址仍然存在，并注意 PAC 可能只让部分域名走代理；测试时可暂时使用明确的系统代理模式或全局路由做短时验证。
- 关闭浏览器中独立代理扩展、启动参数或企业策略造成的代理覆盖，然后完全退出并重新打开浏览器。
- 如果 Windows 代理页显示了旧端口，先在 v2rayN 中重新设置系统代理，再刷新代理设置。
Windows 系统代理主要影响遵循系统网络设置的应用。Firefox、开发工具、终端程序和部分跨平台软件可能使用自己的代理配置；因此“系统代理已开启”只能证明系统设置存在，不能证明目标应用已经读取。
如果只有 Microsoft Store 或其他 UWP 应用无法连接本机代理，可能涉及回环访问限制。微软文档指出，UWP 应用默认可能不允许回环连接；在确认应用包名后，可按官方格式使用 CheckNetIsolation.exe LoopbackExempt -a -n=<PackageFamilyName> 添加豁免。不要直接照抄未知包名，也不要对不明应用批量放开权限，具体方法见Microsoft UWP 回环连接排查文档。
第 4 步：用 Test-NetConnection 和 curl 显式验证本地入口
入口路径：打开 PowerShell，替换下面的 <端口> 为 v2rayN 当前实际 HTTP 或混合端口。
- 先测试本机 TCP 端口：
Test-NetConnection 127.0.0.1 -Port <端口>。如果TcpTestSucceeded为False，说明该端口没有正常接受 TCP 连接，回到第 1、2、5 步。 - 再用 HTTP 代理显式请求：
curl.exe -v --proxy http://127.0.0.1:<端口> https://example.com/。 - 如果你记录的是 SOCKS5 端口，改用：
curl.exe -v --proxy socks5h://127.0.0.1:<端口> https://example.com/。 - 对比不指定代理的结果：
curl.exe -v --noproxy "*" https://example.com/。该命令只用于建立直连基线，不代表目标站点一定允许直连。
curl 官方手册说明，--proxy 可以指定代理，http_proxy、HTTPS_PROXY、ALL_PROXY 等环境变量也会影响代理选择；NO_PROXY 可让指定主机绕过代理。完整参数可查看curl 官方参数说明。
结果判断：显式 curl 成功，说明本机入口至少能接受该测试请求，问题优先落在系统代理、浏览器或终端配置；显式 curl 失败，查看输出中的连接拒绝、超时、TLS、DNS 或代理响应，并结合 v2rayN 日志判断是本地入站还是远端出站。
TCP 端口测试只验证 TCP 监听，不适用于判断 UDP 或 QUIC 协议是否可用。启用 TUN 或 fake-IP 后，流量路径可能改变，显式本地代理测试与 TUN 接管测试应分开记录。
第 5 步：定位端口占用、残留进程和代理软件冲突
入口路径：PowerShell 执行下列命令，把 <端口> 替换为实际端口。
- 查看端口是否监听：
Get-NetTCPConnection -LocalPort <端口> -ErrorAction SilentlyContinue。 - 查看占用端口的进程：
$c = Get-NetTCPConnection -LocalPort <端口> -ErrorAction SilentlyContinue; if ($c) { Get-Process -Id $c.OwningProcess -ErrorAction SilentlyContinue | Select-Object Id,ProcessName,Path } else { '未发现监听进程' }。 - 如果没有结果，说明当前端口没有发现 TCP 监听；检查核心是否启动、端口是否记错，或该入口是否为其他协议。
- 如果进程不是 v2rayN 或其核心，说明可能被其他软件占用。退出冲突软件后重新启动 v2rayN，或在 v2rayN 中改用未占用端口，并同步更新系统代理和应用代理。
- 若有多个 v2rayN 实例、旧核心或其他代理客户端，先全部退出，再只启动一个实例测试。
微软的 Get-NetTCPConnection 文档说明，该命令可查看本地端口、连接状态和 OwningProcess；Windows 网络排查文档也建议使用 Get-NetTCPConnection -LocalPort <port>确认端口是否处于监听状态。
不要为了排查而长期关闭防火墙。若确认是防火墙或安全软件拦截，应针对实际程序、端口和网络配置建立明确规则，并在测试后恢复原有安全设置。
第 6 步：分别修复浏览器、终端、Git、npm、pip 和 Docker
判断原则：如果第 4 步的 curl 显式代理成功，但目标软件仍无法联网，优先认为该软件没有读取 Windows 系统代理，或保存了旧端口。修复后要完全重启目标软件。
浏览器
- 先关闭代理扩展或独立代理设置，确认浏览器使用系统代理。
- 如果浏览器启动参数固定了旧代理，删除旧参数后完全退出浏览器再重开。
- 浏览器对
localhost、回环地址和本地资源可能存在默认绕过规则，不要用本地地址判断公网代理是否生效。
PowerShell 临时环境变量
将 <HTTP端口> 换成实际端口，变量不存在时用容错读取：
Get-ChildItem Env:HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,NO_PROXY -ErrorAction SilentlyContinue
$env:HTTP_PROXY = "http://127.0.0.1:<HTTP端口>"; $env:HTTPS_PROXY = "http://127.0.0.1:<HTTP端口>"; curl.exe -v https://example.com/
清除当前 PowerShell 会话中的旧变量：Remove-Item Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY,Env:NO_PROXY -ErrorAction SilentlyContinue。curl 官方文档说明，协议专用代理变量优先级可能高于 ALL_PROXY，同时存在旧变量时容易出现“改了端口仍不生效”。
Git
- 查看：
git config --global --get-regexp "http\..*proxy" - 设置 HTTP 代理：
git config --global http.proxy http://127.0.0.1:<HTTP端口> - 清除旧配置：
git config --global --unset http.proxy和git config --global --unset https.proxy；不存在时出现提示可忽略。
npm
- 查看：
npm config get proxy与npm config get https-proxy - 设置：
npm config set proxy http://127.0.0.1:<HTTP端口> - 清除：
npm config delete proxy与npm config delete https-proxy
pip
- 临时测试：
python -m pip install --proxy http://127.0.0.1:<HTTP端口> <包名> - 如果不想长期保存，优先使用命令行参数；长期配置位置和作用域以当前 pip 文档为准。
Docker
- Docker Desktop 与 Docker daemon 的代理设置不是同一个入口，先确认你需要代理的是镜像拉取、构建过程还是容器运行时。
- 不要把
127.0.0.1直接当成容器内部的宿主机地址；容器网络环境可能需要使用宿主机可达地址，并且必须确认 v2rayN 是否允许局域网监听。 - 修改 Docker 代理后重启 Docker，再用镜像拉取或构建命令复测。
这些工具的配置项可能因版本变化，本文只给出最短定位路径，不把某个端口或菜单视为固定值。订阅链接、节点链接和日志可能包含凭据，复制到终端或截图前请打码。
第 7 步：检查路由、DNS、直连规则并完成收尾复测
入口路径：在 v2rayN 当前版本的路由、代理模式和 DNS 设置中检查请求最终走向，再从一个全新浏览器会话复测。
- 短时切换到便于验证的路由模式，确认目标域名是否被规则判定为直连；测试完成后恢复你原来的分流策略。
- 查看日志中是否出现目标域名，以及对应的出站结果是直连、代理、阻断还是 DNS 失败。
- 如果只有域名打不开而 IP 或其他域名正常，分别测试 DNS 解析和规则命中；不要仅凭 ping 结果判断 HTTP 或 HTTPS 代理是否可用。
- 如果启用了 TUN，先关闭 TUN 做基础系统代理测试；TUN 需要虚拟网卡、路由和相应权限，不能用普通系统代理测试结果替代 TUN 验证。
- 确认目标应用已经完全退出并重启，避免它继续使用旧的代理端口、旧 PAC 或旧环境变量。
- 修复后若不再需要系统代理，回到 v2rayN 使用“清除系统代理”或当前版本对应的关闭选项，并在 Windows 代理页确认旧地址和端口已清除。
v2rayN 的 Windows 代码包含直接代理、命名代理和自动配置脚本等设置类型；因此系统代理、PAC、应用独立代理和 TUN 是不同接入方式。不要同时开启多个入口后再判断故障来源，建议一次只改一个变量。
最小复测清单：活动配置正常；核心无启动错误；实际端口可监听；显式 curl 有结果；Windows 代理地址端口正确；目标应用已重启；日志能看到新请求；旧代理变量和旧 PAC 已清理。
常见问题
v2rayN 系统代理开启后，为什么浏览器还是打不开网页？
先读取 v2rayN 当前实际 HTTP 或混合端口，再用 curl 显式指定该端口测试。curl 能通而浏览器不通时，重点检查 Windows 代理页、PAC、浏览器扩展、启动参数和旧端口，并完全重启浏览器。
v2rayN 的 10808 和 10809 是固定端口吗？
不能把它们视为固定端口。不同版本、核心或配置可能使用统一混合端口，也可能分别提供 HTTP 与 SOCKS 端口。应以当前 v2rayN 设置页显示的地址和端口为准。
系统代理生效了，为什么 Git、npm 或 pip 仍然连接失败？
这些工具可能读取自己的配置或环境变量，不一定跟随 Windows 系统代理。分别执行 Git、npm、pip 的查看命令，清理旧代理后设置当前 HTTP 端口，或使用一次性的命令行代理参数测试。
浏览器能用，PowerShell 中 curl 却不走代理怎么办？
浏览器和终端的代理来源可能不同。先执行 <code>Get-ChildItem Env:HTTP_PROXY,HTTPS_PROXY,ALL_PROXY,NO_PROXY -ErrorAction SilentlyContinue</code>，检查是否存在旧变量，再用 curl 的 <code>--proxy</code> 参数显式指定当前端口进行对照测试。
v2rayN 系统代理和 TUN 模式应该同时开启吗？
排查时不建议同时改变两种接入方式。先关闭 TUN，确认普通系统代理和本地端口正常，再单独测试 TUN 的虚拟网卡、路由、DNS 和权限；TUN 的结果不能直接用系统代理结果替代。