第一次连上 Clash 之后：挑节点、做延迟测试、确认流量走了代理

先给结论：节点有数字，不等于应用已走代理

首次验证建议按这个顺序做：确认配置已启用，选一个可用节点，打开系统代理，再用新请求检查连接记录。最后才看出口 IP。不要同时开启 TUN、切换 DNS、修改规则和更换节点，否则页面恢复后也难以判断是哪一步起了作用。

Clash 是一类客户端与内核生态的常见称呼。使用 mihomo 内核的客户端，界面按钮和功能细节可能不同，但都要区分三个环节：订阅提供节点与规则，策略组决定选谁，流量入口决定应用请求能否进入内核。订阅导入成功，只证明配置被接收，并不证明这三个环节都已接通。

1. 确认配置处于启用状态。不要只看订阅列表里出现了名称；还要确认当前运行配置就是刚导入的那份。
2. 把运行模式设为规则模式。首次检查时保留原有规则，避免把所有访问都强行交给代理。
3. 在实际使用的策略组中选择节点。规则可能指向“国外网站”“流媒体”等不同组，不能只改一个未被引用的组。
4. 打开系统代理后发起新请求。保留连接面板，观察请求进入内核后的去向。

延迟测试测了什么：先统一地址，再比较节点

节点列表里的毫秒数，通常来自内核经该节点请求指定 URL 的耗时，不应直接理解为 ICMP ping，也不是下载速度。它可能包含连接建立、代理协议握手、TLS 协商及等待 HTTP 响应的时间；具体计时边界取决于内核和测试实现。

同一组比较，需要相同测试条件

先查看客户端的延迟测试设置，或配置里的 url-test 策略组。常见测试目标是返回 HTTP 204 的地址，例如 https://www.gstatic.com/generate_204。不同目标的网络位置与可达性不同，用甲地址测出的 80 毫秒，不能直接和乙地址测出的 120 毫秒排名。

• 固定测试地址：比较时用相同 URL，不在中途改成另一个站点。
• 分三轮测试：例如每轮间隔 10 秒，记录连续结果；这是手动观察方法，不是要求修改内核定时参数。
• 暂缓大流量任务：下载、网盘同步和系统更新会占用本地带宽，影响结果。
• 记录网络条件：同一节点在家庭 Wi-Fi、手机热点和办公网络下可能表现完全不同。

表中是解释读数的假设示例，不是本站对某个服务的实测排名。三次结果只能帮助筛选，不能据此计算长期丢包率或承诺高峰期体验。

超时不一定是节点完全不可用

测试目标被阻断、解析失败、节点认证失效、本地网络中断，都可能显示超时。若所有节点一起超时，先查网络和测试 URL；若只有一个节点持续失败，再换节点对照。若测试成功而目标网站打不开，应测试那个网站本身，不能把一个 204 响应当成所有网站均可访问的证明。

按用途挑节点：延迟、稳定性和出口区域分开看

先选择连续测试都能响应的节点，再按实际用途筛选。节点名称里的地区、倍率或“专线”等文字属于提供方的标注，不能代替出口验证，也不能直接证明线路质量。客户端显示的低延迟，尤其不能保证特定网站的区域授权或账号可用。

• 网页浏览与在线文档：重点看首次打开是否顺畅、连续操作是否报错。稳定的中等延迟通常比偶尔很快、频繁超时更好用。
• 视频播放与文件传输：看实际缓冲和持续吞吐。短请求测试无法测出长时间传输能力；做下载测试前先确认流量额度与计费方式。
• 会议与实时通信：还要看抖动、丢包、UDP 支持及应用是否进入代理。HTTP 测试成功，不能单独证明语音通道可用。
• 需要固定区域的服务：同时检查出口区域、网站规则和服务自己的使用条件。IP 数据库显示的国家与网站判断可能不同。

首次排查，先手动固定一个节点

url-test 会按测试结果自动选路，fallback 组通常按配置顺序选择可用项；手动选择组则由用户指定。自动策略的切换会让前后两次请求落到不同出口。为了获得可复现的结果，可以在配置允许的情况下，临时将相关选择组固定到同一个节点，验证结束后再恢复自动策略。

还要检查策略组是否嵌套。例如“国外网站”选中了“自动选择”，而“自动选择”才指向具体节点。界面上看到的外层组名并不是最终出口，后面需要在连接详情里沿策略链确认。

第一种验证：在连接面板找目标域名和策略链

连接面板是最直接的证据。打开客户端中名为“连接”或“Connections”的页面，保留窗口，再用浏览器访问目标站点。菜单名称随客户端而变，重点是找到显示目标地址、流量与规则的活动连接列表，而不是节点延迟列表。

1. 暂停其他下载任务，在连接列表中搜索目标域名。
2. 打开一个新页面或无痕窗口，发起真正的网络请求；只看已缓存的页面可能不会产生新连接。
3. 点开新出现的记录，查看目标域名或 IP、命中规则、策略链和上传下载字节数。
4. 确认策略链最终落到预期节点，而不是 DIRECT 或 REJECT。

