Clash 設定檔與訂閱

Profile、設定檔與訂閱連結

Clash 用戶端中的 Profile，通常是指一份可供核心載入的設定，以及相關的管理紀錄。設定內容多採用 YAML 格式，常見副檔名為 .yaml 或 .yml。管理紀錄則可能包含顯示名稱、訂閱網址、自動更新時間等資訊；這些紀錄不一定會寫在設定內容中。

訂閱連結是取得內容的入口，並不是代理節點本身。用戶端連線至網址後，伺服器可能回傳完整的 Clash 設定，也可能只提供節點清單。成功匯入只代表用戶端取得了可辨識的內容，不能只憑這個狀態判斷節點可用、規則正確或流量已經經過代理。

三大區塊如何串接

閱讀設定時，可以先從流量出口的引用關係著手：proxies 定義節點，proxy-groups 將節點或其他策略組成群組，rules 則決定連線交由哪個出口處理。有些設定也會透過 proxy-providers 引入節點，因此本機的 proxies 為空不一定代表故障。

proxies：節點連線參數

每個節點通常包含 name、type、server、port，以及協定所需的驗證與傳輸欄位。節點名稱是後續引用時使用的識別名稱。修改名稱後，必須同步更新策略群組中的引用；只改一處，可能會在載入時出現找不到代理的錯誤。

節點的出口地區、驗證資訊與伺服器端連接埠由服務提供者決定。不要把用戶端的本機監聽連接埠填成節點的伺服器端連接埠，也不要只憑名稱判斷協定。名稱中的「香港」或「備用」只是標籤，不會影響連線協定的選擇。

proxy-groups：手動選擇與自動選擇

• select：手動選擇成員，適合需要明確固定出口的情境。
• url-test：依指定探測網址的測試結果自動選擇。測試結果不等於檔案下載速度。
• fallback：依成員順序檢查可用性，優先使用排在前面的可用成員。
• load-balance：依支援的策略分配連線，不代表能直接累加單一下載連線的頻寬。

規則引用的是策略群組名稱，而不是「目前滑鼠選取的節點」。例如規則指向「網頁出口」群組，就應檢查該群組及其下層群組的實際選擇。只在另一個無關的策略群組切換節點，不會改變該規則的出口。

rules：由上而下比對

常見規則包括精確網域比對 DOMAIN、網域後綴比對 DOMAIN-SUFFIX、IP 網段比對 IP-CIDR，以及放在最後兜底的 MATCH。在規則模式下，通常由第一條符合的規則決定流量去向；具體規則應放在較寬泛的規則之前，並將 MATCH 放在最後。

DIRECT 與 REJECT 是內建出口，分別代表直連與拒絕。規則最後一欄也可以填入已定義的策略群組名稱。名稱必須完全一致，包括空格、大小寫與標點；外觀相似的全形逗號不能取代規則中的半形逗號。

以最小設定檢查 YAML 結構

以下是用來理解結構的直連範例。範例沒有遠端代理節點，不能用來連線至遠端代理服務。HTTP 與 SOCKS 共用的監聽連接埠設為 7890，並關閉區域網路存取，再透過一個手動群組連接規則與內建直連出口。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 手動出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手動出口

1. proxies: [] 表示這個區塊沒有定義節點。策略群組仍可引用內建的 DIRECT。
2. DOMAIN-SUFFIX,example.com,DIRECT 會比對範例網域及其子網域，用來說明語法，不代表任何服務的實際分流需求。
3. 192.168.0.0/16 是私有 IP 位址範圍；no-resolve 表示不為這條 IP 規則主動觸發網域解析。
4. 未符合前面規則的連線會交由「手動出口」處理；本例中的群組只有直連成員。

YAML 縮排請使用空格，不要使用 Tab。此範例每層縮排兩個空格。鍵名後的冒號與值之間要保留空格；名稱包含 # 等特殊字元時，應以引號括住。排查問題時，先查看記錄指出的行號，再檢查前一行的縮排與引號是否成對。

匯入訂閱與首次驗證

以 Clash Verge Rev 常見介面為例，先進入「訂閱」，將服務提供者給的完整訂閱網址貼到訂閱連結欄位，再執行匯入。不同版本的按鈕文字可能不同，但要區分「新增訂閱」、「更新內容」與「啟用設定」這三個操作：新增訂閱不代表已切換目前執行中的設定。

1. 確認回應格式。使用服務提供者標示為 Clash 或 mihomo 的訂閱入口。如果下載結果是登入頁面、錯誤訊息或一串編碼後的節點網址，請勿直接當成完整 YAML 使用。
2. 為 Profile 命名。匯入後立即設定容易辨識的本機名稱，並確認清單中能區分不同來源。
3. 啟用目標設定。選取該 Profile，等待核心載入完成。若出現錯誤，先查看記錄，不要反覆匯入同一個網址，以免產生重複項目。
4. 檢查策略群組。進入「代理」，確認預期的群組存在、群組內有可選成員，再選擇所需的出口。
5. 驗證流量接管。先選擇一種接管方式，例如系統代理；接著開啟目標應用程式建立新連線，並在連線記錄中檢查規則與出口。

