Clash 开了系统代理却不走代理？浏览器与终端排查清单

先确认请求有没有进入 Clash

系统代理开关只表示尝试修改了系统代理设置，不表示所有应用都已交给 Clash。浏览器可能被扩展接管，终端通常需要单独指定代理，PAC 也可能把目标域名判成直连。即使请求进入内核，规则仍可能选择 DIRECT。先区分“没有接管”和“接管后直连”，比反复切换节点更有效。

1. 在客户端查看当前配置和本地监听端口。本文用 127.0.0.1:7890 作为 HTTP 或混合代理示例，以实际配置为准。
2. 打开客户端的 Connections（连接）页面，并在 Logs（日志）中查看新请求；必要时临时把日志等级调到 info。
3. 记录当前时间，在浏览器访问一个确定会触发网络请求的页面，然后核对目标域名、命中规则和代理链。
4. 再用后文的显式代理命令访问同一目标。如果命令成功而浏览器失败，优先排查浏览器与系统设置，不要立即改订阅。

检查本地端口：系统代理地址必须对应内核监听

客户端界面中的控制端口不等于代理端口。配置项 external-controller 用于控制 API，不能填到浏览器的 HTTP 代理地址里。port 通常提供 HTTP 代理，socks-port 提供 SOCKS 代理，mixed-port 同时接受 HTTP 与 SOCKS 请求。

例如，7890 和 7891 只是常见配置值，不是固定标准。下面是用于说明端口对应关系的局部 YAML，不包含节点、订阅和完整规则，不能作为完整可联网配置：

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

Windows：检查监听与系统设置

在 PowerShell 执行以下命令。第一条检查端口是否处于监听状态，第二条查看 Windows 当前用户的代理配置位置则需要手动打开设置：

Get-NetTCPConnection -State Listen -LocalPort 7890
Start-Process "ms-settings:network-proxy"

进入「设置」→「网络和 Internet」→「代理」，核对手动代理地址是否为 127.0.0.1、端口是否与客户端一致，同时记录“使用设置脚本”是否开启。若第一条命令没有返回记录，先检查客户端内核状态；若返回其他进程占用的端口，需要确认所属进程，不能直接把它当作 Clash。

macOS 与 Linux：先确认监听，不猜默认值

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

# Linux
ss -lntp 'sport = :7890'

macOS 可在「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」核对 HTTP、HTTPS 与自动代理配置。Wi-Fi 和以太网是不同服务，切换网络后需要再次确认。Linux 的桌面代理设置依桌面环境而异，也不能假定所有应用都会读取桌面的代理开关。

浏览器排查：扩展、独立设置与 PAC 分开验证

Chrome 与 Edge：先排除扩展接管

Chrome 通常通过「设置」→「系统」→「打开您计算机的代理设置」查看系统代理；Edge 对应入口一般位于「设置」→「系统和性能」→「系统」。不同发行版本的菜单文字可能略有变化，也可以在设置页搜索“代理”。

• 检查代理切换扩展的当前模式。扩展可能固定使用另一个端口，或者把部分域名加入直连列表。
• 暂时停用所有会修改代理的扩展，关闭全部浏览器进程后重启测试。无痕窗口并不能保证扩展全部停用，获准在无痕模式运行的扩展仍可能生效。
• 若设备受组织管理，查看 chrome://policy 或 edge://policy 中的代理策略。策略锁定的设置需要由设备管理员调整。
• 检查浏览器启动参数是否包含 --no-proxy-server、--proxy-server 或 --proxy-pac-url，这些参数可能改变实际行为。

Firefox：确认没有使用另一套代理

进入「设置」→「常规」→「网络设置」→「设置」。选择“使用系统代理设置”后再测试；如果使用“手动代理配置”，逐项核对 HTTP、HTTPS 或 SOCKS 地址和端口。“不使用代理”的例外列表也要检查，尤其是曾为开发环境添加过的域名后缀。

PAC：浏览器先决定是否进入 Clash

PAC 脚本中的 FindProxyForURL 会根据 URL 和主机名返回路由选择。返回 DIRECT 时，请求不会经过本地 HTTP 代理；返回 PROXY 127.0.0.1:7890 才会把请求交给对应端口。如果结果包含 PROXY 127.0.0.1:7890; DIRECT，代理不可用时还可能退回直连，具体行为取决于应用实现。

PAC 直连和 Clash 规则直连发生在不同位置。PAC 先决定是否使用代理，Clash 的 rules 则在请求进入内核后继续决定去向。临时停用自动配置脚本、仅保留正确的手动 HTTP 代理，可以缩小范围；测试前记录原值，完成后恢复，不要在工作设备上随意覆盖组织下发的 PAC。

终端排查：用显式代理建立对照组

许多命令行程序不会读取系统代理。浏览器能访问、curl 仍直连，并不说明 Clash 失效。先绕开环境变量的歧义，用命令参数明确指定本地代理。

Windows PowerShell 测试

使用 curl.exe，避免 Windows PowerShell 5.1 中 curl 别名指向其他命令。以下命令访问示例站点，强制使用本地 HTTP 代理，并用命令行的绕过列表覆盖可能存在的 NO_PROXY 设置：

curl.exe -v --connect-timeout 10 --max-time 30 --proxy http://127.0.0.1:7890 --noproxy localhost https://example.com/ --output NUL

这里 --noproxy localhost 仅让 localhost 绕过代理，测试目标 example.com 不在其中。这样也避免部分旧版 PowerShell 对空字符串参数的传递差异。该域名只用于演示请求路径，能否访问它不代表所有目标站点都可用。

macOS 与 Linux 测试

