先分清系统代理、应用代理与 TUN
打开 Clash Nyanpasu 的「系统代理」后，客户端会把本机代理地址写入操作系统设置。以常见配置为例，代理服务器是 127.0.0.1，混合端口是 7890。浏览器读取这项设置后，会把 HTTP 请求以及通过 CONNECT 建立的 HTTPS 连接交给 Clash；Clash 再按照当前配置中的规则、策略组和节点处理流量。
关键点在于，系统代理是一项供应用读取的设置，不是操作系统对所有网络包的强制转发。Chrome、Edge、Safari 等桌面浏览器通常会遵守系统代理，许多命令行程序、游戏启动器、开发工具和自带网络栈的应用则会自行决定是否读取。因此，“浏览器可以访问，终端仍然直连”并不矛盾，通常说明代理核心与节点已经工作，问题集中在终端程序如何取得代理参数。
| 接管方式 | 生效范围 | 常见配置位置 | 适合场景 |
|---|---|---|---|
| 系统代理 | 读取操作系统代理设置的应用 | Clash Nyanpasu「设置」→「系统代理」 | 浏览器与常规桌面应用 |
| 应用内代理 | 指定应用自身 | 应用网络设置或启动参数 | Git、浏览器扩展、开发工具 |
| 环境变量 | 当前终端或由其启动的进程 | HTTP_PROXY、HTTPS_PROXY、ALL_PROXY | curl、包管理器、命令行工具 |
| TUN 模式 | 经过虚拟网络接口的更多流量 | Clash Nyanpasu「设置」→「TUN 模式」 | 不读取代理设置的应用与 UDP 流量 |
第一步：确认 Clash 核心与本地端口正常
不要一开始就修改系统网络设置。先在 Clash Nyanpasu 中确认配置已经启用、代理核心处于运行状态，并检查当前模式是「规则」「全局」还是「直连」。规则模式下，某些目标按规则直接连接属于预期结果；如果测试域名命中了 DIRECT，即使请求进入 Clash，也看不到代理节点出口。
核对混合端口与监听地址
进入「设置」→「Clash 设置」或当前版本对应的端口设置页面，查看 mixed-port。常见值是 7890，但导入配置、端口冲突或手动调整都可能让实际值变成 7891、7897 等。后续命令中的端口必须与界面一致。
默认监听地址通常使用回环地址 127.0.0.1。如果命令就在本机运行，不需要开启局域网访问，也不应把代理地址填成本机 Wi-Fi IP。只有容器、虚拟机或同一局域网中的其他设备需要访问时，才需要结合 allow-lan、防火墙和监听地址进一步配置。
用 curl 直接测试本地代理
先绕过系统代理设置，明确指定 Clash 的 HTTP 代理进行一次请求：
curl -I -x http://127.0.0.1:7890 https://www.example.com如果返回 HTTP/2 200、HTTP/1.1 200 OK 或目标站点的正常重定向状态，说明本地端口可连接，HTTPS 隧道也已建立。若提示 Failed to connect 或 Connection refused，优先检查端口、核心运行状态和本地防火墙。若连接建立后超时，则查看 Clash 日志中的规则命中、节点错误和 DNS 结果。
还可以指定 SOCKS5 入口测试。混合端口通常同时接受 HTTP 与 SOCKS5，请以当前配置为准：
curl -I --proxy socks5h://127.0.0.1:7890 https://www.example.comsocks5h 中的字母 h 表示由代理端解析目标域名，适合用来区分本地 DNS 解析问题与代理链路问题。如果 HTTP 代理测试成功、直接请求失败，基本可以把排查范围收敛到系统设置或应用配置。
浏览器能用时，检查扩展与代理覆盖
浏览器访问正常只能证明“浏览器当前使用的某条代理路径可用”，不能直接证明系统代理设置正确。Chrome 和 Edge 一般读取系统代理，但代理扩展、企业策略、启动参数以及浏览器内置的安全 DNS 都可能改变实际行为。Firefox 还拥有独立的连接设置，可以选择系统代理、手动代理或直接连接。
排除浏览器代理扩展的独立配置
- 暂时停用负责切换代理的浏览器扩展。
- 完全退出浏览器，再重新启动，避免后台进程继续沿用旧连接。
- 只开启 Clash Nyanpasu 的系统代理，然后重新访问测试页面。
- 在 Clash 的连接记录中确认出现对应域名，并查看规则命中结果。
如果停用扩展后立刻失效，说明此前是扩展直接连接 127.0.0.1:7890，而不是系统代理生效。此时应检查操作系统代理地址是否仍指向旧端口，或者系统代理开关是否被其他代理软件覆盖。
检查 Firefox 的连接设置
Firefox 可进入「设置」→「常规」→「网络设置」→「设置」。选择「使用系统代理设置」时，它才会跟随操作系统；选择「手动代理配置」时，需要把 HTTP 代理与 HTTPS 代理填写为 127.0.0.1 和实际混合端口。若使用 SOCKS，应选择 SOCKS v5，并根据需求启用通过 SOCKS 代理 DNS。
识别安全 DNS 带来的差异
浏览器的 DNS over HTTPS 可能让域名解析路径与终端不同。终端通常先调用系统 DNS，浏览器则可能向自己的加密 DNS 服务查询。若表现为浏览器可访问、终端提示“无法解析主机”，先运行 nslookup 或 dig 检查系统解析，再用前面的 socks5h 请求测试代理端解析。此时问题不一定出在代理端口，而可能是系统 DNS、VPN 残留设置或网络接口优先级。
终端为什么不会自动跟随系统代理
命令行工具跨平台运行时，往往不依赖桌面系统的代理接口。curl、Git、Python、Node.js 及各类包管理器对代理变量的支持也不完全相同。最稳定的做法是先给当前终端会话设置环境变量，再启动目标命令；测试完成后清除变量，避免以后切换端口时仍连接旧地址。
Windows PowerShell 临时设置
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"
$env:NO_PROXY="localhost,127.0.0.1,::1"
curl.exe -I https://www.example.comHTTPS_PROXY 的值写成 http:// 是常见且正确的配置：它表示客户端先通过 HTTP 代理建立 CONNECT 隧道，隧道内再传输 HTTPS。不要因为变量名包含 HTTPS 就擅自把协议改成 https://，除非本地代理端口明确提供 TLS 代理服务。
这些 PowerShell 变量只影响当前窗口以及从该窗口启动的子进程。关闭窗口后设置失效。清除方式如下：
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXY
Remove-Item Env:ALL_PROXY
Remove-Item Env:NO_PROXYWindows CMD 临时设置
set HTTP_PROXY=http://127.0.0.1:7890
set HTTPS_PROXY=http://127.0.0.1:7890
set ALL_PROXY=socks5://127.0.0.1:7890
set NO_PROXY=localhost,127.0.0.1,::1
curl.exe -I https://www.example.comWindows 中还存在 WinINET 与 WinHTTP 两套代理机制。浏览器和不少桌面程序读取系统界面的代理设置，某些系统服务则使用 WinHTTP。可以用 netsh winhttp show proxy 查看 WinHTTP 状态，但不要为了修复普通终端请求就直接导入全局设置；先确认目标程序究竟读取哪一套配置。
macOS 与 Linux 的当前会话设置
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"
export NO_PROXY="localhost,127.0.0.1,::1"
curl -I https://www.example.com同时设置小写变量可以兼容只读取小写名称的工具：
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
export no_proxy="$NO_PROXY"清除当前会话变量可执行：
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
unset http_proxy https_proxy all_proxy no_proxy如果要写入 ~/.zshrc、~/.bashrc 或其他 shell 配置，建议定义开启和关闭代理的函数，而不是长期固定一个端口。这样在 Clash 未启动时，终端不会反复等待一个不存在的本地代理。修改配置文件后，需要重新打开终端或执行相应的 source 命令。
Git、包管理器与开发工具要单独核对
环境变量设置正确后，部分工具仍可能被自己的配置覆盖。排查时应同时检查“系统设置、环境变量、应用配置”三个层级，并留意配置的优先级。最常见的情况是 Git 中保存了旧端口，或者 npm 配置中仍指向已停用的代理地址。
Git 的代理配置
查看 Git 当前读取到的代理来源：
git config --show-origin --get-regexp "http\..*proxy|https\..*proxy"需要为当前用户设置代理时，可执行：
git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890以后改用环境变量或 TUN 模式时，应移除这两项，避免固定配置继续覆盖新路径：
git config --global --unset http.proxy
git config --global --unset https.proxynpm 与 pnpm 的代理记录
npm config get proxy
npm config get https-proxy
pnpm config get proxy
pnpm config get https-proxy输出若是旧地址，应更新为当前端口或删除对应配置。包管理器还会受到镜像源、证书链、DNS 和仓库服务状态影响，因此“下载失败”不能只看代理开关。建议先用 curl 请求同一仓库域名，再查看命令的详细日志，区分 TCP 连接失败、域名解析失败、TLS 错误与服务端限流。
容器与虚拟机中的 127.0.0.1
Docker 容器、WSL 和虚拟机里的 127.0.0.1 通常指向它们自己的网络环境，不一定是宿主机。把宿主机 Clash 地址原样复制进去，常见结果就是连接被拒绝。此时需要使用宿主机在该虚拟网络中的地址，并在 Clash 中按需开启局域网访问，同时配置操作系统防火墙。开放范围应限制在可信网络，不要直接暴露给公共网络。
什么时候应改用 TUN 模式
如果目标应用不支持 HTTP 或 SOCKS 代理，也不读取环境变量，系统代理就难以覆盖。典型场景包括部分游戏启动器、使用 UDP 的程序、固定直连的桌面应用，以及需要同时接管多个开发工具的工作环境。这时可以考虑 TUN 模式，让流量先经过虚拟网络接口，再交给 mihomo 核心按规则处理。
TUN 模式解决的是接管范围
TUN 并不会自动提升节点质量，也不会修复订阅中错误的服务器参数。它主要改变流量进入 Clash 的方式。启用后，原本绕过系统代理的 TCP 或 UDP 流量有机会被统一接管，规则模式、策略组和节点选择仍按当前配置执行。
在 Clash Nyanpasu 中，可从「设置」→「TUN 模式」启用相关功能。Windows 首次启用可能需要管理员权限来创建虚拟网络接口；macOS 可能弹出网络扩展或系统权限确认；Linux 通常需要相应的网络管理权限。不同客户端版本的菜单名称会略有差异，但应以 TUN 开关、网络接口状态和核心日志为判断依据。
启用前后的检查顺序
- 关闭其他 VPN、加速器或同类 TUN 程序，避免路由表被多方同时修改。
- 记录当前系统代理状态、混合端口和 DNS 设置，便于恢复。
- 启用 TUN 后确认虚拟接口创建成功，并观察核心日志是否出现权限错误。
- 先测试浏览器和 curl，再测试原本无法接管的应用。
- 检查局域网地址、打印机、开发服务器是否仍可访问，必要时配置直连规则。
TUN 与系统代理可以在部分客户端中同时开启，但排障阶段最好一次只验证一种接管方式。否则同一请求可能经过不同入口，难以判断问题来自系统代理、环境变量还是虚拟接口。确认 TUN 工作后，再按使用习惯决定是否保留系统代理。
DNS、规则与回环地址的常见误判
终端报域名解析失败
如果错误发生在连接代理之前，例如提示 Could not resolve host，先判断使用的是 HTTP 代理还是 SOCKS。HTTP CONNECT 请求通常会把目标主机名交给代理处理；socks5:// 可能先在本地解析，而 socks5h:// 明确要求代理端解析。用两种写法对照测试，可以快速判断故障位于系统 DNS 还是代理链路。
请求进入 Clash 却显示 DIRECT
规则模式会按域名、IP、进程或规则集选择策略。如果日志显示 DIRECT，说明请求已经被接管，只是规则决定直连。可以检查当前配置的规则顺序、目标域名所属规则集以及最终兜底规则。临时切换到全局模式可用于对照，但测试结束后应恢复原模式，避免把本应直连的局域网和国内服务全部交给代理节点。
localhost 被代理后访问异常
开发服务器常使用 localhost:3000、127.0.0.1:5173 或其他本地端口。设置环境变量时应通过 NO_PROXY 排除 localhost、127.0.0.1 和 ::1，否则某些工具会尝试把本地请求发送到代理。需要访问内网服务时，也可按工具支持的格式加入公司域名或网段，但不同程序对通配符和 CIDR 的支持并不一致。
按现象收敛问题的完整清单
- 浏览器正常，curl 直连失败：使用
-x明确指定代理。若成功，为终端设置环境变量或工具内代理。 - 浏览器正常，curl 指定代理也失败：浏览器可能使用扩展中的另一端口。核对扩展配置和 Clash 当前混合端口。
- curl 指定代理成功，环境变量方式失败：检查变量拼写、大小写、当前 shell 作用域，以及工具是否支持这些变量。
- 连接记录中没有目标请求：请求尚未进入 Clash，继续检查应用配置、本地地址、容器网络与端口占用。
- 连接记录出现但规则为 DIRECT：检查规则匹配结果，不要把直连误认为系统代理失效。
- 连接记录出现且代理节点报错：测试策略组中的其他节点，并检查订阅更新、节点可用性与网络连通性。
- 只有域名失败，IP 可连接：重点检查系统 DNS、Clash DNS 配置和 SOCKS 域名解析方式。
- 应用完全不支持代理参数：评估 TUN 模式，并处理虚拟接口权限、路由冲突与局域网直连规则。
最有效的排查顺序是：先确认本地端口，再明确指定代理测试，然后检查系统代理或环境变量，最后才考虑 TUN。浏览器已经可以访问时，通常无需反复更换节点或订阅；应把注意力放在终端是否读取代理、端口是否一致、DNS 在哪里解析，以及请求是否真正进入 Clash 核心。