为什么"系统代理已开启"不等于"所有流量都走代理"
Clash 客户端的"系统代理"开关,本质是修改操作系统或桌面环境的代理配置项(Windows 的 WinINet 设置、macOS 的网络服务代理、Linux 的 GSettings 或环境变量)。这类配置只对主动读取系统代理设置的程序生效,常见的是浏览器、部分 GUI 应用。它不是网络层的强制转发,进程可以选择忽略这个配置——这正是很多人遇到"代理明明开着,某个程序却不走代理"的根本原因。
命令行工具(curl、wget、git、包管理器等)大多不读取系统代理设置,而是读取环境变量(http_proxy、https_proxy、all_proxy)。这意味着系统代理打开与终端能否走代理是两件独立的事,分别需要不同的排查思路。
如果需要不区分程序、统一按流量强制代理,唯一可靠的方式是 TUN 模式——它在网络接口层接管流量,不依赖应用是否主动读取代理配置。本文后面会具体说明系统代理与 TUN 模式的取舍。
排查前先确认一件事:Clash 本身有没有正常运行、有没有可用节点。如果内核未启动或订阅节点全部失效,系统代理配置再正确也无法建立连接。这类问题建议先看运行日志确认代理端口是否监听正常。
浏览器不走代理的排查步骤
浏览器不走代理通常分为四类原因:代理开关未生效、浏览器有独立代理设置、扩展或安全软件拦截、DNS 未走代理导致的部分泄露。按以下顺序逐条排查。
第一步:确认系统代理开关状态
打开 Clash 客户端设置页,确认"系统代理"处于开启状态,并核对监听端口(通常是 HTTP/Mixed 端口,默认 7890 左右)。部分客户端在切换配置文件后会重置该开关,升级或重启系统后也可能被系统恢复为关闭。
- Windows:打开"设置 → 网络和 Internet → 代理",确认"使用设置脚本"或"手动设置代理"是否指向本机地址与对应端口。
- macOS:打开"系统设置 → 网络 → 所选网络服务 → 详细信息 → 代理",确认 Web 代理(HTTP)与安全网页代理(HTTPS)均已勾选并填入正确端口。
- Linux(GNOME 等桌面环境):在"设置 → 网络 → 网络代理"中确认为"手动"模式,而非"自动"或"关闭"。
第二步:排除浏览器自身的独立代理设置
部分浏览器(尤其是 Firefox)默认不跟随系统代理,而是使用自己的连接设置。如果 Firefox 里手动配置过代理或选择了"不使用代理",即使系统代理正常也不会生效。检查路径:
- Firefox:设置 → 常规 → 网络设置 → 确认选中"使用系统代理设置"。
- Chrome / Edge / 大多数基于 Chromium 的浏览器:默认跟随系统代理,一般不需要单独设置,但企业策略或某些扩展可能覆盖这一行为,可在浏览器的代理设置页确认是否被锁定。
第三步:检查扩展与安全软件的拦截
广告拦截类扩展、企业安全客户端、部分 VPN 客户端可能会强制修改网络请求路径或劫持代理设置。可以先在浏览器的隐私/无痕模式下(默认禁用扩展)测试是否恢复正常,如果恢复正常则说明问题出在某个扩展上,逐个禁用排查即可定位。
第四步:确认 DNS 请求是否也走了代理
浏览器"能连上但很慢"或"部分网站正常、部分网站异常",很多时候是 DNS 泄露导致的——网页数据走了代理,但域名解析走的是本地 DNS,被运营商或本地网络提前干扰。这种情况不算严格意义上的"代理不生效",但表现类似,建议同时检查规则模式是否开启了 DNS 劫持或 fake-ip 模式。
如果只想验证代理链路本身是否通畅,建议直接访问 IP 查询类页面观察出口 IP 是否变化,而不是先测试某个具体网站——具体网站异常可能是规则分流把它划到了直连组,并不代表代理整体失效。
命令行终端不走代理的排查步骤
终端工具是否走代理,取决于该工具是否读取代理环境变量,以及变量是否正确设置并被当前会话继承。排查顺序如下。
第一步:确认环境变量是否已设置
在 macOS / Linux 终端执行:
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:7890"Windows 下使用 PowerShell 时对应命令为:
$env:http_proxy="http://127.0.0.1:7890"
$env:https_proxy="http://127.0.0.1:7890"第二步:确认变量写入了正确的配置文件
临时用 export 设置的变量只在当前终端会话有效,新开的终端窗口不会继承。如果需要长期生效,应写入 shell 的启动配置文件,例如 ~/.zshrc、~/.bashrc 或 ~/.bash_profile(具体取决于使用的 shell 和系统),修改后需要执行 source ~/.zshrc 或重新打开终端才能生效。
第三步:确认工具本身是否读取这些变量
不同工具遵循的规则不完全一致:
curl、wget:默认读取http_proxy/https_proxy,大小写通常不敏感但建议统一小写。git:不自动读取系统环境变量转发,需要单独配置git config --global http.proxy与https.proxy。- 包管理器(如 npm、pip、apt):各自有独立的代理配置项,环境变量未必被识别,通常需要在对应的配置文件里单独声明代理地址。
- Docker、Docker Compose:容器内进程默认不共享主机的环境变量,需要在 Docker 配置或
docker-compose.yml中显式传入代理变量,或者为 Docker daemon 单独配置代理。
第四步:用最小化命令验证代理链路
排除工具本身逻辑干扰,直接用 curl 测试代理端口是否真的可用:
curl -x http://127.0.0.1:7890 -I https://www.example.com如果这条命令能正常返回响应头,说明代理端口本身工作正常,问题出在具体工具没有正确读取到代理配置;如果连这条命令都超时或报错,说明问题在 Clash 客户端或节点本身,应回到客户端检查节点连通性与监听端口。
建议把"用 curl 加 -x 参数手动指定代理测试"作为终端类问题的第一步验证动作——它能快速把问题范围缩小到"代理端口"还是"具体工具配置"两者之一,避免在工具自身的复杂配置项里绕圈子。
系统代理开关与 TUN 模式该怎么选
系统代理和 TUN 模式是两种覆盖范围完全不同的机制,选择前建议先明确自己的需求场景。
系统代理开关的特点
系统代理只修改操作系统或浏览器读取的代理配置项,优点是开销小、切换灵活、对系统网络栈没有侵入性;缺点是覆盖不完整——任何不主动读取系统代理设置的程序(部分命令行工具、游戏、某些后台服务)都不会被代理覆盖,需要额外手动配置环境变量或应用内代理选项。
TUN 模式的特点
TUN 模式会在系统中创建一个虚拟网络接口,由 Clash 内核接管经过该接口的全部流量,不区分应用是否主动配置代理。这意味着命令行工具、后台服务、游戏等原本"不走系统代理"的流量也会被统一处理,更接近全局代理的效果。代价是配置项更复杂(通常需要额外开启进程模式、处理路由表或防火墙规则),部分系统需要管理员/root 权限才能创建虚拟网卡。
两种方式的取舍建议
- 只需要浏览器和常见桌面应用走代理:优先用系统代理开关,配置简单,出问题也容易定位到具体软件。
- 需要命令行工具、脚本任务、后台服务统一走代理,又不想逐个配置环境变量:优先考虑 TUN 模式,一次性覆盖大部分场景。
- 同时需要精细的分流控制(某些程序直连、某些程序走代理):TUN 模式配合进程规则或 IP 段规则,比给每个工具单独设置代理更省心,但需要花时间理解规则配置的写法。
- 出现连接异常时,先确认当前用的是系统代理还是 TUN 模式,再针对性排查——两者的故障现象和检查路径并不相同,混着排查容易走弯路。
如果开启 TUN 模式后仍有部分流量绕过代理,通常是路由表或防火墙规则冲突导致,可先临时关闭其他 VPN、网络加速类工具后重新测试,排除多个网络接管工具互相冲突的可能。
常见误判场景与排查心态
系统代理相关问题里,有几类现象经常被误判为"代理不生效",实际原因并不在代理配置本身:
- 规则分流导致某网站走了直连:如果配置文件里有针对特定域名或 IP 段的直连规则,该网站不经过代理是预期行为,不属于故障。
- 节点本身连接异常:代理配置正确但节点失效,表现同样是"网页打不开",需要先在客户端里单独测试节点延迟与连通性。
- DNS 缓存未刷新:切换代理或节点后,本机 DNS 缓存可能仍指向旧的解析结果,建议排查前先清空系统 DNS 缓存或重启网络服务。
- 多个代理工具同时运行:如果同时开着其他代理软件或 VPN,系统代理设置可能被后启动的工具覆盖,建议排查时先确认当前只有一个工具在修改网络配置。
整体的排查思路可以概括为:先确认 Clash 本身运行正常且节点可用,再确认系统代理开关或环境变量配置正确,最后确认具体应用是否遵循这些配置。按这个顺序逐层验证,能避免在错误的层级里反复调整而找不到问题根源。