Mihomo节点延迟高怎么排查？按网络、DNS与配置定位

更新于 2026-11-10 · v2xo.shop

简答：Mihomo节点延迟高，先关闭代理测试本机网络，再用同一节点比较延迟、丢包和真实访问。单节点高通常优先检查节点或线路；全部节点高，则先查Wi-Fi、运营商出口、DNS、TUN和当前生效配置。最后再核对url-test、proxy-provider健康检查和测速地址。

定义：Mihomo节点延迟是客户端从本机发起测试到节点或测试目标完成连接所需的时间，通常只能反映特定测试路径，不能单独代表下载速度或所有网站的访问体验。

先做这一步：建立不经过代理的网络基线

如果节点延迟突然升高，先不要立即修改DNS、MTU或TUN参数。关闭系统代理、退出TUN或暂时切换到直连后，访问一个平时能打开的网站，并连续执行几次基础测试。这样可以先判断问题是否在本机网络、无线连接或运营商出口。

Windows：打开命令提示符，执行ping 目标域名，再执行tracert 目标域名。
macOS/Linux：终端执行ping -c 10 目标域名，再执行traceroute 目标域名；部分系统也可使用tracepath 目标域名。
记录连续多次测试中的平均延迟、超时次数和是否出现明显抖动，不要只看一次结果。

判断标准：直连状态也出现超时或明显波动，优先处理Wi-Fi、网线、路由器、IPv6或本地网络；直连正常而Mihomo测试异常，再进入客户端配置和节点排查。

这里的ping和Mihomo健康检查不是同一种测试。Mihomo代理组的url是健康检查地址，interval控制周期，timeout控制超时时间；测试结果会受到测试地址、DNS、代理协议和路径影响。具体字段可参考Mihomo代理组配置文档。

按现象定位：单个节点高，还是全部节点高

现象	优先检查	判断与处理	回滚方式
只有一个节点延迟高	节点服务器、协议、端口、线路	用同一测试地址重复测试；若其他节点正常，优先暂时避开该节点，不要先改全局DNS。	恢复原节点或切回手动选择。
同地区多个节点都高	本机出口、Wi-Fi、运营商路径、晚间拥堵	换网络或使用手机热点复测；如果不同网络结果差异明显，问题更可能在本地出口或线路。	切回原网络并保留对比记录。
全部节点都超时	订阅是否生效、系统代理、DNS、TUN、时间和防火墙	先确认当前选择的代理组和节点确实已应用，再看日志中的解析、拒绝和握手超时信息。	关闭TUN，恢复原代理模式和DNS配置。
显示延迟高但网站能打开	测速地址、健康检查参数、缓存结果	用真实业务访问和多个测试地址复核，不要把一次健康检查数值当成全部体验。	恢复原来的url、interval和lazy设置。

如果策略组启用了lazy: true，未被选中的代理组可能不会定期测速；如果节点来自proxy-providers，还要检查代理集合自己的健康检查配置。官方文档明确区分了代理组的检查范围与代理集合的健康检查字段，不能只修改其中一处。参考代理组配置和代理集合配置。

检查Mihomo真正生效的模式、日志和节点选择

不同客户端的菜单名称可能不同，因此不要只凭面板上的“已开启”判断配置是否生效。优先查看当前运行配置、代理组实际选择和实时日志。如果客户端提供外部控制页面，可以检查当前的mode、log-level、ipv6和tun字段；Mihomo API文档说明，/configs可以返回当前运行配置，/logs可以获取实时日志。

确认模式是否为rule、global或direct中的预期状态。规则模式下，不同域名可能命中不同策略组。
确认当前业务使用的代理组不是“自动选择”中的旧节点，并检查实际选中的节点名称。
将日志级别临时提高到debug或至少保留info，重现一次连接，再恢复到原级别。
重点查看DNS解析失败、连接拒绝、认证失败、TCP或TLS握手超时等关键词。日志中包含订阅地址、节点域名或认证信息时，分享前应打码。

日志级别和运行模式的可选值以Mihomo通用配置文档为准；不要把某个客户端的面板名称当作所有客户端的固定入口。

DNS、IPv6与TUN：延迟高时怎样逐项验证

DNS问题不一定表现为“完全打不开”，也可能表现为首次连接慢、部分域名超时、节点域名无法解析或规则命中异常。Mihomo将普通域名解析、代理节点域名解析和直连域名解析分成不同配置范围，包含nameserver、proxy-server-nameserver、direct-nameserver以及fake-ip等字段。具体含义应以Mihomo DNS配置文档为准。

