Clash 首次连接检查清单:从测速选线到确认代理已生效

1. 导入订阅后，先确认配置已经启用

订阅导入成功，只说明客户端拿到了配置内容。要让浏览器连接经过代理，还需要完成配置启用、代理组选线和流量接入。第一次连接建议先用系统代理验证浏览器请求，暂时关闭 TUN 模式，避免两种接入方式叠加后难以判断问题发生在哪一层。

不同客户端可能把配置入口称为「配置」「订阅」或「Profiles」。进入对应页面后，检查下面四项，不要只看“更新成功”的提示。

1. 当前配置：导入的条目处于选中或启用状态，而不是仅保存在列表里。
2. 更新时间：手动更新一次，确认没有认证失败、下载超时或解析错误。
3. 内核状态：Clash 或 mihomo 已启动，日志里没有配置加载失败、端口占用等错误。
4. 代理组内容：能看到节点或已加载的节点提供者，不能只有空组和 DIRECT。

如果配置提示字段不支持，先核对订阅要求的内核。Clash 与 mihomo 的配置能力并不完全相同。反复开关系统代理无法解决配置语法或协议兼容问题，应先让内核正常加载配置。

2. 在代理组里选节点，再做延迟测试

打开客户端的「代理」或「Proxies」页面，找到默认代理组。组名由订阅定义，可能是“节点选择”，也可能是其他名称。先确认规则最终使用哪个组，再在该组内选择一个节点。若组内嵌套了其他代理组，还要继续查看下一层，直到确定最终出口。

延迟数字能说明什么

客户端的延迟测试通常是通过节点请求指定测试 URL，而不是简单的 ICMP Ping。结果受测试地址、超时设置、DNS 与当时线路状态影响。它适合筛选当前可连接的节点，不直接代表下载带宽，也不能保证所有网站都能访问。

• 先测试 2—3 个节点，尽量使用同一个测试地址和超时条件。
• 连续测试 3 次，观察是否稳定，避免只凭一次最低值选线。
• 优先验证正常网页访问，再进行大文件测速，减少不必要的流量消耗。

例如，一条线路三次结果为 85、92、88 毫秒，另一条为 45 毫秒、超时、310 毫秒。前者虽然最低延迟更高，但波动较小，更适合作为首次连接的验证对象。这是结果判断示例，不是某个节点的实测报告。

超时与自动选择的处理

单个节点超时，可以换同组其他节点；全部超时，则检查本地网络、订阅有效期、系统时间及内核错误。测试地址本身不可达，也可能导致批量超时，因此还应使用实际目标网站复核。

选择了 url-test 自动测速组时，当前出口由测试结果决定；fallback 组通常按可用性与配置顺序选择；load-balance 组可能让不同连接走不同节点。为了让首次检查更容易复现，可以暂时在手动选择组中固定一个节点，检查结束后再恢复自动策略。

3. 使用规则模式，开启系统代理

桌面客户端首次验证建议使用规则模式。它按配置中的 rules 自上而下匹配，请求可能被送到代理组，也可能命中 DIRECT 或 REJECT。系统代理则负责把愿意遵循系统代理设置的应用请求送进本地监听端口。两者作用不同，需要分别确认。

“全局模式”并不等于接管系统全部流量。没有进入内核的连接，不会因为切换全局模式就自动被代理。浏览器代理扩展、应用独立代理设置与系统代理之间也可能存在覆盖关系，排查时应先关闭额外的代理扩展。

核对本地地址与监听端口

在客户端设置里查找 HTTP 端口或混合端口。常见示例是 127.0.0.1:7890，但实际值必须以当前配置为准。mixed-port 可以接收 HTTP 与 SOCKS 代理请求；external-controller 是控制接口，不能当作浏览器代理端口。

• Windows 11：「设置」→「网络和 Internet」→「代理」→「手动设置代理」，核对客户端写入的地址与端口。首次操作优先使用客户端提供的系统代理开关。
• macOS：「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」，检查当前生效的代理项目。系统版本不同，入口名称可能略有变化。

本机使用不需要为了“连接成功”而开启允许局域网访问，也不需要开放控制接口。监听端口冲突时，应先关闭占用它的其他代理程序，再重新启动当前客户端。

4. 用连接日志确认规则与实际节点

开启系统代理后，打开客户端「连接」或「Connections」页面，再用浏览器新开一个标签页，访问准备验证的网站。重点找刚刚产生的请求，而不是观察总流量数字是否变化。部分短连接很快结束，可配合日志页面查看。

1. 看目标：域名或目标地址是否与刚访问的网站相符。
2. 看命中规则：确认是域名规则、规则集、地区规则，还是末尾的 MATCH。
3. 看策略链：检查显示的是 DIRECT，还是预期代理组及其最终节点。
4. 看传输：请求是否产生发送与接收数据，是否连续出现连接失败或超时。