如果命中了 DIRECT，说明请求进入了内核，但规则让它直连。这与“浏览器绕过 Clash”是两种问题。前者要查规则顺序及策略组指向；后者要查系统代理、浏览器扩展、应用自己的代理设置或 TUN 路由。

一个网页也不等于一条连接。主文档、图片、登录接口和视频可能使用不同域名，因而命中不同规则。只找到主站域名并不足以解释某个视频无法播放，应继续查看失败资源对应的请求。

第二种验证：用日志区分入口、规则和上游错误

连接面板看去向，日志看过程。先使用 info 级别重现一次问题；信息不足时，再短暂提高到 debug。完成后恢复常用级别，避免大量记录淹没有效线索。

不同内核版本的日志格式并不一致，不必寻找完全相同的一句英文。更可靠的方法是记下操作时间、目标域名和所选节点，只重现一次，再筛选同一时间段的记录。分享截图前，遮住订阅地址、认证信息、节点服务器地址及不相关的访问域名。

如果日志与连接列表都没有对应请求，先确认正在查看的确实是当前运行的内核，再检查应用入口。不要在流量尚未进入内核时反复改订阅规则，这通常解决不了问题。

第三种验证：用出口 IP 对照，但别只看查询页

IP 查询页能说明“访问这个查询服务时使用的出口”。它不能证明所有应用都经过同一节点，也不能证明所有协议都已被接管。规则模式下，查询网站可能直连，而目标网站走代理；因此必须把 IP 结果和该查询请求的连接记录一起看。

用显式代理命令隔离浏览器设置

下面以 Windows 的 curl.exe 为例，将请求明确交给本机 7890 端口。macOS 和 Linux 通常使用 curl，参数相同。该端口需要提供 HTTP 代理或混合代理服务，不能把仅支持 SOCKS 的端口直接照填进去。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org

第一条显式走 HTTP 代理，第二条要求 curl 不使用应用层代理。两条命令的连接建立超时为 10 秒，总超时为 20 秒。查询服务由第三方运营，会看到本次访问的出口 IP；输出结果无需公开发布。

• 显式代理成功、浏览器失败：说明该命令所用链路可用，继续查浏览器入口、扩展和相关域名规则。
• 提示连接被拒绝：先查客户端是否运行、端口是否正确；请求可能还没到节点选择这一步。
• 两个出口不同：说明这两次请求用了不同出口，仍需从连接面板确认代理请求的实际策略。
• 两个出口相同：不立即判定失败。查询域名可能被规则直连，也可能存在 TUN、其他 VPN 或相同公网出口。

只有在规则确实把查询域名交给代理时，显式连接到本地端口才会继续经过代理节点。访问本地代理端口与最终使用远端出口，是两个不同层次的判断。

浏览器正常、其他应用不通：再检查 TUN 与独立代理设置

系统代理不是对所有程序的强制接管。有些终端工具使用环境变量，有些应用提供自己的 HTTP 或 SOCKS 设置，还有些应用不读取系统代理。出现浏览器正常、其他应用没有连接记录时，应先检查该应用的代理能力，再决定是否启用 TUN。

TUN 是扩大接管范围，不是延迟优化开关

TUN 通过虚拟网络接口和路由让更多流量进入内核，但是否生效还取决于管理员权限、服务状态、路由配置和 DNS 接管。它不保证节点变快，也不代表规则模式自动变成全局代理。流量进入 TUN 后，仍可能按规则直连。

1. 先保存原设置，只开启 TUN，不同时改 DNS 模式或订阅内容。
2. 检查客户端是否报告虚拟接口创建成功，权限或服务是否满足要求。
3. 重新启动目标应用或断开其旧连接，发起新请求，再观察连接面板。
4. 若与公司 VPN、其他隧道工具冲突，恢复原设置后分别测试；不要盲目删除系统路由。

UDP 应用还需要节点协议、服务端和本地配置共同支持 UDP 转发。即使 TUN 中出现了应用连接，也不能只凭 HTTP 延迟数字判断游戏或会议体验。优先使用应用自身的网络统计观察丢包与抖动，并与不开代理时的结果对照。

配置入口和基础术语可以继续查阅入门指南与使用手册中的代理模式说明。已经能稳定工作的链路，不必为了追求更低的测试数字而一次更换多个设置。

首次连接的验收清单

完成下面五项，比截图里出现一个很小的毫秒数更有意义。建议记下网络环境、目标域名、节点名称、实际出口与检查时间；下次异常时可以按同样条件重测。

• 配置：当前运行的是预期订阅，节点与规则已加载。
• 节点：在同一测试地址下多次响应，实际目标站点也能正常使用。
• 入口：浏览器或目标应用的新请求确实出现在连接面板。
• 路径：命中预期规则，策略链最终落到选定节点，而非意外直连。
• 出口：IP 查询结果与该请求的策略记录相互印证，其他应用另行验证。

如果某一步未通过，就在该层继续排查：没有连接先看入口，已有连接但直连先看规则，选中了节点却失败再查上游。保持一次只改变一个变量，通常比来回切换所有开关更容易找到原因。