故障排查 预计阅读 12 分钟

开了代理浏览器能走、终端不走？系统代理不生效分场景排查

系统代理开关打开了流量却没走代理，浏览器和终端的原因往往不同。分别给出浏览器代理设置覆盖、终端环境变量、代理端口核对的检查步骤，附常用验证命令。

先分清故障发生在哪一层

Clash、Clash Meta（mihomo）以及基于这些内核制作的桌面客户端，通常会在本机监听 HTTP、SOCKS5 或 mixed 代理端口。客户端里的“系统代理”开关，只负责把操作系统的代理地址改成类似 127.0.0.1:7890 的本地监听地址。应用是否读取这项设置、请求是否进入内核、规则最终选择哪个策略，是三个彼此独立的环节。

因此，“系统代理已打开”并不等于所有程序都会自动经过 Clash。Chrome、Edge 等浏览器通常跟随系统代理；Firefox 可以使用自己的代理配置；curl、Git、npm、Python 包管理器和远程终端往往读取环境变量或各自的配置文件。游戏、UDP 程序及部分商店应用也可能绕开传统 HTTP 系统代理，需要 TUN 模式接管。

用四个结果快速判断范围

测试结果 更可能的问题 优先检查
浏览器可用，终端不可用 终端没有读取系统代理 环境变量、Git/npm 单独配置
浏览器与终端都不可用 端口、内核、配置或节点异常 监听端口、运行日志、策略组
显式指定代理可用，系统代理不可用 系统代理写入失败或被覆盖 操作系统设置、浏览器策略、扩展
网页可用，游戏或 UDP 不可用 系统代理覆盖范围不足 TUN、DNS、路由与防火墙

第一步：核对 Clash 实际监听端口

不同客户端的默认端口并不完全一致。常见配置是 HTTP 或 mixed 端口 7890、SOCKS5 端口 7891、外部控制端口 9090。其中 9090 用于控制面板调用 API，不是网页代理端口，把系统代理指向它会直接失败。最终应以客户端当前设置和配置文件为准，不能只按常见数字猜测。

在带界面的客户端中，先进入「设置」→「参数设置」或「设置」→「网络设置」，查看 HTTP、SOCKS 和 Mixed Port。若配置只写了 mixed-port: 7890，HTTP 与 SOCKS5 都可以连接到 7890；若分别写了 port 和 socks-port，调用时要匹配协议。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

直接测试本地 HTTP 代理

在终端显式指定代理，可以绕过系统代理设置，单独验证 Clash 端口是否工作。以下命令访问标准测试页面，正常情况下会返回 HTTP 响应头；加入 -v 后还能看到连接的是不是 127.0.0.1:7890。

curl -I -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204

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

如果显式代理成功，而不带 -x 的命令失败，说明内核、节点和端口基本正常，问题集中在系统代理或终端配置。如果显式代理也出现 Connection refused，通常是端口填错、内核未启动或本地安全软件阻止监听。如果能连接本地端口，却在后续看到 timeout，则继续检查节点、规则和 DNS。

检查端口是否正在监听

# Windows
netstat -ano | findstr :7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

输出中应出现本地监听地址。仅供本机使用时，监听 127.0.0.1:7890 是正常情况；需要让局域网内其他设备连接时，才需要启用 allow-lan 并检查防火墙。不要为了修复本机浏览器问题随意开放局域网监听。

浏览器不走代理：检查覆盖项与代理来源

Chrome 和 Edge 在 Windows、macOS 上通常读取系统代理，但扩展、企业策略、启动参数和安全软件都可能覆盖它。Firefox 则有独立的网络设置，可以选择“不使用代理”“使用系统代理设置”或“手动代理配置”。浏览器之间结果不同，往往正是这些配置来源不同造成的。

Chrome 与 Edge 的检查顺序

  1. 完全退出浏览器，再重新打开，避免旧连接池继续复用直连连接。
  2. 进入浏览器「设置」→「系统和性能」→「打开计算机的代理设置」，确认地址为 127.0.0.1，端口与 Clash 一致。
  3. 临时停用会管理代理的扩展，尤其是能切换 PAC、固定代理或情景模式的扩展。
  4. 检查快捷方式或启动脚本中是否存在 --proxy-server、--no-proxy-server 等参数。
  5. 打开 Clash 连接列表或实时日志，再刷新网页，确认是否出现目标域名。

