Clash Meta 外部控制器與 Secret：區域網路啟用 Web 面板安全步驟（2026）

1. external-controller 是什麼？和 mixed-port 差在哪

在 mihomo 系列設定裡，mixed-port（或分開的 port／socks-port）負責的是應用程式要把流量交給代理時連進來的埠：瀏覽器、系統代理或手機 Wi‑Fi 上的 HTTP 代理欄位，指的都是這一類資料轉送入口。相對地，external-controller 開的是另一條 HTTP 通道，給相容的儀表板、腳本或自動化工具呼叫REST 風格的 API：查目前模式、切換代理、重載設定、看連線摘要等。簡單說：mixed-port 是「給流量走」；external-controller 是「給控制台指揮核心」。

也因為職責不同，兩者的曝露範圍與防護需求完全不同。把 mixed-port 開給可信區網裝置使用時，你期望的是「這台裝置的 App 能把連線交給我的核心」；若把未設防的 external-controller 開在同一個可被掃描的範圍，攻擊面變成「任何人只要能連上這個埠，就有機會透過 API 改你的路由決策」。因此在規劃時，請先在腦中畫兩個圈：代理入口圈與控制 API 圈，再分別決定要綁在哪個位址、要不要給區網、要不要經過防火牆縮小來源 IP。

圖形客戶端（例如各平台的 Verge 系列或其他殼）通常會把上述選項翻成「外部控制器」「API 埠」「Dashboard」等字樣，並可能在進階設定裡提供與 YAML 同步的開關。若你發現「YAML 已改、面板卻仍連不到」，優先確認實際載入的是否為同一份設定檔，以及客戶端是否覆寫了埠號或監聽位址——這類問題與訂閱內容無關，卻是新手最常卡住的無形門檻。

2. 為什麼 Secret 幾乎是必備：REST API 能做什麼

Secret（或相容客戶端裡同等意義的「API 金鑰」「密鑰」欄位）的作用是：在 HTTP 層為你的 REST API 加上共享密鑰驗證，典型做法是請求標頭帶上 Authorization: Bearer <你的 Secret>。沒有這道門檻時，只要 TCP 能連進 external-controller，任何人都可以依照文件嘗試讀寫控制指令——在你自己家中這或許「感覺」安全，但一旦筆電帶到咖啡廳、會議現場或合租套房，同一網段上有誰在聽，並不是你能直覺掌握的。

實務上建議把 Secret 視為與路由器管理密碼同等級：長度足夠、隨機、不要與訂閱網址共用同一串字，也不要隨手貼在公開備忘或截圖社群。若你曾在論壇或聊天群組貼過完整設定檔，請假設 Secret 已外洩並立即更換，同時檢查是否有不明裝置連線紀錄。部分進階使用者會搭配反向代理＋TLS再包一層，那是另一條硬化路徑；對多數讀者而言，先把 Secret 設強、監聽範圍收斂，就已經消除最大的「控制台裸奔」風險。

3. 最保守做法：只聽本機與 Yacd-meta 連線方式

若你只需要在同一台電腦上開瀏覽器看儀表板，最乾淨的起手式是把 external-controller 綁在 127.0.0.1（或客戶端等價的「僅本機」選項）。這樣一來，封包只會在本機回環介面流動，區網上的手機或隔壁電腦預設無法直連這個埠，除非你再另外開隧道或改監聽位址。對於日常調規則、看延遲與連線列表，這種設定通常已經足夠。

Yacd-meta一類的 Web 控制台常以「靜態前端＋瀏覽器直連 API」的模式運作：你會在 UI 裡填後端位址（例如 http://127.0.0.1:9090，埠號請換成你的環境）以及Secret。若連線失敗，請先用同一台機器上的瀏覽器開啟 API 根路徑或版本資訊類端點確認服務活著，再回頭檢查瀏覽器是否因為HTTPS 混合內容擋下了對 http API 的請求——必要時改用允許的本機開啟方式或依文件調整。

# Mihomo-style excerpt — verify keys against your running build
external-controller: '127.0.0.1:9090'
secret: 'replace-with-a-long-random-string'

若你的日常開發環境需要從WSL、容器或另一個使用者工作階段連回這個 API，記得它們眼中的「本機」不一定是同一個網路命名空間；此時比起貿然把監聽改成 0.0.0.0，常更安全的是使用SSH 本機埠轉發或客戶端內建的僅允許指定介面選項，把曝露面縮在你掌控的管道裡。

