先区分“客户端运行”和“请求已通过代理”

先打开客户端的「连接」和「日志」页面，再刷新打不开的网页。窗口里显示“运行中”、系统托盘图标亮起，或者节点有延迟数字，只能说明部分环节正常，不能证明浏览器的这次请求已经过代理，更不能证明目标网站可访问。

Clash 是一类代理内核与客户端的常用称呼；Clash Meta 后续以 mihomo 名称继续维护。不同图形客户端的开关位置并不完全相同。下面以 Windows 11 的系统设置路径、常见客户端的「系统代理」「代理模式」「连接」「日志」功能和 mihomo 配置字段为参照，端口示例统一使用 7890，实际操作必须以当前配置为准。

  1. 记录现状：保存客户端名称、内核版本、活动配置名称、当前节点、混合端口和 TUN 开关状态。
  2. 排除基础断网：关闭系统代理与 TUN 后，访问日常可直连的网站。仍然失败时，先检查 Wi-Fi、网关、宽带认证或校园网登录。
  3. 缩小测试范围：只保留一个客户端运行，用同一个目标网址反复测试，每次只调整一项。
  4. 观察请求：刷新后没有连接记录，优先检查流量入口；有记录但连接失败，再检查出站节点、规则与 DNS。

检查系统代理：浏览器是否进入本地端口

核对地址、端口与代理例外

在 Windows 11 打开「设置」→「网络和 Internet」→「代理」→「手动设置代理」→「编辑」。普通浏览器 HTTP 代理的服务器地址应与客户端监听地址对应；客户端只监听本机时通常填 127.0.0.1，端口填写实际 HTTP 端口或混合端口，例如 7890。不要把控制面板的 API 端口当成代理端口。

在 macOS 打开「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」，检查网页代理与安全网页代理。不同系统版本名称可能略有差别。若启用的是自动代理配置，还要确认 PAC 地址能够访问、脚本规则是否让目标域名直连。检查代理例外列表，避免目标域名被意外排除。

  • 客户端重新启动后，再核对系统设置；旧进程退出时可能恢复了另一套代理值。
  • Firefox 可在「设置」→「常规」→「网络设置」→「设置」中选择“使用系统代理设置”，或明确填写自己的代理。
  • 临时停用浏览器代理扩展，避免扩展覆盖系统代理。企业管理的浏览器还可能受到策略控制。
  • 系统代理并不接管所有应用。终端工具、游戏和部分商店应用可能需要各自配置，或在确认普通代理正常后使用 TUN。

用显式代理请求绕开浏览器设置

在 Windows PowerShell 中使用 curl.exe，避免旧版 PowerShell 的 curl 别名干扰。以下命令向本机 HTTP 代理发送一次请求，总超时为 15 秒；example.com 只是连通性测试目标，随后应替换成实际失败网站再测一次。

curl.exe -v --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

macOS 与 Linux 可执行对应命令：

curl -v --connect-timeout 5 --max-time 15 --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

如果命令能获取 HTTP 响应，而浏览器仍失败，重点检查浏览器扩展、独立代理与缓存连接。如果直接出现连接 127.0.0.1:7890 被拒绝，先查本地监听，不要立即更换订阅。即使返回 403，也应与网络超时分开看：它表明已有 HTTP 服务响应，但可能是目标网站或中间设备拒绝了访问。

检查端口占用：确认监听者是当前内核

mixed-port 提供 HTTP 与 SOCKS 混合代理入口；external-controller 则用于控制 API，二者用途不同。示例配置中的 9090 不能直接填进浏览器代理栏。配置片段仅用于核对字段，不要用它覆盖完整订阅：

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090

在 Windows PowerShell 中查看监听进程：

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

将输出中的 OwningProcess 数字填入 Get-Process -Id 后查看进程名称。macOS 可使用第一条命令，Linux 可使用第二条；部分进程信息需要相应权限才能显示。

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -ltnp 'sport = :7890'
检查结果可能原因下一步
没有监听记录内核未启动、配置加载失败，或实际端口不是 7890查看启动日志和活动配置，确认实际监听端口
其他应用占用端口旧客户端、另一款代理工具或后台服务仍在运行正常退出冲突应用，再重启当前内核
日志含 address already in use当前内核绑定地址失败释放端口，或修改端口并同步系统代理
只监听 ::1监听地址与填入的 IPv4 回环地址不一致核对监听设置，让代理地址与监听地址一致

不要根据一个端口号直接强制结束陌生进程。先确认名称和来源。如果把混合端口改成 7891，必须同步修改系统代理、浏览器独立代理以及终端环境变量，否则请求仍会发往旧端口。

检查节点：延迟数字不等于目标网站可用

打开「代理」页面，找到实际参与出站的策略组。策略组可能指向另一个组，也可能选择了 DIRECT；界面上高亮了某个节点，不代表当前连接一定使用它。回到「连接」详情，核对请求域名、策略链和最终出站节点。

  1. 在同一个策略组中手动选择另一个节点，关闭旧连接后重新加载目标网页。
  2. 临时切换到全局模式，并在全局策略组中明确选择一个代理节点，再做相同请求。
  3. 若全局模式可用、规则模式失败，继续检查规则命中；若两者都失败，优先检查节点与本地网络。
  4. 通过服务提供方的账户页面确认订阅是否过期、流量是否耗尽，以及节点是否有维护通知。

