先釐清訂閱網址、節點連結與設定檔
「訂閱」並不是單一檔案格式。使用者貼到用戶端的通常是一個 HTTPS 網址，用戶端向該網址發出請求後，伺服器才會回傳 Base64 文字、Clash YAML、JSON 或其他結構。網址只是取得內容的入口，回應本文的格式才決定用戶端能否解析。因此，同一個訂閱網址在瀏覽器中看似只是一串字元，交給不同用戶端卻可能出現「不支援的格式」、「設定解析失敗」，或匯入後沒有節點。
另一個容易混淆的概念是單一節點連結。以 ss://、trojan://、vmess://、vless:// 開頭的內容，通常只描述一個代理節點；訂閱本文則可能將數十個節點連結合併成一份清單。Clash 原生設定進一步加入代理群組、規則、DNS、監聽連接埠等欄位，已不只是節點集合，而是一份可直接驅動代理核心的完整設定。
| 內容形式 | 常見特徵 | 主要用途 | 能否直接保留規則 |
|---|---|---|---|
| 訂閱網址 | https:// URL，可能帶有驗證參數 |
定期擷取遠端內容 | 取決於伺服器回傳格式 |
| 單一節點 URI | ss://、trojan:// 等 |
分享單一節點的連線參數 | 不能 |
| Base64 節點集合 | 解碼後通常每行一個 URI | 批次分發節點 | 通常不能 |
| Clash YAML | 包含 proxies、proxy-groups、rules |
供 Clash 或相容核心載入 | 可以 |
| sing-box JSON | 包含 inbounds、outbounds、route |
供 sing-box 及相關用戶端載入 | 可以，但欄位架構不同 |
Clash YAML 與常見節點連結各自儲存哪些內容
Clash 設定由四類資訊組成
一份基礎 Clash 設定通常同時儲存監聽設定、節點、代理群組與分流規則。傳統 Clash 常見的本機混合連接埠是 7890，控制連接埠常見為 9090；這些數字只是常用預設值，用戶端也可能改用其他連接埠。節點位於 proxies，選擇、自動測速或故障轉移邏輯位於 proxy-groups，網域與網段的處理順序位於 rules。
mixed-port: 7890
mode: rule
proxies:
- name: "Tokyo-01"
type: trojan
server: edge.example.net
port: 443
password: "example-password"
sni: edge.example.net
proxy-groups:
- name: "節點選擇"
type: select
proxies:
- "Tokyo-01"
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,節點選擇
- GEOIP,CN,DIRECT
- MATCH,節點選擇這段範例說明了為什麼「將 Clash 轉成節點連結」通常會遺失資訊。Trojan URI 可以容納伺服器、連接埠、密碼、SNI 等連線參數，卻沒有統一位置儲存完整的 proxy-groups 與 rules。若轉換器只輸出單一節點 URI，代理群組的選擇邏輯、自動測速間隔及規則順序都會被捨棄。
節點 URI 之間也不是完全等價
- Shadowsocks：
ss://主要描述加密方式、密碼、主機與連接埠，外掛參數通常放在查詢字串中。 - Trojan：
trojan://主要描述密碼、伺服器、連接埠、TLS 主機名稱及選用的傳輸參數。 - VMess：常見分享形式會將一段 JSON 編碼後放入
vmess://，不同產生器對欄位命名與預設值的處理可能有所不同。 - VLESS：
vless://通常透過查詢參數攜帶security、type、sni、flow等資訊。 - Hysteria2 與 TUIC：取決於用戶端核心版本與欄位支援情況，舊版 Clash 核心通常無法完整識別，mihomo 的支援範圍較廣。
轉換時不能只看協定名稱，還要核對傳輸層、TLS、Reality、WebSocket 路徑、gRPC 服務名稱、UDP 與用戶端指紋等參數。協定相同但擴充欄位不同，轉換結果也可能只能「成功匯入」，實際連線仍會逾時。
訂閱轉換服務的實際工作流程
訂閱轉換不是簡單地修改副檔名。轉換程式會先取得來源訂閱，再判斷內容屬於 YAML、JSON、Base64 節點清單或數個明文 URI；接著將不同輸入解析成內部節點物件，執行篩選、重新命名與排序，最後依照目標用戶端的欄位規則重新序列化。若目標是完整 Clash 設定，還要套用代理群組與規則範本。
- 擷取來源內容：向訂閱網址發出 HTTP 請求，處理重新導向、壓縮回應與字元編碼。
- 識別輸入格式：檢查回應標頭、文字結構與協定前綴，而不是只依據 URL 檔名。
- 解析節點參數：將伺服器、連接埠、驗證、TLS 與傳輸層欄位整理成統一結構。
- 執行篩選：依據節點名稱、地區關鍵字或正規表示式保留及排除項目。
- 套用範本：產生代理群組、測速群組、規則提供器與預設兜底規則。
- 輸出目標格式：產生 Clash YAML、單一連結集合或其他用戶端可讀取的結構。
為什麼轉換後的節點數量會改變
數量減少不一定是網路故障。轉換器可能主動略過無法識別的協定、缺少必要欄位的節點或名稱重複的項目。例如來源訂閱包含 86 個節點，其中 8 個使用目標核心不支援的協定，3 個缺少連接埠，2 個在去重後合併，最後輸出 73 個節點是可以解釋的結果。較穩妥的檢查方式，是比較轉換記錄中的「讀取、略過、輸出」三組數字。
數量增加則常見於範本展開或訂閱合併。兩個來源訂閱分別有 40 和 35 個節點，合併後可能產生 75 個節點，但代理群組中的引用數量會更多，因為同一個節點可以同時出現在「手動選擇」、「自動測速」和「故障轉移」三個群組中。代理群組的引用數不能視為實際節點數。
用戶端 User-Agent 會影響回傳內容
部分訂閱服務會根據請求的 User-Agent 回傳不同格式。用戶端宣告為 Clash 時會取得 YAML，使用一般瀏覽器存取時則可能取得 Base64 文字或管理頁面。因此，瀏覽器中看到的內容與用戶端實際下載的內容不一致並不罕見。排查時應在用戶端記錄中確認回應狀態碼與解析錯誤，而不是只靠瀏覽器頁面判斷。
將其他格式轉換為 Clash 設定
只有節點連結時，需要補齊代理群組與規則
將一組 ss://、trojan:// 或 vless:// 連結轉換成 Clash YAML，第一步只是產生 proxies。如果設定沒有 proxy-groups，使用者就無法在介面中依群組選擇；如果沒有 rules，規則模式也缺少流量去向。最小可用範本通常至少包括一個手動選擇群組、一條區域網路直連規則和一條最終 MATCH 規則。
規則順序必須維持由具體到寬泛。DOMAIN,api.example.com,DIRECT 應放在 DOMAIN-SUFFIX,example.com,節點選擇 之前，而 MATCH 必須位於最後。若轉換工具重新排序規則，可能導致原本應直連的網域先命中後綴規則。
確認目標核心是傳統 Clash 還是 mihomo
「Clash 格式」本身也存在功能差異。傳統 Clash 設定常見的欄位不代表 mihomo 的全部功能；mihomo 增加或擴充了規則提供器、DNS、TUN、Sniffer 及新協定相關欄位。將 mihomo 設定匯入舊核心時，可能在不認識的代理類型或欄位處直接報錯，也可能忽略部分選用項目。
| 檢查項目 | 轉換後應核對的內容 | 常見現象 |
|---|---|---|
| 協定支援 | 目標核心是否能識別節點 type |
匯入失敗或節點未顯示 |
| TLS 參數 | sni、憑證驗證與指紋是否保留 |
握手失敗、連線逾時 |
| 傳輸層 | WebSocket 路徑、請求標頭、gRPC 服務名稱 | 連接埠可連通但代理無法使用 |
| 代理群組引用 | 群組內名稱是否與節點名稱完全一致 | 設定驗證提示找不到代理 |
| 規則提供器 | 遠端網址、行為類型、更新間隔 | 規則集下載失敗 |
| DNS 與 TUN | 位址段、監聽連接埠與網路介面設定是否衝突 | 啟用 TUN 後無法解析網域 |
從 Clash YAML 匯出其他格式時會遺失什麼
從完整 YAML 匯出為單一連結集合時，最先遺失的是全域設定。mixed-port: 7890、區域網路存取開關、執行模式、外部控制器、DNS 與 TUN 設定都不屬於單一節點 URI。接著遺失的是節點之間的組織關係，包括選擇群組、負載平衡群組、自動測速群組及其測試 URL、間隔與容差。
規則同樣無法自然附加到節點 URI 上。網域分流、IP 網段、程序名稱規則、規則提供器與最終兜底策略，必須由目標用戶端重新設定。若轉換目標是另一種完整設定格式，例如 sing-box JSON，轉換器可以嘗試對映這些結構，但雙方的路由語意並非逐項對應，仍需人工複核。
名稱與字元編碼也可能改變
- URL 片段中的空格、中文與符號需要進行百分比編碼，編碼錯誤會造成名稱截斷。
- Base64 可能使用標準字元集或 URL 安全字元集，填充符號處理錯誤會導致整筆記錄無法解碼。
- 同名節點在 Clash 代理群組中難以區分，轉換器通常會追加序號，這也會同步改變群組內引用。
- YAML 中含有冒號、井字號或前後空格的名稱應加上引號，否則可能被解讀為語法。
自建訂閱轉換服務的部署思路
自建服務的主要目的，是讓訂閱內容在受控環境內完成解析。部署位置可以是本機、家用伺服器或私有雲主機。無論採用哪種實作，都應將「轉換介面」和「管理介面」分開考量：前者處理來源網址與輸出格式，後者負責範本、篩選規則與執行記錄。
本機執行適合單人維護
本機服務可以只監聽迴路位址，例如 127.0.0.1:25500，避免同一區域網路中的其他裝置直接存取。用戶端訂閱網址指向本機介面，再由轉換程式取得遠端訂閱。這種方式不需要將來源訂閱提交到公開網站，但電腦休眠或服務停止時，用戶端自動更新會失敗。
伺服器部署需要限制存取範圍
伺服器方案方便多部裝置更新，但應啟用 HTTPS、介面驗證、請求大小限制與存取記錄輪替。若轉換介面允許任何使用者提交 URL，還要防止它被用來存取內部網路位址。至少應拒絕迴路位址、鏈路本地位址與私有網段目標，並限制重新導向後的最終位址。
快取策略也要謹慎。假設上游訂閱每 6 小時更新一次，可將轉換快取設為 15 至 60 分鐘，避免每次用戶端啟動都重複請求；但快取檔案中包含完整節點憑證，必須同時設定儲存權限與過期清理。記錄中不應記錄完整查詢字串，只保留請求時間、輸出類型、狀態碼與去識別化的工作識別碼即可。
範本應納入版本管理
轉換服務升級後，預設代理群組名稱或欄位行為可能改變。建議為範本保留明確版本，例如 clash-template-2026-05.yaml，每次修改先在測試設定中驗證，再替換正式範本。節點訂閱與規則範本分開儲存，可以避免上游更新時覆蓋本地分流邏輯。
轉換完成後的五步驗證
- 執行語法驗證：先在用戶端匯入但不要立即啟用，確認 YAML 縮排、重複名稱與代理群組引用沒有錯誤。
- 核對節點數量：記錄來源節點數、略過數與輸出數，重點查看不支援的協定及缺少必要欄位的項目。
- 測試單一節點：選擇一個已知可用的節點進行延遲測試，再存取 HTTPS 頁面確認 TLS 與傳輸參數正常。僅看到
80 ms或200 ms的延遲數值，不能取代實際連線測試。 - 檢查規則命中：開啟用戶端連線記錄，分別存取預期直連與代理的網域，確認命中的規則和代理群組符合範本設計。
- 驗證 DNS 與 TUN：先測試系統代理，再視需要啟用 TUN。若系統代理正常而 TUN 異常，應檢查 DNS 劫持、虛擬網路介面權限與路由衝突，不要直接歸因於節點轉換。
在桌面用戶端中，設定入口名稱會因版本不同而變化，常見路徑是「設定」→「訂閱」更新遠端檔案，再到「代理」選擇代理群組；部分用戶端會將更新週期放在「設定」→「參數設定」。更新後應確認目前啟用的設定確實已切換到新檔案，避免實際測試的仍是舊快取。
常見轉換失敗現象與排查順序
訂閱網址能開啟，但用戶端卻提示解析失敗
先確認回應是否為用戶端需要的格式。瀏覽器顯示正常網頁，只能說明 HTTP 請求成功；若回傳的是登入頁、額度提示或 HTML 錯誤頁，Clash 仍無法解析。接著檢查回應狀態碼、重新導向後的網域與內容開頭。YAML 中混入定位字元、縮排層級錯誤或引號未閉合，也會導致整份設定載入失敗。
可以匯入，但所有節點都逾時
全部逾時時，通常應優先檢查轉換參數，而不是逐一更換節點。核對伺服器位址、連接埠、TLS 的 sni、WebSocket 路徑、gRPC 服務名稱與 Reality 公鑰等欄位。如果來源格式使用了目標格式無法表達的擴充參數，轉換器可能輸出看似完整但無法連線的節點。
更新後原有規則與分組消失
這通常是將「節點訂閱」直接當成「完整設定」覆蓋了本機檔案。正確做法是讓遠端節點透過代理提供器載入，或在轉換階段固定套用本機範本。節點資料負責變動，規則與分組由範本維護；兩者分離後，上游更新就不會直接重寫本機分流結構。
節點名稱正常，但代理群組卻是空的
檢查代理群組是靜態列出節點名稱，還是透過提供器引用。靜態名稱必須逐字相符，包括空格、大小寫與轉換器追加的序號。使用正規表示式篩選時，也應確認地區名稱是否在重新命名步驟後改變。例如先將「Hong Kong」改成「香港」，原本只比對 Hong Kong 的篩選表示式就會得到空結果。
選擇轉換方式時的實際建議
如果訂閱提供者已提供 Clash 或 mihomo 專用網址，優先直接使用該格式，減少中間對映。只有在來源格式與目標用戶端不相容、需要合併多個來源，或確實需要自訂分組與規則時，才加入轉換步驟。轉換鏈路越長，排錯時需要檢查的快取、範本與欄位對映就越多。
臨時遷移少量節點時，可以在本機完成單一連結轉換；長期使用多個訂閱，適合建立固定範本並記錄轉換器版本；需要跨裝置自動更新時，可以部署具備驗證機制的私有服務。無論選擇哪種方式，最終判斷標準都不是「成功產生檔案」，而是語法可載入、節點參數完整、規則命中正確，且更新流程可以重複驗證。