Clash 系统代理不生效排查:浏览器走不了与终端命令行不走代理分开处理

B-01先分清故障发生在哪一层

“Clash 打开了但不生效”是一句模糊的描述,真正定位问题之前,必须先把“系统代理生效范围”这张图纸摊开看。Clash 客户端在系统代理模式下,做的事情是修改操作系统的网络设置(Windows 的 Internet 选项 注册表项、macOS 的网络服务代理字段),让走系统代理协议栈的程序自动使用本地监听端口(通常是 HTTP 代理 127.0.0.1:7890 或混合端口)。但操作系统的“系统代理”这个开关,只对遵守系统代理设置的程序生效,浏览器、终端命令行、部分后台服务对它的遵守程度并不一致。

因此同一个“不生效”症状,浏览器侧和终端侧的排查思路完全不同,合并处理只会越改越乱。本文按“浏览器侧—系统层—终端侧”三段分开给出检查清单,末尾附验证命令,建议按顺序逐项核对,不要跳步。

B-02浏览器侧排查:扩展冲突与内置代理设置优先级

浏览器不走代理是最常见的反馈,原因集中在三处,按优先级依次排查。

1. 浏览器安装了代理管理类扩展

SwitchyOmega、Proxy SwitchySharp 一类扩展会接管浏览器的代理配置接口,一旦安装并启用,浏览器会优先听扩展的设置而不是操作系统的系统代理。如果这类扩展当前处于“直连”或指向了另一个失效端口的配置,即便 Clash 已经把系统代理设好,浏览器依旧走不通。解决办法是在扩展里新建一条规则指向 Clash 的本地端口,或者临时禁用扩展,观察是否恢复。

2. 浏览器企业策略或历史残留配置

部分浏览器(尤其是企业环境预装的版本)会被组策略强制锁定代理设置,系统代理的变更对它无效。可以在浏览器地址栏访问内置的网络设置页,确认代理来源显示为“使用系统代理设置”而不是“直接连接”或“手动配置”。如果发现是手动配置且指向了旧地址,清除后重启浏览器即可。

3. PAC 脚本模式下端口或规则写反

Clash 客户端部分版本支持通过 PAC(Proxy Auto-Config)脚本方式接管系统代理,如果 PAC 脚本里写的判断逻辑有误,或者监听端口与客户端实际使用的端口不一致,浏览器请求 PAC 脚本得到的结果会是“直连”,表现出来就是完全不走代理。建议先切换回标准的“系统代理”模式(非 PAC)排查一遍,确认问题是否随之消失,再决定是否继续使用 PAC。

B-03系统层排查:确认系统代理确实被写入

浏览器排查无果之后,退一步确认“系统代理”这一层本身是否真的生效,而不是想当然认为 Clash 开关打开了就一定写进去了。

Windows:核对 Internet 选项

打开“控制面板 → 网络和 Internet → Internet 选项 → 连接 → 局域网设置”,确认“为 LAN 使用代理服务器”已勾选,地址与端口与 Clash 客户端设置界面显示的一致。如果这里是空的,说明客户端的“设置为系统代理”开关没有真正写入成功,常见原因是客户端权限不足(需要以管理员身份运行)或者与其他代理软件(如企业 VPN 客户端)产生了写入冲突,后启动的一方会覆盖前者的设置。

macOS:核对网络服务的代理字段

在“系统设置 → 网络 → 当前使用的网络服务 → 详细信息 → 代理”里,检查“网页代理(HTTP)”与“安全网页代理(HTTPS)”是否已勾选并填入了 Clash 的监听地址与端口。macOS 上如果同时有多个活跃的网络服务(比如以太网和 Wi-Fi 都在线),Clash 只写入了当前优先的那一个,而系统实际路由走的是另一个服务,也会造成“设置了但没生效”的假象,需要确认生效的网络服务与 Clash 写入的是同一个。

B-04终端命令行不走代理:环境变量才是关键

