Profile 到底是什麼

很多人把「訂閱連結」和「設定檔」當成一回事,嚴格來說這兩者不完全等同。訂閱連結是一個 HTTP 位址,客戶端會定期向這個位址發起請求;回傳的內容才是真正的設定檔,通常是一份 YAML 格式的文字,業界習慣稱之為 Profile。客戶端把這份文字下載到本機、解析後載入執行,你在介面上看到的節點清單、代理群組切換按鈕、規則比對結果,全部來自這一份 YAML 的內容。

Profile 本質上只是一份結構化的文字設定,不神秘也不複雜,拆開來看只有三個核心段落在真正發揮作用:節點定義、代理群組編排、規則清單。剩下的欄位大多是連接埠、日誌等級、DNS 這類執行參數,理解了三大段落,基本就理解了 Profile 的運作方式。

節點、代理群組、規則:三大段落各管什麼

把一份 Profile 從上到下讀一遍,會發現內容基本按三個層級組織,層級之間是明確的引用關係,不理解這個引用鏈,後續的多設定管理和規則調整都會走彎路。

proxies:節點是什麼

proxies 段落列出所有可用的代理伺服器,每一條記錄包含伺服器位址、連接埠、加密方式、密碼或金鑰等連線參數,對應到某個具體的伺服器節點。這一層是最底層的「原材料」,不直接決定流量走向,只是宣告「有哪些伺服器可以用」。

proxy-groups:代理群組是什麼

proxy-groups 段落把上面宣告的節點組織成邏輯分組,常見的群組類型包括:

  • select——手動選擇群組,介面上能看到一排節點按鈕,點哪個用哪個;
  • url-test——自動測速群組,依延遲自動選出最優節點,通常配合定時探測週期;
  • fallback——故障轉移群組,主節點失效後自動切到備用節點;
  • load-balance——負載平衡群組,多個節點分攤流量。

代理群組之間還可以互相巢狀引用,比如一個「自動選擇」的 url-test 群組,可以作為另一個手動 select 群組裡的一個選項,這種巢狀是排查規則命中異常時最容易被忽略的一環。

rules:規則是什麼

rules 段落是一份從上到下逐條比對的清單,每條規則由比對條件和目標策略組成,格式類似:

DOMAIN-SUFFIX,openai.com,美国节点
DOMAIN-KEYWORD,github,自动选择
GEOIP,CN,DIRECT
MATCH,自动选择

比對條件常見的有 DOMAIN(精確網域)、DOMAIN-SUFFIX(網域後綴)、DOMAIN-KEYWORD(網域關鍵字)、GEOIP(依目標 IP 所屬地區)、IP-CIDR(依 IP 段),最後一條通常是 MATCH,代表「以上都不滿足時走這裡」的兜底策略。規則從上往下逐條比對,一旦命中就立即執行對應策略,不再往下繼續比對——這個「命中即停」的特性,是後面講規則互相覆蓋問題的關鍵前提。

Notice / 提示

規則裡填的「目標策略」必須是前面 proxy-groups 裡已經存在的群組名稱,或者是 DIRECT/REJECT 這兩個內建策略,寫錯群組名稱會導致該條規則直接失效或載入時報錯。

多個訂閱設定共存時的切換邏輯

隨著使用時間變長,大部分人手上不會只有一份訂閱。有的機場提供多條線路分別對應不同訂閱位址,有的使用者會同時保留一份日常使用的訂閱和一份用於特定情境的自訂規則訂閱。多份設定共存時,客戶端的處理方式大致遵循下面幾條邏輯。

設定是互斥載入,不是疊加載入

客戶端在某一時刻只會載入一份 Profile 進入執行狀態,切換設定本質上是「卸載目前設定、載入另一份設定」的過程,不是把多份規則疊加在一起同時生效。這一點很容易被誤解——有使用者以為新增了第二份訂閱之後,兩份設定的規則會合併生效,實際情況是切換後原來那份設定的節點、代理群組、規則全部被取代,不會保留任何交叉狀態。

切換時機與生效範圍

切換設定會重新建立代理群組和規則表,正在進行中的連線一般不會被中斷,但新發起的連線會立即依新設定的規則比對。如果切換後發現某個網站突然連不上,大概率是新設定裡對應網域的規則策略和舊設定不同,先檢查新設定的規則比對結果,而不是急著重新啟動客戶端。

