Mihomo 节点速度慢怎么办？先分清节点、DNS 还是 TUN
简答：先关闭 TUN 和系统代理测直连，再用同一大文件、同一节点测代理；只有单节点慢就换节点，全部节点慢再查 DNS、规则、健康检查、TUN 和本地网络。
定义：Mihomo 节点速度慢，是指连接已建立但出现下载吞吐低、网页首屏慢、延迟高、丢包或断流，不能只用延迟数字判断。
先试这一步：建立直连与代理基线
节点显示延迟不高，但下载只有几百 KB/s 时，先不要改 DNS 或重装客户端。暂停下载、云同步、系统更新和其他 VPN，固定同一设备、同一网络、同一测试文件，连续测试 3 次。
本文是第三方使用指南，与 Mihomo 项目及其开发者无隶属关系。Mihomo 的连接记录、匹配规则和代理链可通过 API 查看，官方字段说明见 Mihomo API 文档。
| 优先检查位置 | 典型信号 | 先做什么 |
|---|---|---|
| ① 节点本身 | 只有一个节点慢，其他节点正常 | 固定测试目标，对照相邻地区或相近延迟节点 |
| ② 代理组与健康检查 | 自动选择结果与实际访问不一致，延迟长期不变 | 改为 select 手动固定一个节点，再测真实下载 |
| ③ DNS 与 IPv6 | 网页首屏慢，打开后下载速度正常 | 对照 IPv6、DNS 和 fake-ip，不要同时修改多个变量 |
| ④ 规则 | 只有特定网站慢，连接记录显示 DIRECT | 在 Connections 中查看实际命中规则和出口链 |
| ⑤ TUN 与本地网络 | 关闭 TUN 后恢复，或换网络后全部节点变快 | 检查虚拟网卡、路由、防火墙、Wi-Fi 和 MTU |
四个指标怎么读：延迟主要看往返响应；首包看 DNS、建连和服务端开始响应的等待；吞吐看持续下载速度；丢包看连接是否反复重传或断开。延迟低不代表吞吐高，健康检查快也不等于真实网站下载快。
| 指标 | curl 字段或工具 | 偏高或异常时优先怀疑 |
|---|---|---|
| 连接延迟 | time_connect、Test-NetConnection | 本地到目标或代理入口的建连路径 |
| 首包等待 | time_starttransfer | DNS、规则分流、TLS、节点出口或目标站响应 |
| 下载吞吐 | speed_download | 节点带宽、共享拥塞、线路质量或限速 |
| 波动与丢包 | 重复测试、日志和连接是否反复断开 | Wi-Fi、MTU、路由、防火墙或线路抖动 |
Windows 的 Test-NetConnection 可做 ICMP、TCP、路由和连接诊断，但它不使用 HTTP 代理。直连测试前先关闭 TUN 和系统代理；TUN 开启时，所谓“直连”可能仍被虚拟网卡接管。
正确测直连和代理：不要让命令测错路径
测试文件请替换为你能稳定访问的较大文件，例如企业自有测试文件或公开的 50 MB 以上文件。不要用只有几 KB 的页面判断吞吐量，也不要把测速地址的结果当成所有网站的代表速度。
Windows 直连测试：先关闭 Mihomo 的 TUN 和系统代理，再在 PowerShell 或命令提示符运行。--noproxy "*"用于避免环境变量代理干扰。
curl.exe -L --noproxy "*" -o NUL -sS -w "dns=%{time_namelookup} connect=%{time_connect} first=%{time_starttransfer} total=%{time_total} speed=%{speed_download}\n" "https://替换为你的测试文件地址"
Windows 代理测试：保持 Mihomo 已运行，确认客户端的 HTTP 或混合端口，再把下面的 7890 替换为实际端口。curl 的 -x 参数用于指定代理，speed_download表示完整下载的平均速度，字段定义见 curl 官方命令文档。
curl.exe -L -x http://127.0.0.1:7890 -o NUL -sS -w "dns=%{time_namelookup} connect=%{time_connect} first=%{time_starttransfer} total=%{time_total} speed=%{speed_download}\n" "https://替换为你的测试文件地址"
macOS 或 Linux：将 Windows 命令中的 curl.exe改为 curl，将输出文件从 NUL改为 /dev/null。如果 PowerShell 中直接输入 curl实际调用的是别名，请使用 curl.exe。
判定方法：直连正常、代理明显变慢，优先检查节点、代理组和规则；直连与代理都慢，先查本地网络；只有 first明显变大，优先查 DNS、IPv6、规则和 TLS 建连；只有 speed明显低，优先对照节点出口、线路拥塞和服务端限速。每种模式至少测 3 次，记录中位表现，不把单次峰值当结论。
单节点慢还是全部节点慢：固定节点做对照
在 Mihomo 面板中先记下代理组、实际选中的节点、测试时间和模式。将自动选择暂时改为 select，依次测试当前节点、相近地区节点和协议不同但延迟接近的节点。每次只改变节点，不同时改 DNS、规则和 TUN。
- 只有一个节点慢：同一测试文件下，若其他节点明显更快，先保留测试记录并换节点。仅凭本地配置无法证明该节点一定存在服务端故障。
- 同一订阅全部节点慢：先检查订阅是否成功更新、节点配置是否完整，再关闭 TUN 对照系统代理。
- 所有订阅都慢：更换有线网络或手机热点测试；如果换网络后恢复，优先查 Wi-Fi、路由器、运营商链路或本地防火墙。
- 只有某个网站慢：在 Connections 页面查看该请求的
rule、rulePayload、chains和出口；如果显示 DIRECT，说明规则没有让它走代理。
要查看实际命中规则，可在客户端的 Connections 或连接页发起一次新请求；也可以把 Mihomo 的 log-level临时设为 info，官方配置文档说明该级别会输出一般运行日志，API 还支持按 info、warning、error和 debug读取实时日志，见 Mihomo 通用配置文档与Mihomo API 文档。
url-test、proxy-provider 和 lazy：延迟不更新不等于节点失效
url-test会按照配置的测试地址和间隔比较代理响应。Mihomo 官方示例包含 url、interval、tolerance和可选的 lazy字段，具体见 Url-Test 配置文档。
健康检查地址可能被屏蔽、返回状态异常，或者在你的网络环境下走了 DIRECT，因此测速结果可能与真实访问不同。先确认该测试地址在当前网络可访问，再对实际下载文件做第二次验证；不要只因 generate_204等地址失败就认定全部节点失效。
如果节点来自 proxy-providers，还要检查提供者自己的 health-check.enable、health-check.url、health-check.interval、health-check.timeout和 health-check.lazy。官方文档明确列出这些字段，并说明提供者节点未被使用时，health-check.lazy为默认状态可能不执行检查，见 Mihomo proxy-providers 配置文档。
排查时先用 select手动固定节点，再用实际下载测试；确认真实速度后再恢复 url-test。不要为了让延迟数字频繁刷新而盲目缩短间隔，因为这只增加检查请求，不能提高节点带宽。
DNS、IPv6 和规则：网页首屏慢时先查这里
如果页面迟迟不开始加载，但一旦打开后下载速度尚可，优先检查解析和分流。Mihomo DNS 文档列出了 ipv6、enhanced-mode、fake-ip、fake-ip-filter、nameserver-policy和 proxy-server-nameserver等字段，见 Mihomo DNS 配置文档。
- 保持节点和测试文件不变，只暂时关闭 IPv6 做一次对照；如果首包改善，再检查本地 IPv6 和 AAAA 解析。
- 在规则模式与全局模式之间切换一次。规则模式慢、全局模式正常时，查看 Connections 中的命中规则和实际出口。
- 如果使用
fake-ip，检查局域网域名、路由器地址和需要真实地址的应用是否在fake-ip-filter中；不要直接清空过滤列表。 - 不要一次替换多个 DNS、同时切换 fake-ip、关闭 IPv6 和启用 TUN，否则无法知道是哪一项造成变化。
测速地址本身也可能被规则送往 DIRECT，或者被网络拦截。使用 Connections 检查测试文件域名实际走的是哪个代理链，再决定是修规则还是换测试目标。
TUN、系统代理和不同平台的入口
Mihomo TUN 配置包含 auto-route、dns-mode、dns-hijack、strict-route和 mtu等字段。官方文档明确区分了 dns-mode的 disabled、native和 hijack，同时说明 mtu只在极端条件下影响传输速率，一般用户可保留默认值，见 Mihomo TUN 配置文档。
| 平台 | 先测什么 | 常见入口与判定 |
|---|---|---|
| Windows | 系统代理与 TUN 分开 | Clash Verge Rev 等桌面客户端中分别查看 System Proxy、TUN、Connections、Logs；界面以实际版本为准 |
| macOS | 系统代理与 TUN 分开 | 在客户端设置中分别切换代理入口，再查看连接记录；不要同时启用其他 VPN |
| Android | VPN 开关和应用分流 | Clash Meta for Android 等客户端中查看 VPN 状态、应用是否被排除和日志；以实际版本为准 |
如果关闭 TUN、仅保留系统代理后速度恢复，优先检查虚拟网卡、自动路由、DNS 劫持、严格路由和防火墙；如果系统代理无效但 TUN 正常，说明应用可能不遵循系统代理。Mihomo 文档还说明 Windows 的 strict-route可能影响特定虚拟化软件。
MTU 不要盲改。只有在特定网站打不开、长连接反复断开或大文件传输异常已经稳定复现时，才一次调整一个值，并保留原配置以便恢复。
最小化配置：只保留一个节点和一个 select 组
当你无法判断是订阅、规则还是客户端设置导致速度慢时，先复制原配置文件，不要覆盖正在使用的订阅文件。下面只是排查骨架，节点字段必须从你的原订阅复制；不同 Mihomo 核心版本和客户端生成配置可能存在字段差异，最终以 Mihomo proxy-groups 文档为准。
mixed-port: 7890
mode: rule
log-level: info
proxies:
- name: "排查节点"
type: "从原订阅复制"
server: "从原订阅复制"
port: 443
uuid: "从原订阅复制"
cipher: "从原订阅复制"
proxy-groups:
- name: "排查组"
type: select
proxies:
- "排查节点"
rules:
- MATCH,排查组
上面的 type、server、uuid、cipher只是占位说明，不能直接作为可用节点配置。不要把真实订阅链接、密码或密钥公开发布。
最小化测试顺序是：先关闭 TUN、使用系统代理；再固定一个节点；随后用同一大文件测试；最后才分别启用 TUN、切换 DNS 或恢复自动选择。每次记录模式、节点、测试时间、connect、first、total和 speed。测试完成后关闭临时配置，恢复备份。
排除配置后，再检查订阅状态和服务端因素
如果同一设备、多个网络、多个订阅和多个节点都慢，且直连基线正常，才进入非本地配置因素排查。先打开订阅信息页，检查剩余流量、到期时间、更新时间和节点列表是否正常；页面没有展示的项目写“未核实”，不要根据速度猜测订阅已过期或被限速。
若只有高峰时段变慢，记录具体日期、时间段、节点名称、测试文件、直连结果和代理结果。若只有某个节点或地区慢，整理对照数据后再反馈；不要把一次测速结果写成服务商固定速度，也不要仅凭延迟判断线路质量。
常见问题
Mihomo 延迟只有几十毫秒，为什么下载还是很慢？
延迟主要反映往返响应，不能代表持续下载吞吐量。请用同一较大文件比较直连和代理的 speed_download、first 和 total；如果延迟接近但吞吐差异明显，应继续对照节点出口、线路拥塞和共享带宽。
curl 测试怎样保证测到的是代理，而不是直连？
代理测试必须显式加入 -x 或 --proxy，例如 -x http://127.0.0.1:7890，并把端口替换为客户端实际混合端口。直连测试先关闭 TUN 和系统代理，再使用 --noproxy "*"；Test-NetConnection 只适合直连 TCP、ICMP 或路由诊断。
url-test 自动选中的节点一定是下载最快的吗？
不一定。url-test 使用配置中的测试地址、间隔、超时和容差，得到的是该测试地址的响应表现。建议先让它筛选候选节点，再用真实下载文件和实际网站做手动对照。
延迟数字长时间不更新，是不是节点失效？
不一定。代理组或 proxy-provider 可能启用了 lazy，未使用的节点不会持续健康检查。先手动固定节点并发起真实请求，再检查 health-check 的 lazy、interval、timeout 和测试地址是否可访问。
关闭 TUN 后速度变快，应该马上修改 MTU 吗？
不建议。先检查虚拟网卡、自动路由、DNS 劫持、strict-route、防火墙和其他 VPN 冲突。只有特定连接异常能够稳定复现时，才一次调整一个 MTU 值并保留原配置。
什么时候应该联系服务商，而不是继续改配置？
完成直连与代理对照后，如果多个节点、多个网络和多个设备仍出现相同问题，再整理时间段、节点、测试目标、剩余流量、到期时间和对照结果反馈。未显示在订阅页面中的限速或流量状态均应写为未核实。