curl -v --connect-timeout 10 --max-time 30 \
  --proxy http://127.0.0.1:7890 --noproxy "" \
  https://example.com/ --output /dev/null

观察详细输出中的本地连接地址与 HTTPS 隧道协商。出现 CONNECT example.com:443 表示 curl 正在向 HTTP 代理申请隧道；收到 200 Connection established 也不代表后续 TLS 和网页请求一定成功，仍需查看最终结果及客户端连接记录。

• Connection refused：优先检查本地端口和内核监听。
• 隧道已经建立，随后 TLS 报错：检查系统时间、证书信任及是否存在其他 HTTPS 检查软件，不要直接使用跳过证书验证作为修复。
• 客户端显示节点连接超时：请求已进入代理链，继续检查节点与远端连接。

环境变量与应用配置：修改只影响正确的进程

显式代理测试成功后，再给需要代理的终端进程设置环境变量。对 curl 而言，HTTPS 目标可使用 https_proxy；变量值中的 http:// 描述的是“客户端到代理”的协议，并不要求改成 https://。不同工具支持的变量和优先级并不完全一致。

先检查现有值

# PowerShell：列出当前进程的代理相关环境变量
Get-ChildItem Env: | Where-Object Name -Match '^(http_proxy|https_proxy|all_proxy|no_proxy)$'

# macOS / Linux
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

重点检查残留端口、旧代理地址，以及 NO_PROXY 或 no_proxy。例如 NO_PROXY=* 会使支持该约定的工具绕过所有代理；域名后缀匹配规则则要以工具文档为准。curl 对 HTTP 代理变量有特殊安全处理，POSIX shell 中优先使用小写 http_proxy，不要只设置大写 HTTP_PROXY。

仅在当前终端设置，验证后再持久化

# PowerShell：作用于当前进程及之后启动的子进程
$env:http_proxy = "http://127.0.0.1:7890"
$env:https_proxy = "http://127.0.0.1:7890"

# macOS / Linux：作用于当前 shell 及之后启动的子进程
export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

上述设置不会自动覆盖已经启动的 IDE、后台服务或其他终端窗口。确认环境变量有效时，应新启动目标程序，或者在当前终端直接运行它。使用 sudo 后环境可能被过滤；WSL、容器及远程 SSH 会话中的 127.0.0.1 也不应直接等同于宿主机，应先确认网络边界和实际可达地址。

Git 还可能存在独立的代理配置。执行以下命令定位配置来源；先读后改，避免覆盖仓库或组织要求：

git config --show-origin --get-regexp 'http\..*proxy|https\..*proxy'

请求进入内核后：核对 Rule、DIRECT 与策略组

在 Connections 中找到目标请求，查看目标域名、匹配规则、规则载荷和代理链。字段名称随客户端而异，但判断逻辑一致：如果链路为 DIRECT，说明这次请求被选择为直连；如果显示策略组和实际节点，则应沿着该节点继续排查。

1. 核对模式：Rule 按规则分流，Direct 模式直接连接；Global 使用全局策略。系统代理开关与这三种模式不是同一个开关。
2. 核对顺序：规则一般按顺序匹配，前面的域名、IP 或规则集条目可能先命中，末尾 MATCH 不会覆盖已经命中的规则。
3. 核对组内选择：即使规则指向一个名为“代理”的策略组，组内仍可能选中了 DIRECT。组名不是实际出口的保证。
4. 核对域名信息：应用直接连接 IP、DNS 缓存或不同接管方式，可能改变内核可用于匹配的信息。不要看到域名规则未命中就直接认定规则集失效。

必要时，可临时切换 Global 并选择一个已知可用的节点做对照。若全局模式可用而 Rule 模式直连，重点检查规则与组内选择；测试完成后恢复原模式。切换节点或规则后，已有 TCP、HTTP/2 连接不一定重建，应用需要重新发起连接才能验证新路径。

系统代理覆盖不到的流量，再评估 TUN

系统 HTTP 代理并不接管所有 UDP，也不保证覆盖自行实现网络栈的游戏、命令行工具或其他应用。Clash Meta（mihomo）的 TUN 功能通过虚拟网络接口与路由接管流量，覆盖范围与系统代理不同，但仍取决于平台权限、路由、DNS 设置及内核配置。

不要在本地端口尚未确认时同时开启 TUN、改 DNS、切全局模式。这样虽然可能改变结果，却无法知道是哪一步生效。若目标应用确实不支持代理，再按客户端说明检查 TUN 所需的服务或管理员权限，并排查与 VPN、其他虚拟网卡的冲突。浏览器安全 DNS 影响解析路径，也不能简单等同于“浏览器绕过 HTTP 代理”。

复测与记录：用同一目标比较修改前后

• 记录客户端名称与实际版本、内核版本、操作系统版本、HTTP 或混合代理端口；不要只写“最新版”。
• 每轮只修改一项，保持测试域名、请求工具和所选节点一致，记录测试时间。
• 同时保存浏览器结果、显式代理 curl 结果、连接页面的命中规则和实际代理链。
• 若需核对出口 IP，使用可信服务并与连接记录交叉判断。单一页面显示的地理位置可能滞后，不能代替链路证据。
• 分享排查信息前，删去订阅地址、访问令牌、节点凭据和个人访问记录；命令详细输出也应先检查。

最终应能把问题落到一个明确环节：本地端口未监听、应用未使用代理、PAC 或例外列表绕过、规则选择直连，或者代理链连接失败。只要显式代理、浏览器设置和内核记录三条证据能够对应，就不需要靠反复重装客户端来猜测原因。基础配置顺序可参阅入门指南，规则与 DNS 的细节可继续查看配置进阶。