开了系统代理却没生效?浏览器与终端分开排查的完整流程

先确认问题发生在哪一层

“系统代理已开启”只说明 Clash 客户端尝试把操作系统的代理地址改为本机监听端口，不代表所有应用都会读取这项设置。Chrome、Edge 和 Safari 通常跟随系统代理；Firefox 可以使用自己的连接设置；curl、Git、npm、Python 包管理器以及多数终端程序则可能直接连接网络。排查时应先区分浏览器、终端和 Clash 内核，而不是反复切换节点。

开始前先在客户端确认三件事：配置文件已经启用，策略组中存在可用节点，内核处于运行状态。不同客户端的菜单名称略有差异，常见路径是「配置」→「当前配置」、「代理」→「策略组」以及「设置」→「系统代理」。如果日志页完全没有新连接，问题通常位于应用到本地代理端口之间；如果日志出现连接但显示超时、规则错误或节点失败，再处理配置与远端节点。

用四个现象快速定位

现象	优先检查	常见原因
所有网页都无法打开	Clash 监听端口与系统代理地址	内核未启动、端口填错或端口被占用
浏览器可用，终端失败	终端环境变量与程序自身配置	命令行工具没有读取系统代理
浏览器只有部分网站失败	规则命中、绕过列表与扩展	域名被直连、代理扩展覆盖系统设置
开启 TUN 后可用，系统代理模式失败	应用是否支持 HTTP 或 SOCKS 代理	应用绕过系统代理直接建立连接

核对 Clash 监听端口与系统代理地址

Clash 常见的本地监听形式有 HTTP 端口、SOCKS5 端口和 mixed-port。较早的配置常把 HTTP 设为 7890、SOCKS5 设为 7891；mihomo 配置也经常只启用 mixed-port: 7890，让同一端口同时接收 HTTP 与 SOCKS5 请求。端口并非固定值，最终应以客户端「设置」→「端口设置」或当前配置中的实际数值为准。

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

这段配置表示代理只监听本机 127.0.0.1:7890。系统代理中的服务器地址也应指向 127.0.0.1，HTTP 与 HTTPS 可以填写同一个 mixed 端口。不要把订阅节点的远端地址填进操作系统代理设置，也不要把 Clash 的控制端口误当作流量端口。

Windows 11 检查路径

打开「设置」→「网络和 Internet」→「代理」。
查看「使用代理服务器」是否开启。
核对地址是否为 127.0.0.1，端口是否与 Clash 当前监听端口一致。
如果客户端使用自动配置脚本，确认「使用设置脚本」中的地址仍然有效。
切换系统代理后，关闭并重新打开出现问题的应用，避免它继续使用旧连接池。

macOS 检查路径

打开「系统设置」→「网络」。
选择当前正在使用的 Wi-Fi 或以太网连接。
进入「详细信息」→「代理」。
核对网页代理 HTTP、安全网页代理 HTTPS 与 SOCKS 代理的地址和端口。
如果 Clash 客户端负责接管设置，不要同时保留另一款代理工具写入的旧端口。

直接测试端口是否监听

Windows 可以在 PowerShell 中执行以下命令。出现 Listen 或可建立 TCP 连接，说明本地端口已打开；连接失败则应先重启内核或解决端口冲突。

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue

macOS 与 Linux 可以使用 lsof 查看监听进程：

lsof -nP -iTCP:7890 -sTCP:LISTEN
nc -vz 127.0.0.1 7890

如果监听者不是当前 Clash 或 mihomo 进程，先退出占用端口的旧客户端，再启动正在使用的客户端。也可以在「设置」→「端口设置」中改为未占用端口，例如 7892，随后重新开启系统代理，让操作系统同步新值。

浏览器不生效时逐项排查

Chromium 系浏览器通常读取操作系统代理，但浏览器扩展、企业策略和独立用户配置都可能改变实际路径。排查时建议先打开普通窗口，暂时停用负责代理切换的扩展，再访问目标页面。隐私窗口不一定会停用所有扩展，应在扩展管理页确认其状态。

Chrome 与 Edge

