Clash 系统代理不生效的排查方法:浏览器与终端分别处理

先做三分钟基础确认

很多「系统代理不生效」其实卡在最基础的一层。动手改任何设置之前,先按顺序把下面四项过一遍,大概率能直接定位问题。

1. 确认客户端确实在运行。托盘区能看到图标、主界面能正常打开,而不是最小化之后已经悄悄退出。
2. 确认节点可用。在代理页对当前节点做一次延迟测试,超时或延迟异常的节点先换掉。系统代理只是入口,节点不通,入口开得再对也没有用。
3. 确认系统代理真的写进了系统。客户端里开关显示「已开启」还不够,要到操作系统里看实际值:Windows 在「设置 → 网络和 Internet → 代理」里看「使用代理服务器」;macOS 在「系统设置 → 网络 → 详细信息 → 代理」里看网页代理与安全网页代理;Linux(GNOME)在「设置 → 网络 → 网络代理」里看是否处于手动模式。地址应为 127.0.0.1,端口与客户端一致。
4. 确认端口对得上。客户端设置页显示的端口必须与系统里写入的端口相同。改过端口却忘了重开开关,是高频翻车点。

系统代理开关到底做了什么

理解原理能省掉一半瞎试。这个开关只做一件事:把「127.0.0.1 + 客户端监听端口」写进操作系统的代理配置。此后,凡是遵循系统代理的应用——绝大多数浏览器和桌面软件——发起连接时会先把流量交给 Clash 内核,由内核按规则分流;不读系统代理的应用则完全不受影响,命令行工具就是最典型的一类。

因此「开关开了没效果」只可能出在三个位置:

• 写入失败:系统里根本没有这条配置,常见于权限不足、被安全软件拦截、被另一个代理软件抢占。
• 应用不读:应用使用自己的代理设置,或者压根不看系统代理。
• 入口不通:配置写对了,但 Clash 的端口没在监听,或当前节点不可用。

第一、三种在上一节的基础确认里就能排掉。剩下的,按浏览器与终端两条线分别处理。

浏览器线路:先查扩展与独立设置

先用一条命令确认 Clash 入口本身是通的。打开终端,显式指定代理访问 IP 查询接口:

curl -x http://127.0.0.1:7890 https://api.ip.sb

返回的应当是节点出口 IP。这一步就失败,说明问题在客户端或节点,与浏览器无关,回到第一节处理;这一步正常而浏览器不生效,再按下面的顺序查:

1. 停用代理类扩展。SwitchyOmega 一类的扩展会接管浏览器代理,优先级高于系统设置。先全部停用再测,确认恢复后逐个启用,定位是哪一个在抢。
2. 用无痕窗口对照。无痕模式默认不加载扩展,若无痕里正常、普通窗口不正常,基本可以断定是扩展在抢代理。
3. 检查 Firefox 的独立设置。Firefox 的代理设置独立于系统面板,若之前手动改过,到「设置 → 网络设置」里确认选回「使用系统代理设置」。
4. 清掉残留的自动配置脚本。系统代理里若留着「使用自动配置脚本(PAC)」地址,浏览器会按脚本走而不是按 Clash 走,把该项关闭。
5. 用出口 IP 做最终对照。打开 IP 查询网站,切换节点后刷新,出口 IP 跟着变,说明链路已通;个别网站仍打不开,那是规则或节点的问题,不再是系统代理的问题。

终端线路:命令行不读系统代理

这是最常见的误会:终端以及里面的 curl、git、npm 默认完全不读系统代理,开关开得再久它们照样直连。终端要走代理,得单独配环境变量。

macOS / Linux(bash、zsh):

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

Windows PowerShell:

$env:http_proxy="http://127.0.0.1:7890"
$env:https_proxy="http://127.0.0.1:7890"

Windows cmd:

set http_proxy=http://127.0.0.1:7890
set https_proxy=http://127.0.0.1:7890

配完执行 curl https://api.ip.sb 验证,返回节点 IP 即生效。还有几个细节值得记住:

