本文目錄
先確認是否匹配這次 EasyTier 失聯
Mihomo v1.19.31 於 2026 年 9 月 14 日發布，正式加入了 type: easytier 出站。隨後提交的 issue #3214 記錄了一種特定現象。
報告中，Mihomo 和其他代理仍正常，只有 EasyTier 出站變成 alive: false，延遲歷史為 0，測速持續 Error 或 Timeout，對端的 peer 清單也看不到這台 Mihomo 節點。
這是一份 Linux/amd64、with_gvisor、OpenWrt/Kwrt 與 ShellCrash 環境中的使用者報告，不代表所有 v1.19.31、所有前端或所有平台都會遇到。報告者當天觀察到三次，只有第一次明確發生在 EasyTier 對端重啟之後，因此不能把對端重啟寫成唯一觸發條件。
如果所有代理都不可用、Mihomo 無法啟動、設定載入失敗，或只有 DNS 和規則命中異常，就不屬於這份報告已經描述的範圍。先按首條錯誤處理，不要僅憑一個 alive: false 判斷根因。
現象與判斷
| 看到的情況 | 是否匹配 | 下一步 |
|---|---|---|
| 只有 EasyTier 出站 alive: false，其他代理正常 | 較匹配 | 繼續核對延遲歷史和對端 peer |
| 延遲歷史為 0，測速 Error 或 Timeout | 需要結合其他信號 | 確認測試流量確實命中該出站 |
| 對端 peer 清單中預期 hostname 消失 | 匹配報告中的關鍵觀察 | 儲存狀態後再做受控重啟 |
| Mihomo 整體無法啟動或所有出站失敗 | 不匹配 | 先查設定、服務、網路和連接埠 |
| 只有某個網域或 DNS 請求失敗 | 證據不足 | 檢查規則命中、DNS 與目標服務 |
先排除按需啟動和設定條件
Mihomo 官方文件說明，EasyTier 出站只有在規則、策略群組或其他路由方式把流量送到它時才啟動。剛載入設定、尚未有請求命中時看不到活躍實例，可能只是正常的按需行為，不是靜默失聯。
先固定一個可重複的測試目標和一個明確選擇 EasyTier 的策略群組，讓請求實際走向該出站。若沒有設定 listeners，文件要求至少提供一個 peers；overlay 位址只支援 IPv4，ip-version 只決定底層 peer 連線使用 IPv4 還是 IPv6，不能用它開啟 overlay IPv6。
本輪只驗證啟動條件，不同時修改金鑰、peer 位址、策略群組和路由。一次改多個變數，即使恢復也無法區分是設定修正還是實例重建起了作用。
先建立可比較的測試
確認執行版本
記錄 Mihomo v1.19.31、平台、架構、建置標籤，以及由哪個前端或服務管理器管理。
讓流量命中 EasyTier
臨時固定一個策略選擇併發起實際請求，確認請求不是被規則送到 DIRECT 或其他代理。
核對最小設定條件
沒有 listeners 時確認至少存在一個 peers；overlay 位址保持 IPv4，並正確理解 ip-version 的作用。
保留其他代理作對照
用同一目標測試一條普通代理，判斷是單個 EasyTier 出站異常還是整個 Mihomo 路徑異常。
重啟前記錄出站與 peer 狀態
如果測試流量已經命中 EasyTier，仍出現 alive: false、歷史延遲全為 0 和連續超時，先儲存現場再重啟。記錄出站名稱、狀態、測速時間、首條相關日誌，以及 EasyTier 對端 peer 清單中是否還有預期 hostname。
報告者使用 easytier-cli peer 核對對端節點，並看到異常實例消失。你可以使用目前 EasyTier 部署提供的 peer 查看入口做同樣的只讀確認，但不要為了復現執行來源不明的指令碼或修改生產 peer。
一次 curl 的 Empty reply from server 也不能證明認證和 overlay 已經正常；它最多說明 TCP 連線後沒有收到有效回應。
分享證據前刪除 network-secret、私鑰、peer 公鑰、Controller secret、公用網路位址和訂閱資訊。保留原始私有副本，公開的只使用脫敏版本。
出站從未承載流量
先完成按需啟動測試，不進入重啟結論。
EasyTier 異常，普通代理與 Mihomo 處理程式正常
儲存 alive、history、測速和 peer 狀態，繼續做最小重啟。
peer 位址的底層連接埠不可達
先檢查防火牆、連接埠、位址和對端服務，不把問題歸為實例靜默失聯。
peer 仍存在，但 overlay 目標不可達
繼續檢查路由、exit-node、proxy-networks 和目標 IPv4，不只看延遲。
所有出站同時失敗
先恢復 Mihomo 設定、系統網路或管理服務。
先用受控重啟恢復目前連線
issue #3214 的報告者在等待超過 30 分鐘仍未恢復後，重啟 Mihomo 讓 EasyTier 出站重新可用，對端 peer 清單也重新出現該節點。這是單一環境已經觀察到的臨時恢復方法，不是維護者對所有平台的保證，也不能代替後續修復。
先確認路由器或遠端主機仍有本機控制台、旁路管理入口，或其他不會經過該 EasyTier 出站的管理路徑。然後透過目前前端、ShellCrash、systemd 或裝置管理介面只重啟 Mihomo；不同管理方式的命令不同，不要複製一條不適合本機的服務命令。
重啟後使用同一策略、同一目標和同一網路重新發起請求，再對照 alive、history、延遲和 peer 清單。若恢復，只能記錄“本次重啟恢復”；若仍失敗，就回到連接埠、設定、對端服務和路由檢查，不連續重啟掩蓋首條錯誤。
完成一次最小恢復
儲存目前證據
記錄版本、出站狀態、測速結果、peer 清單和首條相關日誌，並製作脫敏副本。
確認備用管理入口
遠端裝置必須先確認重啟核心後仍能管理，避免把唯一的控制路徑一起中斷。
只重啟 Mihomo
使用目前管理工具的正常入口重啟核心，不同時重啟整台路由器、修改設定或更換 peer。
重複同一組驗證
確認 EasyTier 重新啟動、peer 回來、延遲恢復，並完成一次實際 overlay IPv4 請求。
穩定版和 Alpha 應該怎麼選
v1.19.31 正式版早於修復合併，因此不包含本次自動重建邏輯。PR #3215 已於 2026 年 9 月 15 日合入 Alpha，最終提交為 fbb6742；2026 年 9 月 16 日的滾動 Prerelease-Alpha 也明確列出“在靜默 overlay 失敗後重啟 EasyTier 出站”的修復。
最終實作沒有增加定時測速或把每次超時都當作重啟信號。EasyTier 自身繼續負責 peer 重連，Mihomo 消費事件流；只有事件流關閉、實例確實停止時，才重建 Host 和 Instance。這個範圍比“任何超時都自動修復”窄。
Alpha 是滾動標籤，之後會指向新的提交。決定試用時要同時記錄 fbb6742、下載時間、資產檔名和目前建置標籤，不能只寫“最新版 Alpha”。無人看管的路由器、沒有備用管理入口或無法快速回復舊版的裝置，更適合留在穩定版等待後續正式 Release 明確包含該修復。
版本選擇
| 目前情況 | 建議 | 原因 |
|---|---|---|
| 尚未出現匹配現象 | 繼續使用 v1.19.31 穩定版 | 不為單一公開報告主動切換預發布版 |
| 偶發失聯，受控重啟可以接受 | 暫留穩定版並記錄頻率 | 等待正式 Release 給出明確修復邊界 |
| 頻繁失聯，有維護視窗和備用入口 | 評估包含 fbb6742 的 Alpha | 可以驗證已合入的自動恢復邏輯，並隨時還原 |
| 遠端無人看管或無法恢復舊核心 | 不要直接追滾動 Alpha | 預發布回歸可能同時影響其他出站和管理路徑 |
驗證 Alpha 是否能自動恢復
測試 Alpha 前先儲存 v1.19.31 穩定版完整二進位、準確架構與建置變體，並備份設定和管理工具中的核心選擇。只使用 Mihomo 官方 Prerelease-Alpha 資產，確認執行提交包含 fbb6742；不要把新的核心檔案和舊版本元件混合複製。
先讓實際流量命中 EasyTier，確認 peer 已出現且 overlay IPv4 請求成功。只有在維護視窗、對端可控且有備用管理入口時，才讓測試 peer 短暫停止後恢復，觀察是否在不重啟 Mihomo 的情況下重新出現 peer、恢復延遲和實際請求。
PR 作者在 disable-p2p: true、單一路徑的本機測試中看到對端恢復後約一秒出現 peer_added，Mihomo PID 沒有變化。這支援該特定測試中的自動恢復設計，但不能承諾所有 P2P、中繼、多路徑或不穩定網路都在一秒內恢復。多路徑網路也可能根本沒有明顯斷流。
Alpha 自動恢復驗證清單
- 執行版本可以對應到包含 fbb6742 的 Alpha 提交，而不是只記錄滾動標籤
- 測試請求確實命中 EasyTier 出站，普通代理仍可作為對照
- 中斷前 peer、alive、history、延遲和實際 overlay IPv4 請求都已記錄
- 對端恢復後無需重啟 Mihomo，預期 peer 能再次出現
- 延遲歷史恢復，實際 TCP 請求成功；需要 UDP 時另做實際 UDP 驗證
- Mihomo PID 未變化，日誌沒有反覆重建或錯誤循環
- 其他出站、基本網路連線和裝置管理入口沒有回歸
- 穩定版二進位、設定備份和恢復步驟仍然可用
Alpha 異常就完整還原穩定版
如果 Alpha 無法啟動、CPU 或記憶體異常、普通代理出現回歸，或 EasyTier 仍不能恢復，先停止繼續改設定。關閉 Mihomo 後恢復升級前儲存的 v1.19.31 完整二進位和原設定，再透過同一管理入口重新啟動。
還原後先確認版本和設定載入，再驗證普通代理、EasyTier 出站、overlay IPv4 與管理入口。不要只複製舊庫檔案、外掛程式或單個模組到 Alpha 目錄，也不要把 issue 報告者使用獨立 EasyTier Core 加 SOCKS5 的替代架構寫成維護者推薦。
穩定版還原會重新失去 fbb6742 的自動恢復邏輯。若失聯仍會復發，可以保留受控重啟作為臨時恢復，並等待後續穩定 Release；不要透過不停改 peer、金鑰和路由來掩蓋可重複的版本差異。
還原完成標準
- 目前執行的是原先儲存的 v1.19.31 穩定版和正確建置變體
- 原設定、策略群組、EasyTier peer 與管理方式已經恢復
- 普通代理和基礎網路請求正常
- EasyTier 出站能按需啟動並完成實際 overlay IPv4 請求
- 裝置本機與遠端管理入口仍可使用
- Alpha 的提交、現象、日誌與還原結果已經脫敏記錄
- 沒有混用不同版本的二進位或元件
以後以正式 Release 判斷修復邊界
截至 2026 年 9 月 16 日，目前穩定版仍是 v1.19.31，EasyTier 靜默失聯後的自動重建只在 Alpha 提交 fbb6742 中有明確記錄。後續要以 Mihomo 正式 Release 是否包含該提交或等價修復為準，不猜測下一個版本號，也不把 issue 關閉狀態當作已經發布。
正式版發布後，仍要用相同策略、相同 peer 和相同測試目標復核一次正常啟動、短時中斷、自動恢復、普通代理與還原。Release 說明、執行版本和本機結果三者一致，才能撤銷臨時重啟或 Alpha 測試方案。
繼續向專案意見回饋時，應提供平台、架構、建置標籤、最小脫敏設定、EasyTier 與普通代理對照、alive/history、peer 變化和首條相關日誌。不要公開 network-secret、私鑰、Controller secret、訂閱或完整公用網路拓撲。