Mihomo节点速度慢怎么排查？一套可执行的分层排查步骤
简答：先关闭后台下载并固定同一设备、网络、测试目标和节点，分别记录直连、单节点延迟与持续下载结果。再根据“只有一个节点慢、同地区节点都慢、所有节点都慢”分流检查节点线路、DNS、规则、TUN和系统代理，最后用日志确认是否为解析失败、握手超时或本地接入问题。
定义：Mihomo节点速度慢，是指节点延迟、网页首开、持续下载、视频缓冲或连接稳定性中的一项或多项低于同条件基线，不能只用延迟数值判断。
先做三步速查：不要一上来就换节点
第一步：先定义“慢”是哪一种。网页首开慢通常涉及 DNS、规则匹配或首次握手；持续下载慢更接近线路吞吐、节点负载或出口拥塞；视频缓冲和游戏卡顿还要考虑丢包、UDP支持与持续波动。
第二步：建立可比较的基线。关闭系统更新、云同步、下载器和浏览器后台标签，只保留一个测试应用。固定同一设备、同一 Wi-Fi 或有线网络、同一目标地址、同一节点，并在相近时段重复记录。
第三步：按结果分流。只有一个节点慢，优先检查该节点或其线路；同地区多个节点都慢，重点看线路、高峰拥塞和协议差异；所有节点都慢，则先查本地网络、DNS、TUN、系统代理和多代理冲突。
| 现象 | 优先检查 | 不要直接下结论 |
|---|---|---|
| 延迟高但下载正常 | 测试地址、节点距离、路由路径 | 延迟高不等于带宽低 |
| 延迟低但下载慢 | 节点负载、出口带宽、线路拥塞 | url-test选中低延迟节点不代表吞吐最佳 |
| 网页首开慢 | DNS、规则命中、首次连接和缓存 | 不要只换节点 |
| 测速超时或波动 | 测试目标、丢包、健康检查超时 | 测速失败不一定代表所有业务都不可用 |
| 浏览器能用，其他应用不能用 | 系统代理、TUN、应用是否接入 | 不要同时修改多个配置项 |
建立测速记录：延迟、网页速度和下载吞吐分开看
先在 Mihomo 前端中手动选择一个节点，不要使用自动选择组作为唯一依据。使用同一个健康检查地址和相同超时时间进行对比。Mihomo 的策略组支持通过 url、interval、timeout 和 expected-status 设置健康检查；官方文档也说明，健康检查返回的是节点到测试地址的延迟，不是完整业务下载速度。可参考策略组配置说明与Mihomo API 中的延迟测试接口。
建议使用下面的最小记录表，每次只改变一个变量：
| 时间 | 网络 | 节点 | 延迟 | 网页首开 | 持续下载 | 备注 |
|---|---|---|---|---|---|---|
| 固定记录 | Wi-Fi/有线/移动网络 | 节点名称 | 毫秒 | 快/慢/失败 | 稳定/波动/低 | 是否高峰、是否TUN |
- 先测试直连或不经过 Mihomo 的同一目标，记录本地网络基线。
- 再固定一个节点测试至少两次，观察延迟是否稳定、网页是否能正常打开。
- 最后做持续下载或实际业务测试，不要只看一次测速结果。
- 如果更换测试地址后结论完全不同，优先怀疑测试目标或目标站点限制，而不是立即判断节点失效。
如果使用 url-test，要注意它按健康检查结果选择节点；tolerance 是节点切换容差，interval 控制测试间隔。低延迟节点可能只是到测试地址更近，持续带宽仍可能较差。排查时可暂时切换为手动选择，避免自动切换让两次测试使用了不同节点。相关字段以url-test 官方配置说明为准。
按三种结果定位：单节点、同地区节点、全部节点
只有一个节点慢
固定其他条件，换一个同地区或相近协议节点对比。如果只有单个节点出现高延迟、握手超时或持续下载低，优先记录节点名称、测试时间、错误日志和重复结果，再以节点或线路问题处理。不要因为一次失败就把所有节点都判定为不可用。
同地区多个节点都慢
如果同地区节点在相同时间段一起变慢，重点观察是否集中在晚间、高峰或特定网络运营商。继续对比不同地区、不同协议和不同线路类型，但每次只改一个条件。若不同地区节点都出现类似丢包或超时，则更应检查本地出口、路由、MTU、DNS和防火墙。
所有节点都慢
先关闭 TUN 或系统代理做一次对照，再恢复原设置验证。检查是否同时运行了多个代理客户端、浏览器代理和系统 VPN；确认应用流量确实进入 Mihomo，而不是一部分直连、一部分经过另一个代理。Windows、macOS 和 Android 的菜单名称会随前端版本变化，应以当前客户端界面为准。
如果启用了 TUN，重点核对自动路由、DNS 劫持、出口网卡和系统权限。Mihomo 官方文档说明，TUN 的 dns-mode、dns-hijack、auto-route 等选项会影响系统流量接入；Windows、macOS 和 Android 对 DNS 劫持也存在平台差异，详见TUN 配置说明。
DNS、fake-ip、IPv6与规则：网页慢时重点核对
网页首开慢、部分域名打不开、打开后反复转圈，优先检查 DNS，而不是先改节点。先确认 Mihomo DNS 是否启用，再确认当前模式是 fake-ip 还是 redir-host，并检查是否存在过宽或错误的 fake-ip-filter、nameserver-policy 和 IPv6 设置。官方 DNS 文档列出了这些字段及其作用，尤其是 proxy-server-nameserver 用于解析代理节点域名，不能简单等同于普通业务域名解析。可参考DNS 配置说明。
- 只改一个变量：先暂时关闭 IPv6 或将节点出口固定为 IPv4，观察同一域名是否恢复。
- 若使用 fake-ip，检查局域网域名、内网设备和特殊应用是否需要加入过滤列表。
- 检查规则是否把目标域名错误地分到 DIRECT、错误代理组或不存在的策略组。
- 刷新 DNS 缓存后重新测试，避免把旧解析结果当成当前结果。Mihomo API 提供 DNS 缓存清理接口，但具体调用方式取决于前端是否开放外部控制端口。
不要为了“看起来更快”同时更换 DNS、切换 fake-ip、修改规则和启用 TUN。一次只改一项，记录修改前后的网页首开、日志和节点结果，确认有效后再保留。
日志验证与失败分流：看懂错误关键词
| 日志关键词或现象 | 常见指向 | 下一步 |
|---|---|---|
| DNS resolve failed、no such host | 域名解析失败或 DNS 路径异常 | 检查 DNS、策略和代理节点域名解析 |
| connection refused | 目标端口拒绝连接或节点服务未接受连接 | 换同条件节点重复测试 |
| handshake timeout、i/o timeout | 连接建立或握手阶段超时 | 对比其他节点、IPv4/IPv6与网络时段 |
| rule 命中但应用无响应 | 规则选择与应用接入可能不一致 | 确认实际策略组、系统代理和 TUN 状态 |
| 节点延迟正常但业务慢 | 测试延迟与持续吞吐不等价 | 固定节点做实际下载或视频播放对照 |
排查顺序建议固定为：备份当前配置；关闭后台流量；记录直连基线；手动固定单节点；检查日志；只修改一个变量；重新载入配置；再次复测；确认问题消失后再恢复自动选择。Mihomo API 文档提供了当前配置、代理组、节点存活状态、延迟历史和配置重载等接口说明，可用来核对“前端显示”和“内核实际状态”是否一致。
如果修改后问题更严重，撤销最后一次改动，恢复备份配置，并先关闭 TUN 或系统代理做最小化对照。配置项和菜单可能随 Mihomo 内核及前端版本变化，无法确认的字段应以当前版本官方文档为准。
完成标准：什么时候可以认为排查有效
一次有效排查不等于测速数字变小，而是能够回答三个问题：第一，慢的是延迟、首开、持续吞吐还是稳定性；第二，问题只影响一个节点、某一组线路，还是所有节点；第三，修改哪个变量后，使用同一设备、同一网络、同一目标和同一节点复测，结果出现可重复变化。
如果只有一个节点慢，保留其他节点作为对照即可；如果所有节点都慢，优先恢复本地网络、DNS、TUN或系统代理的最小配置；如果自动选择频繁切换，先改为手动节点，待基线稳定后再恢复 url-test。不要用一次健康检查延迟替代真实业务结论。
常见问题
Mihomo延迟很低，为什么下载速度仍然慢？
健康检查通常只反映到测试地址的响应延迟，不能代表持续下载吞吐。请固定同一节点做实际下载或业务测试，并对比其他节点。
url-test自动选中的节点一定最快吗？
不一定。url-test根据健康检查结果和切换容差选择节点，低延迟只说明测试地址响应较快。排查速度时建议暂时改为手动选择。
Mihomo网页打开慢，应该先换DNS还是换节点？
先固定节点并检查日志。如果是解析失败、域名超时或首开慢，优先核对DNS、fake-ip、规则和IPv6；如果握手阶段超时，再对比其他节点。
只有浏览器能用，其他应用速度慢怎么办？
确认其他应用是否使用系统代理，或是否被TUN接管。检查是否同时运行多个代理客户端、VPN或应用内代理，并查看Mihomo连接记录是否出现目标应用流量。
怎么判断是本地网络还是节点线路问题？
先做直连基线，再在同一网络下固定多个节点测试。若直连和所有节点都慢，优先查本地网络；若只有一个节点慢，优先查该节点或线路；若同地区节点同时变慢，再观察时段和运营商差异。