Chrome 可进入「设置」→「系统」→「打开您计算机的代理设置」，确认它跳转到当前系统的代理页面。
Edge 可进入「设置」→「系统和性能」→「打开计算机的代理设置」。
完全退出浏览器进程后重开。只关闭一个标签页不会清理已有的长连接。
在 Clash 日志中按目标域名观察规则命中。如果记录显示 DIRECT，应检查规则顺序，而不是修改浏览器端口。
如果浏览器由组织策略管理，在地址栏打开 chrome://policy 或 edge://policy，查看是否存在固定代理策略。

Firefox 的独立连接设置

Firefox 可以不跟随系统代理。进入「设置」→「常规」→「网络设置」→「设置」，通常有四种状态：不使用代理、自动检测、使用系统代理设置、手动代理配置。希望跟随 Clash 系统代理时选择「使用系统代理设置」；需要独立测试时，可选择手动配置并填写 127.0.0.1 与实际端口。

使用 SOCKS5 手动配置时，代理地址可填 127.0.0.1，端口填 Clash 的 SOCKS 或 mixed 端口，并选择 SOCKS v5。若界面提供“使用 SOCKS v5 时代理 DNS 查询”，建议在诊断阶段开启，以便域名解析也沿同一路径完成。

检查绕过列表

系统代理通常会绕过 localhost、127.0.0.1、局域网地址或用户手动添加的域名。Windows 代理页中的“不对以下列条目开头的地址使用代理服务器”，以及 macOS 代理页中的“忽略这些主机与域的代理设置”，都会让匹配目标直接连接。

如果某个域名始终不出现在 Clash 日志中，先从绕过列表移除该域名及其通配写法，再重新启动浏览器。局域网管理页通常应继续保留直连，例如路由器地址 192.168.1.1；不要为测试而删除全部本地地址例外。

终端默认不走系统代理的处理方法

终端本身只是命令运行环境。是否使用代理由 curl、Git、npm、pip 等具体程序决定。许多命令行工具会读取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY，但也有程序只读取小写变量，或者优先使用自己的配置文件。因此浏览器已经可用时，终端仍然需要单独设置。

macOS、Linux 与 Bash、Zsh

仅对当前终端会话生效的 HTTP 代理写法如下。代理地址中的 http:// 表示终端程序通过 HTTP 代理协议连接本地端口，并不限制目标网站只能使用 HTTP。

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="$NO_PROXY"

使用 SOCKS5 时，可以为支持该变量的程序设置：

export ALL_PROXY="socks5h://127.0.0.1:7890"
export all_proxy="$ALL_PROXY"

socks5h 中的字母 h 表示由 SOCKS 代理一侧解析域名，可减少本地 DNS 路径与代理路径不一致的情况。并非所有程序都识别该格式，遇到不支持时应改用程序自己的代理选项。

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"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

这些变量只影响当前 PowerShell 窗口及从该窗口启动的子进程。关闭窗口后即失效，适合排查。需要清除时执行：

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

Windows 命令提示符

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

同样只需要临时诊断时，不要立即使用永久环境变量。旧端口一旦写入系统级变量，即使 Clash 后来改为其他端口，新的终端程序仍会继续连接旧地址，形成“系统代理正确但命令一直失败”的现象。

用 curl 分离测试代理、DNS 与目标站点

curl 适合直接指定代理，不依赖系统代理和当前环境变量。先用显式 HTTP 代理发起请求，并添加 -v 查看连接过程：

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

输出中如果先出现连接 127.0.0.1:7890，同时 Clash 日志新增 example.com，说明终端到 Clash 的路径成立。若提示 Connection refused，优先检查端口与内核；若本地连接成功但随后超时，则查看策略组节点、规则命中和远端连接。

SOCKS5 测试可使用：

curl -v --proxy socks5h://127.0.0.1:7890 https://example.com/

再使用不指定代理的命令做对照：

curl -v https://example.com/

显式代理成功而普通命令失败，说明 Clash 本身可以工作，问题集中在环境变量或程序配置。两条命令都失败时，继续看日志：显式代理请求没有进入日志，多半是端口错误；进入日志后连接失败，则属于配置、规则或节点链路问题。

确认环境变量实际值

macOS 与 Linux 可执行：

env | grep -i proxy

PowerShell 可执行：

Get-ChildItem Env: | Where-Object Name -Match "PROXY"

