故障排查 预计阅读 12 分钟

Clash 系统代理不生效怎么排查:浏览器与终端两条路线分开验证

系统代理开了却没走代理?浏览器与终端的代理机制并不相同。按两条路线分别验证:浏览器查代理设置与扩展冲突,终端查环境变量与代理端口,逐步定位失效环节。

先确认问题发生在哪一层

“系统代理已开启”只说明客户端尝试把 HTTP 和 HTTPS 代理地址写入操作系统设置，不代表所有程序都会读取这项设置。Chrome、Edge 等浏览器通常跟随系统代理；Firefox 可以使用系统设置，也可以保留一套独立代理；终端里的 Git、curl、npm、Python 和容器工具则经常绕过系统代理，改读环境变量或各自的配置文件。

排查时不要先更换节点、重装客户端或反复导入订阅。先把链路拆成四段：Clash 内核是否运行、监听端口是否存在、目标程序是否把连接交给该端口、连接进入 Clash 后命中了什么规则。只要逐层验证，就能判断故障是在客户端、操作系统、应用程序还是规则配置。

观察结果 优先检查 常见原因
浏览器和终端都不能代理 内核、端口、配置状态 内核未启动、端口占用、配置加载失败
浏览器正常，终端直连 终端环境变量与工具配置 命令行程序不读取系统代理
终端显式指定代理正常，浏览器直连 系统代理与浏览器设置 系统代理未写入、扩展覆盖、浏览器使用独立配置
请求进入日志但网站打不开 规则、节点、DNS 与证书错误 命中 REJECT、节点不可用、域名解析异常
普通程序正常，游戏或 UWP 应用异常 TUN、回环限制、UDP 支持 程序不走 HTTP 代理或需要 UDP 转发

记录实际端口，不要直接套用 7890

很多配置使用 7890 作为 mixed-port，但这不是强制值。不同客户端可能显示 HTTP、SOCKS5 和混合端口，端口也可能被配置文件覆盖。打开客户端的「设置」→「端口设置」或「设置」→「Clash 设置」，记录当前正在监听的地址与端口。若界面显示混合端口为 7890，后面的命令才使用该值。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port 同时接受 HTTP 与 SOCKS5 连接。若配置分别使用 port: 7890 和 socks-port: 7891，测试命令必须对应协议。把 SOCKS5 请求发到仅接受 HTTP 的端口，常会得到连接重置或代理握手失败，而不是明确提示“端口类型错误”。

浏览器路线：检查系统代理与扩展覆盖

第一步：核对操作系统里的代理地址

Windows 11 可进入「设置」→「网络和 Internet」→「代理」，查看“使用代理服务器”是否开启。地址通常是 127.0.0.1，端口应与 Clash 当前 HTTP 或混合端口一致。若客户端已经显示系统代理开启，而 Windows 页面仍是旧端口，先关闭客户端里的系统代理开关，再重新开启一次。

macOS 可进入「系统设置」→「网络」→ 当前网络接口 →「详细信息」→「代理」。常见配置会同时勾选“网页代理（HTTP）”与“安全网页代理（HTTPS）”，服务器填写 127.0.0.1，端口填写客户端显示的 HTTP 或 mixed 端口。仅配置 SOCKS 代理时，应用是否使用它取决于应用自身实现。

系统代理里不应填写节点服务器地址。系统设置的目标是本机 Clash 监听地址，例如 127.0.0.1:7890；节点地址、认证信息和传输参数由 Clash 配置处理。把远端节点端口直接写入系统代理，通常无法完成对应协议握手。

第二步：排除浏览器独立代理与扩展冲突

Chrome 和 Edge 默认读取系统代理，但代理切换扩展可以覆盖这一路径。先打开无痕窗口测试；如果扩展允许在无痕模式运行，还需要在扩展管理页暂时停用代理类扩展。重点检查 SwitchyOmega 的替代扩展、企业策略代理、抓包工具和调试代理。多个工具同时控制代理时，最后写入或优先级更高的一方决定实际出口。

Firefox 需要单独查看「设置」→「常规」→「网络设置」→「设置」。选择“使用系统代理设置”才能跟随 Clash 写入的系统值；选择“手动代理配置”时，应填写当前本地端口；选择“不使用代理”则会直接连接。Firefox 的“自动检测此网络的代理设置”也不等同于跟随系统代理。

