本文目錄
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 原始碼的比對，寫成跨版本執行實測。