Clash 系统代理开了却没效果：浏览器与命令行终端分开检查

先区分系统代理、应用代理与规则分流

系统代理开启，只代表操作系统记录了代理设置，不代表所有进程都会使用它。浏览器可能遵循系统设置，也可能被扩展或独立配置覆盖；命令行程序通常需要环境变量或专用参数。连接进入 Clash 内核以后，还要按当前模式、规则和策略组决定最终出口。

因此，“出口地址没变”不能单独证明系统代理失效。连接可能已经进入内核，但命中了 DIRECT；也可能应用完全绕过了代理。排查时应同时看应用配置与客户端连接记录，不要只看网页是否打开。

在支持这些字段的 Clash 或 mihomo 内核中，下列片段表示仅向本机提供 HTTP 与 SOCKS 代理入口。它需要合并进已有配置，不包含节点与规则，不能替代完整订阅。

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

mixed-port 同时接受 HTTP 与 SOCKS 代理连接；独立的 port 和 socks-port 则要按协议分别使用。
allow-lan: false 适合本机测试。排查本机浏览器时，不需要为了连通而开放局域网访问。
mode: rule 继续按规则分流。需要确认的是目标连接匹配了哪条规则，而不是只看模式名称。

第一步：确认内核监听与显式代理请求

先绕开系统代理开关，用命令明确指定入口。如果显式代理也失败，应先查监听端口、内核运行状态和节点连接，而不是继续修改浏览器选项。

检查 7890 是否在监听

Windows PowerShell 可执行以下命令。输出中的 OwningProcess 是进程编号，可在任务管理器的“详细信息”页核对，避免把其他软件占用的端口当成 Clash。

Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

macOS 可用 lsof，Linux 可用 ss。没有输出时，先确认实际端口是否不同，以及配置是否成功载入。

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

# Linux
ss -lntp 'sport = :7890'

用 curl 显式指定 HTTP 代理

Windows 使用 curl.exe，避免部分 PowerShell 环境中的同名别名干扰。macOS 与 Linux 将命令名改为 curl 即可。这里的 --noproxy "" 用于排除已有绕过列表对本次测试的影响。

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

先看是否连接到 127.0.0.1:7890，再看 HTTPS 的 CONNECT 隧道是否建立，最后才看目标站响应。示例域名只用于连通性演示；定位实际故障时，应使用同一个出现问题的目标地址。

观察结果	优先检查
连接本地 7890 被拒绝	内核是否运行、端口是否一致、监听地址是否可达。
本地入口已连接，目标连接超时	客户端日志里的目标、规则、策略组和节点出口。
请求成功，浏览器仍失败	浏览器代理来源、扩展、绕过列表与已有连接。
显式参数成功，普通终端命令失败	环境变量是否设置、程序是否支持、是否被工具配置覆盖。

CONNECT 成功只能证明代理入口接受了隧道请求，不能独立证明走了某个远端节点。最终路径仍要结合客户端连接详情中的规则与链路判断。

第二步：浏览器按代理来源逐项检查

先核对操作系统中的实际地址

Windows 11 可进入“设置”→“网络和 Internet”→“代理”，查看手动代理地址与端口。macOS 可进入“系统设置”→“网络”→当前使用的网络服务→“详细信息”→“代理”。不同系统版本的文字可能略有区别，重点是检查当前正在使用的网络服务，而不是已断开的 Wi-Fi 或网卡。

本机入口通常填 127.0.0.1，端口与内核监听一致；不要把订阅地址填进代理服务器地址。
若使用 PAC 自动配置，确认自动配置脚本地址及匹配规则。PAC 可以按目标返回直连，并不等于所有网址都走同一入口。
关闭客户端系统代理后又被自动恢复，可能是其他代理软件或管理策略在写入设置，应先保留一个设置来源。

再排除扩展与浏览器独立配置

Chrome、Edge 在常规桌面环境下通常读取系统代理，但代理切换扩展、启动参数与企业策略都可能覆盖它。先暂停代理相关扩展，完全退出浏览器并重新打开，再对同一网址测试。无痕窗口不能保证排除所有扩展，因为扩展可以获准在无痕模式运行。

Firefox 可在“设置”→“常规”→“网络设置”→“设置”中检查代理来源。需要沿用操作系统设置时，选择“使用系统代理设置”；若选择“手动配置代理”，则必须单独核对地址、端口和“不使用代理”列表。

公司管理设备还应检查浏览器的管理状态。Chrome 的 chrome://policy 与 Edge 的 edge://policy 可查看策略是否生效；受管理策略限制时，应向管理员确认，不要反复覆盖设置。

查看绕过列表与连接复用

浏览器和系统常对本地地址、内网域名或指定网段绕过代理。用 localhost、路由器管理页或公司内网地址测试，往往无法判断公网代理是否有效。修改设置以后，已有长连接也可能继续复用；关闭相关标签页、完全退出浏览器再启动，比连续刷新同一页面更适合复测。