4. 區網使用：bind-address、防火牆與信任邊界

當你想在平板或手機瀏覽器開儀表板，而核心跑在桌機上時，便會遇到「127.0.0.1 只有桌機自己看得到」這個物理限制。此時有兩條常見路線：其一是維持 API 仍聽本機，透過SSH 隧道或 VPN把埠轉到你的手持裝置；其二是在你信任的區網把監聽開到區網介面，並搭配強 Secret、防火牆來源限制與短期開放。第二條路不是「錯」，而是顯式地把信任邊界從單機擴大到整個子網路——你應該假設同 Wi‑Fi 上還有其他裝置會掃描埠。

bind-address（或圖形介面裡對應的「監聽位址」「綁定位址」）決定核心要把服務掛在哪張網卡的哪個位址上。常見寫法包含僅限回環、全部 IPv4 介面（實務上以 * 或 0.0.0.0 等形式出現，請以你的版本文件為準）、或指定某一個區網 IP。對於 external-controller，請單獨思考：你是否真的要讓「任何能路由到你這個埠的客戶端」都能發起連線；若答案是否定的，就不要沿用代理埠那一套的「全家敞開」習慣。

Windows 使用者請同步檢視Defender 防火牆入站規則：即便核心已在 0.0.0.0 監聽，作業系統仍可能擋下來自區網的 TCP。做法與放行 mixed-port 類似，但要把規則限制在你指定的 API 埠，不要做成「允許所有程式任意監聽」。同時請避免在公用網路設定檔勾選過於寬鬆的允許範圍，以免帶筆電外出時規則仍在生效。

需要讓其他裝置走HTTP／SOCKS 代理（而非開儀表板）的讀者，請改參考本站 區域網路共用本機 Clash：allow-lan 與防火牆一文：該篇整理了 allow-lan、mixed-port 與手機 Wi‑Fi 代理欄位怎麼對齊，與本篇 external-controller 安全模型互補而不重複。

5. Yacd-meta、API Base 與 curl 驗證範例

部署 Yacd-meta 時，請把手機或瀏覽器端的「後端位址」填成你的桌機區網 IP 加上 API 埠（例如 http://192.168.1.50:9090），並在密鑰欄位貼上與設定檔一致的 Secret。若畫面一片空白或請求全紅，請先在桌機本機用下列方式驗證 API 是否回應正常，再把問題縮小到「手持裝置到桌機的 TCP 是否打通」。

# Example: fetch runtime config over REST (paths vary by version)
curl -sS -H 'Authorization: Bearer TOKEN' \\
  'http://127.0.0.1:9090/configs'

若不加標頭或 Token 錯誤，伺服器通常會回401或拒絕存取——這反而是好事，代表匿名裸奔已被擋下。若在未設定 Secret 的環境仍能讀到敏感資訊，請立刻補上 Secret 並重載，同時檢查是否有舊版面板快取了無驗證的連線方式。

進階使用者若以腳本調整模式或拉流量統計，請固定使用官方／上游文件記載的路徑與動詞，並留意寫入類 API可能改變目前路由狀態；在生產或多人共用環境，應再加稽核與權限分段，而不是長期共用同一組全域 Secret。

6. 與 allow-lan 的關係：不要拿 API 埠當代理埠

allow-lan影響的是代理入站能否接受區網來源，與 external-controller 是否開放並無自動等同關係。實務上曾見使用者把手機 Wi‑Fi 代理埠填成 API 埠，結果瀏覽器連線行為異常、日誌卻看不出典型代理流量——這就是把兩種協定與用途完全不同的埠搞混了。請記住：給 App 上網走的是 mixed-port／HTTP(S) 代理埠；給面板與自動化走的是 external-controller。

當你同時啟用區網代理共用與區網儀表板時，等於在內網放了兩個不同功能的入口：一個轉送使用者流量，一個指揮核心。二者的曝露策略可以不一致——例如代理僅限家用 SSID、API 仍僅本機；或兩者都給區網，但皆設強密鑰並限定來源 IP。關鍵是不要用同一套「全都開最大」的習慣去套兩種服務。

若你的設定檔骨架尚未建立，建議先到本站 訂閱匯入教學把基底節點與規則補齊，再回到本篇調整 external-controller；否則面板再漂亮，也只是在「空白策略」上看動畫而已。