1. 先确认端口，再区分系统代理与 VPN 接管

打开客户端的「设置」，查找「端口」「入站」或「混合端口」。记下实际数值，再检查内核是否正在运行。不同客户端的菜单名称不一致，不要直接把教程中的端口填进系统。本文用 127.0.0.1:7890 演示；只有你的 HTTP 或混合端口确实是 7890 时，才可原样执行。

系统代理是一组交给应用读取的代理地址，不是强制接管所有网络连接的开关。浏览器通常会读取它，命令行工具则各有规则。摘要中的“终端只认环境变量”指常见排查入口；严格来说，真正发请求的是 curl、Git、包管理器等程序，它们还可能读取命令行参数和自己的配置文件。

入口作用常见误判
系统 HTTP 代理向遵循系统设置的应用提供代理地址开关开启就等于全部应用走代理
HTTP／混合端口接收应用主动发送的代理请求；混合端口兼容 HTTP 与 SOCKS把 SOCKS 专用端口填入 HTTP 代理栏
TUN 模式通过虚拟网络接口与路由接管符合条件的流量开启后无需检查路由、DNS 与分流规则
Android VPN 服务通过 Android 的 VpnService 接收设备流量把它当成桌面的系统代理开关

2. 用一次显式代理请求，判断故障在哪一层

先不要反复切换节点。打开终端，使用 curl 的显式代理参数，绕过“应用是否读取系统代理”这个变量。下面的地址只是测试目标，不是测速节点；重点看请求是否进入客户端，以及失败发生在哪一步。

macOS 或 Linux

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

Windows PowerShell

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

Windows 使用 curl.exe，避免 Windows PowerShell 5.1 中的 curl 别名调用其他命令。这里设置连接超时 10 秒、总时限 20 秒，只是为了避免测试一直等待，不是节点性能标准。--noproxy "" 用来清空本次请求的绕过列表。

  • 本机连接被拒绝：优先检查内核是否启动、端口是否正确，以及该端口是否只支持另一种代理协议。
  • 出现 HTTP 407：本地代理要求身份认证。按实际配置提供凭据，不要把密码贴进公开日志。
  • 出现 CONNECT 成功响应：说明 HTTP 代理接受了隧道请求，但后续 TLS 握手和目标响应仍可能失败。
  • 收到目标站点响应：说明这条目标请求的本地代理路径可用；不能据此认定所有节点、域名和规则都正常。

同时打开客户端的「连接」或「日志」页。查看请求域名、命中规则、策略组和最终出站。请求显示 DIRECT 时，流量可能已经进入内核，只是被规则安排为直连；这和“系统代理没有生效”不是同一件事。

3. 浏览器打不开：按系统设置、扩展、独立配置排查

Chrome 与 Edge：先看系统代理，再停用代理扩展

  1. Windows 11 打开「设置」→「网络和 Internet」→「代理」，核对「手动设置代理」中的地址与端口。若客户端管理的是自动配置脚本，也要核对脚本来源。
  2. macOS 进入「系统设置」→「网络」→ 当前连接 →「详细信息」→「代理」。检查网页代理、加密网页代理或自动代理配置是否符合客户端的设置方式。
  3. 在 Chrome 的「设置」→「系统」中打开计算机代理设置；Edge 对应入口通常位于「系统和性能」。也可直接使用上述操作系统路径。
  4. 打开扩展管理页，暂时停用所有能修改代理的扩展，再重新访问同一个测试地址。记录原来的扩展模式，测试后按需恢复。

代理扩展可能固定使用另一个端口，也可能通过 PAC 决定某些域名直连。PAC 是一段按网址选择代理的自动配置脚本。若浏览器提示设置由组织管理，检查浏览器策略或联系管理员，不要尝试用反复切换客户端开关覆盖组织配置。

Firefox：明确选择一种代理来源

打开「设置」→「常规」→「网络设置」→「设置」。要跟随操作系统，就选择「使用系统代理设置」；要独立测试，就选择「手动配置代理」，填入实际 HTTP 代理地址与端口，并检查是否将该代理用于 HTTPS。不要一边选择“不使用代理”，一边只修改系统代理。

如果采用 SOCKS v5，代理栏与端口必须对应 SOCKS 或混合入站。需要由代理侧解析域名时，检查 Firefox 中 SOCKS v5 的代理 DNS 选项。安全 DNS、缓存与代理类型都会影响解析路径，不能看到浏览器开启安全 DNS 就断定 Clash 的 DNS 一定失效。

