外观
代理客户端会修改系统代理、监听本地端口，开启 TUN 模式时还会创建虚拟网卡、接管路由。这些改动和系统、安全软件、其他网络工具之间一旦冲突，就会出现「退出代理上不了网」「端口被占用」「规则不生效」等问题。本页先用「两步速查」表按症状定位冲突类型，简要讲清系统代理与 TUN 模式的工作原理后，按第一步到第十一步的顺序排查：系统代理残留、端口占用、防火墙与权限、应用各自的代理配置、PAC 与单位网络、局域网共享、规则走向，再分系统检查、对照报错、用 netstat 和 lsof 等命令诊断，最后把系统恢复到干净状态并预防冲突再次发生。
两步速查：先定位问题类型
代理冲突的症状看起来都像「上不了网」，但原因分布在系统代理、端口、虚拟网卡、应用配置和规则五个层面。第一步对照下表找到最接近的症状，判断冲突在哪个层面；第二步点「先看哪一节」跳到对应步骤处理。
| 症状 | 可能原因 | 第一个动作 | 先看哪一节 |
|---|---|---|---|
| 退出客户端后浏览器打不开，提示代理连接失败 | 系统代理残留 | 关闭系统设置中的手动代理 | 第一步：客户端退出后检查系统代理残留 |
| 退出客户端后部分应用能用、浏览器不能用 | 系统代理残留，只影响读取系统代理的应用 | 同上 | 第一步：客户端退出后检查系统代理残留 |
| 客户端启动失败，提示端口被占用 | 另一个程序占用端口，或旧进程残留 | netstat -ano / lsof 查占用 | 第二步：排查端口占用和多个网络软件冲突 |
| Windows 上换了好几个端口都无法监听 | 端口落在系统保留范围内 | 查看保留端口范围 | 第二步：排查端口占用和多个网络软件冲突 |
| TUN 模式开不了或开了就断网 | 权限不足、驱动未安装、安全软件拦截 | 按客户端说明授权或加入信任 | 第三步：检查防火墙、权限和网络接管 |
| 开了代理，终端命令仍然连不上 | 终端不读取系统代理 | 设置环境变量 | 第四步：浏览器、终端和应用分别检查代理配置 |
| 关了代理，git、npm 仍然报连接本地端口失败 | 工具配置中残留了代理地址 | 查看并删除工具代理配置 | 第四步：浏览器、终端和应用分别检查代理配置 |
| 某网站始终不走代理 | 规则判定为直连，或应用不走系统代理 | 看连接日志 | 第七步：规则未生效或流量走向异常 |
| 国内网站变慢 | 国内流量被送进了代理 | 检查规则与运行模式 | 第七步：规则未生效或流量走向异常 |
| 开代理后公司 VPN、局域网打印机失效 | TUN 接管路由，与其他网络工具冲突 | 只保留一种接管方式 | 第二步：多个工具争抢路由 |
| 手机提示无法建立 VPN 连接 | 另一个 VPN 类应用占用，或设置了始终开启 | 关闭其他 VPN 应用 | 第三步：检查防火墙、权限和网络接管 |
名词速查
- 系统代理：操作系统提供的一个公共代理设置，浏览器等应用读取后把请求发给指定地址（通常是客户端监听的本地端口）。
- 本地端口：客户端在本机上开放的入口，例如
127.0.0.1:7890，应用把流量发到这里，客户端再转发出去。 - TUN 模式：客户端创建一块虚拟网卡并修改路由，让系统几乎所有流量都先经过客户端，不依赖应用是否支持代理。
- PAC：代理自动配置脚本，由浏览器执行，按规则决定哪些网址走代理。
核心结论
核心结论
- 退出后上不了网先查系统代理：客户端异常退出导致的代理残留是最常见原因。
- 同一时间只跑一个网络工具：多个代理、VPN、加速器同时运行，会争抢端口、系统代理和虚拟网卡。
- 端口冲突用命令定位：Windows 用
netstat -ano，macOS 用lsof，找到占用进程再处理。 - 系统代理不覆盖所有应用：终端、部分游戏和独立设置了代理的应用，需要单独配置或使用 TUN 模式。
- 看连接日志判断流量走向：客户端连接列表里看不到请求，说明流量根本没进客户端。
- 改动之前先记录：恢复时有据可依，避免越改越乱。
代理接管原理简述
代理客户端接管流量有两种基本方式：「请应用把流量交过来」的系统代理，和「在网络层把流量截过来」的 TUN 模式。冲突的种类，基本由这两种方式各自修改了哪些系统设置决定。
两种接管方式对比
| 对比项 | 系统代理模式 | TUN 模式 |
|---|---|---|
| 修改了什么 | 系统代理设置（地址 + 端口） | 新增虚拟网卡、修改路由表，通常还接管 DNS |
| 哪些应用受影响 | 只有读取系统代理的应用 | 几乎所有应用，包括终端和游戏 |
| 需要的权限 | 普通用户权限即可 | 通常需要管理员权限、系统扩展或 VPN 授权 |
| 退出时要恢复什么 | 把系统代理关掉 | 删除虚拟网卡、恢复路由和 DNS |
| 典型冲突 | 代理残留、端口被占用、应用不走代理 | 与其他 VPN 争抢路由、被安全软件拦截、权限不足 |
冲突从哪里来
- 设置未恢复：客户端崩溃、被强制结束或电脑断电时，来不及恢复它改过的设置；
- 资源被争抢：两个工具都想监听同一个端口、都想设置系统代理、都想接管路由；
- 范围不一致：系统代理只覆盖部分应用，用户以为「开了代理」，实际很多程序没走；
- 第三方拦截：安全软件、防火墙把虚拟网卡或本地端口的流量当作可疑行为拦截。
理解这四类来源后，排查就有了方向：先确认有没有残留，再确认有没有争抢，然后看覆盖范围，最后排除拦截。
第一步：客户端退出后检查系统代理残留
客户端开启「系统代理」时，会把系统的代理服务器设置为本机的某个端口（例如 127.0.0.1:7890）。正常退出时客户端会恢复设置；如果客户端崩溃、被强制结束或电脑直接断电，这个设置就会留在系统里，所有遵循系统代理的应用都会去连接一个已经不存在的端口。
典型症状
- 退出客户端后，浏览器提示「无法连接到代理服务器」或
ERR_PROXY_CONNECTION_FAILED； - 部分应用能上网（不读取系统代理），浏览器却打不开；
- 重新打开客户端后又恢复正常。
Windows 检查与清除
- 打开 设置 → 网络和 Internet → 代理；
- 在「手动设置代理」中关闭「使用代理服务器」；
- 如果「使用设置脚本」被打开且不是你主动设置的，一并关闭。
也可以用命令确认：
bash
# 查看当前用户的系统代理开关与地址（ProxyEnable 为 0x1 表示开启）
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable
reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer
# 查看与重置 WinHTTP 代理（部分系统服务使用，重置需要管理员权限）
netsh winhttp show proxy
netsh winhttp reset proxyWinHTTP 代理与「设置」里的代理是两套独立的配置：前者主要供系统服务和部分后台程序使用，普通用户很少修改。如果 netsh winhttp show proxy 显示为「直接访问（没有代理服务器）」，说明这一项没有问题。
macOS 检查与清除
- 打开 系统设置 → 网络 → 选择当前网络 → 详细信息 → 代理；
- 关闭不是你主动开启的网页代理（HTTP）、安全网页代理（HTTPS）、SOCKS 代理和自动代理配置。
命令行方式（把 Wi-Fi 换成你的网络服务名称，可先用第一条命令列出）：
bash
# 列出所有网络服务名称
networksetup -listallnetworkservices
# 查看当前生效的代理设置
scutil --proxy
# 分别查看某个网络服务的 HTTP、HTTPS、SOCKS 代理与自动代理配置
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"
networksetup -getautoproxyurl "Wi-Fi"
# 关闭 Wi-Fi 上的 HTTP、HTTPS 和 SOCKS 代理
networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off
networksetup -setsocksfirewallproxystate "Wi-Fi" offscutil --proxy 输出中 HTTPEnable : 1、HTTPSEnable : 1 或 SOCKSEnable : 1 表示对应代理处于开启状态。注意要对正在使用的网络服务操作：插着网线时是以太网，用无线时是 Wi-Fi，两者的代理设置互相独立。
移动设备
| 系统 | 检查位置 |
|---|---|
| Android | 设置 → 网络和互联网 → VPN，确认没有残留的「始终开启的 VPN」；在当前 Wi-Fi 的详细设置中，确认代理为「无」（菜单位置因品牌而异） |
| iOS / iPadOS | 设置 → 无线局域网 → 点当前网络右侧的 ⓘ → 配置代理，设为「关闭」；设置 → 通用 → VPN 与设备管理，检查 VPN 配置 |
示例场景：浏览器打不开但聊天软件正常
某用户强制结束了代理客户端，之后浏览器提示无法连接到代理服务器，而部分聊天软件可以正常收发消息。原因是聊天软件不读取系统代理，直接联网；浏览器则仍在把请求发给已经不存在的本地端口。关闭系统设置中的手动代理后，浏览器立即恢复。
第二步：排查端口占用和多个网络软件冲突
代理客户端需要在本机监听端口，供浏览器和其他应用连接。如果这个端口已被别的程序占用，客户端会启动失败或提示 address already in use、「端口被占用」。
用命令找到占用端口的进程
以下以端口 7890 为例，换成你的客户端实际使用的端口：
bash
# Windows：查找监听该端口的连接，最后一列是进程 PID
netstat -ano | findstr :7890
# Windows：根据 PID 查看进程名称（把 1234 换成上一步查到的 PID）
tasklist /FI "PID eq 1234"
# macOS：查看监听该端口的进程
lsof -nP -iTCP:7890 -sTCP:LISTEN
# Linux：查看监听端口及对应进程
ss -ltnp | grep 7890PowerShell 中也可以用 Get-NetTCPConnection -LocalPort 7890 -State Listen 查看，OwningProcess 一列即为 PID。
Windows 系统保留端口
在 Windows 上，即使没有任何程序占用，某些端口也可能被系统保留（常见于启用了 Hyper-V、WSL 或 Docker 的电脑），导致客户端无法监听。可用以下命令查看保留范围：
bash
netsh interface ipv4 show excludedportrange protocol=tcp如果客户端端口落在保留范围内，在客户端设置里换一个不在范围内的端口即可。换端口后，记得同步修改手动写过该端口的地方（终端环境变量、git 配置、浏览器代理扩展等），否则它们仍会连接旧端口。
常见冲突来源
| 冲突来源 | 表现 | 处理方法 |
|---|---|---|
| 同时运行两个代理客户端 | 端口被占用、系统代理被互相覆盖 | 只保留一个，完全退出另一个 |
| 旧进程未退出 | 重新打开客户端时提示端口占用 | 结束残留进程，或重启电脑 |
| 游戏加速器、其他 VPN | 虚拟网卡和路由互相覆盖 | 使用代理时关闭其他网络工具 |
| 开发工具（本地服务、容器） | 恰好使用了相同端口 | 修改客户端或该工具的端口 |
| 公司 VPN、远程办公软件 | 与 TUN 模式争抢路由和 DNS | 二者择一，或按单位规定配置直连 |
| 浏览器代理扩展 | 覆盖系统代理，指向错误端口 | 停用扩展或修正其中的地址 |
结束进程前确认身份
用 PID 结束进程前，先确认它是哪个程序。不认识的系统进程不要随意结束，换一个端口通常是更安全的选择。
多个工具争抢路由的识别方法
TUN 模式和其他 VPN 都通过修改路由表接管流量，后启动的工具通常会覆盖先启动的。可以查看路由表确认当前由谁接管：
bash
# Windows：打印路由表
route print
# macOS / Linux：打印路由表（-n 不解析主机名）
netstat -rn如果默认路由（0.0.0.0 或 default）指向的接口不是你预期的那块网卡，或者存在多块虚拟网卡同时声明默认路由，就是争抢的迹象。处理方法是完全退出其中一个工具，而不是手动删除路由条目。
第三步：检查防火墙、权限和网络接管
客户端开启 TUN 模式（也常叫增强模式、虚拟网卡模式）时，需要更高的系统权限来创建虚拟网卡、修改路由。权限不足或被安全软件拦截时，会出现模式无法开启、开启后无法上网等问题。
常见情况与处理
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| Windows 上 TUN 模式开不了 | 没有管理员权限，或驱动 / 服务未安装 | 按客户端说明以管理员身份运行或安装其服务组件 |
| macOS 上无法开启增强模式 | 尚未授权系统扩展或网络扩展 | 按系统提示在系统设置中允许，具体位置以客户端文档为准 |
| 局域网其他设备连不上本机代理 | 防火墙阻止了入站连接，或未开启「允许局域网连接」 | 在客户端开启局域网访问，并在防火墙中允许该应用 |
| 开启后所有流量中断 | 安全软件拦截虚拟网卡流量 | 在安全软件中把客户端加入信任列表 |
| Android 提示无法建立 VPN | 已有其他应用占用 VPN，或设置了始终开启的 VPN | 关闭其他 VPN 类应用 |
| iOS 上代理应用连接后立即断开 | 另一个 VPN 配置处于连接状态，或配置已失效 | 在 VPN 与设备管理中只保留需要的配置 |
Windows 防火墙设置位置
Windows 安全中心 → 防火墙和网络保护 → 允许应用通过防火墙，确认客户端在列表中且勾选了对应的网络类型。客户端首次运行时如果弹出防火墙提示，按你的使用场景选择允许。
公用网络与专用网络
Windows 会把网络分为专用和公用两类。在咖啡店等公共网络中，不建议为代理客户端开放局域网访问。
移动端的 VPN 独占规则
手机系统同一时间只允许一个 VPN 类应用处于连接状态，后连接的会把先连接的断开。Android 的 VPN 设置中还有「始终开启的 VPN」和「屏蔽未使用 VPN 的连接」两类选项：前者会让某个应用在开机后自动占用 VPN，后者会在该 VPN 断开时阻止所有联网。如果你曾为其他应用开启过这两项，代理应用可能无法连接，或在关闭代理后整台手机断网。
第四步：浏览器、终端和应用分别检查代理配置
「系统代理」只是一个公共设置，各个应用是否遵循它由应用自己决定。这就是为什么浏览器能用，终端、某些应用却不行。
各类应用如何获取代理
| 应用类型 | 代理来源 | 说明 |
|---|---|---|
| Chrome、Edge、Safari | 系统代理 | 默认跟随系统设置，代理扩展可覆盖 |
| Firefox | 自身设置 | 在 设置 → 常规 → 网络设置 中可选择「使用系统代理设置」或手动配置 |
| 终端与命令行工具 | 环境变量或自身配置 | 多数不读取系统代理 |
| git、npm 等开发工具 | 自身配置文件 | 可能单独写死了代理地址 |
| 游戏和部分客户端软件 | 通常不支持代理 | 需要 TUN 模式才能接管 |
| WSL、虚拟机、容器 | 各自独立的网络环境 | 需要在其内部单独配置，具体以对应软件文档为准 |
浏览器内的检查
- Chrome / Edge：地址栏打开
chrome://net-internals/#proxy（Edge 为edge://net-internals/#proxy），可以看到浏览器当前实际使用的代理设置，并有重新应用设置、清除失败代理记录的按钮； - Firefox：设置 → 常规 → 网络设置，确认是否被改成了手动代理；
- 代理扩展：停用所有代理类扩展后再测，排除扩展覆盖系统代理的情况。
终端代理的检查与设置
bash
# macOS / Linux：查看当前终端的代理环境变量
env | grep -i proxy
# 临时为当前终端设置代理（端口换成客户端实际端口）
export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890
# 不需要走代理的地址（本机与局域网示例）
export no_proxy=localhost,127.0.0.1
# 取消
unset http_proxy https_proxy all_proxy no_proxyWindows PowerShell 中可用 Get-ChildItem Env:*proxy* 查看，用 $env:HTTPS_PROXY="http://127.0.0.1:7890" 临时设置。上面的设置只对当前窗口有效，关闭终端即失效；如果你把它写进了 ~/.zshrc、~/.bashrc 或 Windows 的用户环境变量，退出代理后它仍然生效，这是「关了代理终端反而连不上」的常见原因。
大小写的差别
不同程序读取的环境变量名称不完全一致：有的只认小写，有的大小写都认。例如 curl 出于安全考虑只读取小写的 http_proxy。为稳妥起见，排查时大小写两种写法都检查一遍。
开发工具的残留代理
退出代理后 git 或 npm 报连接失败，常见原因是之前写入了代理配置：
bash
# 查看 git 全局代理配置，有输出说明设置过
git config --global --get http.proxy
git config --global --get https.proxy
# 删除 git 全局代理配置
git config --global --unset http.proxy
git config --global --unset https.proxy
# 查看 npm 代理配置
npm config get proxy
npm config get https-proxy
# 删除 npm 代理配置
npm config delete proxy
npm config delete https-proxy第五步：排查 PAC、自动检测与单位网络环境
除了手动代理，系统还支持「自动检测设置」和「使用设置脚本」（PAC）两种自动方式；它们与客户端写入的手动代理叠加时，浏览器的实际行为可能和你在客户端里看到的不一致。排查时要把三种设置一起看，而不是只看手动代理开关。
三种代理设置的关系
| 设置 | 作用 | 常见问题 |
|---|---|---|
| 自动检测设置 | 浏览器尝试在网络中自动发现代理配置 | 在某些网络中会拖慢首次连接；在单位网络中通常由管理员开启 |
| 使用设置脚本（PAC） | 按脚本中的规则决定哪些网址走哪个代理 | 脚本地址失效时可能导致所有网页打不开，Chrome 报 ERR_MANDATORY_PROXY_CONFIGURATION_FAILED |
| 手动设置代理 | 所有请求都发给指定的地址和端口 | 客户端退出后残留 |
部分客户端提供以 PAC 方式设置系统代理的选项。如果你曾使用过这种方式，退出客户端后要额外检查「使用设置脚本」是否仍指向本机地址。macOS 上对应的是网络代理设置中的「自动代理配置」，可用 networksetup -getautoproxyurl 查看。
单位或学校网络
在公司、学校等由管理员管理的网络和设备上，代理、DNS 和防火墙设置往往由统一策略下发，部分选项会显示为灰色、无法修改，或修改后被自动恢复。这种情况下：
- 不要尝试绕过或删除单位下发的策略和证书；
- 系统代理被策略锁定时，个人安装的客户端可能无法写入系统代理，属于预期行为；
- 有工作需要时，向网络管理员咨询合规的使用方式，并遵守单位规定和所在地法律法规。
示例场景：开启 TUN 后公司 VPN 断开
某用户在家办公时先连接了公司 VPN，又开启了代理客户端的 TUN 模式，随后公司内网系统全部无法访问。查看 route print 发现默认路由被后启动的虚拟网卡接管，公司 VPN 的路由失效。退出代理客户端后重新连接公司 VPN，内网恢复。这类冲突的根本解决方法是同一时间只使用一种接管方式。
第六步：局域网共享与其他设备连接本机代理
让手机、平板或其他电脑通过本机客户端上网时，冲突点从「本机」扩展到了「局域网」：本机客户端要允许局域网连接，本机防火墙要放行入站流量，其他设备要填对本机的局域网 IP 和端口。任何一环不满足，表现都是「其他设备连不上」。
排查步骤
- 在客户端中开启「允许局域网连接」类选项（名称以客户端为准）；
- 在本机运行
ipconfig（Windows）或ifconfig（macOS）查到本机的局域网 IP，通常为192.168.x.x； - 确认本机防火墙允许客户端在当前网络类型下接收入站连接；
- 在其他设备的 Wi-Fi 代理设置中填写本机局域网 IP 和客户端端口；
- 在其他设备上访问网页测试，同时观察本机客户端连接日志中是否出现来自该设备的请求。
常见失败原因
| 现象 | 原因 |
|---|---|
| 其他设备提示无法连接代理 | 未开启局域网连接，或防火墙拦截了入站 |
| 本机日志里看不到其他设备的请求 | 填写的 IP 或端口错误，或两台设备不在同一网段 |
| 隔一段时间就失效 | 本机局域网 IP 变化（由路由器动态分配） |
| 在公共 Wi-Fi 中无法互通 | 公共网络通常开启了设备隔离 |
不要在公共网络开放局域网连接
在公共 Wi-Fi 中开放本机代理端口，同一网络中的陌生设备也可能连接并使用你的代理。只在可信的家庭网络中使用此功能，用完及时关闭。
第七步：规则未生效或流量走向异常，看连接日志
客户端运行正常，但某些网站没有走代理，或国内网站被送进了代理，这类问题出在分流规则或代理接管范围上。
排查顺序
- 确认运行模式：客户端处于「规则」「全局」还是「直连」模式。切换到全局，如果问题消失，说明是规则匹配问题。
- 查看连接日志：大多数客户端有「连接」或「日志」页面，能看到每个请求命中了哪条规则、走了哪个节点。
- 确认流量是否经过客户端：连接列表里根本看不到该应用的请求，说明这个应用没有使用系统代理，需要 TUN 模式或单独配置。
- 检查浏览器扩展和安全 DNS：代理扩展会绕过系统代理；浏览器的安全 DNS 可能让客户端无法按域名分流。
- 检查自定义规则顺序：规则通常从上到下匹配，靠前的宽泛规则会让后面的规则失效。
常见现象对照
| 现象 | 可能原因 |
|---|---|
| 某网站始终直连 | 规则把它判定为直连，或应用不走系统代理 |
| 国内网站很慢 | 国内流量被规则送进了代理 |
| 全局模式正常、规则模式异常 | 规则缺失或顺序有误，更新订阅或规则集 |
| 连接日志中看不到请求 | 流量没有经过客户端 |
| 日志里只有 IP 没有域名 | 应用自己完成了解析，客户端只能按 IP 匹配规则 |
分流规则的基本原理，见 代理与分流；规则配置方法，见 客户端配置教程；与 DNS 相关的分流异常，见 DNS 解析问题。
第八步：分系统排查步骤
下面把前面各节的检查按系统串成一条完整路径，适合「不知道从哪开始」时从头执行。每一步都写明了正常应该看到什么，出现异常就在这一步停下来处理。
Windows 10 / 11
- 在系统托盘和任务管理器中确认只运行了一个代理类工具，没有残留进程；
- 设置 → 网络和 Internet → 代理，确认「使用代理服务器」与客户端状态一致（客户端退出时应为关闭）；
- 管理员命令提示符运行
netsh winhttp show proxy，正常应为直接访问； - 运行
netstat -ano | findstr :端口号检查端口占用，必要时查看保留端口范围； - 运行
ipconfig /all，确认物理网卡的 DNS 没有被改成失效地址； - 检查 Windows 安全中心和第三方安全软件，确认客户端未被拦截；
- 在终端中用
Get-ChildItem Env:*proxy*检查环境变量是否有残留； - 启动客户端，先用系统代理模式和默认配置测试。
macOS
- 在菜单栏和「活动监视器」中确认只运行了一个代理类工具；
- 运行
scutil --proxy，确认代理开关状态与客户端一致； - 在 系统设置 → 网络 中逐个检查正在使用的网络服务的代理和 DNS；
- 运行
lsof -nP -iTCP:端口号 -sTCP:LISTEN检查端口； - 运行
scutil --nc list列出系统中的 VPN 配置，确认没有其他处于连接状态的 VPN； - 在 系统设置 → 通用 → 登录项与扩展（不同系统版本名称和位置可能不同）中检查网络扩展是否已允许；
- 检查
~/.zshrc等启动文件中是否写死了代理环境变量； - 启动客户端，先用默认配置测试。
Linux
- 运行
ps aux | grep -i加客户端名称，确认没有重复进程； - 运行
env | grep -i proxy检查环境变量，并检查~/.bashrc、~/.profile等文件； - 桌面环境的网络代理设置（如 GNOME 设置中的「网络代理」）与终端环境变量相互独立，两处都要检查；
- 运行
ss -ltnp检查端口占用； - 运行
ip route查看默认路由是否被其他工具接管。
Android
- 设置 → 网络和互联网 → VPN，确认只有一个代理应用，关闭其他应用的「始终开启的 VPN」；
- 在当前 Wi-Fi 的高级设置中确认代理为「无」；
- 检查电池优化设置：系统可能在后台杀掉代理应用，导致 VPN 状态异常，可把代理应用设为不受限制（菜单位置因品牌而异）；
- 重新连接代理应用测试。
iOS / iPadOS
- 设置 → 通用 → VPN 与设备管理，确认只有需要的 VPN 配置，且没有其他处于连接状态的配置；
- 设置 → 无线局域网 → ⓘ → 配置代理，确认为「关闭」；
- 关闭再开启代理应用，必要时删除其 VPN 配置后由应用重新添加。
第九步：对照报错信息
下表集中列出与代理冲突相关的常见报错。Chrome 错误代码取自 Chromium 源码的错误列表，curl 错误号参考 curl 官方文档，其他浏览器和客户端的提示文字因版本和语言而异，以实际显示为准。
浏览器
| 来源 | 报错代码或提示 | 含义 | 处理方向 |
|---|---|---|---|
| Chrome / Edge | ERR_PROXY_CONNECTION_FAILED | 无法连接到代理服务器 | 客户端是否运行、系统代理是否残留、端口是否一致 |
| Chrome / Edge | ERR_TUNNEL_CONNECTION_FAILED | 已连上代理，但无法通过代理建立隧道 | 节点状态、规则，见 节点连接失败 |
| Chrome / Edge | ERR_MANDATORY_PROXY_CONFIGURATION_FAILED | 强制使用的代理配置（如 PAC）失败 | 检查「使用设置脚本」是否指向失效地址 |
| Chrome / Edge | ERR_CONNECTION_REFUSED | 连接被拒绝 | 端口无人监听，或连接被防火墙拒绝 |
| Chrome / Edge | ERR_CONNECTION_RESET | 连接被重置 | 节点、网络干扰或安全软件 |
| Firefox | 「代理服务器拒绝连接」类提示 | 无法连接到所配置的代理 | 检查 Firefox 自身的网络设置与客户端状态 |
| Safari | 无法连接服务器类提示 | 可能为系统代理指向失效端口 | 检查系统代理 |
客户端与命令行
| 来源 | 报错文本 | 含义 |
|---|---|---|
| 客户端日志 | address already in use / bind: ... | 监听端口已被占用 |
| 客户端日志 | 权限不足、无法创建 TUN 设备类提示 | TUN 模式缺少权限、驱动或系统扩展授权 |
| curl | curl: (5) Could not resolve proxy | 代理地址无法解析，多为环境变量写错 |
| curl | curl: (7) Failed to connect to 127.0.0.1 port ... | 本地端口无人监听，客户端未运行或端口不一致 |
| curl | curl: (56) ... | 接收数据失败，常见于代理中途断开 |
| curl | curl: (97) ... | 与代理握手出错，常见于代理类型写错（如把 SOCKS 端口当 HTTP 用） |
| git | 无法连接 127.0.0.1 某端口 | git 配置中残留了代理地址 |
| Windows 系统 | 端口在保留范围内导致监听失败 | 见 Windows 系统保留端口 |
第十步：进阶诊断命令
前面各节的命令已覆盖常见场景，下面把更细致的检查集中在一起，适合需要精确定位或提交反馈的情况。除特别注明的「重置」类命令外，以下都是只读命令。
验证本地端口与代理链路
bash
# 通过客户端本地端口请求测试地址，返回 204 说明代理链路可用
curl -I -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204
# 显式绕过所有代理，测试直连是否正常
curl -I --noproxy "*" https://www.baidu.com
# 通过 SOCKS5 端口测试（端口换成客户端实际的 SOCKS 端口）
curl -I -x socks5h://127.0.0.1:7890 https://www.gstatic.com/generate_204Windows 的 PowerShell 中请输入 curl.exe。socks5h 表示由代理端解析域名，socks5 表示由本机解析，两者结果不同可以帮助判断是否与 DNS 有关。很多客户端提供同时支持 HTTP 和 SOCKS 的混合端口，具体以客户端设置为准。
查看虚拟网卡与路由
bash
# Windows PowerShell：列出网卡，查看是否有多块虚拟网卡处于启用状态
Get-NetAdapter
# Windows：打印路由表
route print
# macOS：查看网络接口（TUN 模式常见为 utun 开头的接口）
ifconfig
# macOS / Linux：打印路由表
netstat -rn系统代理的完整状态
| 系统 | 命令 | 关注点 |
|---|---|---|
| Windows | reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | ProxyEnable、ProxyServer、AutoConfigURL |
| Windows | netsh winhttp show proxy | 是否为直接访问 |
| macOS | scutil --proxy | HTTPEnable、HTTPSEnable、SOCKSEnable、ProxyAutoConfigEnable |
| macOS | networksetup -getautoproxyurl "Wi-Fi" | 是否设置了不认识的 PAC 地址 |
| Linux | env | grep -i proxy | 环境变量 |
重置网络栈（最后手段）
以下 Windows 命令会把 Winsock 目录和 TCP/IP 设置恢复为默认，需要管理员权限，执行后必须重启。它可能影响依赖网络组件的其他软件（如部分 VPN、安全软件），只有在常规恢复步骤都无效时才使用，执行前先记录手动配置过的 IP 和 DNS：
bash
netsh winsock reset
netsh int ip resetmacOS 没有对应的一键命令，通常通过删除并重新添加网络服务、或重启设备来达到类似效果。
第十一步：恢复原配置并验证正常连接
当你改了很多地方、已经说不清哪里出了问题时，最有效的方法是把系统恢复到干净状态，再一步一步重新开启代理。
恢复步骤
- 完全退出所有代理、VPN 和加速器，必要时在任务管理器或活动监视器中确认没有残留进程；
- 关闭系统代理：按本页「系统代理残留」一节的方法检查并清除；
- 恢复 DNS 为自动获取：见 DNS 解析问题；
- 清理终端和开发工具的代理配置；
- 重启设备，让虚拟网卡和路由表恢复默认；
- 验证直连正常：不开任何代理，确认国内网站能正常访问；
- 重新开启一个客户端，先用默认配置和系统代理模式测试，正常后再按需开启 TUN 模式或自定义规则。
验证代理是否正常
bash
# 通过客户端本地端口请求测试地址，返回 204 说明代理链路可用
curl -I -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204Windows 的 PowerShell 中请输入 curl.exe。命令成功而浏览器失败，问题在浏览器或系统代理；命令失败，问题在客户端、节点或订阅，可参考 节点连接失败。
不要从来源不明的地方下载「一键修复」工具
网上流传的网络修复脚本和工具可能修改系统设置或捆绑恶意程序。本页列出的都是系统自带命令，优先使用系统设置和官方客户端提供的功能。
预防冲突的习惯
- 用菜单正常退出客户端：不要直接在任务管理器结束进程，关机前先退出客户端；
- 只安装一个代理客户端：需要切换时先完全卸载或退出另一个；
- 固定一个不在保留范围内的端口，并在一个地方记录它被写进了哪些配置；
- 终端代理按需临时设置：尽量用
export临时设置，而不是写进启动文件； - TUN 模式与其他 VPN 不同时开启：公司 VPN、加速器、远程办公工具使用时先关代理；
- 只从官方渠道下载客户端，见 客户端下载，并请遵守所在地法律法规与单位网络规定。
一页排查清单
按顺序逐项核对，每一项都能对应到本页的某一节；全部核对完仍然异常，问题大概率不在本机系统，而在客户端本身、节点或订阅：
- 只运行了一个代理、VPN 或加速器类工具，没有残留进程；
- 客户端退出状态下，系统手动代理、设置脚本、自动代理配置均已关闭；
- WinHTTP 代理为直接访问（Windows）；
- 客户端监听端口没有被占用，也不在系统保留范围内；
- 物理网卡的 DNS 为自动获取，没有指向失效的本地地址；
- TUN 模式所需的管理员权限、驱动或系统扩展已授权，安全软件未拦截；
- 终端环境变量、shell 启动文件、git 与 npm 配置中没有残留代理地址；
- 浏览器没有启用会覆盖系统代理的扩展；
- 客户端连接日志中能看到目标应用的请求，并命中了预期的规则；
- 用 curl 通过本地端口访问测试地址能得到正常响应。
清单中的每一项都只需要一两条命令或一次设置查看，完整走一遍通常只要十几分钟，比反复重装客户端更高效。
何时联系服务商或客户端开发者
- 恢复干净环境后，只运行一个客户端、使用默认配置仍然异常：如果是节点或订阅问题，联系服务商；
- 客户端本身无法启动、TUN 模式反复失败：查看客户端的官方文档或问题反馈渠道。
反馈时附上这些信息
系统版本类别（如 Windows 11、macOS）、客户端名称、运行模式（系统代理或 TUN）、完整报错或日志原文、netstat / lsof 的端口检查结果，以及你已经做过的恢复步骤。注意遮挡订阅链接和账号信息。
常见问题
退出代理客户端后电脑上不了网怎么办？
多数是系统代理残留：客户端异常退出时没有把系统代理关掉，所有请求仍被发往已经不存在的本地端口。到系统的代理设置里关闭手动代理，或重新打开客户端再正常退出即可。
客户端提示端口被占用是什么意思？
说明另一个程序已经在使用客户端想监听的本地端口，常见于同时运行了两个代理工具或旧进程没有完全退出。用 netstat 或 lsof 找到占用端口的进程，结束它或在客户端里换一个端口。
为什么浏览器能走代理，终端里的命令却不行？
大多数命令行工具不读取系统代理设置，而是读取 http_proxy、https_proxy 等环境变量或自身的配置。需要单独为终端设置环境变量，或使用客户端的 TUN 模式。
可以同时开两个代理或 VPN 软件吗？
不建议。多个软件会争抢系统代理设置、本地端口和虚拟网卡，手机上同一时间也只能有一个 VPN 生效。排查问题时只保留一个网络工具运行。
Chrome 提示 ERR_PROXY_CONNECTION_FAILED 和 ERR_TUNNEL_CONNECTION_FAILED 有什么区别？
前者表示浏览器连不上设置的代理服务器本身，多为客户端没运行或系统代理残留；后者表示已经连上代理，但代理没能建立到目标网站的隧道，问题多在节点或规则。
明明没开代理，为什么 git 或 npm 还在连 127.0.0.1？
这些工具有自己的配置文件，之前写入的代理地址不会随客户端退出而消失。用 git config --global --get http.proxy 和 npm config get proxy 查看，有输出就删除对应配置。
开启 TUN 模式后公司 VPN 或局域网访问失效怎么办？
TUN 模式会接管路由，可能与其他 VPN 或内网路由冲突。同一时间只使用一种接管方式，确需同时使用时，应在客户端中把内网地址段和公司域名设为直连，具体以客户端文档和单位网络规定为准。
网上的一键网络修复工具能用吗？
不建议使用来源不明的工具，它们可能修改系统设置或捆绑恶意程序。本页列出的系统自带命令和设置已能覆盖常见问题，重置网络栈前还应先记录现有配置。
延伸阅读
- 新手第一次买机场：按预算选：代理冲突是本地软件问题，和选哪家机场无关；如果你还没有订阅、正准备购买，可以从这里开始。
- 代理与分流：系统代理、TUN 模式和分流规则的工作方式。
- 客户端配置教程：客户端端口、模式和规则的设置说明。
- Windows 客户端：Windows 平台客户端的安装与设置要点。
- macOS 客户端：macOS 平台客户端的安装与权限授权。
- DNS 解析问题：DNS 设置被修改、退出代理后解析异常的处理。
- 节点连接失败：系统环境干净后仍连不上时的排查。
- TLS 与证书错误：安全软件拦截 HTTPS 导致证书报错时的处理。
更新记录
| 日期 | 变更 |
|---|---|
| 2026-10-07 | 首次发布完整内容 |
| 2026-10-07 | 扩写为深度指南 |
| 2026-10-08 | 按搜索结果页结构调整：开头加「两步速查：先定位问题类型」表，正文小标题改为第一步到第十一步的排查顺序 |
本专题文章
暂无文章，敬请期待。