先验证代理入口，再检查应用设置

先保持当前配置不变，用一条显式指定代理的请求验证本地端口。系统代理开启，只表示客户端尝试把代理地址写入操作系统设置；它既不能证明内核正在监听，也不能保证所有应用读取这份设置。浏览器、命令行工具和虚拟网卡是不同入口，混在一起排查容易把正常的直连规则误判为代理失效。

建立三项基线

  1. 确认客户端内核已运行，当前配置已启用。只完成订阅导入、没有切换到该配置，并不代表规则已加载。
  2. 记录当前 HTTP 或 mixed 端口、运行模式、选中的策略组节点。排查期间先关闭 TUN，减少流量路径叠加。
  3. 打开客户端的「连接」与「日志」页面，再向同一个目标发起请求。关注目标域名、命中规则和最终策略，而不只看开关颜色。

不同客户端的菜单名称不同，配置文件中的 port 表示 HTTP 代理入口，socks-port 表示 SOCKS 入口，mixed-port 同时接受 HTTP 与 SOCKS。客户端可能通过覆写修改这些值，应查看最终运行配置，而不是仅查看订阅原文。仅供本机使用时，不需要为了排查开启「允许局域网连接」。

用 curl 显式指定代理，区分端口故障与规则直连

在 Windows PowerShell 中使用 curl.exe，避免 Windows PowerShell 5.1 的 curl 别名调用到 Invoke-WebRequest。macOS 和 Linux 可直接使用 curl。下面访问的 example.com 仅用于验证请求路径，不用于判断地区解锁或测量节点速度。

Windows：明确指定 HTTP 代理

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

macOS / Linux：使用相同目标复测

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

--noproxy "" 用于清空这一次请求的绕过列表，防止现有 NO_PROXY 干扰。详细输出应先显示连接到 127.0.0.1:7890，随后对 HTTPS 目标发起 CONNECT example.com:443。看到隧道建立说明请求已进入本地代理，但仍需结合客户端连接记录判断最终是代理节点还是 DIRECT。

观测结果判断方向下一步
本地连接被拒绝端口未监听或填写错误检查内核状态、最终端口及端口占用
隧道建立后请求超时入口可用，后续链路仍有问题检查所选节点、目标可达性与内核日志
客户端记录命中 DIRECT流量已进入内核，但规则决定直连检查命中的域名规则和策略组
显式代理成功，浏览器失败浏览器代理设置可能不同检查扩展、PAC、浏览器自身设置

Windows 可运行 Get-NetTCPConnection -LocalPort 7890 -State Listen 查看监听与所属进程；Linux 可运行 ss -ltnp 'sport = :7890'；macOS 可运行 lsof -nP -iTCP:7890 -sTCP:LISTEN。若发现其他程序占用端口，应先处理冲突，而不是反复更新订阅。

浏览器单独排查：扩展、系统代理与 PAC

显式代理测试通过后，再检查浏览器。Chrome 与 Edge 通常读取系统代理，但扩展、启动参数和组织策略可能覆盖它；Firefox 还提供独立的连接设置。浏览器能打开网页，也不等于正在使用代理，缓存页面和规则直连都可能造成误判。

先检查操作系统写入结果

  • Windows 11：进入「设置」→「网络和 Internet」→「代理」，检查「手动设置代理」中的地址与端口。使用本地 HTTP 入口时，地址为 127.0.0.1，端口与客户端一致。
  • macOS 13 及之后：进入「系统设置」→「网络」→当前连接→「详细信息」→「代理」。分别检查网页代理、加密网页代理或自动代理配置，确认正在修改实际使用的网络服务。
  • Firefox：进入「设置」→「常规」→「网络设置」→「设置」，检查是否选择「使用系统代理设置」。若使用手动代理，记录其地址、端口与不使用代理的地址列表。

Windows 的 netsh winhttp show proxy 查看的是 WinHTTP 设置，不能直接代表浏览器正在使用的用户代理设置。不要因为它显示直接访问，就认定客户端没有写入系统代理，也不要为了浏览器问题先修改整台机器的 WinHTTP 配置。

暂时停用控制代理的扩展

打开 Chrome 的 chrome://extensions/ 或 Edge 的 edge://extensions/，暂时停用具有代理控制能力的扩展，然后完全退出浏览器再启动。隐私窗口不一定能隔离代理设置来源，也不保证所有扩展都停用。若设备由组织管理，再查看 chrome://policy/ 或 edge://policy/；受策略控制的设置应交由管理员确认。

PAC 返回 DIRECT 时，本地内核不会收到该请求

PAC 是浏览器侧的代理选择脚本，与 Clash 内核中的规则不是同一层。PAC 返回 DIRECT，浏览器就直接连接；返回 PROXY 127.0.0.1:7890，才会把请求交给本地 HTTP 入口。如果 PAC 写了 PROXY 127.0.0.1:7890; DIRECT，代理不可用时还可能回退直连。

排查时可暂时停用自动配置脚本，只保留一套手动代理设置，重启浏览器后重复同一目标请求。记录旧 PAC 地址便于恢复，不要同时启用两种配置后猜测优先级。若浏览器请求在客户端完全没有记录，而显式 curl 请求有记录，优先检查浏览器绕过列表与 PAC，而不是调整规则集。

终端单独排查：环境变量与工具配置

终端程序不一定读取系统代理。curl、Git、包管理器各有配置来源，系统开关开启后仍直连很常见。先检查当前终端的环境变量，再检查工具专用配置；已经运行的进程通常不会自动获取后来修改的环境变量。

