适用于 v2rayN 已启动，但浏览器打不开目标网站、终端仍直连，或者只有部分应用能连接的情况。先用显式代理请求验证本地入口，再分别检查浏览器代理控制权、系统 PAC 设置和终端环境变量。下文以 Windows 为主，补充 Bash 与 Zsh 的检查命令；示例端口需要替换成客户端实际监听值。
一、先区分系统代理、应用接入与路由分流
v2rayN 的「自动配置系统代理」不是把整台电脑的网络请求强制送入代理。它修改系统代理设置，愿意读取这些设置的应用才会使用本地代理入口。浏览器通常会读取，但扩展、浏览器策略和独立代理设置可能覆盖它；命令行工具是否读取，则取决于工具自身实现。
路由模式位于接入之后。即使选择「全局」，没有进入本地监听端口的请求也不会因此被接管。反过来，已进入内核的请求仍可能被当前路由规则分配为直连。排查时先确定请求有没有进入，再看它走了哪个出站，避免把两层设置混为一谈。
- 浏览器能用、终端不能用：优先检查终端代理参数和环境变量，不急着更换节点。
- 显式代理能用、浏览器不能用：优先检查扩展、PAC 和浏览器独立代理设置。
- 显式代理也不能用：先查端口、内核运行状态和出站日志，系统代理开关暂时不是重点。
- 仅部分域名异常：再核对绕过列表、路由匹配、DNS 与目标站点响应。
二、用明确端口验证本地代理入口
先在 v2rayN 主界面底部状态栏查看本地端口，再到「设置」→「参数设置」核对监听端口及其协议类型。不同版本可能显示 SOCKS、HTTP 或混合监听入口，不能把其他教程的数字直接当成本机配置。以下假设已确认 127.0.0.1:10808 接受 HTTP 代理；若该端口仅支持 SOCKS，请使用后面的 SOCKS 命令。
Windows PowerShell 中先检查端口是否可达，再使用 curl.exe 显式指定代理。写成 curl.exe 可以避开部分 Windows PowerShell 环境中 curl 别名指向其他命令的问题。测试目标使用 https://example.com/，它只用于检查请求链路，不代表特定业务网站的可达性。
Test-NetConnection 127.0.0.1 -Port 10808
curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 5 --max-time 20 -I -v https://example.com/--noproxy "" 在本次命令中清空绕过列表，避免已有 NO_PROXY 干扰测试。若入口仅支持 SOCKS5，改用以下命令；socks5h 表示将目标域名交给代理端处理，而不是先由 curl 在本机解析。
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 5 --max-time 20 -I -v https://example.com/结论：先固定入口，再检查自动接入
显式代理能收到目标站点的 HTTP 响应后，再排查浏览器和终端的自动代理设置。只有 200 Connection established 还不够，它表示隧道建立；还应继续确认 TLS 握手及后续目标响应。目标返回 403 也不等同于本地端口失效。
三、浏览器侧检查扩展控制权与 PAC 残留
下面以 Windows 11 的 Chrome、Edge 和 Firefox 为例。先记录当前代理设置，尤其是工作网络使用的脚本地址。受组织管理的设备应按管理员要求处理，不要直接删除既有配置。无痕窗口不是可靠的扩展隔离测试：部分扩展被允许在无痕模式运行，系统设置也仍会沿用。
-
停用代理扩展
Chrome 打开「扩展程序」→「管理扩展程序」；Edge 打开「扩展」→「管理扩展」。暂时停用会控制代理、自动切换规则或网络请求的扩展，关闭全部浏览器窗口后重新启动，再测试同一目标地址。
-
检查系统入口
Windows 打开「设置」→「网络和 Internet」→「代理」。核对「手动设置代理」中的地址与端口，确保与本地 HTTP 或混合监听入口一致。只填地址的字段使用
127.0.0.1，不要填成完整代理 URL。 -
检查脚本设置
在同一页面检查「使用设置脚本」。个人设备上若仍启用旧 PAC 地址，先记录后临时关闭，只保留本次要验证的一种接入方式。不要同时修改脚本、手动端口与路由预设，否则无法判断是哪一项修复了问题。
-
检查独立代理
Firefox 打开「设置」→「常规」→「网络设置」→「设置」。若目标是跟随 v2rayN 写入的系统设置，选择「使用系统代理设置」；若保留手动代理，则逐项核对端口。不要把 SOCKS 专用端口填进 HTTP 代理字段。
-
重新写入设置
确认本地显式代理测试通过后，在 v2rayN 托盘菜单「系统代理」中先选「清除系统代理」，再选「自动配置系统代理」。随后重新打开 Windows 代理页面，确认地址和端口确实发生了预期变化。
PAC 是根据 URL、域名等条件返回代理选择的脚本，可能对某些请求返回直连。因此“有脚本地址”不能证明所有请求都使用了 v2rayN。若浏览器显示设置被组织管理，或关闭后又自动恢复，应继续检查管理策略和其他正在运行的代理工具，而不是反复点击系统代理按钮。
四、终端侧分别检查变量、协议与进程继承
浏览器已经能访问，不代表终端会自动跟随。对 curl 等工具，先使用上一节的 --proxy 参数验证，再设置当前终端会话的环境变量。这里的 https_proxy 表示“访问 HTTPS 目标时使用的代理”，其值仍可为 http://127.0.0.1:10808：客户端通过 HTTP 代理的 CONNECT 方法建立目标 TLS 隧道，并不要求把代理 URL 改成 HTTPS。
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'
Remove-Item Env:all_proxy -ErrorAction SilentlyContinue
curl.exe --connect-timeout 5 --max-time 20 -I -v https://example.com/以上赋值只修改当前 PowerShell 进程及之后启动的子进程，不会自动改动已经运行的终端、编辑器或后台任务。Windows 环境变量名不区分大小写；在其他系统中则要同时留意大小写版本。不要把含凭据的代理变量输出直接发到公开讨论区。
Bash / Zsh：清理冲突后使用小写变量
env | grep -iE '^(http|https|all|no)_proxy='
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY all_proxy
export http_proxy='http://127.0.0.1:10808'
export https_proxy='http://127.0.0.1:10808'
export no_proxy='localhost,127.0.0.1,::1'
curl --connect-timeout 5 --max-time 20 -I -v https://example.com/curl 对 http_proxy 有大小写方面的特殊处理，跨平台排查时优先使用小写。ALL_PROXY 是部分工具支持的通用代理变量，但不能假定所有工具都读取它；NO_PROXY 则用于绕过代理。若它包含目标域名，甚至设置为 *，就可能出现“变量有值但请求仍直连”。不同工具的匹配语法并不完全一致。
- 只在当前窗口失败：比较两个终端会话中的变量，确认旧窗口是否仍持有旧端口。
- 在编辑器终端失败：若变量在编辑器启动后才改变，重启编辑器，让新建终端继承更新后的环境。
- 在子系统或容器中失败：
127.0.0.1可能指向它自身，而不是宿主机。按实际网络模式确认宿主地址，不能直接照抄宿主回环地址。 - curl 能用但其他工具失败：检查该工具的独立代理配置和官方支持方式，不据此判断 v2rayN 失效。
测试结束后可在 PowerShell 中用 Remove-Item Env:http_proxy,Env:https_proxy,Env:no_proxy -ErrorAction SilentlyContinue 移除本次变量；Bash / Zsh 使用 unset http_proxy https_proxy no_proxy。若测试前已有值，应恢复记录的原值，而不是直接删除。
五、按真实报错定位失败阶段
保留命令行的完整报错及发生时间，并对照 v2rayN 日志中的同一次请求。下面列出 curl 常见原文片段，端口、目标地址和超时毫秒数会随环境变化。错误码能缩小范围，但仍需结合显式代理测试判断，不能只看一句“连接失败”。
报错：curl: (7) Failed to connect to 127.0.0.1 port 10808
原因：curl 未能连接这个本地入口，可能是内核未启动、监听端口不符或连接被本机策略阻止。
解法：核对实际监听端口及内核日志，再用 Test-NetConnection 检查；确认监听进程身份，不要直接关闭整套防火墙。
报错：curl: (5) Could not resolve proxy
原因：代理服务器名称无法解析，常见于代理地址写错，或变量中混入错误格式的主机名。
解法：在本机测试中明确指定已确认的回环地址和端口，检查变量内容，再重试同一条命令。
报错：curl: (28) Connection timed out
原因：连接或传输超过时间限制；仅凭超时不能区分本地入口、远端出站与目标站点故障。
解法：从 -v 输出判断是否已连上本地端口，再对照同一时间的内核日志，检查出站连接及目标响应。
报错：curl: (60) SSL certificate problem
原因：证书验证失败，可能与系统时间、信任链或网络中的 HTTPS 检查有关，不等于请求没有进入代理。
解法：检查系统日期、证书颁发者和系统信任配置，不要把关闭证书验证作为长期修复办法。
如果日志显示请求命中直连规则，就继续核对路由，而不是重装浏览器。VMess、VLESS 等节点协议描述的是代理出站连接，本地应用通常接入 HTTP 或 SOCKS 入口；把节点协议名称写进 http_proxy 并不能建立正确的本地代理连接。
六、用对照结果收尾，避免一次改动多个层级
每次只修改一项设置，并复测同一个目标。建议保存三组结果：显式指定代理的 curl、只依赖环境变量的 curl、关闭代理扩展后的浏览器访问。这样既能定位故障，也便于在更新客户端、改变端口或切换网络之后重现检查过程。
- 显式代理成功，变量测试失败：检查变量值、绕过列表、进程继承及工具配置。
- 两组 curl 都成功，浏览器失败：检查扩展、PAC、独立代理和管理策略。
- 端口可达，但显式代理失败：确认入口协议是否匹配，再看内核日志、节点连接和目标站点。
- 全部恢复：按需逐个恢复扩展和既有脚本；每恢复一项复测一次，找出具体冲突源。
结论：以同一请求的接入证据为准
系统代理按钮的状态只说明设置动作，不证明目标请求走了代理。将客户端日志、curl 详细输出与应用代理配置对应起来，比反复切换全局模式更容易确定故障层级。
需要进一步检查时，可记录操作系统版本、v2rayN 版本、监听协议与端口、失败命令及错误时间。提交日志前移除订阅地址、访问令牌、节点凭据和个人目标地址。订阅更新主要改变连接配置，并不会替终端补齐环境变量，也不会自动解除浏览器扩展的代理控制权。