终端(Terminal、PowerShell、Bash)里的 curl、wget、git、npm、pip 等命令行工具,绝大多数不读取系统代理设置,而是各自读取一套约定的环境变量,这是终端不走代理最常被忽略的根本原因。系统代理写入成功、浏览器也能正常上网,终端依旧提示超时或连接失败,属于完全正常的现象,不是故障,而是需要额外配置的一步。

需要手动设置的环境变量

大多数命令行工具遵循的是 http_proxy、https_proxy(以及大写形式 HTTP_PROXY、HTTPS_PROXY)这两个环境变量,值填 Clash 客户端的本地 HTTP 代理监听地址。

macOS / Linux(Bash 或 Zsh),临时生效,仅在当前终端会话内有效:

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

如果希望每次打开终端都自动生效,把上面两行追加到 ~/.zshrc 或 ~/.bash_profile 末尾,保存后执行 source ~/.zshrc 使其立即生效。

Windows PowerShell,临时生效:

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"

需要长期生效的场景,可以在 PowerShell 配置文件($PROFILE 指向的脚本)里追加同样两行,或者通过系统环境变量界面新建用户级变量。

部分工具有自己的独立代理配置

git 即使设置了上述环境变量,某些版本仍需要额外配置才能对 HTTPS 协议的仓库生效:

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

npm 与 pip 同理,分别使用 npm config set proxy / npm config set https-proxy,以及 pip install 时追加 --proxy 参数或在 pip.conf 里配置。这类工具的独立配置项优先级高于环境变量,如果环境变量已经设置但工具依旧不走代理,先检查该工具是否存在独立的代理配置项并被覆盖。

B-05用 TUN 模式绕开系统代理与环境变量的双重配置

如果频繁遇到某些程序既不遵守系统代理、也不读取环境变量的情况(常见于部分 GUI 应用、游戏客户端、某些语言运行时的网络库),更省事的做法是切换到 TUN 模式。TUN 模式由 Clash Meta(mihomo 内核)及基于它的客户端(Clash Verge Rev、FlClash 等)支持,原理是创建一个虚拟网卡接管系统全部出站流量,不依赖应用层是否读取代理设置,浏览器与终端命令行会同时生效,无需分别配置。

启用 TUN 模式通常需要客户端申请管理员/Root 权限来创建虚拟网卡,macOS 与部分 Linux 发行版可能需要额外安装网络扩展组件,具体开启步骤在各客户端的“TUN 模式”或“Tun 网卡”设置项中,开启前建议先关闭系统代理选项,避免两种接管方式叠加造成路由异常。

B-06逐项验证:确认修复是否真的生效

改完配置不要凭“感觉能上网了”下结论,用下面几条命令逐一验证,能明确区分是系统代理生效、终端生效,还是仍未生效。

验证终端环境变量是否被读取并成功走代理:

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I

返回 HTTP/1.1 204 No Content 说明代理端口本身工作正常。接着不带 -x 参数、仅依赖已设置的环境变量再测一次:

curl https://www.gstatic.com/generate_204 -I

如果这一次也返回 204,说明环境变量确实被 curl 读取并生效;如果超时或直接失败,说明环境变量没有正确导出到当前会话,回头检查变量名大小写与配置文件是否被正确加载。

验证系统代理端口是否被系统正确注册(Windows PowerShell):

netsh winhttp show proxy

该命令显示的是 WinHTTP 层的代理配置,与浏览器使用的 WinINet 层配置可能不完全一致,如果两者显示的地址不同,通常也是浏览器不走代理的原因之一,需要在浏览器代理设置里手动确认。

• 浏览器不走代理:先查扩展、再查内置代理来源、最后查 PAC 脚本是否写错。
• 系统代理开关打开无效:核对 Windows Internet 选项 / macOS 网络服务代理字段是否真的被写入,以及是否存在多网络服务冲突。
• 终端命令行不走代理:设置 http_proxy / https_proxy 环境变量,git、npm、pip 等工具单独核对各自配置项。
• 反复出现同类问题:考虑切换到 TUN 模式,一次性接管全局流量。