第三步：用日志确认浏览器请求是否进入 Clash

  1. 打开客户端的「日志」页面，将日志级别保持在 info。
  2. 关闭浏览器中正在自动刷新的页面，减少后台请求干扰。
  3. 新建标签页，访问一个此前未打开的 HTTPS 站点。
  4. 在日志中搜索该域名，观察连接来源、命中规则和最终策略。

如果日志完全没有出现该域名，问题位于浏览器到本地端口之间，应继续检查系统代理、浏览器策略和扩展。若日志出现 MATCH、DOMAIN-SUFFIX 等规则，并显示某个代理组或 DIRECT，说明浏览器已经把请求交给 Clash，接下来要检查规则选择和节点状态。

浏览器显示的缓存页面不能证明当前代理有效。建议使用开发者工具的「网络」面板勾选“停用缓存”，再执行一次硬刷新。也可以同时观察 Clash 的「连接」页面：新连接应显示目标域名、网络类型、上传下载流量与命中链路。

终端路线：显式指定代理验证端口

终端程序的行为不能用浏览器结果推断。最可靠的做法是先让单条命令显式指定代理。如果显式代理成功，再配置环境变量或工具级参数；如果显式代理也失败，则回到本地端口、内核状态和防火墙检查。

使用 curl 直接测试 HTTP 代理

在 Windows PowerShell 5.1 中，curl 可能是 Invoke-WebRequest 的别名，应明确运行 curl.exe。Windows 10 较新版本与 Windows 11 通常自带 curl。假设 mixed-port 为 7890，执行：

curl.exe -v -x http://127.0.0.1:7890 https://example.com/

macOS、Linux、Git Bash 或已安装独立 curl 的环境可执行：

curl -v -x http://127.0.0.1:7890 https://example.com/

详细输出中若出现 Connected to 127.0.0.1，以及对 HTTPS 目标发出的 CONNECT 请求，说明 curl 已连接本地代理。随后返回 HTTP 状态码，且 Clash 日志出现目标域名，代理链路成立。若立即出现 Connection refused，说明该端口没有监听，或者填写了错误端口。

使用 SOCKS5 并让 Clash 解析域名

SOCKS5 测试建议使用 socks5h。末尾的 h 表示域名交给代理端解析，可避免本地 DNS 结果影响测试。端口应填写 SOCKS 端口或 mixed-port：

curl -v --proxy socks5h://127.0.0.1:7890 https://example.com/

socks5:// 与 socks5h:// 的区别主要在域名解析位置。前者通常先在本机解析，再把 IP 交给代理；后者把域名放入 SOCKS 请求。排查域名污染、分流依赖域名或本地 DNS 不稳定时，优先使用 socks5h。

配置当前终端会话的环境变量

在 PowerShell 中，可以只为当前窗口设置代理。关闭窗口后变量失效，适合故障验证：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
curl.exe -v https://example.com/

在 macOS、Linux、WSL 或 Git Bash 中，可同时设置大写与小写变量，因为不同程序读取规则并不完全一致：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
curl -v https://example.com/

还要检查 NO_PROXY 和 no_proxy。如果目标域名、域名后缀或通配范围出现在排除列表中，程序会主动绕过代理。下面的设置只让本机地址直连：

export NO_PROXY=localhost,127.0.0.1,::1
export no_proxy=localhost,127.0.0.1,::1

Git、npm 与 Python 各自可能保存代理

Git 可以读取环境变量，也可能在全局配置中保留旧端口。先查看当前来源，再决定是否修改：

git config --global --get http.proxy
git config --global --get https.proxy
git config --show-origin --get-regexp "http\..*proxy"

需要为 Git 明确设置本地代理时，可使用：

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

npm 可通过 npm config get proxy 与 npm config get https-proxy 检查配置。Python 的 pip 既可能读取 HTTPS_PROXY，也可以通过单次参数测试：

python -m pip install --proxy http://127.0.0.1:7890 包名

工具配置中的旧端口很容易造成误判：浏览器已切换到新的 7890，Git 却仍连接之前的 7897。因此每次更改 Clash 监听端口后，都应复查环境变量、Git 配置、npm 配置、IDE 终端和容器环境。

确认内核与端口是否真正监听

Windows 查看监听进程