全局模式改变的是进入内核后的路由选择，并不会自动让所有应用进入内核。测试完应恢复规则模式。节点延迟通常来自客户端配置的测试 URL，它只证明该测试请求在当时完成；不能由一个 150 ms 的数字推断视频、登录或特定网站也正常。

检查规则误判：查看首条命中的规则

规则模式按顺序匹配，首条命中规则决定连接走向。常见问题是目标域名被放进直连规则、较宽泛的规则排在前面，或者规则指向的策略组最终选择了不可用节点。不要只阅读配置末尾的 MATCH，应以该次连接详情中的规则记录为准。

下面展示规则顺序的作用。这里的 DIRECT 和 REJECT 是内置策略；该片段不是完整配置，也不应直接加入正在使用的订阅：

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,REJECT

在这个片段中，example.com 及其子域名会先匹配直连，其他未匹配请求会被拒绝。如果把两行颠倒，前面的 MATCH 会截住所有请求，后面的域名规则就没有机会生效。这正是“规则写了但没有作用”的典型原因。

  • 命中 DIRECT 后失败：先确认目标是否适合直连；需要代理时，将更精确的域名规则放到相关宽泛规则前。
  • 命中 REJECT：检查广告过滤或自定义拦截规则，判断是否误伤登录、验证码或静态资源域名。
  • 命中代理组仍失败：追踪该组最后选中的节点，不要仅凭组名判断。
  • 配置更新后问题复现：用客户端支持的覆写或合并功能保存自定义规则，避免直接修改被订阅刷新覆盖的内容。

修改规则后关闭对应旧连接再测试。浏览器可能复用已经建立的 HTTP/2 连接，单纯刷新未必产生新的路由判断。一个页面还可能同时请求多个资源域名，主页面成功但图片或登录失败时，应检查失败资源的连接记录。

检查 DNS 与 TUN：把解析故障和接管故障分开

先识别 DNS 错误

出现 Could not resolve host、no such host 或日志中的 DNS 超时，应先确定由谁解析域名。浏览器安全 DNS、系统 DNS、mihomo 的 DNS 模块可能采用不同路径。Windows 的 nslookup example.com 默认测试系统所选 DNS 的响应，并不自动代表 mihomo 内部解析正常；必须结合实际请求日志判断。

启用 fake-ip 时，看到 198.18.0.0/15 范围的地址不一定是异常。它可以是内核为域名分配的映射地址，需要由代理接管后恢复域名语义。如果关闭 TUN 后，浏览器仍缓存着这类地址，就可能继续失败。应先恢复一致的 DNS 与流量路径，再重启浏览器；Windows 可按需要运行 ipconfig /flushdns 清理系统缓存。

不要把 nameserver、fallback 全部替换成随机收集的公共地址。先确认上游 DNS 的地址与传输方式在当前网络可达，若上游使用域名，还要考虑其启动解析路径。浏览器安全 DNS可临时关闭作对照，确认问题后再按实际需求恢复。

普通代理正常后，再单独验证 TUN

TUN 使用虚拟网络接口接管流量，比系统代理涉及更多环节。若显式代理命令成功，开启 TUN 后反而全网失败，重点检查客户端服务权限、虚拟接口、路由与 DNS 劫持，不要继续盲目换节点。

  1. 关闭其他 VPN、虚拟组网和代理客户端，只保留当前工具，排除路由竞争。
  2. 确认客户端要求的服务模式或权限已正确启用，查看 TUN 启动日志是否报错。
  3. 先关闭 TUN，单独验证系统代理；再开启 TUN，按客户端建议设置系统代理，避免重复路径影响判断。
  4. 用 route print（Windows）或 ip route（Linux）观察切换前后的路由；企业网络需要保留的内网路由应单独处理。

mihomo 的 TUN 配置可使用 dns-hijack 接管匹配的 DNS 请求，但常见的 53 端口劫持不等于能接管所有加密 DNS。浏览器使用的 DoH 属于 HTTPS 流量，需要结合实际规则和 DNS 方案处理。

按报错收尾：记录能复现的最小案例

现象或日志优先排查
连接本机 7890 被拒绝端口、监听地址、内核启动状态
请求已进入内核，出站连接超时最终节点、上游连通性、出站拦截
全局模式成功，规则模式失败规则命中、策略组选择、直连路径
只有 TUN 开启时失败服务权限、虚拟接口、路由与 DNS 接管
certificate verify failed系统时间、证书链、HTTPS 检查设备
只有某一个站点返回 403 或 429目标站点限制、出口地址、账户与访问频率

证书错误时先同步系统日期与时间，确认网络是否要求认证，以及单位网络是否部署了 HTTPS 检查。不要把跳过证书验证作为常规修复。遇到 403 或 429，也不要反复刷新：代理链路可能已经建立，失败点在站点访问策略或请求频率。

需要进一步求助时，提供客户端与内核版本、系统版本、复现时间、目标域名、系统代理及 TUN 状态、显式代理测试结果，以及同一时间附近的错误日志。把“浏览器打不开”改成“本机端口可连接，规则命中某策略组，但最终节点出站超时”，处理方向会清楚得多。