如果请求命中 DIRECT，说明它进入了内核，但被分流为直连。这不等于系统代理没生效。反过来，完全没有相关连接记录时，应检查应用是否遵循系统代理、页面是否来自缓存，以及客户端是否隐藏了部分连接。mihomo 配置还可能设置日志等级或隐藏相关记录，不能仅凭单一空白页面下结论。

若能看到目标请求，却走了意外节点，检查代理组是否嵌套、是否使用负载均衡，以及客户端是否恢复了上次选择。暂时固定一个节点，比同时修改规则、DNS 和 TUN 设置更容易定位原因。

5. 对照出口 IP，验证代理是否真正生效

连接日志解释“请求怎么走”，出口 IP 则帮助确认“外部服务看到了哪个地址”。两者一起检查更可靠。先在关闭系统代理和 TUN 的条件下记录直连出口，再开启系统代理、固定节点，并用同一个 IP 查询服务重新检测。测试时避免其他 VPN 同时运行，否则直连基线也可能已经经过其他隧道。

规则模式下，IP 查询服务本身可能被设为直连。若出口没有变化，先看该请求的命中规则。需要隔离规则影响时，可以短时切到全局模式，并把全局选择器设为目标节点，完成验证后恢复规则模式。

用命令行区分本地代理与系统接入

下面以混合端口 7890 为例。第一条显式绕过代理，第二条显式连接本地 HTTP 代理。执行前确认已关闭 TUN，且没有其他 VPN 接管路由；将端口改成客户端实际监听值。查询服务会接收到本次请求及其来源地址。

# macOS / Linux：直连请求
curl --noproxy "*" --max-time 15 https://api.ipify.org

# macOS / Linux：显式经过本地代理
curl --noproxy "" --proxy http://127.0.0.1:7890 --max-time 15 https://api.ipify.org

Windows PowerShell 中建议明确使用 curl.exe，避免部分环境把 curl 解释成其他命令。显式代理测试前可暂时清除当前终端的 NO_PROXY 环境变量，再执行：

Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue
curl.exe --proxy http://127.0.0.1:7890 --max-time 15 https://api.ipify.org

显式代理命令成功，说明本地端口与对应请求链路可用，但不能单独证明系统代理已配置正确。还要回到浏览器，用日志确认浏览器请求确实进入了内核。

出口地区数据库可能更新滞后，节点名称也不保证与实际出口城市相同。IPv4 与 IPv6 的结果还可能不同。不要只看国旗图标；应记录查询时间、地址类型、命中策略与出口地址。即使 IP 相同，也要结合规则和策略链判断，避免把共享出口或不同地址族造成的现象误认为连接故障。

6. 浏览器可用、其他应用不通时再检查 TUN

系统代理不是透明接管。部分游戏、命令行工具与自带网络栈的应用不会读取它；UDP 流量也不能指望仅靠普通 HTTP 系统代理接入。此时可先查看应用是否支持独立 HTTP 或 SOCKS 代理，再决定是否使用客户端的 TUN 模式。

TUN 通过虚拟网络接口及路由设置，把符合条件的流量送入内核。桌面端可能需要管理员权限、服务模式或网络扩展授权；Android 客户端则通常使用系统 VPN 接口。具体权限和入口由客户端、操作系统决定，不应直接照搬另一平台的菜单。

• 先确认系统代理路径已验证成功，再单独测试 TUN，避免同时处理节点不可用与路由问题。
• 检查是否与其他 VPN、虚拟机网络、企业网络策略冲突。
• 开启后重新检查目标应用的连接记录，不把“TUN 已启动”当作代理成功结论。
• 如果出现局域网设备不可达，检查路由排除与直连规则，而不是直接关闭防火墙。

能访问 IP、不能解析域名时，应进一步检查 DNS 配置及内核解析日志。系统代理下的解析行为、TUN 下的 DNS 劫持与 fake-ip 映射并非同一件事。首次检查不建议随意复制整套 DNS 配置；先保留可工作的原配置，查清哪个域名、哪个解析请求失败。

7. 常见失败现象与检查顺序

每次只改变一个变量：节点、模式、端口或接入方式。记录改动前后的现象，才容易找出有效修复。遇到证书错误，先检查系统时间与目标网站证书信息，不要通过跳过 TLS 验证来完成首次连接测试。

8. 首次连接完成后的复核清单

• 当前订阅已启用，内核没有持续报错。
• 明确默认代理组及最终节点，不只记住测速数字。
• 系统代理地址与实际监听端口一致。
• 目标请求出现在连接记录中，并命中预期策略。
• 出口 IP 与日志结论一致，已区分直连规则和代理规则。
• 恢复日常使用的规则模式，撤销临时测试改动。
• 退出客户端前关闭系统代理，或确认客户端能够正确恢复系统设置。

满足这些条件后，才算完成从订阅导入到实际访问的闭环。后续如果仅某个网站或应用异常，优先检查它自己的规则、解析和连接记录，不必从重新安装客户端开始。基础操作可继续查阅系统代理设置说明，具体排障入口见连接检查文档。