2026 年 9 月 30 日，MetaCubeX 发布 Mihomo v1.19.32，将 TUN 默认协议栈调整为 mips，同时修正 listeners 中 TUN 入站的默认栈。对启用 TUN、却未显式设置 stack 的用户，升级可能改变实际使用的协议栈。合理做法是先核对最终配置，再决定沿用原栈还是验证新默认值。版本与改动可查官方 v1.19.32 发布说明。
这次 Mihomo TUN 默认协议栈变化，不等于所有 Clash 兼容客户端都会自动切换。2026 年 9 月 30 日这次发布面向内核；如果客户端传入的配置已写明 stack: system、gvisor 或 mixed，就不能仅凭升级版本断言改用了 mips。本文建议先保存配置和版本信息，在可恢复的环境中检查；截至 2026 年 10 月 2 日，官方 TUN 文档仍写着默认 gvisor，判断本版本应同时参考默认值变更提交。
先看要点：哪些用户需要检查
- 启用了 TUN，并依赖省略的 stack 字段：优先核对升级前后行为。
- 已经明确指定协议栈：先确认客户端最终传给内核的值是否仍然保留。
- 通过 listeners 单独配置 TUN：不要只检查顶层 tun，这条配置入口也有默认值变化。
- 只是看到界面更新：先确认实际运行内核版本，再判断本次说明是否适用。
默认值改变，与主动选择协议栈是两回事
官方 9 月 27 日提交把顶层 TUN 默认配置中的 C.TunGvisor 换成了 C.TunMips，并在配置示例中使用 mips。9 月 30 日的另一项提交，则把 listeners 的 TUN 初始化默认值也改为 mips。这两个入口应分别核对；依据是TUN listener 默认值修正，不能把顶层示例直接当成 listeners 的完整写法。
默认值负责填补未指定的选项，显式设置则表达配置选择。因此，排查时最有价值的问题是“实际加载了什么配置”，而不是“界面上有没有一个 TUN 开关”。本文据此建议：有配置合并、覆写或生成步骤时，同时保存输入配置与最终配置，比较 stack 是否被写入。具体查看入口取决于客户端，本文不假定各客户端界面相同。
如果尚未弄清 TUN 与系统代理的作用范围，可以先阅读TUN 模式、系统代理和透明代理的区别。本次需要核验的是 TUN 内部的栈选择，不宜同时把接管流量的方式也换掉，否则很难判断是哪项变更影响了连接。
文档写 gvisor，发布代码写 mips，应该怎么判断
截至本次核验，官方 TUN 文档的 stack 小节仍把默认值列为 gvisor，同时列出 system、gvisor、mixed、mips 四个可选值，并将 mips 解释为 Mihomo 自研 IP 协议栈。这个名称在此表示协议栈选项，不能据此推断应下载哪一种处理器架构的安装包。
这里存在可观察到的文档与版本代码不一致。本文采用的判断顺序是：先确定运行版本，再查该版本发布记录及对应实现，最后用文档理解字段含义。不要因为网页尚未同步就删除配置，也不要把新默认值推广到所有旧版内核。官方资料没有因此给出每个操作系统、每个客户端的迁移结果。
如果你此前有明确、可重复验证的栈配置，保留显式选择有助于减少升级变量。若此前依赖默认值，则应记录“字段原本缺省”这一事实；没有记录时，事后仅看新配置无法可靠还原旧环境。
升级前后核验清单：一次只改变一个变量
以下是基于此次默认值变化提出的编辑建议，不是项目宣称的兼容性测试结果。只在自己管理或获得授权的设备上执行；远程维护设备应先准备独立的恢复入口，避免修改网络后无法继续操作。
- 记录基线。保存客户端版本、实际内核版本、操作系统、最终配置和一段正常启动日志。配置中若有订阅凭据或服务端密钥，备份应限制访问，反馈问题前要脱敏。
- 定位字段。检查顶层 tun 是否启用、是否存在 stack；使用 listeners 时，逐项找出 type 为 tun 的配置。不要把一个入口的值当作另一个入口的证明。
- 明确本轮目标。是验证新内核下原配置能否继续工作，还是验证 mips？先选一个目标。保留 DNS、路由规则、出口与测试网络，避免同时修改多项参数。
- 核实运行状态。从所用客户端提供的内核信息和日志入口确认启动的是预期版本，查看是否有配置解析或 TUN 初始化错误。若界面没有展示实际栈，不要把界面默认选项当作证据。
- 检查实际业务。用升级前相同的合法目标验证网页连接、需要的 UDP 应用和授权内网访问；记录失败发生在解析、连接建立还是持续传输阶段。若有双栈需求，分别记录 IPv4 与 IPv6 的结果。
- 重启后复核。确认配置没有被客户端重新生成或覆写。无法确认最终 stack 时，先解决配置来源问题，不宜继续做速度比较。
若连接走错出口，应先检查域名、IP 与规则优先级。若只有大数据传输卡顿，可以结合MTU 与 MSS 排查方法整理症状；这些现象本身都不足以证明 mips 有缺陷，也不应直接归结为服务端故障。
出现异常时，怎样回退才有判断价值
编辑建议是先恢复已验证的显式栈设置，保持其他条件不变，再重复同一项失败操作。若还需恢复旧内核，应使用此前保存的官方版本与配套配置，并遵守所用客户端的恢复方式。不要把新版配置未经核对直接交给旧内核，也不要删除整个配置目录来代替定位问题。
对比结果只能说明问题与某次变更有关，还不能单独证明根因。提交反馈时，提供内核版本、系统、脱敏后的相关 TUN 配置、明确的复现步骤及错误日志；同时说明最终配置是否显式指定了 stack。不要把带有令牌的订阅地址或完整私密配置贴到公开讨论区。
常见问题
升级到 v1.19.32 后，必须手动改成 mips 吗？
不必因默认值变化就主动改写所有配置。发布说明与提交确认的是默认选择变化。已有显式配置的用户应先核对最终生效值；依赖默认值的用户则需要验证升级后的业务行为，再决定是否固定栈选择。
mips 是否代表速度更快，可以直接替换 gvisor？
不能从本次改动得出这种结论。默认值调整不是针对你设备的性能承诺。本文没有进行实测，发布说明也不能替代相同网络、相同目标和相同配置条件下的验证。选择应以实际业务能否正常完成为先。
只在 listeners 里配置 TUN，也需要检查吗？
需要。9 月 30 日的官方修正专门涉及 listener TUN 默认栈。请检查对应的 type: tun 项是否指定 stack，而不是只查看顶层 tun。两种入口的配置结构不同，不应机械互相复制。
是否应同时打开 congestion-controller 来优化？
不建议把它加入第一轮迁移验证。官方默认值变更提交也加入了 TUN 的 congestion-controller 选项，示例注明该选项只对 mips 有效。本文建议先保持其他条件不变，确认连接正常后，再根据明确需求单独评估；它不是完成升级所必需的设置。
官方来源与核验入口
- MetaCubeX/mihomo，2026 年 9 月 30 日发布：Release v1.19.32 · MetaCubeX/mihomo · GitHub：版本与改动列表。
- MetaCubeX/mihomo，2026 年 9 月 27 日提交：chore: change default IP stack mode to mips and support `congestion-controller` option for tun。
- MetaCubeX/mihomo，2026 年 9 月 30 日提交：fix: default listener tun to mips stack (#3264)。
- MetaCubeX 虚空终端 Docs，页面未标注发布日期，2026 年 10 月 2 日核验：Tun - 虚空终端 Docs：stack 字段与配置含义。
以上入口均于 2026 年 10 月 2 日访问。版本事实以所引发布与提交为界；客户端打包情况、配置覆写行为和设备上的运行结果仍需读者自行核验。
关于作者
