故障排查 预计阅读 12 分钟

Clash 系统代理不生效排查:浏览器不走代理与终端命令行设置方法

分浏览器与终端两条线排查系统代理失效:检查代理扩展冲突、PAC 与例外列表,并给出各系统终端设置环境变量的做法。

先区分系统代理、规则模式与 TUN

打开客户端的“系统代理”，通常只是把操作系统的 HTTP、HTTPS 代理地址改为本机监听端口。应用是否读取这组设置，取决于应用自身。浏览器可以遵循系统设置，终端里的 curl、Git 和包管理器则可能使用环境变量或独立配置。因此，“网页能打开、终端连接超时”并不直接说明节点失效。

Clash 或 mihomo 内核的“规则模式”决定进入内核的连接如何分流；“全局模式”通常把这些连接交给全局代理组。两者都不会自动让所有进程进入内核。TUN 则通过虚拟网卡与路由接管流量，是另一条入口，仍然受路由、DNS、进程排除和规则影响。

现象优先检查判断依据
浏览器和终端都失败内核、监听端口、配置是否启用显式指定代理的 curl 是否能连接本地端口
浏览器正常，终端失败环境变量与工具配置同一终端显式指定代理后是否成功
终端正常，浏览器失败代理扩展、PAC、例外列表浏览器请求是否出现在连接面板
请求进入内核但仍然直连匹配规则与代理组选择连接记录是否显示 DIRECT

建立基线：确认本机端口和显式代理请求

先读客户端的实际监听值

进入客户端设置中的端口或入站设置页，记录 HTTP、SOCKS、Mixed 端口及当前运行内核。不同客户端菜单名称不同，应以实际界面和运行配置为准。下面统一用 127.0.0.1:7890 作为 Mixed 端口示例；7890 不是所有客户端的固定值。不要把控制接口端口当成代理端口，external-controller 提供的是管理 API。

# 用于说明端口含义，不要直接覆盖完整订阅配置
mixed-port: 7890
allow-lan: false
mode: rule

Mixed 端口可接受 HTTP 和 SOCKS 代理连接。若配置只有 port: 7890，应按 HTTP 代理使用；若只有 socks-port: 7891，则需要使用对应的 SOCKS 地址。仅供本机访问时，不必为了排障开启局域网访问，也不要把代理监听端口暴露到公共网络。

用一次请求分开“入口故障”和“出口故障”

在 macOS、Linux 终端运行下面的 curl 命令；Windows PowerShell 中把 curl 写成 curl.exe，避免旧版 PowerShell 的同名别名影响参数解析。测试时暂时关闭 TUN，保留一个客户端运行，减少多个入口混用带来的干扰。

curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/
  • Connection refused：常见原因是端口写错、内核未启动或没有监听该地址。
  • 连接本地端口成功，但 CONNECT 失败或返回 502：检查客户端日志、节点可达性及匹配的代理组。
  • 出现 200 Connection established：只代表 HTTP 隧道已建立，还要继续看 TLS 握手与目标站响应。
  • 收到目标站 HTTP 响应：证明这次显式代理请求走通，不代表其他应用已经配置正确。

浏览器不走代理：按系统设置、扩展、PAC 顺序排查

检查系统设置是否真的被写入

Windows 11 可进入「设置」→「网络和 Internet」→「代理」。若客户端使用手动代理，应看到本机地址与实际端口；若客户端采用自动配置脚本，则检查脚本地址是否仍然有效。不要把 PAC 地址填写到手动代理的服务器地址中，它们是不同类型的设置。

macOS 14 可进入「系统设置」→「网络」→ 当前使用的网络服务 →「详细信息」→「代理」。确认修改的是当前活动网络，例如 Wi-Fi，而不是未连接的以太网服务。HTTP 与 HTTPS 代理项使用的通常都是客户端的 HTTP 或 Mixed 监听端口；目标网址是 HTTPS，并不意味着本地代理地址也必须写成 HTTPS。

