前言：為什麼需要自動切換節點？

代理節點的不穩定，往往不是「完全無法連線」這麼簡單。更常見的情況是：網頁偶爾打不開、套件下載速度突然下降、SSH 連線在執行部署時中斷，或 API 請求因為延遲過高而逾時。當你只依靠 Clash Verge、Clash Verge Rev 或 Mihomo 客戶端手動切換節點，就必須一直觀察延遲、重新測試，工作流程也容易被打斷。

Clash API 提供了一條可程式化控制代理的路徑。只要啟用外部控制器（External Controller），腳本便能讀取目前的代理群組、測試節點延遲，再透過 API 將策略組切換到較合適的節點。進一步加入連續失敗計數、冷卻時間、日誌與復原邏輯後，就能建立一個不會因單次測試誤判而頻繁跳線的自動化方案。

本文以支援 Clash API 的 Mihomo 配置為例，示範如何規劃節點群組、測試 API、撰寫 Python 自動切換腳本，以及如何讓這套流程適合長時間維運。不同客戶端的介面名稱可能略有差異，但核心配置與 API 路徑大致相同。

適用情境

適合需要長時間下載、遠端開發、CI/CD 部署、雲端 API 呼叫，或希望在節點品質下降時自動維持連線的進階使用者。

1啟用 Clash API 與規劃策略組

自動切換的第一步，是讓腳本能夠安全地存取 Clash 核心。請先在配置檔案中確認 external-controller 與 secret。建議只監聽本機地址，避免把控制介面暴露到區域網路或公網。

external-controller: 127.0.0.1:9090
secret: "請替換成一組足夠複雜的密碼"

修改配置後，請在 Clash Verge Rev 或其他客戶端中重新載入配置，並確認核心沒有報錯。若客戶端已經提供外部控制器設定，也可以直接在圖形介面中查看目前的監聽地址與密鑰；不要在公開截圖、Git 儲存庫或共享日誌中洩露 secret。

建立可控的節點群組

腳本不應該直接管理所有代理，而應該只操作一個明確的策略組。這樣可以把工作流、影音、一般瀏覽等不同用途分開，避免自動化程式誤改其他流量的路由。以下是一個簡化的 url-test 群組範例：

proxy-groups:
  - name: Auto-Select
    type: url-test
    proxies:
      - Japan-01
      - Singapore-01
      - Hong-Kong-01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

url-test 會依照測試 URL 和間隔自動選擇節點；如果你需要更嚴格地控制切換條件，也可以使用 select 群組，再由腳本透過 API 指定目前使用的代理。前者適合低維護成本的基本場景，後者則更適合需要自訂評分、失敗門檻與降級順序的環境。

安全提醒

不要將 external-controller 設為 0.0.0.0:9090，除非你已經配置防火牆、反向代理與存取控制。API 可以切換節點，也可能修改配置，暴露後會帶來實際的控制風險。

2先用 API 測試節點與群組狀態

在撰寫自動化腳本之前，建議先用 curl 驗證 API 是否可用。常見的 API 位置是 http://127.0.0.1:9090，如果配置了密鑰，請在請求標頭加入 Authorization: Bearer。

curl -H "Authorization: Bearer 請替換成你的密鑰" \
  http://127.0.0.1:9090/proxies

回應內容會包含代理清單與各策略組的目前狀態。若要測試某個具名節點，可以呼叫延遲測試端點：

curl -G \
  -H "Authorization: Bearer 請替換成你的密鑰" \
  --data-urlencode "url=http://www.gstatic.com/generate_204" \
  --data-urlencode "timeout=5000" \
  http://127.0.0.1:9090/proxies/Japan-01/delay

不同 Mihomo 版本或節點名稱包含特殊字元時，URL 路徑可能需要進行編碼；實際使用時應以目前核心版本的 API 文件與回應為準。測試結果通常會回傳毫秒數，數值越低代表這一次探測的往返延遲較小，但低延遲不等於長時間穩定，因此不要只用單次結果決定節點。

建議採用多項指標

延遲：每個節點連續測試數次，取中位數而不是單次最低值，降低偶發尖峰的影響。
可用性：將逾時、連線拒絕與 HTTP 錯誤分開記錄，避免把所有問題都簡化成延遲過高。
穩定分數：保留最近幾輪結果，連續失敗時扣分，連續成功時逐步恢復分數。
切換成本：對長連線服務設定較長冷卻時間，避免節點在兩個相近結果之間反覆切換。

小撇步

測試 URL 應該與實際工作流相近。若主要使用程式碼託管服務，就選擇穩定且回應快速的 HTTPS 端點；不要只測一個與實際流量完全無關的網站。

3用 Python 建立自動切換腳本

下面的範例會讀取指定策略組，逐一測試其中的節點，排除逾時節點後，選擇延遲最低者。腳本使用標準函式庫，方便在 Windows、macOS、Linux 或伺服器環境執行。請先安裝並啟動支援 Clash API 的核心，再依自己的配置修改群組名稱。

import json
import os
import time
import urllib.parse
import urllib.request

API = os.getenv("CLASH_API", "http://127.0.0.1:9090")
SECRET = os.getenv("CLASH_SECRET", "")
GROUP = os.getenv("CLASH_GROUP", "Auto-Select")
TEST_URL = "http://www.gstatic.com/generate_204"