先清缓存再复测：如果客户端面板提供清理DNS或Fake-IP缓存的功能，清理后只复测一个节点和一个目标网站。
检查节点域名解析：节点服务器是域名时，重点确认proxy-server-nameserver是否能解析该域名；不要只测试普通网站域名。
暂时对比IPv4和IPv6：如果开启IPv6后全部节点同时变慢或超时，可临时关闭IPv6进行对比；若问题消失，再检查本地IPv6路由和节点协议兼容性。
单独验证TUN：先关闭TUN，只保留系统代理测试；若延迟恢复，再检查TUN的自动路由、DNS劫持、防火墙和协议栈设置。

TUN配置包含自动路由、DNS劫持、协议栈和MTU等参数。官方文档同时提示，某些协议栈在防火墙开启时可能需要放行核心程序，因此不要一次同时修改MTU、DNS和协议栈；每次只改一项并记录回滚值。参考Mihomo TUN配置文档。

如果问题仅在TUN开启时出现，推荐顺序是：关闭TUN复测 → 恢复TUN但关闭DNS劫持复测 → 检查防火墙放行 → 最后才尝试调整MTU。没有统一适用于所有网络的MTU数值，未确认前不要直接套用他人的配置。

url-test、lazy和测速地址：为什么延迟显示不更新

Mihomo的自动选择并不是持续测量所有节点。代理组的interval决定周期性测试是否启用，lazy默认为懒惰状态，未选中的代理组可能不执行测试；timeout则决定一次健康检查等待多久。代理集合还拥有独立的health-check.enable、health-check.interval、health-check.timeout和health-check.lazy字段。

因此，遇到“延迟一直不更新”时按下面顺序核对：

当前查看的是否是已经选中的代理组。
测试节点是否写在代理组的proxies中，还是通过use引入代理集合。
代理组和代理集合是否各自配置了健康检查。
健康检查地址是否能在当前网络打开，返回状态是否符合expected-status。
手动测速后，是否用真实网站或业务连接复测，而不是只看面板数字。

建议选用稳定、返回内容简单的测试地址，并在同一网络、同一客户端、同一时间段连续测试。测试地址只适合做对比，不代表所有网站的实际延迟，更不能直接推出下载速度。

复测与回滚清单：确认问题是否真的解决

完成调整后，按照同一顺序复测，避免“改了很多项但不知道哪项有效”。

恢复或记录直连基线：连续测试本机网络，确认没有同时发生Wi-Fi或运营商波动。
固定一个节点和一个测试地址，连续测试多次，再换第二个节点进行对照。
分别比较系统代理、TUN和直连三种状态；每次只切换一个变量。
记录延迟、丢包、首次打开时间和实际业务是否卡顿，不只记录面板上的单次数字。
如果修改DNS、IPv6、MTU或TUN后没有改善，恢复原配置并清理对应缓存。

最终判断可以采用“同网络多次结果 + 同节点跨时段结果 + 不同节点对比 + 真实访问表现”的组合，而不是设定一个没有来源的固定延迟阈值。若只有某个节点或某个时段异常，保留证据后更换节点或线路；若所有节点和直连都异常，继续处理本机网络或出口问题。

本文为第三方使用指南，Mihomo及各客户端的版本、菜单和配置入口可能不同；涉及版本功能时，应以对应项目的当前文档和客户端页面为准。

常见问题

Mihomo节点延迟高，是不是节点已经失效？

不一定。先判断是单个节点高还是全部节点高，再用同一测试地址和真实网站复测。单个节点异常更像节点或线路问题；全部节点异常则应先查本机网络、DNS、TUN和当前生效配置。

为什么Mihomo显示延迟很高，但实际打开网页并不慢？

面板延迟通常来自代理组健康检查，并不等于所有网站的完整访问时间。测试地址、DNS、规则、TLS握手和目标网站路径都可能不同，应结合首次打开时间、连续测试和实际业务表现判断。

Mihomo的lazy会不会导致节点延迟不更新？

可能会。代理组的lazy默认可能让未被选中的策略组不执行测试；通过proxy-provider引入的节点还要检查代理集合自己的health-check配置。应同时核对当前选择的代理组、proxies/use来源和健康检查字段。

节点全部超时，应该先改DNS还是先重装客户端？

先不要重装。先关闭TUN和系统代理建立直连基线，再确认订阅和当前配置是否生效，查看日志中的DNS失败、连接拒绝或握手超时，最后再逐项对比DNS配置。这样更容易保留证据并回滚。

调整MTU能解决Mihomo节点延迟高吗？

不能默认认为可以。MTU只应在确认问题与分片、特定网络路径或TUN相关后逐项验证；没有适用于所有网络的统一数值。修改前记录原值，测试无效就恢复。