Clash 故障排查手册:八类症状分章的系统化检修指南

C6 / 系统代理不生效

系统代理不生效:告示不是执法

先说透原理:「系统代理」只是操作系统贴出的一张告示——「建议大家走 127.0.0.1 的这个端口」。应用可以看,也可以装没看见。浏览器一般看,终端从来不看,部分客户端软件有自己的主意。所以这一章必须分对象排查。

浏览器不走代理

确认浏览器的代理设置是「使用系统代理」。Firefox 默认用自己的代理设置,不读系统的,需要手动指到 127.0.0.1 加对应端口。

代理类扩展会覆盖系统设置。装过 SwitchyOmega 一类扩展的,先禁用再测——扩展里残留的旧规则是这一症状的头号嫌犯。

换个浏览器交叉验证:A 浏览器通、B 浏览器不通,锅一定在 B 自己的设置里,别再折腾客户端。

终端不走代理

终端程序只认环境变量,不认系统告示。开着 Clash 用 curl、git、包管理器照样直连,是正常现象不是故障。给当前会话手动挂上:

# macOS / Linux(当前会话有效,端口以你的配置为准)

export https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 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"

注意 git、docker 这类工具还有自己独立的代理配置项,环境变量不一定全覆盖,连不上时去各自的配置文件里再确认一层。

TUN 模式:一次接管所有流量

不想逐个应用伺候,就上 TUN 模式:内核创建一块虚拟网卡,在网络层直接接管全部流量,谁都别想装没看见告示。代价是需要管理员权限或系统授权,首次开启会有安装虚拟网卡的确认步骤。开了 TUN 之后建议关掉系统代理开关,避免流量被处理两遍。浏览器与终端的完整分路排查记录,见博客:系统代理不生效的浏览器与终端分路排查。

TUN 也有它自己的失效方式。虚拟网卡装好了但路由没接管成功时,现象是「开了 TUN 跟没开一样」,多数发生在系统更新后驱动失效,或者设备上还装着别的 VPN 类软件抢占了路由表——把其他 VPN 客户端退干净,再重新开一次 TUN,大多能恢复。另一种是开了 TUN 之后局域网设备互访失效,原因是局域网网段的流量也被隧道接管了,把内网网段加进直连规则即可。

代理开关看着开着,其实早被顶掉了

Windows 上系统代理是写进注册表的一个全局设置,谁都能改。常见的顶掉场景有三种:另一个代理客户端启动时把它改成了自己的端口;某次异常退出没有把设置清干净,残留了一个已经没人监听的端口;企业设备上的策略脚本在登录时又把它刷回公司代理。判断方法很直接——去系统的代理设置页面,亲眼确认地址和端口跟客户端里显示的一致,而不是只看客户端里那个开关是不是绿的。

macOS 上则要注意「按网络服务分别设置」这件事:代理设置是挂在具体网卡上的,给 Wi-Fi 打开的代理,插上网线用以太网时并不生效。多网卡设备上遇到「换了个上网方式代理就失灵」,先去网络偏好里确认当前那张在用的网卡有没有配上代理。

还有一个必须知道的例外:绕过列表。系统代理设置里通常有一份「不使用代理的地址」清单,本机地址与内网网段默认在里面。有人为了排查随手往里加过通配符,之后就会出现「某些域名死活不走代理」的怪现象。这份清单是排查系统代理问题时必看的一栏,别只盯着端口。