第三步：终端单独设置 http_proxy 与 HTTPS_PROXY

终端窗口不会因为客户端开启系统代理，就自动给所有命令注入环境变量。先在当前会话临时设置，确认有效后再考虑持久化。对于 HTTP 代理入口，即使目标网站是 HTTPS，代理地址也通常仍写 http://127.0.0.1:7890，不能仅因变量名含 HTTPS 就改成 https://。

macOS 与 Linux：当前 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 --connect-timeout 10 --max-time 30 -v https://example.com/

# 测试结束后移除本次设置
unset http_proxy https_proxy no_proxy

curl 对 HTTP 代理变量只接受小写的 http_proxy；其他程序的大小写支持可能不同。若同时存在大写变量、ALL_PROXY 或工具自带配置，应一并检查，避免删除一组变量后仍被另一组影响。

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

# 测试结束后移除本次设置
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY

这些设置仅作用于当前 PowerShell 与随后启动的子进程，不会修改已经运行的 IDE、终端或后台服务。若原先有变量值，应先记录，结束测试后恢复原值，而不是直接删除。通过系统界面持久修改变量后，通常需要重新启动相关应用才能继承新值。

第四步：检查 Git、WSL 与工具自己的代理配置

如果 curl 正常而某个工具失败，不应立刻判定节点不可用。Git、包管理器与运行时可能有专用代理设置，也可能由不同网络库处理环境变量。以 Git 为例，先查看所有已定义的配置及其来源：

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

远程地址使用 SSH：[email protected]:git/git.git 不走 Git 的 HTTP 代理链路，需要检查 SSH 自身的连接方式。
WSL 2：在默认 NAT 网络下，Linux 内的 127.0.0.1 指向 WSL 自身，不能简单等同于 Windows 宿主。镜像网络模式的行为不同，应按当前网络模式确认宿主可达地址。
容器：容器内的回环地址也不是宿主地址。若确需跨边界访问代理，应限定监听接口与防火墙来源，而不是直接向所有网络开放。
sudo 与后台服务：环境变量可能被过滤，或服务由独立账户启动。交互式终端测试成功，不代表服务进程拥有相同环境。

第五步：请求进入内核后，再看规则与出口

在客户端的连接列表或运行日志中，用目标域名与测试时间定位本次请求。重点记录目标地址、匹配规则、所选策略组和实际链路。客户端界面名称不统一，但这几项比“已开启”状态更能说明流量去了哪里。

如果看到 DIRECT，先检查是否命中了直连规则，或策略组当前选中了直连。
如果进入预期策略组但超时，再排查节点、服务端与本地到节点的连接。
如果完全没有相关记录，先核对日志级别、筛选条件和请求是否真实发出，再回头检查应用入口。

短时提高到 log-level: debug 可以补充线索，复现完成后恢复 info。日志可能含域名、内网地址与订阅相关信息，提交给他人之前应脱敏。不要用关闭 TLS 证书验证的方法“修复”代理；证书错误需要按证书链、系统时间和网络拦截分别处理。

什么时候考虑 TUN 模式？

应用不支持代理设置，或需要接管更多网络流量时，再考虑 TUN。系统代理主要依赖应用主动使用代理入口；TUN 通过虚拟网卡和路由接管流量，覆盖范围不同。Clash Meta 后续发展的 mihomo 支持相关功能，但能否使用还取决于客户端集成、系统权限和运行环境，不能把所有名为 Clash 的客户端视为同一实现。

在 mihomo 环境中，以下只是字段关系示例，不是适用于所有设备的通用配置。部分客户端会根据界面选项生成这些字段，应优先核对最终生效配置，避免界面开关与手写内容互相覆盖。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

auto-route 涉及路由接管，通常需要管理员或相应网络权限。
auto-detect-interface 用于自动判断出口接口；多网卡、虚拟网卡或 VPN 并存时仍需核对实际出口。
DNS 接管需要另行检查 DNS 模块、劫持规则与系统解析路径，上述四项不代表 DNS 已全部处理。
浏览器的安全 DNS、IPv6 与 QUIC/UDP 流量应按实际链路判断，不宜将其一律认定为故障原因。

按结果收敛，不同时改多个开关

最短排查路径是：确认监听端口 → 显式指定代理测试 → 浏览器核对设置来源 → 终端核对环境变量 → 客户端核对规则与链路。只有应用确实无法通过常规代理接入时，才进一步评估 TUN。

每次复测保留四项信息：操作系统与客户端名称、实际监听端口、执行的完整命令、同一时间的连接记录。若显式代理成功而浏览器失败，继续查浏览器；若终端加参数成功而不加参数失败，继续查环境与工具配置。这样可以把“系统代理没效果”拆成可验证的问题，而不是反复重装客户端。

需要核对字段含义，可查看Clash 配置字段；初次导入配置和选择代理模式，可从入门指南按顺序操作。