Mihomo 控制 API 是代理核心的管理介面，監聽及憑證應與代理流量連接埠分開保護。限制 HTTP 控制器的監聽範圍，設定強 Secret，選用可信面板，並驗證未獲授權拒絕及獲授權存取。瀏覽器載入網頁，不足以證明管理介面安全。［1］

關鍵要點

代理認證與 HTTP 控制 API 認證保護不同介面。

loopback 減少暴露，但本機程序和瀏覽器程式碼不會自動可信。

Unix socket 及 Windows Named Pipe 不驗證 HTTP API Secret。

遠端管理須有受控入口、加密傳輸及可驗證的撤銷方法。

Mihomo 控制 API 能管理甚麼？

本文按 Mihomo v1.19.32 及官方全域設定核對 HTTP 控制欄位與認證行為，沒有聲稱作者完成端到端部署或測試所有面板與封裝。變更前記錄實際核心、封裝、作業系統及面板來源。［1］［2］

自建運維責任規劃協助指定憑證、更新及退役負責人。管理存取可能披露連線資料或更改路由，而開放代理的濫用風險是另一邊界。分別保護及驗證，不假定一個密碼涵蓋所有介面。

只處理你有權管理的實例，私下備份有效設定，保留不依賴控制器的還原通道。共用主機先協調時段並查明使用憑證的客戶端，再輪換。不要關閉日常使用的代理、VPN 客戶端或其他代理來騰出連接埠。

步驟 1：辨識監聽及憑證負責人

列出真正執行核心的程序、載入設定檔、全部控制監聽、代理連接埠、面板檔案及轉送服務。Linux 可在本機用 ss -lntup，其他平台使用原生監聽檢查工具。核對位址、連接埠及所有者，不盲目終止意外程序。

mixed-port、SOCKS 及 HTTP 代理處理應用流量；external-controller 提供管理 API，secret 認證其受保護 HTTP 路由。代理 authentication 屬另一設定，因此單改 allow-lan 不算完整控制介面審核。［1］

同時記錄 IPv4、IPv6、容器、轉送連接埠及反向代理。容器內的 loopback 仍可能透過獨立中介存取；工作站 loopback 也不是伺服器 loopback。核對各個獲授權管理位置的實際入口。

訂閱 URL 屬含憑證輸入，按訂閱連結保密原則保管。不要把完整設定或 Secret 貼到公開問題、網上 YAML 編輯器、未評估遠端面板或截圖。診斷只須描述監聽及拒絕結果，不展示憑證。

步驟 2：設定最小 HTTP 監聽及新 Secret

本地管理先採用 loopback 與新產生的隨機 Secret。以下只顯示本次相關欄位，並非完整代理設定；載入前替換佔位內容，保留無關路由及代理憑證。［1］［3］

external-controller: 127.0.0.1:9090
secret: 'REPLACE_WITH_A_UNIQUE_RANDOM_SECRET'

使用可信密碼管理器或作業系統隨機來源，在本機產生獨一且高熵的值，公開佔位文字不能作憑證。將 Secret 放在私人設定並限制檔案權限，不放進指令參數、URL、shell 歷史或共用紀錄。

移除目標設定中不需要的其他控制監聽，不假定一個欄位會覆蓋所有介面。核對封裝產生的覆寫，套用後再次查看實際監聽。先使用所選版本有文件支援的檢查功能，再經正常負責人重新載入。

socket 及 pipe 為何須獨立核對？

官方說明 external-controller-unix 與 external-controller-pipe 不驗證 Secret；前者依賴通訊端路徑權限，後者依賴 Named Pipe 存取控制。下方 HTTP 拒絕檢查無法證明這兩類介面安全。［1］

沒有需要便不啟用。必須使用時，將 socket 放在私人父目錄，檢查真正所有者及權限，pipe 只准指定帳戶存取。重新啟動後再查，因建立權限及服務身份可能不同於現存檔案。

本次加固不要順便啟用可選 DoH 入口，官方文件亦說明它不檢查 API Secret。DNS 服務暴露需要另外定義範圍及政策；不用的服務保持關閉，可減少獨立存取邊界。［1］

步驟 3：如何限制 Mihomo 面板暴露與遠端入口？

面板是在瀏覽器內接觸管理憑證的程式碼。檔案應來自可追溯項目發行版，記錄版本，變更期間避免未評估第三方託管及自動更新。熟悉外觀不證明來源可靠，本地託管也不能免除對檔案的信任判斷。

使用 external-ui 時指向預期本機目錄，並核對實際提供的內容。官方將 UI 檔案、控制監聽及 Secret 分開；登入表單不是後端認證證據，直接請求受保護路由也須拒絕無憑證存取。［1］

跨來源權限只允許真正需要的面板 origin。不要為消除瀏覽器錯誤而設定萬用來源或開啟私人網絡存取；CORS 約束瀏覽器互動，不認證 CLI 客戶端，亦不能取代 Secret。封裝需要額外 origin 時，記錄原因並驗證有效設定。

偶爾遠端管理可使用窄綁定 SSH 本地轉送。採用已核實主機密鑰及既有獲授權伺服器帳戶，核心 HTTP 留在伺服器 loopback。以下在管理工作站執行，替換帳戶與主機名稱；本地連接埠刻意採用不同值。

ssh -o StrictHostKeyChecking=yes -o ExitOnForwardFailure=yes \
  -N -L 127.0.0.1:19090:127.0.0.1:9090 admin@controller-host.example

