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