Clash Meta Web 面板遠端存取：bind-address、secret 與防火牆逐步加固
Clash Meta（Mihomo）內建的 REST API 與圖形化 Web 面板，都依賴設定檔中的 external-controller。一旦監聽位址設得太寬、又沒有可靠的 secret 與網路邊界控管，等於把「切換節點、重載設定、檢視連線」的控制權交給同一個區網——甚至更糟。本篇以可操作的步驟整理：綁定位址怎麼選、密鑰怎麼設、瀏覽器與 curl 如何帶認證，以及 防火牆／SSH 轉發如何補上最後一道閘門；並與站內 區網代理（mixed-port、allow-lan）、Docker 部署、Linux systemd 等文銜接。
為什麼 external-controller 是「高權限」介面
可以把 external-controller 想成代理程式的大腦對外開的一扇門：透過這扇門，管理端能讀寫執行中的組態、觸發重載、查看即時連線，某些整合還會暴露足以推斷您網路行為的資訊。若這扇門對未授權的客戶端敞開，風險不只是「被看到用哪個節點」，還包含惡意操作導致的流量劫持、設定竄改、服務中斷。
因此預設策略應該非常保守：只聽本機迴環位址（127.0.0.1），需要遠端管理時，優先用 SSH 區域轉發把遠端的 127.0.0.1:9090 映射到您筆電上的本機埠，而不是直接把 9090 暴露在公網。
不建議的做法
將 external-controller 設為 0.0.0.0:9090（或伺服器對外的單一 IP）卻留空 secret、或密鑰極短、或防火牆對全世界開放——這在實務上等於未鑑權的管理後門。若您必須從網際網路管理，請改走 VPN、零信任通道或反向代理＋強認證，而不是裸奔 API 埠。
bind-address 在哪裡？與 external-controller 的關係
在多數 Clash Meta 設定裡，控制器的綁定位址與埠寫在 external-controller 這一行，格式為 位址:埠號。例如 127.0.0.1:9090 代表只有本機行程能連線；若寫成 0.0.0.0:9090，則表示在所有介面上監聽（實際可達範圍仍受作業系統防火牆與路由影響）。部分圖形客戶端會把這段稱為「API 位址」或「外部控制器」，語意相同。
設定檔中也可能另有與 入站代理相關的 bind-address、mixed-port、allow-lan 等欄位——它們管的是流量入口，與 external-controller 這個管理 API不同。混淆兩者時，常見錯誤是：代理分享給區網沒問題，卻順手把 API 也開到區網而忘記設 secret。建議您在變更後，用瀏覽器或 curl 實測「沒帶密鑰是否會被拒絕」。
心智模型
mixed-port 給裝置「上網用」；external-controller 給「管理用」。兩者的暴露面請分開評估：前者可依 區網需求調整；後者預設應維持最小權限。
設定強 secret 與 API 認證方式
secret 是控制 API 的共享密鑰。啟用後，客戶端需在 HTTP 標頭附上 Authorization: Bearer <您的 secret>（實作細節請以您使用的核心與面板版本為準；多數與官方文件一致）。密鑰長度請比照隨機密碼：至少數十個字元的英數與符號混合，避免使用訂閱網址或生日等可猜測字串。
若核心常駐在 Linux 伺服器，請避免把 secret 寫進世界可讀的設定檔後就忘記權限；可搭配 systemd 的 EnvironmentFile、容器環境變數（參考 Docker 一文）等方式，讓密鑰與版本庫分離。
# Minimal example — replace port and secret
external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-string"
變更 secret 後，請同步更新圖形客戶端、自動化腳本與書籤中的面板網址參數（若有），否則會出現 401 或空白頁面。
步驟一：本機確認面板與 API
- 將
external-controller設為127.0.0.1:9090（或您選定的本機埠），並寫入強secret。 - 重啟核心或觸發重載，確認行程無報錯。
- 在同一台電腦用瀏覽器開啟
http://127.0.0.1:9090/ui（實際路徑依版本與嵌入式 UI 而定），依介面提示輸入密鑰。 - 用
curl驗證未授權請求被拒絕、附帶 Bearer 則成功（端點名稱請查您所用版本文件）。
若您使用第三方面板，請確認它連線的基底網址與 external-controller 一致，且 WebSocket／CORS 相關設定（若核心提供 external-controller-cors 類選項）不會意外擴大來源網域。
步驟二：僅限區網時如何開放
當您需要從同一區域網路的手機或另一台電腦開面板，有兩條典型路徑：
- 維持本機監聽，改透過 SSH 轉發或帶認證的反向代理從區網機器連到執行 Clash 的那台主機（較安全、可審計）。
- 將
external-controller改為0.0.0.0:9090或區網介面的私網 IP，並必定搭配強secret，且在作業系統或路由器防火牆上限制來源 IP 段（例如只允許192.168.1.0/24）。
第二條路徑實作快，但請記得：區網≠可信；訪客 Wi‑Fi、被入侵的 IoT、惡意 ARP 都可能讓「只在區網」的假設失效。若環境無法保證乾淨，請回到 SSH 或 VPN。
步驟三：防火牆與埠號收斂
無論 Windows、macOS 或 Linux，作業系統防火牆都是最後一道預設拒絕（default deny）的好夥伴。原則是：僅允許需要管理的來源，開最少埠。Linux 可搭配 ufw、nftables；Windows 可使用 Defender 防火牆進階設定；macOS 可透過應用程式防火牆或上層策略工具。路由器層級亦可限制管理 VLAN 才能存取 NAS 或閘道上的 Clash。
若您依 systemd 教學常駐在伺服器上，請把「對外服務埠清單」當成正式文件：哪些埠給代理、哪些給 API、哪些只給本機 health check。變更後用外部掃描或第二台機器驗證從不可信網段無法連上 API。
從外網管理：優先順序建議
若您人在外，需要操作家裡的 Clash，建議優先序如下：
- 先連回家 VPN（WireGuard、Tailscale 等），再把面板當成區網服務存取。
- SSH 到家中主機，使用
-L本地轉發將遠端127.0.0.1:9090映到筆電。 - 若必須經由反向代理，請在代理層做TLS、身分驗證、速率限制，並讓後端仍只聽
127.0.0.1。
不建議直接把 external-controller 對映到公網 IP 並僅依賴單一 Bearer 密鑰而無任何網路層防護——暴力嘗試、憑證洩漏、瀏覽器 XSS 的衝擊面都會放大。
常見問題
瀏覽器開面板顯示 401 或未授權
請核對面板是否使用與核心一致的 secret、是否以正確標頭或查詢參數傳遞（依客戶端而定），並清除舊的快取或已儲存的 Basic Auth。
改了位址後客戶端連不上
確認沒有多個設定檔互相覆寫、圖形介面的「覆寫 YAML」是否把 external-controller 改回 127.0.0.1、以及防火牆是否尚未放行。
Docker 內的 API 要給宿主存取
請同時對齊容器內監聽位址、publish 的埠映射與宿主防火牆；細節見 Compose 部署文的 API 暴露面一節。
實務檢查清單
external-controller是否已收斂到最小必要監聽範圍？secret是否夠長、夠隨機，且未進版控？- 作業系統或路由器防火牆是否限制來源，而非對全世界開放？
- 是否已驗證未帶密鑰的請求會失敗？
- 遠端場景是否優先採用 VPN／SSH，而非裸奔公網埠？
總結與下一步
Web 面板能讓 Clash Meta 更好用，但 external-controller 本質上是高權限 API。把綁定位址、密鑰與防火牆一次做對，遠比事後清理遭掃描或遭竄改來得便宜。若您剛完成無頭部署，建議把本文與 Linux systemd 指南一併當作安全基線；日常桌面使用則可從 macOS Verge Rev 或 Windows 安裝文出發，再在進階設定中收斂 API。