sing-box 故障轉移與 Mihomo fallback：設定及切換驗證

sing-box 故障轉移倚靠 urltest 出站：它探測每個出口，把新連接交給當時最佳的健康出口；Mihomo 則提供 fallback 代理組，一律優先使用清單中第一個可用出口。本文為兩部由你擁有的出口分別設定這兩種方式，再說明如何量度切換時間、恢復後的表現，以及現有連接、DNS 及 UDP 會受甚麼影響。

關鍵要點

• 故障轉移只讓一個出口運作，檢查失敗時改用另一個；它不會增加頻寬。
• sing-box 的 urltest 按量得的延遲及容差揀選，而非按清單次序。
• Mihomo 的 fallback 按次序揀選第一個可用代理，首選出口恢復後會切回。
• 切換大約需要一個探測間隔加逾時時間，應實際量度而非假設。
• HTTP 健康檢查通過時，同一出口的 UDP 仍可能已經失效。

本文按文末官方來源整理，未完成完整端到端實測。前提是 Linux 客戶端執行 sing-box 1.14.3 或 Mihomo v1.19.32，並有兩個由你管理或已獲授權使用的可用代理出口。先參考自建清單規劃擁有權及復原方式。

sing-box 故障轉移與負載平衡有何分別？

故障轉移讓流量固定經一個出口，只有在它檢查失敗時才更換出口。負載平衡把連接同時分散到多個出口，鏈路聚合則把多條線路合併承載同一個流。鏈路聚合、負載分擔與故障轉移的比較解釋了為何只有聚合能提高單一連接的吞吐量。

工具及類型	如何揀選出口	首選出口恢復後
sing-box urltest	量得延遲最低者，以容差避免來回切換	只有恢復的出口快出容差以上才切回
sing-box selector	手動揀選，經 Clash API 控制	停留在你設定的出口
Mihomo fallback	按清單次序揀選第一個可用代理	第一個代理重新通過檢查後切回
Mihomo url-test	量得延遲最低者，附容差	與 sing-box urltest 相同

sing-box 的 urltest 出站以一個 URL 測試一組出站，預設每 3m 一次，容差 50 毫秒。［1］ 其 selector 出站只能經 Clash API 切換。［2］ Mihomo 的 fallback 組在目前節點逾時後，會按 proxies 的次序揀選第一個可用節點。［3］ 維護兩個出口代表維護工作加倍，如你的目標只是不斷線，請先權衡自建伺服器與託管 VPN。

步驟 1：準備兩個出口及一個健康檢查端點

你需要兩個互相獨立的出口，這裏用兩部 Shadowsocks 2022 伺服器：203.0.113.10（出口 A）及 198.51.100.20（出口 B），各自使用獨立密鑰。它們應位於不同數據中心或不同服務商，否則一次故障會令兩者同時失效。分組前，先確認每個出口單獨都可用。

兩種工具都會經每個出口請求一個 URL。url 留空時，sing-box 會使用 Google 的 generate_204 地址。［1］ 請改用由你控制的端點，例如 https://check.example.net/generate_204，再加一條傳回請求者地址的路徑，例如 /ip。由多個出口每分鐘探測第三方服務，應遵守該服務的條款；自己的端點亦會留下日誌，可確認每次探測來自哪個出口。

步驟 2：設定 sing-box urltest 作故障轉移

如尚未安裝 sing-box，sing-box Linux 客戶端教學介紹了如何安裝固定版本及執行本機監聽。把以下內容儲存為私人檔案 failover.json：

{
  "log": {"level": "warn"},
  "inbounds": [{"type": "mixed", "tag": "local", "listen": "127.0.0.1", "listen_port": 1084}],
  "outbounds": [
    {
      "type": "urltest",
      "tag": "auto-exit",
      "outbounds": ["exit-a", "exit-b"],
      "url": "https://check.example.net/generate_204",
      "interval": "1m",
      "tolerance": 300,
      "interrupt_exist_connections": true
    },
    {"type": "shadowsocks", "tag": "exit-a", "server": "203.0.113.10", "server_port": 8388,
     "method": "2022-blake3-aes-128-gcm", "password": "REPLACE_KEY_A"},
    {"type": "shadowsocks", "tag": "exit-b", "server": "198.51.100.20", "server_port": 8388,
     "method": "2022-blake3-aes-128-gcm", "password": "REPLACE_KEY_B"}
  ],
  "route": {"final": "auto-exit"}
}