Linux 桌面的代理设置随桌面环境变化。GNOME 可从「设置」→「网络」→「网络代理」检查。桌面代理设置不保证被所有沙箱应用、后台服务或命令行工具读取，后文仍需为终端单独验证。

让浏览器只保留一个代理配置来源

  1. Chrome 打开 chrome://extensions/，Edge 打开 edge://extensions/，暂时停用管理代理的扩展，再完全退出并重新打开浏览器。
  2. Firefox 进入「设置」→「常规」→「网络设置」→「设置」，检查当前选择的是“不使用代理”“使用系统代理设置”还是手动配置。排障时先与系统设置保持一致。
  3. 受组织管理的浏览器还应检查 chrome://policy/ 或 edge://policy/。如果策略强制了代理，客户端切换系统设置未必能够改变浏览器行为。
  4. 重新访问同一个测试网址，同时打开客户端的连接面板，观察目标域名、匹配规则、代理链和流量是否出现。

无痕窗口不是可靠的代理隔离环境：部分扩展可以被允许在无痕模式运行，系统代理仍然会被继承。必要时使用临时浏览器配置文件进行对照，不要直接清空日常配置。

检查 PAC 与代理例外

PAC 脚本可以针对不同域名返回代理地址或 DIRECT。如果脚本让某个域名直连，请求根本不会经过内核，修改 Clash 的分流规则也不会改变这次请求。可先保存原有设置，再暂时改为明确的手动代理进行对比；不要同时叠加多个来源不明的 PAC 和代理扩展。

系统与浏览器中的例外列表同样会跳过代理。重点查找测试域名、通配域名、局域网地址以及“对本地地址不使用代理”等选项。访问 localhost 不能用来证明公网代理是否生效，因为回环地址通常有专门的绕过机制。

Windows 终端：PowerShell 与 CMD 分别设置

PowerShell、CMD 和应用自带的终端并不一定使用同一套代理设置。下面的环境变量只影响当前进程及之后启动的子进程；已经运行的终端、编辑器或后台任务不会自动更新。先用临时设置验证，确认有效后再考虑持久保存。

PowerShell 当前会话

$env:http_proxy = "http://127.0.0.1:7890"
$env:https_proxy = "http://127.0.0.1:7890"
$env:no_proxy = "localhost,127.0.0.1,::1"

curl.exe -I --connect-timeout 10 --max-time 20 https://example.com/

# 查看当前代理相关环境变量
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

# 测试结束后清理本次设置
Remove-Item Env:http_proxy, Env:https_proxy, Env:no_proxy -ErrorAction SilentlyContinue

CMD 当前窗口

set "http_proxy=http://127.0.0.1:7890"
set "https_proxy=http://127.0.0.1:7890"
set "no_proxy=localhost,127.0.0.1,::1"
curl.exe -I --connect-timeout 10 --max-time 20 https://example.com/

rem 测试结束后清理
set "http_proxy="
set "https_proxy="
set "no_proxy="

https_proxy 描述的是 HTTPS 请求应该使用哪个代理，不是要求代理连接本身使用 TLS。本例通过本地 HTTP 代理的 CONNECT 方法建立隧道，所以值仍然是 http://127.0.0.1:7890。

macOS 与 Linux：环境变量、SOCKS 与持久化

先在当前 shell 中测试

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export no_proxy="localhost,127.0.0.1,::1"

curl -I --connect-timeout 10 --max-time 20 https://example.com/

# 查看大小写两种形式，排除历史设置干扰
env | grep -i proxy

# 清理本次设置
unset http_proxy https_proxy no_proxy

不同程序对变量大小写的支持不同。curl 对 HTTP 代理特意使用小写 http_proxy，不要只设置大写 HTTP_PROXY 后就判断代理无效。如果历史环境中还存在 ALL_PROXY、HTTPS_PROXY 或其他大小写变量，应先记录原值再清理冲突项。no_proxy 的域名匹配语法也因工具而异，不宜直接在所有工具间复制复杂列表。

需要代理端解析域名时测试 SOCKS

