故障排查 预计阅读 10 分钟

开了系统代理却不走代理：浏览器与终端分开排查

浏览器扩展抢占代理、终端不读系统代理是两类高发原因。本文分别给出检查顺序、环境变量写法与 TUN 模式替代方案。

先区分：没有进入内核，还是规则选择了直连

“系统代理”只是在操作系统中登记代理地址与端口，不等于把整台设备的所有流量交给 Clash。应用是否读取这套设置，取决于它使用的网络组件；浏览器扩展、应用自己的代理选项、终端环境变量，也可能改变最终路径。

另一个常见误判是：请求已经进入 mihomo 内核，却被规则分配给了 DIRECT。此时出口地址没有变化是规则结果，不是系统代理失效。先打开客户端的“连接”页面，按目标域名筛选，再检查匹配规则、策略组与最终出站。

观察结果优先检查下一步
连接页没有目标请求应用是否使用代理检查浏览器设置或显式指定代理
请求出现，最终出站为 DIRECT规则顺序与策略组选择确认该域名是否本来就应直连
请求进入代理组，但连接超时节点、目标站与网络连通性换一个已知可用节点对照
显式代理成功，普通访问失败系统代理接入环节分开处理浏览器与终端

第一步：用显式代理验证本地监听端口

暂时不要改规则、订阅和 DNS。先用同一目标地址做一次显式代理请求，把“内核能不能接收请求”单独验证出来。Windows PowerShell 使用 curl.exe，避免 Windows PowerShell 5.1 中的 curl 别名影响参数解析；macOS、Linux 使用 curl。

# Windows PowerShell
curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

# macOS / Linux
curl -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

--noproxy "" 用于本次测试时清空绕过列表，防止已有的 NO_PROXY 干扰判断。观察详细输出中是否连接到 127.0.0.1:7890，以及 HTTPS 请求的 CONNECT 隧道是否建立；同时在客户端“连接”或“日志”中找对应记录。

  • 立即提示连接被拒绝：检查内核是否运行、端口是否填错，以及监听地址是否包含 IPv4 回环地址。
  • 本地端口连上，但 CONNECT 之后失败：继续检查节点、规则、TLS 或目标站可用性，不要反复切换系统代理开关。
  • 出现 HTTP 407：检查本地代理认证。不要把带密码的完整命令贴到公开日志中。
  • 收到目标站 HTTP 响应：说明本次请求已通过本地代理入口；最终是否经远端节点转发，仍以客户端出站记录为准。

在 Windows 可运行 Get-NetTCPConnection -State Listen -LocalPort 7890 检查监听；在 macOS 可运行 lsof -nP -iTCP:7890 -sTCP:LISTEN。如果端口由其他程序占用，先确定进程身份，再关闭冲突程序或修改客户端端口。

浏览器排查：系统设置、扩展与独立配置

Chrome 与 Edge：先排除扩展接管

  1. 在客户端打开“系统代理”，确认订阅已启用、当前策略组已选中可用节点。
  2. Chrome 打开“设置”→“系统”→“打开您计算机的代理设置”；Edge 打开“设置”→“系统和性能”，找到计算机代理设置入口。界面措辞可能随版本变化。
  3. Windows 11 进入“设置”→“网络和 Internet”→“代理”；Windows 10 进入“设置”→“网络和 Internet”→“代理”。检查手动代理的地址与端口是否对应客户端。
  4. 打开 chrome://extensions/ 或 edge://extensions/，暂时关闭具有代理控制功能的扩展，包括自动切换代理配置的扩展。
  5. 彻底退出浏览器后重新打开，再请求同一测试地址，并观察客户端连接记录。

无痕窗口不是充分的隔离测试：扩展可能被允许在无痕模式运行，系统级配置也仍然有效。更可靠的对照是新建一个未配置代理扩展的浏览器配置文件。若页面提示“由贵组织管理”，还应检查 chrome://policy/ 或 edge://policy/；受管理设备应由管理员调整策略。

Firefox：明确选择代理来源

Firefox 进入“设置”→“常规”→“网络设置”→“设置”。选择“使用系统代理设置”，才能与客户端写入的系统代理保持一致。如果使用“手动配置代理”，则要自行维护 HTTP 代理地址、端口与 HTTPS 代理选项。旧的 SOCKS 配置不会因为打开系统代理而自动失效。

macOS 可在“系统设置”→“网络”→当前网络连接→“详细信息”→“代理”核对 Web 代理与安全 Web 代理。Linux 桌面的代理设置是否被应用读取，取决于桌面环境和应用实现，不能仅凭桌面开关推断所有浏览器都已生效。

终端排查：设置 HTTP_PROXY 与 HTTPS_PROXY

终端程序通常不会自动采用桌面的系统代理。curl、Git、包管理器还可能读取各自的配置文件。浏览器能访问而终端失败时，先给当前终端会话设置环境变量，避免一开始就改系统级环境。

Windows 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 -v --connect-timeout 10 --max-time 20 https://example.com/ -o NUL

# 测试结束后清理本次设置
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

