浏览器能访问，不代表终端已经使用代理。本文以 Windows 上的 v2rayN 为例，先核对实际监听端口，再用显式代理请求隔离故障，最后分别修正浏览器设置和终端环境变量。适合遇到网页正常、命令行超时，或开启系统代理仍无效的用户；排查过程中不需要先重装客户端或反复更换订阅。
一、系统代理与终端代理是两条入口
v2rayN 的系统代理功能主要是把本地代理地址写入操作系统设置，供愿意读取这些设置的应用使用。它并不等于接管本机全部网络连接。浏览器可能读取系统设置，也可能被扩展或企业策略覆盖；命令行工具则可能只读取环境变量、自己的配置文件或启动参数。
这条链路中，系统代理只帮助应用找到入口。请求进入内核后，仍要按路由规则决定直连、代理或阻断。因此，“客户端收到请求”和“请求通过远端节点发出”也不是同一个结论。浏览器访问成功可能来自直连规则，不能单独作为节点可用的证据。
- 系统代理：给支持它的应用提供代理地址，不保证所有终端工具自动采用。
- 本地入站：由内核监听的 HTTP、SOCKS 或混合协议入口，地址与协议必须匹配。
- 路由分流：请求进入内核之后的出站选择，不负责让原本直连的应用自动进入代理。
- TUN 模式：属于另一种流量接入方式。本次先关闭它做隔离测试，避免与系统代理叠加后难以判断入口；测试结束再恢复原设置。
二、先核对 10808 与 10809，不凭旧教程填写
部分旧配置使用 10808 作为 SOCKS 入口、10809 作为 HTTP 入口；其他配置可能只在 10808 上提供混合入口。端口号本身不决定协议，升级、迁移或手动修改后也可能不同。应在 v2rayN「设置」→「参数设置」中核对本地监听相关项目，再结合启动日志确认实际生效值；不同界面的项目名称可能略有差异。
以下 PowerShell 命令只查看这两个示例端口，不会修改配置。如果实际端口不同，请相应替换。输出中的 OwningProcess 是监听进程的编号，可继续用 Get-Process -Id 进程编号 核对归属；真正监听的通常是内核进程，未必是界面进程。
Get-NetTCPConnection -State Listen |
Where-Object { $_.LocalPort -in 10808,10809 } |
Select-Object LocalAddress,LocalPort,OwningProcess| 检查结果 | 可能含义 | 下一步 |
|---|---|---|
| 两个端口都没有监听 | 内核未运行，或使用其他端口 | 查看启动日志与实际参数，不先修改终端变量 |
| 只有 10808 在监听 | 可能是单一协议，也可能是混合入口 | 确认入站类型，再选择 HTTP 或 SOCKS 测试 |
| 监听进程并非当前内核 | 其他程序或残留进程占用端口 | 辨认进程用途后再处理，不盲目结束进程 |
| 只监听 IPv6 回环地址 | 与显式 IPv4 地址不匹配 | 核对监听地址，或使用匹配的 IPv6 回环地址测试 |
三、用显式代理请求隔离终端问题
先跳过环境变量，直接在命令中写入代理地址。Windows PowerShell 中建议明确调用 curl.exe，避免某些环境里的 curl 别名实际调用另一套命令。先执行 curl.exe --version 确认工具存在；下面的目标地址用于说明测试方法，可换成浏览器中正在排查的同一公开 HTTPS 地址，避免两次测试命中不同路由。
# 仅在已确认 10809 是 HTTP 入口时运行
curl.exe -v --connect-timeout 10 --max-time 30 --noproxy "" --proxy http://127.0.0.1:10809 https://example.com/ -o NUL
# 仅在已确认 10808 支持 SOCKS5 时运行
curl.exe -v --connect-timeout 10 --max-time 30 --noproxy "" --proxy socks5h://127.0.0.1:10808 https://example.com/ -o NUL--noproxy "" 用于本次测试时清空绕过列表，避免已有 NO_PROXY 让请求意外直连。若实际 HTTP 混合入口在 10808，应把第一条命令改成该端口，而不是照抄 10809。socks5h 表示由 SOCKS 代理侧处理目标域名解析；socks5 则通常由本地先解析，二者的解析路径不同。
- 先看本地连接。详细输出应显示正在连接指定的回环地址和端口，而不是直接连接目标公网地址。
- 再看代理协商。HTTP 代理访问 HTTPS 时通常会出现 CONNECT 隧道协商；SOCKS 则应看到对应的连接过程。
- 最后看响应。拿到 HTTP 状态码说明至少已收到服务端响应；403 等响应不能简单归为本地端口故障，也不等于目标业务可正常使用。
- 同步看内核日志。确认同一时间的目标域名和出站选择。只有日志明确记录出站时，才能进一步判断是否走了预期节点。
显式代理成功、普通命令失败，优先检查工具的代理读取方式。显式代理也失败，优先检查本地入口、节点连接和路由，不要继续堆叠环境变量。测试时一次只换一个条件，保留命令、时间和结果；这比只记录“网页打不开”更容易复现。
四、浏览器侧检查系统代理、扩展与绕过规则
在 v2rayN 托盘菜单中检查「系统代理」状态。选择「自动配置系统代理」通常表示由客户端写入当前代理设置，并不等于某个 PAC 文件已经生效；「清除系统代理」则会撤销相应设置。「不改变系统代理」只是不主动改写，不代表系统里原有代理已经关闭。
- 在 Windows「设置」→「网络和 Internet」→「代理」中，查看手动代理地址与端口是否和当前 HTTP 或混合入口一致，同时检查是否还启用了设置脚本。
- 暂时停用会接管代理的浏览器扩展。若扩展仍指向旧端口，系统设置即使正确，也可能完全不被采用。
- 检查浏览器是否另设了手动代理。Firefox 可在「设置」→「常规」→「网络设置」→「设置」中核对是否使用系统代理；受组织管理的浏览器还要检查策略限制。
- 关闭并重新打开浏览器，使用同一目标地址重试，同时观察内核日志是否出现新请求。已有连接或缓存页面不能作为新配置生效的证据。
如果浏览器只有启用某个扩展时才能访问，先记录扩展实际使用的协议与端口，再与系统设置比较。这通常说明两条入口不同，而不是系统代理按钮本身失灵。若浏览器与命令行测试了不同域名，也应先统一测试目标，再比较出站结果。
五、终端环境变量要与工具支持范围匹配
许多终端工具读取 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，但各工具支持范围、优先级与配置文件规则并不完全一致。先检查当前进程能看到哪些值，不要直接修改全局环境。下面的 PowerShell 命令只做读取，输出若包含用户名、密码或内部地址，分享前应删去敏感内容。
Get-ChildItem Env: |
Where-Object { $_.Name -match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$' }以下是当前 PowerShell 会话的设置示例，前提仍是 10809 已确认支持 HTTP 代理。若当前已有这些变量，先记下原值，测试结束后恢复。Windows 环境变量名通常不区分大小写；在其他 shell 中则要留意大小写差异，例如 curl 的 HTTP 代理变量采用小写 http_proxy。
$env:http_proxy = 'http://127.0.0.1:10809'
$env:https_proxy = 'http://127.0.0.1:10809'
curl.exe -v --connect-timeout 10 --max-time 30 https://example.com/ -o NULhttps_proxy 的值仍可使用 http://：这里的协议描述的是“工具如何连接代理”，不是目标网页的协议。访问 HTTPS 网站时，工具可通过普通 HTTP 代理建立 CONNECT 隧道，再在隧道内与目标建立 TLS。把它机械改成 https://127.0.0.1:10809，可能导致工具尝试与并不支持 TLS 的本地代理握手。
- NO_PROXY：若包含目标域名、域名后缀或
*，请求可能绕过代理。先保存原值，再做针对性测试，不要永久删除必要的内网例外。 - ALL_PROXY：部分工具把它作为通用代理入口；已有旧值时可能干扰判断，具体优先级以工具文档为准。
- 子进程继承：从当前终端启动的程序通常继承当前环境；已运行的编辑器集成终端未必获得后来修改的系统变量。
- 独立运行环境：WSL 和容器有自己的网络上下文。里面的
127.0.0.1不一定指向 Windows 主机，应按实际网络模式验证，不能直接套用本机地址。
若测试前变量不存在，可用下面的命令清除本次会话设置；若原本有值，应恢复原值而非删除。关闭该 PowerShell 窗口也会结束会话级修改。确认工作后再考虑长期设置，并分别查阅实际命令行工具的代理参数，避免全局变量影响其他任务。
Remove-Item Env:http_proxy -ErrorAction SilentlyContinue
Remove-Item Env:https_proxy -ErrorAction SilentlyContinue六、按报错阶段定位，不把所有超时都归为节点问题
下面保留 curl 常见的报错关键片段；完整行中的地址、耗时和 TLS 后端提示会随环境变化。先判断错误发生在连接本地入口、代理协商，还是访问目标的阶段，再决定改哪个设置。
报错：curl: (7) Failed to connect to 127.0.0.1 port 10809
原因：本地 TCP 连接没有建立，常见于端口未监听或地址不匹配。解法：用监听查询核对当前内核和实际端口，再重试显式代理请求，不先更换远端节点。
报错：curl: (5) Could not resolve proxy
原因：代理服务器名称无法解析，可能是变量里写错主机名或混入了额外字符。解法：检查环境变量完整值，并用已核对的回环地址做显式测试，区分代理地址解析与目标域名解析。
报错：curl: (28) Connection timed out
原因：某个连接阶段超过时间限制，仅凭这一行不能确定是节点、DNS 还是目标服务。解法：结合 -v 最后完成的步骤与同期内核日志，确认本地连接是否已建立，再检查后续出站。
报错：curl: (35) SSL connect error
原因：TLS 建连失败，可能涉及协议误配、中间设备或目标协商。解法：先确认本地代理 URL 的协议，再检查系统时间和完整 TLS 提示；不要把关闭证书验证当作常规修复。
临时提高日志详细程度可以帮助区分路由和连接阶段，但日志可能包含访问域名及节点地址。排查后恢复原日志级别，分享时只保留必要片段，并遮去订阅地址、认证信息和个人访问记录。
七、常见追问与恢复检查
浏览器正常，curl 显式指定代理也正常，为什么普通命令还是失败？
入口与基本连接已经得到验证，下一步检查该工具是否读取环境变量、是否存在自己的代理配置，以及 NO_PROXY 是否命中目标。先在同一终端运行测试，再从这个终端启动实际工具，避免环境继承差异。
改了端口后，为什么浏览器恢复了，终端还连旧端口？
系统代理与终端变量是独立配置。重新读取当前终端的代理变量，替换为实际端口；若工具使用配置文件，也要修改相应项目。已经运行的长驻进程可能需要重新启动。
有 10808 就必须再开一个 10809 吗？
不一定。若 10808 已是混合入口，HTTP 与 SOCKS 客户端可以按各自协议连接同一端口。先确认当前入站能力，再测试，不要为了贴合旧教程重复增加监听项。
客户端退出后，网页反而都打不开了怎么办？
到 Windows「设置」→「网络和 Internet」→「代理」检查是否还指向已停止的本地端口，并清除不再使用的代理设置。终端侧同时恢复测试前的变量，浏览器扩展也要恢复到预期状态。
最后按三个结果收尾：显式请求能连接正确的本地入口；浏览器和终端分别使用预期代理配置；内核日志中的路由出站符合目标。这样才能区分“系统代理设置成功”“应用确实使用代理”和“请求选择了预期出站”，避免下次遇到问题时又从重装开始。
- 记录实际监听地址、端口及协议，保留一条可重复执行的测试命令。
- 恢复排查期间停用的扩展、修改的环境变量与临时日志级别，只保留确认有效的设置。
- 若仍失败，整理工具名称、完整命令、报错阶段及脱敏日志，再继续定位同一条连接链路。