4. 终端不走代理：给实际程序设置环境变量

若显式代理测试成功，而普通终端请求失败，就检查程序是否读取代理配置。环境变量只会传给当前进程及其之后启动的子进程；在一个窗口设置，另一个已经打开的窗口不会自动同步。下面先做会话级测试，不急着写入启动文件。

Bash 或 Zsh：先设置 HTTP 代理变量

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/

https_proxy 的值使用 http:// 并不是写错：这里描述的是连接本地代理时使用的协议，HTTPS 目标通常通过 HTTP CONNECT 隧道访问。不要仅因目标是 HTTPS，就把本地代理地址改成 https://127.0.0.1:7890。

curl 对 HTTP 代理使用小写 http_proxy；其他工具对大小写的处理可能不同。no_proxy 是绕过列表，若其中包含测试域名，程序可能主动直连。检查时注意大小写两套变量是否冲突，不要把带凭据的变量输出公开。

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/

不是每个 PowerShell 命令或应用运行时都会按 curl 的方式读取变量。若 curl 正常但另一个工具失败，继续查那个工具的代理文档，不要据此修改全系统网络设置。使用 sudo 后变量也可能被清理，应检查提权后程序实际获得的配置。

SOCKS 与应用专用配置

若本地确实开放了 SOCKS 或混合入站，可以用下面的单次请求比较解析路径。socks5h 表示将域名交给代理侧解析；普通 socks5 通常先由本机解析。此处的 7890 仍需替换为实际端口。

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

ALL_PROXY 可被部分工具用作通用代理变量，但支持范围与优先级不是全系统统一的。Git 还可能配置了 http.proxy，npm 也有独立的代理项。先查配置来源，避免同时叠加环境变量和遗留配置。

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

5. 什么时候改用 TUN 模式

需要接管多个不读取系统代理的应用，或者应用没有代理设置入口时，可以考虑 TUN。TUN 是虚拟网络接口，mihomo 等内核可借助它接收 IP 流量。它解决的是流量入口问题，不会自动修复失效订阅、错误节点、证书问题或不合适的分流规则。

  1. 先用显式 HTTP 或 SOCKS 请求确认节点路径可用，再启用客户端的「TUN 模式」或「虚拟网卡」入口。
  2. 按客户端提示安装或启动系统服务，授予必要权限。Windows、macOS、Linux 的权限机制不同，不要套用别的平台步骤。
  3. 暂时关闭其他 VPN 或虚拟网络接管工具，避免默认路由竞争。企业设备需先遵循管理要求。
  4. 测试期间去掉浏览器手动代理与终端代理变量，减少显式代理和 TUN 同时参与带来的判断困难。
  5. 重新发起请求，查看客户端连接记录和规则命中。再检查本地网络、打印机与公司内网是否仍可访问。

Android 通常通过 VPN 服务承载这类流量接管，不应照搬桌面安装虚拟网卡驱动的流程。还要检查分应用代理是否排除了目标应用；同一 Android 用户或工作资料中的其他 VPN 也可能影响连接。

6. 根据测试结果收尾，保留能复现的配置

测试现象优先检查下一步
显式代理也连接不上本地端口内核、监听地址、端口和入站协议先修复本地连接，不急着更新订阅
显式代理成功，浏览器失败系统代理、代理扩展、Firefox 独立设置保留一个明确的代理来源后重试
浏览器成功，终端失败环境变量、程序配置、容器网络对实际发请求的程序单独配置
请求进入内核但走 DIRECT规则、模式、策略组核对目标域名命中的规则
TUN 后部分应用仍失败路由、DNS、应用排除与 UDP 支持用该应用的实际请求检查日志

排查结束后，清理临时变量；若测试前已有代理设置，应恢复原值，而不是直接删除。以下命令适用于测试前没有这些变量的情况。持久配置则需要到 shell 启动文件或系统环境变量界面另行处理。

# Bash / Zsh：清理本次会话的临时代理
unset http_proxy https_proxy all_proxy no_proxy
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
# PowerShell：清理本次会话的临时代理
Remove-Item Env:http_proxy, Env:https_proxy, Env:all_proxy, Env:no_proxy -ErrorAction SilentlyContinue

最后记录四项信息：实际入站端口、浏览器代理来源、终端程序的代理配置、请求命中的出站。只要这四项明确，下次出现“系统代理开着但不生效”，就能从对应层继续排查，不必把浏览器、终端和节点问题混在一起。日志对外分享前，遮住订阅链接、认证信息与个人访问记录。