interval 愈短，愈早發現故障，代價是探測次數增加。在 sing-box urltest 設定中，較大的 tolerance 可避免在兩個延遲相近的健康出口之間來回切換，這對不喜歡地址改變的工作階段尤其重要。interrupt_exist_connections 會在所選出站改變時關閉入站連接，內部連接則一律會被中斷。［1］ 如你寧願讓舊連接自然失敗，便保持 false。

以固定版本的執行檔執行 sing-box check -c failover.json 檢查。檢查通過只表示語法正確，並不代表任何一個出口可用。

步驟 3：設定 Mihomo fallback 代理組

使用 Mihomo 時，在獨立目錄內儲存一個私人 config.yaml：

mixed-port: 7891
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: warning
external-controller: 127.0.0.1:9090
secret: "REPLACE_LONG_RANDOM_SECRET"
proxies:
  - {name: exit-a, type: ss, server: 203.0.113.10, port: 8388, cipher: 2022-blake3-aes-128-gcm, password: "REPLACE_KEY_A", udp: true}
  - {name: exit-b, type: ss, server: 198.51.100.20, port: 8388, cipher: 2022-blake3-aes-128-gcm, password: "REPLACE_KEY_B", udp: true}
proxy-groups:
  - name: failover
    type: fallback
    proxies: [exit-a, exit-b]
    url: https://check.example.net/generate_204
    interval: 60
    timeout: 5000
    lazy: false
rules:
  - MATCH,failover

Mihomo fallback 代理組只檢查自己 proxies 欄位內的代理；interval 以秒計，timeout 以毫秒計，lazy 預設為 true，未被選用的組不會測試。［4］ 設為 lazy: false 後，組在閒置時亦保持測試，流量開始時已有最新結果。max-failed-times（預設 5）會在連續失敗後觸發一次強制健康檢查。［4］ 2022 加密方式的名稱取自 Mihomo 的 Shadowsocks 參考文件。［5］

保持 allow-lan: false 及 bind-address: 127.0.0.1，其他裝置便無法使用這個端口。［6］ 控制器可讀取組的狀態，請按保護 Mihomo 控制器 API 的方法加以保護。

步驟 4：執行客戶端並觀察目前出口

每次只在前台執行一種工具，讓測試終端機使用它的本機端口（sing-box 為 1084，Mihomo 為 7891）。Mihomo 可經 API 讀取組目前的揀選，API 接受 Bearer 密鑰：［7］

curl -s -H "Authorization: Bearer $MIHOMO_SECRET" http://127.0.0.1:9090/proxies/failover

回應會註明組目前使用的代理。sing-box 則把 /ip 端點傳回的地址與每個出口已知的出口地址比對。在設定了同一本機端口的瀏覽器中，IP 地址查詢工具應顯示出口 A 或出口 B，而絕不是你自己的網絡。

如何量度切換時間及恢復表現？

經本機端口執行一個附時間戳記的探測循環，然後在維護時段停止出口 A 上的代理服務。不要停掉其他人依賴的共用伺服器。

while true; do
  printf '%s ' "$(date +%T)"
  curl -s -m 5 --proxy socks5h://127.0.0.1:1084 https://check.example.net/ip || printf 'FAIL'
  echo; sleep 2
done

檢查方法	預期現象	不符時的處理
兩個出口都正常	循環穩定顯示同一個出口地址	地址在兩個出口之間來回轉：調高 sing-box 容差
停止出口 A 的代理服務	先出現 FAIL，約一個間隔加逾時後變成出口 B 的地址	組一直不切換：確認經出口 B 能存取探測 URL
恢復出口 A，Mihomo fallback	下一次檢查成功後切回出口 A	停留在 B：檢查清單次序及 lazy: false
恢復出口 A，sing-box urltest	除非 A 快出容差以上，否則停留在 B	頻繁切換：容差相對延遲差距太小
兩個出口都停止	所有請求失敗	請求仍然成功：流量繞過了這個組

記錄由停止出口 A 到第一次經出口 B 成功的時間。這段間隔才是真實的切換延遲，而非設定中的間隔值。請多重複幾次，因為探測計時器與你停止服務的時刻並不同步。

DNS、UDP 及現有連接會怎樣？