重点寻找旧地址、旧端口和重复变量。例如 HTTPS_PROXY 指向 127.0.0.1:7890，而小写的 https_proxy 仍指向 127.0.0.1:1080。不同程序读取顺序不同，重复值会造成结果不一致。诊断阶段应让大小写变量保持相同。

Git、npm 与其他工具的独立代理设置

环境变量正确后，如果只有一个工具失败，应查看它的专属设置。专属设置通常比系统代理更稳定，但端口变化后也需要同步更新。

Git

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 --get-regexp "http.*proxy"

取消全局代理时执行：

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

如果仓库级配置另有代理，进入仓库后执行 git config --local --get-regexp "http.*proxy"。本地配置的优先级高于全局配置，可能导致只有某个仓库连接失败。

npm

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

清理设置时使用：

npm config delete proxy
npm config delete https-proxy

单次命令优先于永久写入

排查阶段建议先使用 curl 的 --proxy、程序命令参数或当前会话环境变量。验证路径稳定后，再决定是否写入 ~/.zshrc、~/.bashrc 或工具配置。这样可以避免客户端端口调整后，启动脚本仍持续注入旧值。

规则、代理模式与假连通现象

请求进入 Clash 日志后，下一步是看规则命中。Rule 模式会从上到下匹配域名、IP、GeoSite、GeoIP 与兜底规则。某个域名命中 DIRECT 时，它会直连，不会经过所选代理节点。排查单个网站时，可以在日志中确认命中的策略组，再检查配置文件中的规则顺序。

Global 模式通常把请求交给全局策略组，适合短时判断问题是否来自规则。如果 Rule 模式失败而 Global 模式成功，说明本地端口与节点基本可用，应回到规则配置处理，而不是长期依赖 Global 模式。Direct 模式会让请求直接连接，用它无法验证代理节点。

延迟测试成功不等于目标请求成功

延迟测试只访问客户端预设的测试地址，通常不能代表所有域名都可访问。
节点显示几十毫秒，只说明测试请求在当时完成，不代表浏览器正在使用该节点。
策略组可能选择了“自动选择”，而实际请求命中了另一个策略组。
已有浏览器连接可能复用旧通道，切换节点后应刷新页面或重启应用再测。
UDP、IPv6 与普通 TCP 请求可能经过不同处理路径，不能只用一种测试推断全部流量。

何时考虑 TUN 模式

系统代理主要覆盖主动读取 HTTP、HTTPS 或 SOCKS 代理设置的程序。部分桌面应用、游戏启动器、系统组件和自行实现网络栈的软件会忽略系统代理。mihomo 的 TUN 模式通过虚拟网络接口接管更广范围的 IP 流量，适合处理这些应用，但它不是修复端口填写错误的替代方案。

启用 TUN 前应先确保配置、节点和规则在普通代理测试中可用。随后进入客户端「设置」→「TUN 模式」开启功能。Windows 可能需要允许客户端安装或启用网络组件；macOS 可能要求确认网络扩展权限。启用后再次观察日志，确认原本缺失的应用请求是否出现。

按固定顺序完成最终排查

确认当前配置已启用，策略组已经选择可用节点，Clash 或 mihomo 内核正在运行。
在「设置」→「端口设置」读取真实端口，不凭经验假定一定是 7890。
使用 Test-NetConnection、lsof 或 nc 确认端口正在监听。
核对操作系统代理地址是否为 127.0.0.1，端口是否与客户端一致。
清理浏览器代理扩展影响，检查 Firefox 独立设置与系统绕过列表。
用 curl 的 --proxy 参数做显式测试，同时观察 Clash 日志。
浏览器可用但终端失败时，设置当前会话的 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。
只有 Git、npm 等单一工具失败时，再检查该工具的专属代理配置。
请求已经进入日志但失败时，核对 Rule、Global、Direct 模式及实际命中的策略组。
应用完全忽略系统代理且普通代理链路已验证后，再启用 TUN 模式。

有效的排查过程应始终保留一组对照结果：浏览器是否产生日志、显式 curl 是否成功、普通 curl 是否读取环境变量、目标域名命中了哪条规则。把问题拆成“应用到本地端口”“Clash 规则处理”“节点到目标地址”三段后，系统代理已开却不生效通常可以定位到一个明确环节。