def request(path, method="GET", payload=None):
    headers = {"Authorization": f"Bearer {SECRET}"}
    data = None
    if payload is not None:
        headers["Content-Type"] = "application/json"
        data = json.dumps(payload).encode("utf-8")
    req = urllib.request.Request(API + path, headers=headers,
                                 method=method, data=data)
    with urllib.request.urlopen(req, timeout=8) as response:
        return json.loads(response.read().decode("utf-8"))

def test_proxy(name):
    encoded = urllib.parse.quote(name, safe="")
    query = urllib.parse.urlencode({"url": TEST_URL, "timeout": 5000})
    try:
        result = request(f"/proxies/{encoded}/delay?{query}")
        return result.get("delay")
    except Exception as error:
        print(f"[WARN] {name}: {error}")
        return None

group = request("/proxies/" + urllib.parse.quote(GROUP, safe=""))
candidates = group.get("all", [])
current = group.get("now")
results = []

for name in candidates:
    delay = test_proxy(name)
    if isinstance(delay, int):
        results.append((delay, name))
    time.sleep(0.2)

if not results:
    raise SystemExit("沒有可用節點，保留目前策略不變")

results.sort()
best_delay, best_name = results[0]

if best_name != current and best_delay < 800:
    request("/proxies/" + urllib.parse.quote(GROUP, safe=""),
            method="PUT", payload={"name": best_name})
    print(f"[OK] {current} -> {best_name}, {best_delay} ms")
else:
    print(f"[KEEP] {current}, best={best_name}, {best_delay} ms")

執行前請透過環境變數提供密鑰，而不是把密碼直接寫入程式：

# macOS / Linux
export CLASH_SECRET='你的API密鑰'
export CLASH_GROUP='Auto-Select'
python3 clash_switch.py

# Windows PowerShell
$env:CLASH_SECRET="你的API密鑰"
$env:CLASH_GROUP="Auto-Select"
python clash_switch.py

這個版本刻意保留幾個保守條件：沒有可用節點時不修改目前選擇；只有最佳延遲低於門檻時才切換；新節點與目前節點相同時不重複發送請求。正式使用時，建議加入「連續兩至三輪勝出才切換」的判斷，並為每個節點維護失敗次數。這比每五分鐘看到一個較低數字就立即換線更穩定。

依評分而不是單純延遲選擇

如果節點的延遲差距只有幾十毫秒，單純選最低值可能會造成頻繁跳轉。可以使用簡單評分模型：延遲低於 200 毫秒給予高分，200 至 500 毫秒給予中分，逾時直接淘汰；連續成功額外加分，連續失敗則扣分。對需要維持登入狀態的服務，還可以為目前節點加入穩定性加權，讓它在品質沒有明顯惡化時繼續使用。

4日誌、排程與復原機制

自動切換真正進入長期運作後，最重要的不是「能不能切換」，而是「出了問題能不能查清楚」。每次測試至少記錄時間、策略組、節點名稱、延遲、錯誤類型與是否發生切換。日誌可以先使用純文字或 JSON Lines，讓後續用 grep、PowerShell 或其他工具快速篩選。

2026-08-24T09:30:00+08:00 group=Auto-Select node=Japan-01 delay=182 action=keep
2026-08-24T09:35:00+08:00 group=Auto-Select node=Singapore-01 delay=145 action=switch
2026-08-24T09:40:00+08:00 group=Auto-Select node=Hong-Kong-01 error=timeout action=skip

排程方面，Linux 可以使用 systemd timer 或 cron，macOS 可以使用 launchd，Windows 則可使用「工作排程器」。建議先以十分鐘或十五分鐘執行一次，觀察一至兩天後再調整頻率。過短的間隔會增加測試流量，也可能讓節點供應商或目標服務看到大量重複探測請求。

必備的復原與降級策略

保留目前節點：測試全部失敗時不要清空策略組，也不要切換到未知節點。
設定冷卻時間：切換後至少等待一段時間，再評估是否需要再次切換。
限制切換次數：例如一小時內最多切換三次，超過後只記錄告警。
設定保底節點：所有候選節點都不理想時，切換到已知較穩定但速度普通的節點。
提供停用開關：以環境變數或檔案旗標暫停腳本，方便排查問題或進行人工維護。
保護密鑰：限制腳本檔案與日誌權限，避免 API 密鑰被寫入錯誤訊息或命令歷史。

不要忽略工作流風險

節點切換可能中斷 TCP 長連線、SSH 工作階段、下載工作或登入狀態。對這類流量，建議使用固定策略組，不要直接套用全域自動切換；先在非關鍵設備上觀察，確認復原機制有效後再擴大使用。

完成配置後，可以用人工方式模擬節點失效：暫時停用目前節點、降低測試門檻，或讓測試 URL 無法連線，觀察腳本是否會記錄錯誤、跳過失效節點並在恢復後重新納入評估。當你能回答「為何切換、切到了哪裡、何時恢復、失敗時保留什麼」這四個問題，這套 Clash API 自動化流程才算具備可維運性。

Clash API 的價值不只是遠端點擊切換按鈕，而是把節點選擇變成一個可觀測、可限制、可回復的工程流程。先從單一策略組與低頻排程開始，再逐步加入評分、告警和多工作流隔離，通常比一開始追求完全自動化更可靠。

立即免費下載 Clash，開啟流暢上網新體驗 →

Clash API 節點自動切換：打造可維運的腳本化方案