本文目录
OpenClash 升级后，内核反复退出，随后提示插件已禁用。此时不断点启动未必有用：如果日志先出现 invalid tun stack，需要核对生成配置里的协议栈与实际内核是否兼容，再恢复插件的启用状态。
升级后起不来，先找第一条内核错误
OpenClash #5361 报告了从 v0.47.156 升级到 v0.48.002、保留旧内核后的这个现象。报告者在 Kwrt 的 fake-ip-tun 模式下发现，未保存过的 stack_type 为空，最终配置却写入了 mips。
其旧内核 alpha-fe22fdd 无法校验这个值，换成 mixed 后通过配置检查并恢复启动。报告仍未关闭，没有官方修复定论；本文给出与固定源码相符的条件式排查，没有在路由器实机复现。
Parse config error: invalid tun stack
OpenClash Now Disabled, Need Start From Luci Page, Exit...先判断是否符合本文范围
| 实际情况 | 下一步 |
|---|---|
| 先报 invalid tun stack，生成的 tun.stack 为 mips | 核对当前运行内核是否支持该值，再做可撤销对照。 |
| 只有插件已禁用提示，没有前面的内核错误 | 向前查启动日志；禁用可能是其他启动失败的结果。 |
| 内核已正常运行，只是网页或 DNS 不通 | 先按真实连接错误排查，不能据此认定协议栈不兼容。 |
为什么改完协议栈仍提示已禁用？
v0.48.002 的设置页面将 mips 作为 TUN 栈默认值。生成脚本先取传入的栈值；为空时再取另一参数，仍为空才回落到 mips。因此，应看自己的最终配置，不能假定所有订阅都会被无条件覆盖。
这里的 mips 是 TUN 协议栈名称，不是路由器的 MIPS 处理器架构，也不是 MASQUE 出站的 ip-stack。不要因为看到这个词就更换内核架构或修改出站节点。
Mihomo v1.19.30 的固定解析代码仅列出 gvisor、system、mixed；v1.19.31 已包含 mips，v1.19.32 也支持它。这说明不同内核确有取值差异，但不能只凭插件版本判断自己使用的构建。
OpenClash 的启动失败处理会把 enable 写成 0；启动入口看到未启用状态时会直接退出。因此，仅修改 stack_type 后再执行 start，仍可能停在已禁用提示。恢复时必须同时确认插件重新启用。
先留好备份，再核对实际内核与原值
先保留能够管理路由器的本地连接，暂停不可中断的传输。将插件设置、订阅和自定义配置另存到独立位置，确认副本可读；记录此前可用的运行模式、协议栈以及插件启用状态。
在插件内核信息与启动日志中核对实际加载的 Mihomo 版本。命令行里的另一份内核不能代表插件正在用的那一份；不要仅凭应用版本或文件名认定支持哪些协议栈。
uci -q get openclash.config.stack_type
uci -q get openclash.config.enable第一条没有输出，可能表示该项尚未设置，不代表最终配置一定为空。另行查看插件生成的运行配置中的 tun.stack，并记录第一条解析错误；不要公开完整配置、订阅地址、节点密码或控制器 secret。
需要进一步校验时，使用插件当前那份内核和实际配置进行配置检查。通过检查只说明解析成功，不等于转发、DNS 或局域网接管已经正常；本文不要求下载测试内核或运行报告者的二进制。
选择已验证可用的栈，并重新启用插件
只有错误、最终 mips 值和内核兼容性相互吻合时，才做下面的单项对照。Mixed 是本次报告者验证通过、且上述旧版固定代码支持的选项；它并不是所有网络环境的通用最优值。
在自己的 LuCI 页面完成恢复
记录原设置并选择 Mixed
打开“插件设置 → 模式设置 → 网络栈类型”，保留原值记录后选择 Mixed。界面名称可能随语言变化；不要改成处理器架构选项，也不同时更换订阅、DNS 或运行模式。
应用设置并确认启用
点击“应用配置”，等待服务重启完成，并确认插件处于启用状态。固定源码中的“保存配置”仅提交设置；“应用配置”才重新启用并重启。若仍提示已禁用，应从 LuCI 明确启用后再查日志。
核对新生成的配置和日志
确认最终 tun.stack 已是 mixed，实际内核不再返回 invalid tun stack，且服务持续运行。若设置没有进入运行配置，先查当前配置与保存结果，不反复修改临时 YAML。
用相同网络和请求验证
保持节点、订阅与其他设置不变，发起新的网页或应用请求，再检查实际出口与日志。旧连接或开关颜色不能证明新的协议栈已经承担流量。
不直接修改插件生成、后续可能被覆盖的运行 YAML，也不手改默认值脚本来掩盖问题。后续可以单独评估官方内核升级，但须核对平台架构、配置兼容性和备份；本文没有验证更换内核的完整升级过程。
恢复后，还要检查解析、联网和重启
保留这几项验证结果
- 原 stack_type 与 enable 状态、当前内核版本和独立配置副本都有记录。
- 最终 tun.stack 为预期值，启动日志不再出现 invalid tun stack，也不再反复提示插件已禁用。
- 服务持续运行，同一域名能够解析，同一网页或应用的新请求可以完成。
- 路由器管理连接与原来需要代理的局域网设备均按预期工作；节点测速成功不能替代这些检查。
- 安排一次正常服务重启后，再核对实际内核、最终配置、启用状态与新请求，确认设置可持久保留。
把本次网络、时间、修改前后的栈值和请求结果一起保存。如果配置检查通过却仍无法联网，说明还需查看路由、权限、DNS 或节点的实际错误，不能继续将所有症状归因于这一个解析问题。
仍未恢复时，怎样撤销并反馈？
恢复记录的原协议栈和启用状态，并使用此前验证可用的独立配置或运行模式。需要导入备份前先另存当前状态，核对备份适用版本；不要清空数据，也不要让旧插件覆盖唯一的配置副本。
如果保留旧内核会继续触发原解析错误，就先停用这一失败组合，使用此前已验证可用的联网方式恢复管理。临时恢复联网与完成 TUN 修复是两项不同验证，不承诺关闭某个开关就能修好所有路由器。
向项目反馈时，提供插件与实际内核版本、固件和设备、原栈值、最终 tun.stack、是否重新启用，以及最早的解析错误和最短重现步骤。移除订阅 Token、节点凭据和 secret，避免上传完整敏感配置。
后续是否有官方修复、默认值调整或新的适用范围，应以项目维护者与发布记录为准。本文核对的是用户报告及明确版本的上游源码，不把报告者的 Dev 源码比对写成跨版本运行实测。