如果浏览器日志中完全没有新连接，说明请求尚未进入 Clash，应继续排查系统代理或浏览器覆盖项。如果能看到连接，但策略显示 DIRECT，说明系统代理已经生效，只是当前规则让该域名直连。此时应检查规则命中结果，而不是反复开关系统代理。

Firefox 使用自己的代理配置

Firefox 可进入「设置」→「常规」→「网络设置」→「设置」。若希望跟随 Clash 的系统代理，选择“使用系统代理设置”；若选择“手动代理配置”，可把 HTTP 代理设为 127.0.0.1、端口设为 7890，并按实际端口填写 SOCKS 主机。使用 SOCKS5 时，如需让域名也通过代理端解析，应同时确认“使用 SOCKS v5 时代理 DNS 查询”选项。

终端不走代理：设置环境变量而不是只开系统代理

macOS 和 Linux 终端程序普遍不会统一继承桌面系统代理。Windows 下也要区分 PowerShell 命令、curl.exe、WSL 和各类开发工具。最稳定的验证办法，是先给当前终端会话设置代理环境变量，再运行请求命令。

macOS 与 Linux 当前会话

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

curl -I https://example.com/

https_proxy 的值写成 http:// 并不矛盾，它表示通过本地 HTTP 代理使用 CONNECT 隧道访问 HTTPS 站点。socks5h 中的字母 h 表示域名交给 SOCKS 代理端解析，可减少本地 DNS 与代理出口不一致的问题。

只想影响一条命令时，可以把变量写在命令前面。确认结果后，再决定是否加入 ~/.zshrc、~/.bashrc 或项目脚本。长期写入启动文件会让终端在 Clash 未运行时仍尝试连接本地端口，因此最好同时准备清除命令。

https_proxy=http://127.0.0.1:7890 curl -I https://example.com/

unset http_proxy
unset https_proxy
unset all_proxy

Windows PowerShell 当前会话

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5h://127.0.0.1:7890"

curl.exe -I https://example.com/

在旧版 Windows PowerShell 中，curl 可能是 Invoke-WebRequest 的别名，参数行为与标准 curl 不同。排查时明确运行 curl.exe，并用 curl.exe --version 查看实际程序。关闭当前 PowerShell 窗口后，上述环境变量就会失效。

WSL 要使用可达的 Windows 主机地址

WSL2 运行在独立虚拟网络中，WSL 内的 127.0.0.1 不一定对应 Windows 上的 Clash 监听地址。应先确认客户端允许局域网连接，再从 WSL 查询默认网关，并把该地址作为代理主机。不同 WSL 网络模式的表现可能不同，不能固定照抄某个私网 IP。

ip route | awk '/default/ {print $3}'

export https_proxy=http://Windows主机地址:7890
curl -I https://example.com/

若 WSL 能连接 Windows 主机但端口被拒绝，应检查 Clash 是否只监听 127.0.0.1、是否启用了局域网访问，以及 Windows 防火墙是否允许对应专用网络。完成测试后，可恢复仅本机监听，减少不必要的局域网暴露。

Git、npm 与开发工具需要单独核对

环境变量生效后，部分工具仍可能优先读取自己的配置。也可能出现相反情况：系统代理已经关闭，但 Git 或 npm 里保存的旧代理仍指向 7890，导致 Clash 退出后所有请求报错。排查时既要检查“缺少配置”，也要检查“残留配置”。

Git 查看、设置与清除代理

git config --global --get http.proxy
git config --global --get https.proxy

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

git config --global --unset http.proxy
git config --global --unset https.proxy

还应运行 git config --show-origin --get-regexp proxy 查看配置来源。项目级 .git/config、用户级配置和系统级配置可能同时存在，优先级较高的项目配置会覆盖全局设置。SSH 形式的远程地址不读取 Git 的 HTTP 代理，需要配置 SSH 的 ProxyCommand，或改用 HTTPS 地址测试。