SSH 加密遠端一段，本地 loopback HTTP 仍需 API Secret。不要改成萬用綁定；完成後關閉該 SSH 工作階段，確認本機 19090 不再監聽。主機密鑰未能核實便停止，不盲目接受。

HTTPS 入口是另一設計，須有有效憑證、客戶端正常驗證、認證及暴露限制，並檢查是否存在直連 HTTP 繞過。TLS 錯誤不能靠略過憑證驗證或公開原始 HTTP 控制器解決。不要只為開啟面板而增加 WAN 轉送。

步驟 4：驗證 Mihomo API Secret 是否生效

對你自己的受保護 /configs 檢查：第一個請求不帶憑證，第二個刻意帶錯誤值，兩者均不得回傳受保護設定。示例為本機 9090；使用 SSH 轉送時改為 19090。［2］

curl --noproxy '*' --max-time 5 --silent --show-error \
  --output /dev/null --write-out '%{http_code}\n' \
  http://127.0.0.1:9090/configs
curl --noproxy '*' --max-time 5 --silent --show-error \
  --header 'Authorization: Bearer intentionally-wrong-secret' \
  --output /dev/null --write-out '%{http_code}\n' \
  http://127.0.0.1:9090/configs

v1.19.32 預期認證失敗為 HTTP 401。逾時或拒絕連線不證明 Secret 已被檢查，只表示那次未能存取。再透過可信本地面板或私人 curl 設定檔使用正確憑證，預期受保護路由成功；不要把真 Secret 寫進公開指令或查詢參數。［2］

檢查方法	預期現象	失敗處理
查看實際監聽通訊端	只有預期控制位址與連接埠	移除意外監聽或轉送負責人
匿名請求受保護路由	HTTP 401，沒有受保護資料	停止外部存取並修正認證
錯誤 Secret 請求	HTTP 401	核對有效設定與中介
正確現用 Secret 請求	受保護路由成功	查憑證載入及路由歸屬
從被排除的授權測試主機存取	沒有非預期路徑通往控制器	關閉轉送或防火牆暴露
關閉遠端入口後再連	入口不可用	找出尚存轉送服務

這些是讀者驗收條件，並非作者結果。直接核心及中介分別核對；反向代理拒絕可能掩蓋未認證後端。也要確認面板只完成預期管理，以及憑證沒有保存在共用瀏覽器設定檔。

步驟 5：輪換憑證並撤銷遠端存取

產生新 Secret，經設定負責人更新私人有效設定，再按正常生命週期載入。更新每個可信客戶端，重做正反檢查。新憑證可用並不足夠，舊憑證須在新的受保護請求中被拒絕。

按所選生命週期結束舊面板工作階段及管理連線；既有串流不等於新認證請求。清除瀏覽器儲存、私人客戶端檔案與轉送設定中的舊權杖。若憑證洩漏，不應為修好客戶端而從備份還原舊 Secret。

設定錯誤需要回復時，還原舊監聽參數，但保留未洩漏 Secret。關閉測試 SSH 轉送，只撤銷本次入口規則，再查監聽；核對一般代理操作及獨立管理，不關閉整個防火牆來恢復面板。

由路由器管理的 Mihomo 可能被插件重新產生設定，可參照OpenClash 部署及網絡還原。若任務不值得承擔面板、憑證及伺服器維護，保留管理面之前先比較自建與託管方案的責任。

總結

控制監聽及中介與代理連接埠分別登記。
HTTP 控制器即使在 loopback 亦保留認證。
核對拒絕、獲授權成功、輪換及入口撤銷。
通訊端權限、瀏覽器信任與 TLS 分開驗收。

常見問題

allow-lan false 可以保護控制 API 嗎？

此設定針對代理流量存取，控制器有自己的監聽及認證。應檢查實際控制位址，再單獨測試受保護 API 路由。

loopback 可否省略 Secret？

loopback HTTP 控制器仍應認證。本機程序及瀏覽器程式碼不會自動可信，後加轉送服務也可能擴大實際暴露。

面板登入畫面能證明認證有效嗎？

介面要求密碼，不等於後端已強制認證。應直接驗證核心拒絕匿名及錯誤憑證請求受保護路由。

Unix socket 是否檢查同一 Secret？

文件說明 Unix socket 及 Named Pipe 不驗證 API Secret。應限制作業系統權限或不啟用，HTTP 測試無法證明其權限安全。

CORS 能否取代存取控制？

CORS 限制特定瀏覽器互動，不約束所有 HTTP 客戶端。即使來源清單明確，也須保留認證、窄監聽及受控遠端入口。

私人 SSH 轉送本身是否足夠？

已核實 SSH 保護遠端傳輸，不取消 HTTP API 認證要求。保持本地窄綁定，並在管理完成後撤銷轉送。

如何證明 Secret 輪換成功？

新憑證須可用，舊憑證須在新的受保護請求中被拒絕。另按客戶端生命週期結束舊管理工作階段，並移除儲存的舊值。

免責聲明：本文說明文件支持的管理控制與讀者檢查，不聲稱作者測試結果。只在獲授權系統操作，並保留不依賴 API 的還原通道。

來源:

Mihomo — General configuration — https://wiki.metacubex.one/en/config/general/
Mihomo — v1.19.32 controller routing and authentication — https://github.com/MetaCubeX/mihomo/blob/v1.19.32/hub/route/server.go
Mihomo — v1.19.32 configuration source — https://github.com/MetaCubeX/mihomo/blob/v1.19.32/config/config.go

Sources checked 2026 年 10 月 11 日。

延伸閱讀:

Mihomo 控制 API 加固：監聽、認證與遠端入口驗證