自動更新與手動切換的界線

每份訂閱可以單獨設定自動更新間隔,自動更新只會刷新該訂閱自身的內容,不會影響你目前選中的是哪一份設定。也就是說,背景可以同時保持多份訂閱各自按週期更新,但介面上生效的始終是你手動選中的那一份,更新行為和切換行為是兩條獨立的邏輯線,互不觸發。

命名習慣:讓多設定不再混亂

設定一多起來,最先出問題的往往不是技術層面,而是「認錯設定」這種人為失誤——明明想切到工作專用的規則集,卻點成了另一份內容相近的訂閱。養成清晰的命名習慣,能省掉大量排查時間。

  • 依用途前綴命名:比如「日常-XX機場」「辦公-規則訂閱」「測試-自架節點」,一眼能看出設定的使用情境;
  • 標註更新週期或時效:如果某份訂閱是臨時用來測速的短期訂閱,命名裡加上日期或「臨時」字樣,避免長期混雜在正式設定清單裡;
  • 避免使用預設檔名:很多客戶端匯入訂閱後會自動產生類似「config.yaml」這樣的預設名稱,多份訂閱都叫這個名稱時幾乎無法區分,匯入後第一時間重新命名;
  • 記錄訂閱來源:如果客戶端支援備註欄位,把訂閱對應的服務商或用途寫進備註,半年後再看清單也能快速回想起來。

避免規則互相覆蓋的管理方法

「規則互相覆蓋」通常不是指兩份設定的規則真的合併衝突,而是指使用者在同一份設定裡做了手動追加或修改之後,下一次自動更新訂閱時,這些手動改動被伺服器回傳的新內容整體覆蓋,改動痕跡消失。這是多設定管理裡最容易踩坑的一點。

覆蓋發生的根本原因

大多數客戶端在更新訂閱時,會用遠端回傳的完整 YAML 內容整體取代本機檔案,而不是逐欄位合併。也就是說,如果你在本機手動往規則清單裡加了一條自訂規則,而這條規則不存在於伺服器回傳的原始訂閱裡,下一次自動更新一旦觸發,這條手動加的規則會隨著整份檔案被取代而消失,不會有任何提示。

三種規避方式

  1. 使用客戶端的「覆寫」或「額外規則」功能:部分客戶端支援在訂閱之外單獨維護一份本機覆寫檔案,更新訂閱時只取代訂閱本身的內容,本機覆寫部分獨立保留、單獨生效,這是最推薦的方式;
  2. 關閉該訂閱的自動更新,手動維護:如果這份設定需要頻繁手動調整規則,且服務商更新頻率不高,可以直接關閉自動更新,改動只會在你主動點擊更新時才被覆蓋,風險可控;
  3. 把自訂規則單獨存成一份設定,透過訂閱轉換工具合併:適合有一定動手能力的使用者,把手動規則維護成獨立的規則檔案,再透過訂閱轉換服務把原始訂閱和自訂規則拼接成新的訂閱位址,這樣每次更新拉取的就是已經合併好的內容,不需要在客戶端裡反覆手動補規則。
Notice / 注意

不確定客戶端是否支援本機覆寫功能時,先做一次手動改動測試:改完立即手動觸發一次「更新訂閱」,觀察改動是否被清空。確認行為之後再決定長期用哪種方式管理,比事後遺失規則再補救省心得多。

日常維護的幾個檢查動作

設定數量增多之後,建議養成幾個固定的檢查習慣,能在問題變大之前就發現異常:

  • 定期打開規則清單,確認最後一條 MATCH 兜底策略指向的代理群組符合預期,避免兜底策略被訂閱更新悄悄改動;
  • 切換設定後,用客戶端自帶的延遲測試功能刷新一次節點狀態,新設定裡的節點池和舊設定往往不完全一致;
  • 如果同時維護多份設定,每隔一段時間清理一次不再使用的舊訂閱,減少介面上誤切的機率;
  • 手動追加的規則,養成隨手記錄一份本機備份的習慣,即便使用了覆寫功能,也建議保留一份文字副本以防客戶端資料遺失。

理清節點、代理群組、規則三層結構的引用關係,再配合清晰的命名和恰當的更新策略,多設定共存並不會變成負擔,反而能讓不同情境的流量分流更精準、更可控。