先确认现象:系统代理到底有没有打开
"系统代理不生效"其实是一个模糊描述,背后可能是完全没走代理、部分程序不走代理、或者走了代理但规则判错了目标节点这三种不同问题。排查前先做一次基础核对,能省掉大半排查时间。
打开客户端主界面,确认左侧或顶部的"系统代理"开关处于开启状态。这一步看起来多余,但在实际支持记录里,相当一部分反馈最终都定位在开关被误触关闭,或者在系统重启、客户端更新之后系统代理设置没有被重新写入。
接着核对端口。Clash 内核默认会监听一个 HTTP(或 HTTP+HTTPS 混合)端口和一个 SOCKS5 端口,常见默认值是 7890(HTTP)与 7891(SOCKS)。打开系统的网络代理设置面板,逐项核对地址与端口是否与客户端配置页显示的一致——如果客户端里把端口改成了自定义值,而系统代理设置还停留在旧端口,流量自然打不进内核。
- 客户端"系统代理"开关是否为开启状态;
- 客户端显示的混合端口/HTTP 端口/SOCKS 端口是否与系统代理设置一致;
- 是否存在多个代理工具同时抢占系统代理设置,后启动的覆盖了前者;
- 节点分组当前选中的策略是否为"直连"或某个已失效的节点。
注意:部分客户端在切换配置文件后会重置系统代理开关,更换订阅或本地配置后建议重新确认一次开关状态,不要凭记忆判断。
浏览器端排查:代理开关、端口与扩展冲突
浏览器是最容易出现"看起来没走代理"的场景,原因往往不在 Clash 本身,而在浏览器自身的网络设置层。不同浏览器对系统代理的采信方式并不完全一致,排查时建议按下面的顺序逐步缩小范围。
核对浏览器是否读取系统代理
多数主流浏览器默认跟随系统代理设置,但也有浏览器提供独立的"内置代理"选项,一旦被启用,就会忽略系统层的设置,转而使用浏览器自己保存的地址。打开浏览器的网络/代理设置页,确认代理模式为"使用系统代理"或"自动检测",而不是被切换成了"手动配置"却填了一个过期的地址。
排查扩展带来的冲突
浏览器扩展是另一个高频雷区。部分翻墙类、广告拦截类或隐私增强类扩展会自行接管代理设置或注入 PAC 脚本,与系统代理产生冲突,表现为"客户端日志里完全没有连接记录"。建议临时禁用所有网络类扩展,刷新页面重新测试;如果恢复正常,再逐个启用扩展定位具体冲突项。
用无痕窗口做对照测试
无痕/隐私窗口默认不加载普通扩展,是排查扩展冲突的便捷手段。如果无痕窗口里代理正常而普通窗口不正常,基本可以确认问题出在扩展或浏览器本地缓存的旧代理配置上,清空浏览器网络设置缓存或重装相关扩展即可解决。
提示:浏览器地址栏输入类似 about:net-internals 或对应浏览器的网络诊断页面,部分浏览器会直接显示当前生效的代理地址与端口,比反复猜测更直接。
终端排查:环境变量、curl 测试与常见误区
终端(命令行)程序通常不读取系统级图形代理设置,而是依赖环境变量。这也是很多人在浏览器代理正常、但 git、curl、npm 等命令行工具依旧连不上外网时感到困惑的原因。
先确认 Clash 客户端是否开启了对应平台的终端代理写入功能(部分客户端在系统代理开启时会同步设置 http_proxy/https_proxy 环境变量,部分则需要手动设置)。可以直接在终端里打印当前环境变量确认:
echo $http_proxy
echo $https_proxy
echo $all_proxy如果输出为空,说明当前终端会话没有代理环境变量,需要手动导出,端口以客户端实际显示的为准:
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:7891"设置完成后,用 curl 发起一次带详细信息的请求,观察是否真的经过了代理:
curl -v -x http://127.0.0.1:7890 https://example.org如果这条命令能正常返回内容,而不带 -x 参数的普通请求失败或走向不同结果,说明代理链路本身没问题,问题出在环境变量没有被目标程序读取上——常见原因是变量只在当前终端会话生效,新开的终端窗口或者由图形界面启动的程序(比如从桌面图标而不是终端启动的应用)根本不会继承这些变量。将导出语句写入 shell 的启动配置文件(如 .zshrc、.bashrc)并重新加载,或者在系统级环境变量里统一设置,可以避免这种"时好时坏"的假象。
Windows 终端的额外一步
Windows 下的 PowerShell 和 CMD 同样不会自动继承图形界面的系统代理设置,需要单独设置会话变量或使用系统环境变量面板永久设置:
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"设置后同样用 curl.exe -v 或 Invoke-WebRequest 做一次验证请求,避免仅凭"浏览器能用"就断定终端也一定通。
绕过规则导致的假性失效
还有一类问题不是代理没生效,而是代理生效了,但流量被规则判定为"应该直连",于是表现得像完全没走代理。这种情况最容易出现在配置文件里的 rules 段或系统代理的绕过列表(bypass list)设置不当时。
系统代理设置里通常会有一个"绕过以下地址"的输入框,默认可能包含 localhost、内网地址段等,如果误将测试用的目标站点或整个通配符加入了绕过列表,该地址就永远不会经过代理,无论客户端本身状态如何。排查时建议先清空绕过列表做一次对照测试,确认问题是否消失。
配置文件层面的规则同样值得核对。一份常见的规则片段如下,重点看是否存在过于宽泛的直连匹配排在了前面:
rules:
- DOMAIN-SUFFIX,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY如果测试目标恰好落在 GEOIP,CN,DIRECT 这类规则之前被命中,即使节点和端口全部正常,该请求也会被直接放行而不经过代理节点。可以打开客户端日志面板,切到详细日志级别,重新访问一次目标地址,观察这条连接命中的具体是哪一条规则、最终使用了哪个策略组——这是判断"规则误判"还是"代理未生效"最直接的证据来源。
排查顺序建议:先看日志命中规则 → 再核对绕过列表 → 再检查端口与开关 → 最后才怀疑节点本身是否可用,按这个顺序定位效率最高,避免一上来就重装客户端或更换订阅。
如果以上都正常,可以考虑 TUN 模式
系统代理依赖的是应用层协议(HTTP/SOCKS)转发,部分程序不遵循系统代理设置、或者使用了自定义网络栈,天然不会经过系统代理,这类情况用系统代理模式很难彻底解决。如果反复排查后确认代理链路本身没问题,只是某些顽固程序绕开了系统代理层,可以考虑切换到 TUN 模式,由内核在网络层接管全部流量,不再依赖单个程序是否读取代理设置。TUN 模式的接管范围更彻底,但对权限与网络适配器配置要求更高,建议在系统代理排查明确无效后再作为下一步方案,而不是一开始就跳过基础排查直接开启。