先分清 provider、代理群組與目前節點
proxy-providers 是節點集合的來源層，負責從遠端 URL、本機檔案或內嵌資料讀取代理條目；proxy-groups 才是決定如何選用節點的策略層，透過 use 引用 provider。使用者在介面中最後選到的，是具體節點或另一個子群組。
因此，provider 顯示更新完成，只代表檔案已取得並可解析，不代表每個伺服器都可達。群組完全沒有節點時，先看 use、名稱正規表示式與協定排除；節點存在但全部逾時，才查健康檢查端點、節點連通性與目前網路。
HTTP、file 與 inline 應該怎麼選
遠端訂閱一般使用 type: http，設定 url、快取 path 和更新 interval。type: file 只讀本機檔案，不會自動替你抓遠端內容；inline 則適合少量、穩定且自行維護的節點。
YAMLproxy-providers:
main-subscription:
type: http
url: "https://provider.example/sub?token=REDACTED"
path: ./providers/main.yaml
interval: 21600
proxy: DIRECT
size-limit: 10485760
proxy 指定更新請求使用的出口。如果訂閱站必須經代理才能存取，固定寫成 DIRECT 反而會失敗。每個 provider 也應使用獨立快取路徑，以免彼此覆蓋；size-limit 的單位是位元組，示例為 10 MiB，不能取代來源驗證。
用名稱正規表示式與協定類型篩選
filter 保留名稱符合正規表示式的節點，exclude-filter 排除特定名稱，兩者可放在 provider 或引用它的群組。provider 的 exclude-type 可排除其中的協定類型；代理群組雖有同名欄位，官方文件說明它只排除直接引入的出站代理，不會處理 use 帶入的 provider 節點。若同一份訂閱要建立日本、香港與工作用群組，可保留一個原始 provider，再分別套用名稱篩選。
YAMLproxy-groups:
- name: Japan
type: select
use:
- main-subscription
filter: '(?i)(日本|東京|大阪|japan|tokyo|osaka|\bjp\b)'
exclude-filter: '(?i)(到期|剩餘|官網|套餐)'
正規表示式比對的是節點名稱，不能證明伺服器實際位置。供應商改名後，原本的規則可能得到空集合；YAML 雙引號也會處理反斜線。先在測試群組逐步增加條件，是比一次改完所有群組更可靠的做法。
health-check 的結果該如何解讀
健康檢查會讓各節點存取指定 URL，並依延遲、逾時與預期 HTTP 狀態判斷可用性。常見欄位有 enable、url、interval、timeout、lazy 與 expected-status。端點要穩定、回應小，而且所有候選出口都能合理存取。
YAMLhealth-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 600
timeout: 5000
lazy: true
expected-status: 204
通過檢查只代表該節點當時能開啟測試 URL，不保證串流、遊戲或特定 API 可用。失敗也可能只是測試端點在某個出口受限。不要設過短間隔，否則大量節點會持續產生請求；啟用 lazy 後，首次使用閒置 provider 也可能需要等待。
依用途接入 select、url-test 或 fallback
provider 不會單獨決定流量。固定出口或會議可用 select 手動選擇；一般瀏覽可讓 url-test 依測試選擇；依序切換主備線路時可評估 fallback。群組自己的測試與 provider 健康檢查屬於不同層次。
| 使用情境 | 群組類型 | 主要風險 |
|---|---|---|
| 會議與固定 IP | select | 需人工確認節點 |
| 日常瀏覽 | url-test | 測試端點不代表所有服務 |
| 主備線路 | fallback | 切換可能中斷現有連線 |
建議保留一個沒有複雜篩選的「全部節點」群組作為基準。更新後若只有某個地區群組為空，就能快速把範圍縮小到該群組的正規表示式，而不是懷疑整份訂閱。
逐層驗證與排錯
- 手動更新 provider，確認時間、檔案大小與解析訊息。
- 在無篩選群組確認原始節點名稱與數量。
- 逐項加入包含、排除與協定條件。
- 觸發健康檢查，分清空群組、檢查失敗與業務不可用。
- 最後才調整群組類型和檢查間隔。
若回應其實是 HTML 登入頁、授權錯誤或空檔，應回到訂閱來源處理；若只有測試 URL 失敗，則換另一個穩定端點交叉驗證。欄位定義請以 官方 proxy-providers 文件及 proxy-groups 文件為準。
修改前保留可回復版本，並分別記錄「來源可更新、群組有節點、健康檢查通過、目標服務可用」。這四個結論分開後，日後供應商改名或節點輪換也比較容易定位。
官方來源與版本邊界
版本號、檔案名稱與介面文字可能隨專案更新而變動，操作前請以連結中的專案文件為準。