macOS / Linux：只对一条命令设置代理

env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 \
curl -v --noproxy "" --max-time 20 https://example.com/ -o /dev/null

这里 https_proxy 的值仍以 http:// 开头，表示连接本地 HTTP 代理，再通过 CONNECT 建立到 HTTPS 网站的隧道。不要因为目标网址使用 HTTPS，就把本地代理地址改成 https://127.0.0.1:7890；普通 HTTP 代理端口并不提供 TLS 代理入口。

curl 对 HTTP 代理环境变量使用小写 http_proxy，其他变量的大小写支持因工具而异。NO_PROXY 或 no_proxy 中若包含目标域名、地址范围或 *，可能让请求跳过代理。保留必要的本地绕过项，并逐项确认，而不是永久清空所有绕过规则。

PowerShell：设置当前会话的代理变量

Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

$env:HTTP_PROXY = 'http://127.0.0.1:7890'
$env:HTTPS_PROXY = 'http://127.0.0.1:7890'
curl.exe -v --noproxy "" --max-time 20 https://example.com/ -o NUL

以上赋值只影响当前 PowerShell 及其之后启动的子进程，不会替已经运行的 IDE、终端标签页或后台任务更新环境。需要撤销测试时，若这些变量原先不存在，可使用下面的命令；若原先已有值，应恢复记录的旧值。

Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY -ErrorAction SilentlyContinue

Git 能否联网，要检查 Git 自己的代理来源

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

该命令显示仓库、本机用户或系统级配置中的代理相关项。注意针对某个 URL 的设置也可能存在；没有匹配项时命令可能以非零状态退出，并不表示 Git 损坏。HTTPS 仓库与 SSH 仓库使用不同传输机制，http.proxy 不能直接解决 SSH 连接问题。npm、pip 等工具同样需要分别核对，不能用 curl 成功推断所有开发工具都已使用代理。

检查规则与 DNS：进入内核不等于使用节点

当浏览器或终端的请求已出现在连接列表中，应从「入口问题」转到「路由问题」。规则模式按顺序匹配规则，再交给对应策略或策略组。命中 DIRECT、选择到直连成员，或进程规则优先匹配，都可能让出口保持本地网络。

  1. 找到刚刚测试的目标，记录命中规则、策略链和选中的节点。不要只查看策略组名称。
  2. 确认运行模式不是直连模式。规则模式下检查规则顺序，特别是较早出现的域名、进程和地址规则。
  3. 必要时短暂切到全局模式，并确认全局策略选中可用代理节点。重复同一请求后恢复原模式；全局测试用于隔离规则因素，不是永久修复办法。
  4. 如果请求进入内核后报告解析失败，再检查 DNS 配置与日志，不要同时替换节点、DNS 和规则集。

浏览器的安全 DNS 设置可能影响域名解析路径，但它不是「绕过 HTTP 代理」的充分证据。使用 HTTP CONNECT 时，浏览器可以把目标域名交给代理；TUN 场景又涉及 DNS 接管与域名映射。应根据连接记录判断请求走向，而不是仅根据 DNS 设置推断。Fake-IP 配置修改后还可能需要重新建立连接，已有长连接不能代表修改后的结果。

何时启用 TUN：处理不读取代理的应用

如果显式代理、浏览器系统代理与终端变量都验证正常，只有某些不读取代理设置的应用仍直连，再考虑 TUN。TUN 通过虚拟网卡和路由接管匹配范围内的流量，与系统代理不是同一个开关；它也不是绕过节点不可用、订阅错误或规则直连的补丁。

按权限、路由、DNS 三项检查

  • 权限与服务：按照客户端提示安装或启动所需服务，并确认虚拟网卡成功创建。Windows、macOS 与 Linux 的权限机制不同，不应套用同一组操作。
  • 路由接管：检查当前运行配置中的 tun.enable、auto-route 等设置与日志。存在 TUN 网卡，并不保证所有目的地址或所有协议都已进入该网卡。
  • DNS 与冲突：检查是否与另一套 VPN、虚拟机网络或企业安全软件同时改写路由和 DNS。一次只停用一个来源，记录恢复方法，避免破坏正常的办公网络。

桌面客户端可以替用户管理部分 TUN 设置，纯 mihomo 内核部署则需要自行确认权限与运行配置。遇到局域网设备无法访问、DNS 超时或启动 TUN 后全部断网，应先关闭 TUN 恢复已验证的系统代理路径，再定位路由与 DNS。不要把所有问题都归因于「需要管理员运行」。

按测试结果收敛问题，避免反复重装

最有效的排查记录包含四项：本地入口是否可连、目标请求是否出现在内核、命中什么策略、哪个应用失败。对同一个目标分别做显式 curl、浏览器和应用测试，可以减少不同站点、缓存与节点状态带来的噪声。

  • 显式 curl 也失败：先修复端口、内核运行状态或后续节点链路。
  • 显式 curl 成功，浏览器没有连接记录：优先处理扩展、PAC、浏览器代理来源。
  • 浏览器成功，终端失败：检查当前进程环境变量、绕过列表和工具专用配置。
  • 请求都有记录，但出口仍直连：核对规则与策略选择，不要继续改系统代理。
  • 只有特定应用直连：确认其代理支持，再决定单独配置还是启用 TUN。

向他人提供排查信息时，可附上操作系统版本、客户端与内核版本、实际监听端口以及脱敏后的错误日志。删除订阅地址、访问令牌、节点密码与私人目标域名。若仍无法定位，可继续查看故障排查说明；恢复代理配置后，再按使用指南整理日常设置。