连接排障 · Clash 技术博客

Mihomo 大配置加载慢：dialer-proxy 修复

Mihomo 启动或重载大配置时卡住、内存猛涨？先确认大量内联 proxies 是否使用 dialer-proxy，保留完整配置副本，核对 v1.19.33 修复，再验证加载、真实请求和回退。

阅读正文返回博客
  • Mihomo
  • v1.19.33
  • dialer-proxy
  • 配置校验
  • 内存占用
本文目录
文章作者
Clash 官网
发布日期
预计阅读
约 8 分钟

启动内核或重新载入配置时，CPU 和内存突然升高，界面迟迟没有就绪；平时代理却未必一直占用很多内存。这个时间点比“订阅很大”更有用：先看问题是否发生在配置校验，而不是立即删除节点或改 DNS。

先分清配置加载慢和运行中的内存上涨

本文限定 Mihomo 配置中大量内联 proxies 设置了 dialer-proxy 的场景。官方 #3315 根据真实用户的大量节点配置定位到校验成本，v1.19.33 已包含对应修复；这不是所有大订阅、所有内存上涨或所有客户端卡顿的共同原因。

按出现时机选择排查方向

现象优先判断
启动、重载或 -t 校验阶段卡顿，许多 proxies 带 dialer-proxy继续核对运行配置、内核版本和同一副本的校验结果。
只有打开托盘菜单或日志页面时卡顿先查客户端界面和日志处理，不把内核校验修复当成通用方案。
正常运行一段时间后内存持续增长分别记录连接量、DNS 和运行日志；与本题的加载阶段峰值区分。
直接报 not found 或 circular dialer-proxy dependency先修复缺失目标或真实循环，升级不会让无效引用变有效。

先记录客户端版本、实际运行的 Mihomo 版本以及启动日志。桌面客户端的版本号与内核版本不是一回事；命令行 mihomo -v 显示的也可能是另一份 PATH 中的程序，必须与客户端当前运行的内核对应。

查看客户端最终交给内核的配置，而不只看订阅原文。确认 proxies 中是否有很多条目带 dialer-proxy，以及它们引用的出站代理或策略组是否存在。少量相关条目通常不是这项成本问题；proxy-providers 不在该旧检查范围内，不能只看节点总数就套用结论。

仅示意引用关系，不是可用节点配置
proxies:
  - {name: relay, type: socks5, server: 127.0.0.1, port: 1080}
  - {name: node-a, type: socks5, server: 127.0.0.1, port: 1081, dialer-proxy: relay}
  - {name: node-b, type: socks5, server: 127.0.0.1, port: 1082, dialer-proxy: relay}

示意中的 relay 是被引用的代理名称；本地地址和端口只是占位，不应粘贴替换真实订阅。A 引用 B、B 又引用 A，或条目引用自身，仍属于真正的循环。目标改名或被覆写删除时，也应先恢复正确引用，而不是删掉 dialer-proxy 来跳过检查。

用完整副本做一次可回退的校验

保留同条件对照

  1. 先保存原来可用的配置

    备份当前配置、覆写、外部资源和客户端设置到独立目录，记下原内核版本及系统代理/TUN状态。不要在唯一数据目录上同时升级、改订阅和调整 DNS。

  2. 确认测试程序与目录

    命令行用户先确认候选文件确实存在、内容正确，再把占位路径换成完整副本。-v 查询版本；-t 会初始化数据目录，缺少 -f 指定的文件时可能生成默认配置，不是只读操作。-d 指定副本数据目录，原相对路径和资源依赖需要一并保留；不能只凭测试成功就认定测过候选配置。

  3. 只测试一次并记录结果

    在可中断时段观察开始到结束的时间、进程峰值内存和首条错误。测试可能占用资源或读取外部资源，不承诺零网络访问；应用托管内核没有受支持的命令行入口时，使用项目提供的配置校验和日志，不强行覆盖或提取内部程序。

命令行：替换路径后使用同一完整副本
mihomo -v
mihomo -t -d "/path/to/complete-copy" -f "/path/to/complete-copy/config.yaml"

更新实际运行的内核，并保留循环检查

v1.19.33 的正式发布记录列出 #3315 修复。固定标签源码改为复用遍历状态，避免为每个带引用的节点重复分配大块检查数据；它仍保留目标不存在和循环引用的错误。更新修复的是校验成本，不会修复真实配置关系。

按项目支持的方式更新

  1. 先确认更新渠道

    独立内核用户从 MetaCubeX/mihomo 的稳定发布渠道选择匹配系统和架构的版本；客户端用户走该项目支持的应用或内核更新流程，不随意覆盖服务目录中的二进制。

  2. 确认修复确实被包含

    v1.19.33 是本篇已核对的正式修复版本。FlClash v0.9.2 的更新记录明确包含 Mihomo v1.19.33，可作为有出处的例子；其他客户端需核对各自记录，不能只凭应用更新成功就认定内核已替换。

  3. 重新读取运行版本

    按项目要求正常重启相关应用或内核，再查看实际进程或启动日志中的版本。保留原配置和资源副本，首次验证不同时更换节点、更新订阅或改 DNS。

同配置检查通过后，再验证真实代理请求

验证清单

  • 实际运行内核已确认包含 v1.19.33 的 #3315 修复，而不是只更新了客户端界面。
  • 同一完整副本的 -t 校验，或托管内核受支持的校验入口正常结束，并确认实际读取了候选配置；同设备、相近负载下比较耗时与峰值内存，不套用别人的秒数或内存上限。
  • 正常启动和重载后代理组、节点选择及 dialer-proxy 引用仍符合原本设计。
  • 恢复需要的系统代理/TUN后，使用同一目标发起真实 HTTPS 请求，并核对连接记录；校验通过不等于节点一定可用。
  • 若仍报缺目标或循环，按完整错误修配置；若只有运行流量中持续增长，转查其他内存原因，不重复执行加载压力测试。

本站没有在真实客户端或路由器上执行本篇命令，也不提供性能倍数保证。上述对照用于让读者判断自己的配置与已确认修复是否相符；网络、设备内存和其他配置问题仍需分别验证。

更新后仍异常，先恢复可用方案

先保存当前错误和配置副本，停止反复重载。按事前记录撤销本轮新增的系统代理/TUN开关，恢复原来可用的网络方式；不要清空全部规则或关闭安全软件来掩盖问题。

升级产生兼容问题时，按该项目支持的方式恢复已知可用版本及匹配配置和资源，避免新旧版本共用唯一数据目录。旧版本可能仍有本题校验成本问题，不应把回退当成修复；小内存设备优先恢复此前能用的配置并暂缓加载有问题的大配置。

向项目反馈时提供运行内核版本、系统和架构、加载阶段、相关条目规模、耗时/内存趋势及脱敏错误。删除订阅令牌、节点密码、私钥和真实服务器信息；尽量保留最小的引用关系，不公开完整订阅。

参考资料