• 环境变量只对当前窗口生效,关闭窗口即失效;想长期生效,写进 shell 配置文件(如 ~/.zshrc)。
• 只想让单条命令走代理,在 macOS / Linux 下可以临时加前缀:https_proxy=http://127.0.0.1:7890 curl https://api.ip.sb。
• 访问本机与内网地址应绕过代理:export no_proxy=localhost,127.0.0.1。
• 取消终端代理:macOS / Linux 执行 unset http_proxy https_proxy all_proxy;PowerShell 把对应变量重新赋空即可。
• git 走自己的配置,部分环境下不看环境变量:git config --global http.proxy http://127.0.0.1:7890;取消用 git config --global --unset http.proxy。注意这只影响 HTTP(S)远程,SSH 远程不受影响。

端口冲突:监听失败时开关形同虚设

端口被别的程序占用时,Clash 的端口监听会失败——开关照常能开、系统配置照常写入,但入口后面没有服务在接流量,表现就是「开了跟没开一样」。 先查端口被谁占用。Windows(PowerShell 或 cmd): ```bash netstat -ano | findstr :7890 ``` 有输出说明端口已被占用,最后一列是占用进程的 PID,再用 `tasklist | findstr ` 看具体是哪个程序。macOS / Linux: ```bash lsof -i :7890 ``` Linux 上也可以执行 `ss -lntp | grep 7890`。如果输出里的进程根本不是你的 Clash 客户端,冲突就坐实了。处理有两条路: - 改端口:在客户端设置页把 mixed 端口换成一个空闲值(如 7897),保存后把系统代理开关关掉再开一次,让新端口重新写入系统。 - 让出端口:最常见的占用者是另一个没退干净的代理客户端,或上一次异常退出残留的进程。从托盘退出,或直接结束对应进程。

权限、残留与多客户端互抢

端口正常却仍不生效,往下查这三类高频原因:

1. macOS 授权被取消。首次开启系统代理时系统会弹出授权框要求输入密码,点「取消」则写入失败——开关看着是开的,系统里其实没写。重新拨动开关,这次完成授权。
2. 安全软件拦截。Windows 上部分安全软件会拦截第三方程序修改系统代理,把客户端加入信任列表后重拨开关。
3. 多客户端互抢。同时运行两个代理客户端,后开的会覆盖先开的写入系统代理,先开的那个自然「不生效」。同一时间只保留一个。

还有一个反向问题值得知道:退出客户端前没关系统代理,系统里会一直留着 127.0.0.1:7890 这条配置,而本地已经没有服务在监听,表现为「关了 Clash 反而断网」。解法是重新打开客户端把开关关一次,或手动到系统代理设置里把它关掉。

企业或校园设备若被组策略、描述文件锁定代理设置,手动写入会被立即改回。这种环境不必再折腾系统代理,直接走终端环境变量,或看下一节的 TUN 模式。

终端工具多,直接换 TUN 模式

系统代理的天生短板是「依赖应用配合」:应用不读系统设置,开关就管不到它。日常要在终端里跑 git、npm、docker 的用户,更省心的方案是 TUN 模式——它创建一张虚拟网卡,在系统网络层接管全局流量,不挑应用,命令行工具无需任何配置自动走代理。

基于 mihomo 内核的客户端(Clash Verge Rev、Clash Nyanpasu、FlClash 等)都在设置页提供 TUN 开关;Windows 与 macOS 上首次开启通常需要安装服务模式或完成一次管理员授权。TUN 与系统代理可以同时开,两者不冲突,TUN 在路由层接管,系统代理管应用层,各走各的。

一页复查清单

排查陷入僵局时,按这份清单从头过一遍:

1. 客户端在运行,当前节点延迟测试通过。
2. 系统代理设置里能看到 127.0.0.1,端口与客户端设置页一致。
3. 命令行执行 curl -x http://127.0.0.1:7890 https://api.ip.sb 返回节点 IP。
4. 浏览器停用全部代理类扩展,无痕窗口对照测试。
5. 终端单独配置 http_proxy / https_proxy 环境变量。
6. netstat 或 lsof 确认端口无冲突,改端口后重拨开关。
7. 只保留一个代理客户端,退出前先关系统代理。
8. 终端需求多,改用 TUN 模式接管全局。

绝大多数「系统代理不生效」到第三步就能分出方向:入口通,查应用;入口不通,查客户端与端口。按线排查,比重装客户端快得多。