系统代理不生效：浏览器与应用分步排查

界面上的“运行中”通常只表示内核已启动。一次完整访问还需要应用把请求交给内核，内核再按规则选出站。本文把这两段分开排查，避免在浏览器没有接入代理时反复更换节点。对系统代理、TUN 和规则模式还不熟悉，可以先看代理模式与接管范围。

先缩小范围：哪一段没有工作

先保存当前系统代理、PAC、客户端模式和端口的截图，退出其他个人代理或 VPN。记录是否只有某个应用失败，还是所有应用都失败；公司管理的 VPN 和安全设置不要自行卸载或绕过，交由管理员处理。

对比结果	主要排查范围
本地代理端口连接被拒绝	内核未启动、端口错误、监听冲突
显式代理也超时或握手失败	节点、DNS、认证、规则或网络
显式代理成功，浏览器失败	系统代理、PAC、扩展、浏览器设置
浏览器成功，某个应用失败	应用独立代理、协议支持或回环限制
代理设置刚开启就被改回	多客户端冲突、管理策略、安全软件

第一步：显式访问本地代理端口

从客户端设置读取 HTTP 或 mixed 端口，下面的 7890 只是示例。使用自己希望测试的 HTTPS 站点；这里以公开示例站点为目标，不需要登录或提交敏感信息。

# macOS / Linux：保留错误输出，限制等待时间
curl -q --proxy http://127.0.0.1:7890 --noproxy localhost --connect-timeout 10 --max-time 20 --head https://example.com/

# Windows：显式调用 curl.exe；不要把它当成 PowerShell 别名
curl.exe -q --proxy http://127.0.0.1:7890 --noproxy localhost --connect-timeout 10 --max-time 20 --head https://example.com/

--proxy 明确指定入口，--noproxy localhost 将本次绕过名单限定为 localhost，避免环境中已有的名单把示例目标排除。得到有效 HTTPS 响应后，在客户端连接列表中找到该域名，核对使用的出站。规则仍可能把它分配到 DIRECT，因此 HTTP 成功本身不能证明节点已被使用。curl 代理参数说明

如果只看到 200 Connection established，随后又报 TLS 错误或超时，这次测试仍未完成；该行是本地代理接受 CONNECT 的回复。应继续看到目标站点响应，再判断响应是否满足实际任务；403 或登录限制可能证明连接已到站点，却不代表业务可用。

如果目标站点不支持 HEAD，改用普通浏览器访问同一地址，或去掉 --head 完成 GET 测试。失败时保留报错：connection refused 优先查端口，域名错误转入 DNS 排查，证书错误转入 TLS 排查。

第二步：检查操作系统实际保存的设置

Windows：区分手动代理、PAC 与 WinHTTP

打开“设置 → 网络和 Internet → 代理”，检查当前使用的是手动代理还是自动配置脚本。地址和端口应与客户端一致；使用 PAC 时，应检查脚本是否可访问，以及目标是否被脚本设置为直连。不要同时凭印象填写多套配置。

以下命令只查询当前用户常见的代理字段，不会修改注册表：

reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v AutoConfigURL
netsh winhttp show proxy

手动代理中 ProxyEnable 为 0x1、服务器指向本机正确端口，是一条有用线索；字段不存在可能表示该项未配置。PAC、自动发现、策略和应用独立设置仍需分别确认，不能只凭一个字段下结论。WinHTTP 的查询结果对应其自身配置；微软文档明确它服务于使用 WinHTTP API 的应用，不等于所有应用的代理状态。WinHTTP 文档

不要为修复浏览器盲目执行 netsh winhttp reset proxy 或导入配置，这会改变另一套设置，也可能影响后台服务。

macOS：检查正在使用的网络服务

打开“系统设置 → 网络 → 当前使用的网络服务 → 详细信息 → 代理”。Apple 将网页代理、安全网页代理、SOCKS、自动代理配置和绕过列表分别列出，应确认使用的是客户端支持的类型。Apple 代理设置说明

在终端可只读查看：

scutil --proxy
networksetup -listallnetworkservices
# 服务名以你的列表为准；有线连接未必叫 Wi-Fi
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"

切换 Wi-Fi 与有线连接后，正在使用的网络服务可能不同。若客户端仅写入了另一网络服务的代理设置，就会出现开关已开、当前应用仍不通的现象。先核对服务，再通过客户端重新应用其系统代理设置。

第三步：检查浏览器和具体应用

先在客户端恢复规则模式，确认策略组选择的是可用节点；短暂使用全局模式时也要选定全局组出站，测试后恢复原模式。v2rayN 的系统代理负责把部分应用流量送进入站，核心路由负责流量出站，两者是不同层面的设置。v2rayN 系统代理与路由

随后一次处理一个应用：

1. 暂停浏览器代理扩展，检查浏览器是否另有手动代理或 PAC；无痕窗口不一定会禁用全部扩展。
2. 完全退出并重开浏览器，重新访问测试站点，同时观察连接列表。没有新连接时，重点查应用是否接入；有连接但出站错误时，重点查规则与策略组。
3. 对有独立网络设置的应用，明确选择“系统代理”或填写正确的 HTTP/SOCKS 地址，避免把 HTTP 端口填成仅支持 SOCKS 的端口。
4. 命令行工具先使用单次命令参数验证，不急于写入永久环境变量；不同工具读取环境变量的规则并不统一。
5. 个别沙盒或 UWP 应用若报本地回环受限，只对确定受影响的应用查阅其官方说明或客户端提供的回环工具，不批量解除所有应用限制。

网页能打开但登录、语音、游戏仍失败，也可能涉及 UDP、WebSocket、应用协议或目标服务限制。系统代理测试成功不能保证这些流量都受支持。

第四步：确实需要时再测试 TUN

对不读取系统代理的程序，可按照客户端官方流程安装必要服务或授予权限，单独启用 TUN。先记录原设置，退出其他会创建虚拟网卡的个人 VPN，保持一个客户端接管流量。启用后重新打开受影响应用，检查连接、路由和出站日志。

如果 TUN 一启用，本地局域网、公司内网或全部 DNS 就失败，先关闭 TUN 恢复原网络，再查其排除路由和 DNS 配置。不要为了一个应用把防火墙长期关闭、批量删除网络适配器或清空系统路由表。

怎样确认修复完成

用原来失败的应用访问原目标，并在客户端看到对应新连接及正确出站；再访问正常直连的网站，确认规则没有把所有流量意外绕行。退出再启动客户端，检查系统设置和应用访问依然正常。最后关闭代理做一次直连验证，确认不会因为残留的 127.0.0.1 代理导致断网。

排查无效时，恢复记录的系统代理、PAC 和应用设置，关闭临时 TUN，并保留配置文件。求助资料包括操作系统版本、客户端/内核版本、监听端口、显式请求结果、受影响应用、是否使用 PAC/TUN、对应规则和出站；截图遮盖内部域名、订阅和认证信息。这样可以清楚区分“请求没有进入内核”与“进入后失败”。