在 PowerShell 或命令提示符中运行以下命令，检查 7890 是否处于 LISTENING 状态：

netstat -ano | findstr :7890

输出末尾是进程 PID。可继续查询进程名称：

tasklist /FI "PID eq 进程编号"

如果占用该端口的不是当前 Clash 客户端，修改监听端口或结束冲突进程。若没有任何输出，回到客户端检查内核状态和配置错误。配置解析失败时，图形界面可能仍打开，但代理端口不会按预期建立。

macOS 与 Linux 查看监听地址

lsof -nP -iTCP:7890 -sTCP:LISTEN

Linux 也可以使用：

ss -lntp | grep 7890

监听在 127.0.0.1:7890 时，仅本机程序可访问，这是桌面使用的常见设置。局域网其他设备要连接该端口，需要客户端开启“允许局域网连接”，配置中的 allow-lan 设为 true，并确认监听地址与系统防火墙允许对应网络访问。不要为了排查本机浏览器问题而改成局域网监听。

日志里出现连接后再看规则

Clash 的规则通常按从上到下顺序匹配，先命中的规则生效。域名可能先命中 DOMAIN、DOMAIN-SUFFIX 或规则集；只有前面都未命中时，才进入最终的 MATCH。如果测试请求命中 REJECT，连接会被主动拒绝；命中 DIRECT，则由本机网络直接访问。

切到全局模式后恢复正常，通常说明端口、系统代理和节点链路都成立，故障集中在规则或策略组。此时记录日志中的规则名称和策略组，检查该组是否选中了可用节点。不要长期停留在全局模式来掩盖规则问题，因为局域网地址、软件更新和本地服务也可能被不必要地送入代理。

系统代理解决不了的程序：判断是否需要 TUN

系统代理主要覆盖主动支持 HTTP 或 SOCKS 代理的应用。部分游戏、命令行程序、商店应用、虚拟机、容器和使用自定义网络栈的软件不会读取系统设置。此时，即使浏览器完全正常，这些程序仍可能直连。

TUN 模式通过虚拟网络接口接管更多 IP 流量，再交给 mihomo 等兼容内核处理。它适合无法单独配置代理、需要 UDP 或希望统一接管应用连接的场景。TUN 不是“系统代理增强开关”，其运行依赖系统权限、路由、DNS 劫持方式与虚拟网卡状态。

启用 TUN 前先做三项确认

启用后应检查客户端日志是否出现 TUN 接口建立成功的信息，再观察目标程序的连接是否进入 Clash。Windows 上若只有特定 UWP 应用无法联网，还要考虑应用回环限制；部分客户端提供 UWP Loopback 辅助入口。该问题与普通桌面浏览器的系统代理设置不是同一层。

如果 TUN 开启后出现整个系统无法解析域名，先关闭 TUN 恢复网络，再检查 DNS 配置、虚拟网卡和其他 VPN 冲突。不要同时改动节点、规则、DNS 与路由，否则难以判断是哪一项造成变化。

按结果收口：一组可复现的排查顺序

  1. 确认客户端内核处于运行状态，配置页面没有解析错误。
  2. 从客户端界面读取实际 HTTP、SOCKS5 或 mixed-port，不预设端口号。
  3. 使用 netstat、lsof 或 ss 确认端口正在监听。
  4. 临时切到全局模式，选择一个已确认可用的节点。
  5. 在浏览器路线中核对系统代理、Firefox 独立设置和代理扩展。
  6. 打开 Clash 日志，访问新域名，确认请求是否进入内核。
  7. 在终端用 curl -x 显式指定代理，不先依赖环境变量。
  8. 显式测试成功后，再设置 HTTP_PROXY、HTTPS_PROXY 或工具级代理。
  9. 切回规则模式，依据日志确认命中的规则、策略组与最终出口。
  10. 仅当应用不支持系统代理时，再评估 TUN、UWP 回环或容器网络。

这套顺序的关键是每一步只验证一个变量。浏览器不通而显式 curl 成功，检查系统代理和浏览器；浏览器通而终端不通，检查环境变量与工具配置；两者都无法连接本地端口，检查内核和监听；请求已进入日志但结果异常，检查规则、节点与 DNS。把“系统代理不生效”拆成这些可观察结果后，通常不需要重装客户端。

下载客户端