# 仅在 7890 确实为 Mixed 或 SOCKS 端口时使用
curl -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/

对 curl 而言，socks5h:// 会把目标主机名交给代理端解析；socks5:// 默认在本地解析。两者的差异适合用来定位本地 DNS 问题，但不能据此认定所有程序都支持相同 URL 格式。工具若不支持 SOCKS 环境变量，应使用该工具明确支持的 HTTP 代理配置。

验证成功后，可按实际 shell 把必要的 export 行写入 ~/.zshrc 或 ~/.bashrc，然后新开终端验证。登录 shell、桌面启动的应用和 systemd 服务加载环境的方式不同，不能假设修改一个文件就覆盖全部进程。通过 sudo 启动命令时，环境变量也可能被过滤。

WSL、容器和虚拟机里的 127.0.0.1 通常指各自的网络环境，不一定是宿主机。WSL 的网络模式会影响回环访问能力；连接失败时先确认宿主机地址和可达端口。需要跨环境访问时，只对可信网络开放必要监听，并配置防火墙，不要直接扩大到所有网络。

命令仍然失败：检查工具配置、规则与 DNS

Git 等工具可能覆盖环境变量

Git 的全局配置、仓库配置与按 URL 设置的代理可能让结果不同。先查看来源，再使用单次命令覆盖测试，避免修改后忘记恢复。以下测试使用公开仓库，不需要在命令中加入账号密码。

git config --show-origin --get-regexp '.*proxy'
git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD

包管理器、IDE 和下载工具也可能有独立设置。浏览器成功只能证明浏览器这条链路可用，不能替代工具自身的连接测试。共享日志时应隐藏订阅 URL、访问令牌、账号和带凭据的代理地址。

进入内核后再判断规则

若连接面板已有目标请求，查看最终代理链：显示 DIRECT 时，检查命中的规则及代理组当前是否选择了直连；显示具体节点时，再检查该节点到目标站的连通性。订阅导入成功不代表配置已经启用，也不代表每个代理组都选择了可用节点。

可短暂切换全局模式并选择一个已验证的节点做对照。如果全局模式可用、规则模式失败，优先检查规则匹配和组选择；测试结束恢复原模式。全局模式仍然只处理进入内核的连接，不能修复浏览器未读取代理或终端未设置入口的问题。

如果错误明确指向域名解析，先分清是谁在解析：应用、本地系统、HTTP 代理还是 SOCKS 代理。浏览器的安全 DNS 设置可能改变解析路径，但并不是所有浏览器代理故障都由它引起。不要一开始就清空 DNS 配置或修改 Fake-IP 范围，以免同时改变多个变量。

何时使用 TUN，以及如何完成复测

对于不支持显式代理的应用，可以在支持该功能的 mihomo 客户端中考虑 TUN。启用前确认客户端版本、内核能力、授权要求以及现有 VPN 路由。TUN 可能需要管理员权限，并与其他虚拟网卡、路由或 DNS 接管发生冲突；它不是检查端口之前的默认修复按钮。

  1. 先完成一次关闭 TUN、显式指定本地代理的成功请求，确认节点与监听入口正常。
  2. 恢复浏览器系统代理，单独验证浏览器，并确认客户端连接记录中的域名和规则。
  3. 在新的终端会话中验证代理环境变量，检查工具独立配置与例外列表。
  4. 确有应用不支持代理时，再启用 TUN，观察默认路由、DNS 与应用连接变化。
  5. 退出客户端后检查网络是否恢复；若仍指向已经停止监听的本地端口，应关闭残留系统代理或清理当前会话变量。

排障记录至少保留操作系统版本、客户端与内核版本、监听端口、测试命令、错误原文及连接面板中的匹配结果。按“应用入口 → 本地监听 → 规则与代理组 → 节点出口 → 目标站”逐段验证，比反复重装客户端更容易定位具体故障。更多基础操作可查看快速上手，字段含义可查阅协议参考，常见问题见帮助中心。

下载客户端