如果實際混合連接埠是 7890，可在終端機執行以下指令，明確指定 HTTP 代理，協助區分「應用程式未使用系統代理」與「代理本身無法使用」。這個指令只會測試這次請求是否經過本機代理，不能證明 TUN 或其他應用程式已正常接管。

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/

連接埠不同時，請使用實際值。若連線遭拒，先檢查用戶端是否正在執行，以及連接埠是否正在監聽；若已連上本機代理，但遠端請求失敗，再檢查節點驗證、目標網站與 DNS 記錄。不要把所有錯誤都歸因於訂閱失效。

多組訂閱的命名與切換

多數桌面用戶端可儲存多個 Profile，但核心通常只會載入一份最終執行設定。儲存三組訂閱，不代表三組規則會自動合併。切換 Profile 通常會替換節點、策略群組與規則；用戶端的全域設定與覆寫功能則可能持續生效。

名稱標示來源，備註記錄用途

• 工作主用：儲存日常工作設定，並在備註中記下所需的策略群組與分流需求。
• 家庭備用：儲存另一個來源，主用設定無法使用時再手動切換，避免與主用設定合併成同一筆更新紀錄。
• 本機規則測試：複製設定後再修改規則，避免直接覆蓋仍可使用的遠端訂閱。

不要在 Profile 名稱中填入完整訂閱網址或權杖。名稱可能出現在截圖、記錄與螢幕分享中。備份時也要確認備份包含哪些用戶端紀錄：只匯出 YAML，不一定會包含遠端網址、排程工作與策略群組先前的選擇。

切換後的四項檢查

1. 確認目標 Profile 上顯示已啟用，且記錄中沒有載入失敗訊息。
2. 重新檢查規則引用的策略群組，不要假設上一份設定的選擇會保留到新設定中。
3. 維持系統代理或 TUN 的預期狀態，避免同時修改接管方式與訂閱，讓問題難以定位。
4. 關閉並重新建立目標應用程式的連線，再檢查新連線的出口；既有長連線不一定會立即切換到新節點。

若要同時使用多個來源的節點，應考慮 proxy-providers 或用戶端明確支援的彙整機制，而不是直接串接兩份 YAML。重複的頂層鍵、同名節點與策略群組都可能造成解析錯誤或引用不明。完整設定訂閱也不一定能直接當作 provider 的節點資料使用，需先確認回傳格式。

更新間隔與本機修改的保存方式

「更新訂閱」和「測試節點」是不同工作：前者取得遠端內容，後者測試現有節點。提高更新頻率不會自動降低延遲，也不會讓失效的帳號恢復可用。對於變動不頻繁的來源，可先設定為每天更新一次，再依服務提供者的要求調整。

遠端更新通常會取代下載回來的設定內容。若直接在遠端檔案中加入自訂規則，下次更新時可能會遺失。需要長期保留的修改，應放入用戶端支援的覆寫或合併機制；若只想離線測試一次，可另存為本機 Profile，並留意它不會再自動隨遠端更新。

覆寫也要確認合併方式。規則清單是附加在後、置於前方，或整份取代，取決於用戶端的實作。若自訂規則被附加在 MATCH 之後，就不會如預期般比對。儲存後應檢查最終規則順序，而不只是確認編輯器中有那一行。

匯入失敗與設定失效的排查順序

下載失敗：檢查網址與取得方式

保留訂閱網址原有的查詢參數，不要漏掉權杖，也不要把通訊軟體附帶的句號一併複製。HTTP 狀態碼 401 或 403 通常與驗證或存取限制有關；429 表示請求受到頻率限制，應停止反覆重新整理。若必須透過代理才能更新訂閱，請先保留一份可用設定，避免陷入「沒有節點就無法下載節點」的循環。

解析失敗：檢查格式與核心相容性

遇到 YAML 錯誤時，先確認回應內容不是 HTML，再檢查縮排與冒號。若出現不支援的代理類型或欄位，請核對目前使用的核心與服務提供者要求，不要為了消除錯誤而隨意刪除驗證欄位。若設定載入成功，卻找不到群組成員，請檢查節點名稱、provider 引用與群組名稱是否一致。

載入成功但無法連線：檢查實際出口

先確認出口模式是否為 rule。若目前使用全域模式或直連模式，觀察到的路徑可能與設定中的規則路徑不同。接著檢查連線記錄中的命中規則、策略群組與目標網址；必要時可用前述明確指定代理的請求進行比對。DNS、系統代理與 TUN 的進階設定請參考進階原理；基礎接管步驟請參閱系統代理說明。

穩妥的管理順序是：先保留可用的 Profile，再匯入新來源；先驗證規則與出口，再安排更新；長期修改則放入可維護的覆寫層。每次只變更一個環節，才能判斷問題出在下載、解析、選擇還是流量接管階段。