已開啟的 TCP 連接留在最初使用的出口。出口失效時它們會斷開；sing-box 啟用 interrupt_exist_connections 時則會提早關閉。兩種情況下應用程式都必須重新連接。新連接則使用組在那一刻揀選的出口。

健康檢查是 HTTP 請求，只經每個出口驗證了 TCP。一個出口可能通過檢查，但 UDP 轉發被封鎖或已損壞，此時以 UDP 運作的應用程式會失敗，卻不會觸發切換。請分別經每個出口測試 UDP 工作；在 Mihomo，如你寧可封鎖 UDP 也不想讓它走不可靠的路徑，可使用組的 disable-udp 選項。［4］

DNS 行為取決於模式。在 FakeIP 模式下，客戶端為應用程式分配合成地址，真正的解析稍後經所選出口完成；FakeIP 與 redir-host 的比較解釋了為何切換後可能留下看似過時的快取對應。切換後某個網站一直無法開啟時，請清除應用程式快取或重新啟動應用程式。

如何回退？

保留每個出口各自的設定。回退時停止故障轉移客戶端，恢復應用程式原來的代理設定，再經單一出口發出一次新請求確認。按你的時間表刪除測試端點的探測日誌，並更換測試期間貼到共用終端機的任何密鑰。

總結

• 想要最快的健康出口便用 sing-box urltest，想要固定的優先次序便用 Mihomo fallback。
• 刻意設定探測間隔、逾時及容差，並探測由你控制的端點。
• 實際量度切換間隔及恢復表現，不要只依賴設定值。
• 另行檢查 UDP 及 DNS，因為 HTTP 健康檢查涵蓋不到它們。

常見問題

sing-box 有否像 Mihomo 那樣按次序回退的類型？

文件中的 urltest 出站按量得延遲及容差揀選，而不是按清單次序。需要固定優先次序時，請使用 Mihomo 的 fallback 組，或手動切換 selector。

sing-box 故障轉移需要多久才會切換？

預計最多約一個測試間隔加上探測本身所需的時間，視乎故障在哪個時刻發生。請以附時間戳記的循環實測，不要只相信設定中的數值。

故障轉移能保住我的視像通話或下載嗎？

通常不能。現有連接會留在失效的出口或被關閉，應用程式必須經新出口重新連接，才能繼續原來的工作階段，中間的中斷無法完全避免。

為何健康檢查通過了，UDP 仍然不通？

因為檢查是以 TCP 傳送的 HTTP 請求。它只證明經該出口的 TCP 轉發正常，並不能證明 UDP 轉發或 QUIC 流量獲准通過。

健康檢查應否使用公共 URL？

可以使用，但自己的端點能避免依賴他人的服務及其條款，而且它的日誌會顯示每次探測來自哪個出口，排查時更直接。

兩個出口採用負載平衡，會否比故障轉移更好？

視乎你的目標。負載平衡把連接分散到多個出口，但不能加快單一流，亦可能令期望固定地址的服務感到混亂，增加排查難度。

為何 Mihomo 在第一個出口恢復後會切回？

fallback 類型一律優先使用清單中第一個可用代理。第一個出口一旦重新通過健康檢查，新連接便會回到它上面，現有連接則不受影響。

免責聲明: 本文僅供一般資訊參考，不構成法律、技術或其他專業建議。我們不保證內容的準確性、完整性或時效性。

來源:

1. sing-box: URLTest outbound — https://sing-box.sagernet.org/configuration/outbound/urltest/
2. sing-box: Selector outbound — https://sing-box.sagernet.org/configuration/outbound/selector/
3. Mihomo wiki: Fallback proxy group — https://wiki.metacubex.one/en/config/proxy-groups/fallback/
4. Mihomo wiki: Proxy groups — https://wiki.metacubex.one/en/config/proxy-groups/
5. Mihomo wiki: Shadowsocks proxy — https://wiki.metacubex.one/en/config/proxies/ss/
6. Mihomo wiki: General configuration — https://wiki.metacubex.one/en/config/general/
7. Mihomo wiki: API — https://wiki.metacubex.one/en/api/

Sources checked 2026 年 10 月 14 日。

延伸閱讀：

• 鏈路聚合、負載分擔與故障轉移
• 在 Linux 架設 sing-box 本機代理
• Mihomo 的 FakeIP 與 redir-host