HTTPS_PROXY 描述的是 HTTPS 目标请求应使用哪个代理，不意味着本地代理地址必须写成 https://。常见 HTTP 或混合监听端口使用 http://127.0.0.1:7890，再通过 CONNECT 转发 HTTPS 连接。

macOS 与 Linux：注意变量大小写

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 -v --connect-timeout 10 --max-time 20 https://example.com/ -o /dev/null

# 测试结束后清理本次设置
unset http_proxy https_proxy no_proxy

在大小写敏感的环境中，curl 对 HTTP 代理只接受小写 http_proxy，其他程序的读取规则也可能不同。先用上面的最小配置验证，再根据目标工具文档设置大写变量。若此前已有代理变量，先记录原值，测试后恢复，而不是直接删除原有工作配置。

环境变量只影响当前进程及之后启动的子进程。已经打开的 IDE 终端、后台任务和系统服务不会因此自动更新。需要持久化时，再将配置加入对应 shell 的启动文件，并在重开终端后检查；不要在代理关闭时留下失效的固定地址。

应用独立配置：Git、SOCKS 与隔离环境

Git：检查残留代理，不急于覆盖全局配置

Git 的 HTTP 传输可受环境变量和 Git 配置共同影响。先查看配置来源，确认是否残留旧端口、远端代理地址或按 URL 限定的配置。输出可能包含认证信息，分享前应脱敏。

git config --show-origin --get-regexp '.*proxy.*'

# 仅对这一次 Git 命令指定代理
git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD

第二条命令只验证 Git 的 HTTPS 访问路径，不写入全局配置。以 git@ 开头的 SSH 仓库地址属于另一条传输链路，不会因为设置 http.proxy 就自动经过 HTTP 代理。

SOCKS：区分本地解析与代理端解析

若客户端只有 SOCKS 监听，不能把它当作 HTTP 端口使用。假设已确认 SOCKS 端口为 7891，可执行下列命令；若使用混合端口，应替换为混合端口的实际值。

curl --proxy socks5h://127.0.0.1:7891 --noproxy "" --connect-timeout 10 --max-time 20 https://example.com/

curl 中的 socks5h:// 会把目标域名交给 SOCKS 代理端解析；socks5:// 通常由本地先解析。这个区别有助于区分本地 DNS 故障，但不能据此认定所有应用的 DNS 都已被接管。

WSL、容器、虚拟机还存在地址边界：其中的 127.0.0.1 不一定指向宿主机。WSL 的 NAT 与镜像网络模式行为不同，应按实际模式确认宿主机地址。需要跨网络访问监听端口时，再评估“允许局域网”、监听地址与防火墙范围，不要直接把代理端口暴露到公共网络。

TUN 模式：处理不读取代理设置的应用

如果应用既不读取系统代理，也不支持显式代理设置，可以考虑 mihomo 客户端提供的 TUN 模式。TUN 通过虚拟网络接口和路由引导 IP 流量，接入层次不同于 HTTP 系统代理；它不是让浏览器“更强制地读取系统设置”。

  1. 先用显式代理确认节点、订阅与规则可用，再导出当前配置，保留回退副本。
  2. 在客户端“设置”中找到“服务模式”，按提示安装或启用服务；部分客户端使用其他提权方式，以当前版本界面为准。
  3. 打开“TUN 模式”，检查日志中虚拟接口和路由是否成功建立。涉及的 auto-route、DNS 接管和接口检测配置，应与客户端生成配置保持一致。
  4. 先关闭其他 VPN 或同类虚拟网卡接管功能，避免默认路由竞争；随后验证浏览器、终端、局域网设备和内网站点。
  5. 若出现断网，先关闭 TUN，再恢复原有系统代理设置。不要在故障状态下同时重写 DNS、路由与规则。

TUN 是否接管某个应用，取决于路由、排除项、网络接口和权限。UDP、QUIC 等流量能否正常转发，还取决于内核配置与节点能力。开启 TUN 后，规则仍然可以选择 DIRECT；“进入 TUN”与“最终走远端节点”仍是两个判断。

复测顺序：一次只改变一个变量

排查结束后，用同一目标、同一节点、同一规则模式做对照。不要仅凭某个网页能否打开，或一次出口 IP 查询下结论：缓存、绕过列表与目标域名的分流规则都可能改变结果。

  • 本地入口：显式指定 127.0.0.1:7890 后，客户端是否记录到该请求。
  • 浏览器：关闭代理扩展、确认代理来源后，连接记录是否出现。
  • 终端：设置当前会话环境变量后，同一请求是否由目标工具发送成功。
  • 出站选择：请求实际匹配了哪条规则，策略组最终选中了哪个节点。
  • 恢复检查：关闭客户端后，是否需要移除终端代理变量；关闭 TUN 后，内网访问与 DNS 是否恢复正常。

需要提交故障记录时，保留操作系统版本、客户端与内核版本、实际监听端口、失败命令、发生时间和对应日志片段。删除订阅地址、认证信息及敏感域名。进一步检查规则与 DNS，可查看排查手册；系统代理、策略组与 TUN 的区别可在概念速查中对照。

下载Clash