本文目錄
「自動」可能是追延遲，也可能是保主線路
url-test 和 fallback 都會做健康檢查，但決策目標不同。url-test 比較候選節點的探測延遲，選擇滿足條件的較低結果；fallback 按設定順序使用第一條可用節點，目前項失效才往後切。
前者適合一組同等節點中偏向較低延遲，後者適合「主線路優先、備用線路兜底」。如果只是想自己點節點，用 select；想把連線分攤到多條線路，則是 load-balance，不能拿 fallback 代替。
策略群組先按意圖選
| type | 它怎麼決定 | 適合情境 |
|---|---|---|
| select | 由使用者手動選擇 | 疑難排解、固定帳號出口、重要長連線 |
| url-test | 根據健康檢查延遲選擇 | 同等級節點的日常自動選擇 |
| fallback | 按清單順序選第一條可用項 | 主備切換，優先級明確 |
| load-balance | 按策略把連線分給多項 | 用於併發分流，不負責故障轉移 |
自動組只能在候選項裡選擇，壞名單不會自動變好
建立自動組前，先用 select 固定候選節點，各完成一次實際請求。協議不受目前核心支援、訂閱已經失效或在本機網路完全不可達的節點，應先移出候選；否則健康檢查會一直發生錯誤，日誌也被無用結果淹沒。
節點可以直接寫進 proxies，也可以透過 use 引用 proxy-providers。provider 更新後新節點會進入候選範圍，因此要留意名稱過濾、地區篩選和空清單；組本身顯示存在，不代表裡面實際有專案。
候選清單具備的條件
- 每個節點在固定選擇下完成過實際請求
- 節點名稱能區分地區或線路，不是大批同名項
- provider 目前更新成功且篩選後不為空
- 重要帳號需要固定出口時另留 select 組
測試 URL 決定「可用」是什麼意思
健康檢查會讓每個候選節點存取 url 指定的位址。位址本身不穩定、在某些地區被拒絕，或必須登入，整組結果都會失真。通常選擇穩定、回應很小、無需帳號的 HTTPS 位址，例如回傳 204 的探測頁。
測試 URL 最好和日常存取內容接近，但不要使用帶個人 token 的 API，也不要給第三方網站製造高頻請求。同一個節點探測成功，只能說明這個 URL 在當時可達，影片、AI 串流回覆和 UDP 仍要在對應應用裡驗證。
proxy-groups:
- name: 自动选择
type: url-test
include-all: true
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
lazy: trueinterval、tolerance、lazy 決定它會不會頻繁折騰
- interval
- 兩次健康檢查的間隔，單位為秒。太短會增加流量和伺服器端壓力。
- tolerance
- url-test 的延遲容差，單位為毫秒。差距不明顯時保留目前選擇，可減少來回切換。
- lazy
- 組沒有被使用時減少或停止主動檢查，適合不是一直使用的策略群組。
- timeout
- 某些設定可設單次探測等待時間。太短會把偶發慢回應當作不可用。
沒有一組參數適合所有網路。家庭網路穩定但節點延遲接近時，可以用較長 interval 和適度 tolerance；移動網路頻繁切換，也不應把間隔壓到幾秒，因為出口反覆變化會中斷登入和串流連線。
修改後觀察一段實際使用。如果 Connections 中的節點幾分鐘內來回變化，而各候選只差幾十毫秒，先增大 tolerance 或 interval，而不是繼續增加節點。
fallback 的清單順序就是主備優先級
fallback 不會因為第二條延遲更低就跳過去。只要第一條透過健康檢查，它就繼續使用第一條；第一條不可用，才選擇後面的可用項。因此設定順序應體現業務偏好，例如穩定主線在前、成本更高或地區不同的備用線在後。
proxy-groups:
- name: 主线路
type: select
include-all: true
filter: "(?i)主线"
proxies: [DIRECT]
- name: 同区备用
type: select
include-all: true
filter: "(?i)同区备用"
proxies: [DIRECT]
- name: 异区备用
type: select
include-all: true
filter: "(?i)异区备用"
proxies: [DIRECT]
- name: 主备线路
type: fallback
proxies: [主线路, 同区备用, 异区备用]
url: https://www.gstatic.com/generate_204
interval: 300
lazy: true主線路恢復後，fallback 會在後續健康檢查中重新判斷。切回時已有連線不一定遷移，新請求才更容易看到新出口；帳號背景和長下載仍應考慮使用固定 select，避免出口變化影響會話。
地區內選快、地區間主備，可以用兩層組表達
候選很多時，不必把所有節點塞進一個 url-test。可以為每個地區分別建立 url-test，再把這些地區組按優先級放進 fallback。這樣「地區內挑延遲」和「地區間保主備」各做一件事，Connections 也能顯示請求經過了哪些組。
層級越多，空 provider、循環引用和同名組越難發現。兩層已經能表達目標就不要加第三層；每個下層組都應單獨可用，再交給上層。
proxy-groups:
- name: 香港自动
type: url-test
include-all: true
filter: "(?i)香港|HK"
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
- name: 日本自动
type: url-test
include-all: true
filter: "(?i)日本|JP"
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
- name: 地区主备
type: fallback
proxies: [香港自动, 日本自动]
url: https://www.gstatic.com/generate_204
interval: 300驗證 url-test 看選擇過程，驗證 fallback 看切換順序
不干擾日常會話的驗證方法
新增或使用獨立測試組
不要在正在下載、開會或登入重要帳號時試切換。
手動觸發一次健康檢查
記錄每個候選的結果和目前選中項。
讓瀏覽器走該策略群組
Connections 應顯示上層組、下層節點和實際出口。
觀察下一輪檢查
url-test 看容差內是否保持，fallback 看清單前項是否優先。
測試 fallback 時，可以把一條已經確認失效、且不含敏感資訊的測試節點臨時放在最前，只在獨立組裡觀察它是否跳到第二項；完成後立即移除。不要透過斷網、關係統代理或破壞生產設定來製造故障，那會同時改變太多變數。
自動組不工作，錯誤通常出在名單、探測或引用
組顯示空白
檢查 proxies / use 引用、provider 更新時間和節點篩選結果。
全部候選 Timeout
單獨測試 health URL，再比較目前網路與實際節點請求。
url-test 一直在兩條節點間切換
增加 tolerance 或 interval，並確認探測位址穩定。
fallback 總選第二項
第一項沒有透過健康檢查；查看它的具體錯誤而不是調順序。
切換後帳號頻繁重新登入
把敏感會話放進固定 select 組，避免自動變更出口。
provider 更新後組突然為空
核對過濾表達式和新節點名稱，舊快取可能掩蓋此前問題。
用實際請求判斷自動組是否值得保留
把目標服務的規則指向自動組，連續完成幾次網頁、串流回覆或下載。Connections 應顯示預期的上層組和具體節點；url-test 不應因微小延遲差頻繁跳動，fallback 應在主線路可用時保持第一項。
若健康檢查全綠而原業務仍失敗，固定目前節點重測，並回到協議、DNS 或目標服務。自動組值得保留的標準很簡單：業務穩定，出口變化可以解釋，主備順序符合預期。只有探測頁變綠，不算完成設定。