npm 与其他包管理器

npm config get proxy
npm config get https-proxy

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890

npm config delete proxy
npm config delete https-proxy

pnpm、Yarn、pip、Maven 和 Docker 可能读取环境变量，也可能维护各自配置。若浏览器正常而安装依赖超时，先查看工具的详细日志，确认它连接的是目标域名、镜像地址还是旧代理端口。容器中的 127.0.0.1 指向容器自身，不能直接代表宿主机上的 Clash。

请求进入 Clash 后仍失败：看规则、DNS 与节点

当实时日志已经出现目标域名，系统代理这一环实际上已经完成。后续失败应按日志继续拆分：规则是否命中预期策略组、策略组是否选择了可用节点、DNS 是否返回正确地址、远端连接是否超时。把所有失败统称为“代理不生效”，容易在错误的位置反复操作。

根据日志字段判断方向

排查时可暂时把客户端模式切换到全局代理，并选择一个已验证的节点做对照。如果全局模式可用、规则模式不可用，重点检查规则命中；如果两种模式都失败，重点检查节点、订阅配置和网络连接。测试完成后再切回规则模式，避免把全局模式当作长期修复方案。

什么时候应该改用 TUN 模式

系统代理主要服务于主动支持 HTTP 或 SOCKS 代理的应用。游戏启动器、部分桌面软件、UDP 流量和固定直连程序可能完全不读取系统代理。此时即使浏览器工作正常，相关应用仍会直连。TUN 模式通过虚拟网卡在网络层接管流量，覆盖范围通常更完整，但需要管理员权限，并会增加 DNS、路由和排除规则的配置量。

适合优先尝试 TUN 的场景包括：应用没有代理设置、程序持续绕过系统代理、需要处理 UDP、希望让多个命令行工具统一遵循 Clash 规则。只处理浏览器和少量开发工具时，系统代理加环境变量通常更清晰，也更容易按应用控制。

开启 TUN 前检查四项

  1. 确认当前客户端使用支持 TUN 的 mihomo 内核，并已授予创建虚拟网卡所需权限。
  2. 记录现有 DNS 设置，避免系统 DNS、浏览器 DoH 与 Clash DNS 多层叠加后难以定位。
  3. 把局域网地址、打印机、开发服务器和本机服务加入必要的直连规则。
  4. 关闭其他 VPN、虚拟网卡工具做单变量测试，避免默认路由和 DNS 互相覆盖。

TUN 开启后如果所有网络立即中断，应先关闭 TUN 恢复连接，再查看内核日志和虚拟网卡状态。不要同时修改订阅、DNS、规则和系统防火墙；每次只改一项，保留前后结果，才能确认真正的故障点。

按顺序完成一次完整排查

  1. 确认 Clash 内核正在运行，当前配置加载成功，策略组已选择可连接节点。
  2. 在「设置」→「参数设置」中核对 mixed、HTTP 或 SOCKS5 端口，避免把控制端口 9090 当成代理端口。
  3. 使用 curl -x 显式指定 127.0.0.1:7890，判断本地代理端口是否可用。
  4. 检查操作系统代理地址和端口，再检查浏览器扩展、Firefox 独立代理及启动参数。
  5. 给终端当前会话设置 http_proxy、https_proxy 或 all_proxy，重新执行同一请求。
  6. 检查 Git、npm 等工具保存的独立代理配置，清理已经失效的旧端口。
  7. 观察 Clash 实时日志；没有连接记录就回查应用侧，有记录则继续看规则、DNS 和节点。
  8. 确认目标程序确实绕过系统代理后，再评估是否启用 TUN 模式。

浏览器能走、终端不走，最常见的原因并不是 Clash 内核故障，而是两类应用读取代理的方式不同。先用显式代理命令验证端口，再分别处理浏览器覆盖项和终端环境变量，可以把范围迅速缩小。只有请求已经进入内核后，规则、DNS、节点和 TUN 才是下一阶段的检查对象。

下载Clash