Clash協定與核心參考

01 · DECISION MODEL

先建立協定選擇架構

協定名稱不是速度排名

在 Clash Plus、Clash Verge Rev、FlClash 等用戶端中，節點旁顯示的 SS、VMess、Trojan、VLESS、Hysteria2 或 TUIC，首先代表用戶端與伺服器交換資料時採用的協定結構，而不是一份可以直接按速度排序的產品清單。一次連線的實際表現同時受到伺服器處理能力、線路往返時間、封包遺失率、壅塞程度、傳輸層、加密實作、用戶端核心與裝置效能影響。即使協定類型相同，兩個節點也可能因線路與伺服器負載不同而表現懸殊；反過來，不同協定在穩定網路中也可能帶來相近的網頁載入體驗。

因此，選擇協定應從「是否相容」開始，再考慮「是否適合目前網路」，最後才比較速度。相容性包括用戶端核心是否支援該協定、訂閱轉換過程是否保留必要欄位、傳輸層組合是否已實作，以及裝置系統能否正常建立 UDP 或 QUIC 工作階段。如果設定在匯入時就遺失關鍵欄位，後續測速便沒有意義。一般使用者優先採用訂閱提供方已驗證的完整設定，比手動將一種協定改成另一種更可靠；協定類型不能只修改名稱就完成轉換。

將影響因素拆成四個層次

第一層是基礎網路。固定寬頻通常延遲與封包遺失較穩定，TCP 類方案容易有平順表現；行動數據、公共 Wi‑Fi 或跨電信商鏈路可能出現瞬間封包遺失與網路切換，此時採用 UDP 且具備壅塞控制能力的 Hysteria2 或 TUIC 可能更具適應性，但前提是網路能穩定傳輸 UDP。第二層是伺服器與線路，同一協定若伺服器 CPU 飽和、出口壅塞或路由繞行，僅在用戶端更換參數並不能消除瓶頸。

第三層是協定與傳輸組合。VMess、VLESS 可搭配 TCP、WebSocket、gRPC 等傳輸方式，VLESS 也常與 TLS、REALITY 等安全層組合；SS 更接近精簡的加密代理結構；Trojan 依賴 TLS 語意；Hysteria2 與 TUIC 則建立在 QUIC 或 UDP 傳輸思路上。第四層是用戶端實作。mihomo 對較新的協定與規則能力涵蓋更完整，而較早的原版 Clash 設定能力有限。選擇協定時必須把這四層連在一起看，不能將網路問題、線路問題和核心問題全部歸因於協定名稱。

測試時記錄哪些項目

用戶端中的延遲測試通常只反映一次探測要求，不能完整代表長連線吞吐量與穩定性。更實用的測試應包含四項：首次開啟多個網站時的回應速度、持續下載一段時間後的吞吐量波動、影片或會議連線中的卡頓情況、裝置鎖定螢幕再喚醒後的恢復速度。每次只變更一個變數，例如固定同一網路與同一伺服器，再比較協定；或固定協定，比較 Wi‑Fi 與行動數據。若同時更換節點、網路、用戶端和協定，就無法判斷改善來自哪一層。

也應在記錄檔中確認失敗發生的位置。網域名稱解析錯誤、連線逾時、驗證失敗、TLS 交握錯誤、UDP 無法連線，分別指向不同問題。記錄檔顯示驗證失敗時，反覆切換全域模式無法解決問題；記錄檔顯示 DNS 解析異常時，更換協定也未必有效。關於記錄檔頁面與代理、設定頁面的對應關係，可繼續閱讀Clash Verge 介面功能速覽。建立這種分層檢查方式後，協定選擇才會從「嘗試哪個名稱」變成可重複、可核對的技術判斷。

03 · CURRENT OPTIONS

VLESS、Hysteria2 與 TUIC 的適用範圍

VLESS：分開理解驗證與加密層

VLESS 使用 UUID 等資訊表達用戶端身分，但協定本身不提供與 VMess 相同的內建加密思路，實際連線安全性通常由 TLS、REALITY 或其他外層機制承擔。理解 VLESS 時必須將協定、傳輸層與安全層分開：VLESS 決定部分驗證與轉送結構，TCP、WebSocket、gRPC 等決定承載方式，TLS 或 REALITY 決定相應的安全交握。用戶端清單只顯示 VLESS 時，仍需展開設定核對 network、tls、servername、reality-opts 和 flow 等欄位。

VLESS 設定中的 flow 並不是可以隨意填寫的效能開關。某些組合會使用特定流量控制值，用戶端、伺服器與底層實作必須一致；錯誤值通常會造成交握或資料傳輸失敗。REALITY 設定還可能包含 public-key、short-id 和 servername，這些欄位具有配套關係。訂閱轉換若改寫欄位名稱、刪除空值時誤刪必要參數，或舊版用戶端不認識相關結構，都會導致「節點存在但無法連線」。因此 VLESS 更適合由支援 mihomo 的現代用戶端完整匯入，而不是複製舊版 Clash 範例後手動拼接。

Hysteria2：面向高封包遺失鏈路的 QUIC 思路

Hysteria2 運作於基於 UDP 的 QUIC 傳輸之上，重點是利用現代壅塞控制與多路複用能力，適應延遲、抖動或封包遺失較明顯的鏈路。這不代表它在所有網路中都會更快：當 UDP 路徑穩定、伺服器頻寬充足且參數合理時，持續傳輸可能維持良好吞吐量；如果本地網路對 UDP 限速、路由品質不佳或中間設備頻繁回收 UDP 工作階段，則可能出現連線逾時、速度波動或待機恢復緩慢。

常見設定欄位包括伺服器位址、連接埠、驗證資訊、TLS server name、憑證驗證以及頻寬相關參數。頻寬值用於協助壅塞控制判斷傳送節奏，不是數字填得越大就能獲得越高速度。設定明顯高於實際線路能力時，可能造成排隊與封包遺失；設定過低則會限制吞吐量。較新的實作也可能依模式自動調整，使用訂閱下發的值通常比盲目修改更穩妥。若用戶端記錄檔顯示 UDP timeout，應先更換網路交叉測試，並確認系統防火牆、路由器與伺服器連接埠，而不是只反覆提高頻寬參數。

TUIC：低延遲工作階段與 UDP 傳輸

TUIC 同樣以 QUIC 和 UDP 為基礎，著重快速建立連線、多路複用與降低隊頭阻塞影響。設定通常包含 UUID、密碼、伺服器名稱、壅塞控制選項及 UDP 中繼模式等。不同實作或設定世代之間可能存在欄位差異，訂閱中的協定標識、版本語意與驗證結構必須與伺服器一致。mihomo 可以識別常見 TUIC 設定，但舊核心或舊版用戶端可能無法解析；匯入後被忽略不代表訂閱為空，也可能是核心不支援該節點類型。

TUIC 適合需要頻繁建立工作階段、網路品質存在波動且 UDP 可用的環境，但它不是 TCP 協定的全面替代方案。企業 Wi‑Fi、訪客網路、部分行動網路或嚴格設定的路由環境可能限制 UDP；此時 TUIC 與 Hysteria2 可能同時失效。實際設定中應保留 SS、Trojan 或其他 TCP 傳輸節點作為回退。對於語音、遊戲和即時通訊，還要區分「用戶端到伺服器使用 UDP」與「目標應用是否經由 UDP 轉送」這兩層，前者可用不代表後者的策略與規則一定正確。

proxies:
  - name: "VLESS-Reference"
    type: vless
    server: node.example.invalid
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    network: tcp
    tls: true
    servername: node.example.invalid

  - name: "Hysteria2-Reference"
    type: hysteria2
    server: node.example.invalid
    port: 443
    password: "your-password"
    sni: node.example.invalid

上方片段用於說明 mihomo YAML 中欄位的層級，位址、身分與密碼是明確的示例值，不能直接用於連線。實際訂閱可能採用不同欄位組合，例如 VLESS 增加 REALITY 參數，Hysteria2 增加連接埠範圍或頻寬設定。編輯設定後，應先使用用戶端的設定檢查功能，再觀察記錄檔是否出現 unsupported、missing field、authentication 或 handshake 等資訊。若設定來自訂閱，優先在訂閱來源修正，或使用明確支援目標格式的轉換方式，避免每次更新都覆蓋本地修改。

05 · MOBILE AND PLATFORM

行動裝置耗電、網路切換與平台差異

耗電量來自持續運作方式

行動裝置的耗電表現不能簡單等同於協定加密強度。影響耗電的主要因素包括無線模組保持活躍的時間、連線重建頻率、背景保活方式、資料傳輸總量、DNS 要求數量、規則比對負擔以及 CPU 處理時間。一個協定若能快速完成任務並讓無線模組回到低功耗狀態，即使瞬間 CPU 使用率略高，總耗電量也可能較低；另一個協定若在不穩定網路中持續重新傳輸或頻繁重新連線，即使單次處理較輕，也可能消耗更多電量。

SS 在設定簡單、鏈路穩定時通常具有較低的處理負擔。Trojan、VMess 或 VLESS 搭配 TLS 時會產生交握與加密成本，但長連線複用正常時，持續使用的差異可能並不顯著。Hysteria2 與 TUIC 需要維持 UDP 或 QUIC 工作階段，網路穩定時可以減少部分等待；當系統頻繁切換基地台、路由器回收 UDP 對映或背景策略限制活動時，工作階段重建可能增加喚醒次數。實際耗電結果還與 Android 廠商的背景限制、iOS 網路延伸機制及用戶端實作有關，不能僅根據協定名稱預判。

Android：背景策略與 VPN 服務

Android 用戶端通常透過系統 VPN 服務接管流量。Clash Plus、Clash Meta for Android、FlClash 與 Surfboard 的介面和功能範圍各不相同，但都會受到系統省電策略、背景活動權限和廠商程序管理影響。出現鎖定螢幕後斷流時，應先確認用戶端是否仍在執行、VPN 標誌是否保留、系統是否限制背景耗電，再檢查協定。若應用程式程序被系統停止，改用另一種協定通常無法解決根本原因。

在 Android 上還應注意 IPv6、私人 DNS、按應用程式代理和熱點分享。某些應用程式會直接使用 IPv6，若設定只處理 IPv4，可能表現為部分應用程式無法連線；私人 DNS 與用戶端 DNS 劫持策略並存時，解析路徑可能與預期不同。按應用程式代理會改變進入核心的流量範圍，測試協定時應確認目標應用程式確實包含其中。Hysteria2 或 TUIC 在行動數據上異常時，可切換至 Wi‑Fi 重新測試；若 Wi‑Fi 正常而行動網路持續逾時，應優先判斷 UDP 路徑與網路策略。

iOS：系統網路延伸功能與前後台切換

iOS 用戶端依賴系統提供的網路延伸能力，連線狀態、記憶體預算與背景行為由系統統一管理。本網站下載清單中的 iOS 首推用戶端為 Clash Plus，可從iOS 下載區進入 App Store。使用時應注意系統設定中的 VPN 狀態、用戶端設定是否啟用，以及切換 Wi‑Fi 與行動網路後是否自動恢復。iOS 不會向一般使用者公開與桌面系統相同的程序控制細節，因此排查重點是系統 VPN 狀態、設定記錄與網路切換結果。

行動裝置使用 UDP 類協定時，切換網路會改變本地位址與 NAT 對映。QUIC 具備處理連線變化的相關機制，但實際能否順利恢復仍取決於用戶端、伺服器與網路路徑。若切換網路後長時間無法恢復，可以在用戶端中斷後重新連線，並檢查記錄檔是否反覆出現 timeout；如果 TCP 類節點能立即恢復，而 UDP 類節點持續失敗，表示目前網路不利於 UDP 工作階段，應暫時使用 TCP 回退項。

桌面平台的差異重點

Windows、macOS 與 Linux 通常沒有手機電池和背景凍結問題，但系統代理、TUN 權限、防火牆與睡眠恢復更為關鍵。Windows 的部分應用程式可能不完全遵循系統代理，需要 TUN 模式或在應用程式內設定；商店應用程式還可能受到迴圈存取限制，可參考Windows UWP 應用程式迴圈存取限制排查。macOS 上應區分系統代理與虛擬網路介面，睡眠後若連線異常，可先重新啟動系統代理或 TUN。Linux 則要重點確認桌面代理設定、路由權限、systemd 服務狀態和 DNS 管理元件。

評估行動裝置耗電時，建議使用系統電池統計觀察完整使用週期，而不是盯著幾分鐘內的瞬間百分比。維持相近的螢幕使用時間、資料量和應用程式任務，分別測試候選協定。若某協定在訊號較差時導致裝置持續發熱、背景活動時間明顯增加或喚醒後反覆重新連線，應優先更換穩定節點或回退協定。耗電表現本質上是協定、網路、用戶端和系統排程共同作用的結果，選擇目標應是減少無效工作，而不是追求某個抽象的最低開銷標籤。

07 · SUBSCRIPTION

訂閱格式與設定相容性檢查

訂閱位址不等於固定格式

「訂閱連結」描述的是取得設定的方式，不代表回傳內容一定採用同一種格式。伺服器可能回傳完整 Clash YAML、只包含節點的 YAML、經過編碼的 URI 清單，或針對特定用戶端產生的設定。用戶端匯入時要先取得內容，再依回應格式解析。連結能在瀏覽器中開啟，只能說明伺服器回傳了資料，不能證明資料符合目前用戶端與核心的要求。

完整 Clash 或 mihomo 設定通常包含代理節點、策略組、規則、DNS 與連接埠設定；節點訂閱可能只有 proxies 資料，策略組和規則則由用戶端範本補充。URI 清單則使用 ss://、vmess://、trojan://、vless://、hysteria2:// 或 tuic:// 等形式分別表達節點。不同 URI 對複雜傳輸參數的表達能力與實作一致性不同，轉換過程中最容易遺失路徑、SNI、ALPN、指紋、REALITY 和壅塞控制欄位。

匯入前後的四次核對

第一次核對回應狀態。匯入失敗時先確認訂閱位址沒有多餘空格，存取時沒有回傳登入頁、錯誤頁或空白內容。第二次核對節點數量與協定類型，確認預期的 Hysteria2、TUIC 或 VLESS 節點沒有在解析階段消失。第三次核對關鍵欄位，選擇一個節點展開查看伺服器、連接埠、驗證、TLS 與傳輸設定。第四次核對策略組，節點成功解析後還要加入目前策略組，否則代理頁面可能仍只顯示舊節點。

訂閱更新是重新取得與合併的一個流程。若更新後本地修改消失，表示修改位於訂閱管理範圍內；應使用用戶端提供的覆寫或設定合併機制，而不是每次直接編輯產生的檔案。若更新後節點重複，可能是同時啟用了多個內容相同的訂閱，或舊設定沒有被替換。若更新時間正常但節點內容沒有變化，可查看記錄檔與回應快取，並確認訂閱服務確實回傳了新內容。更完整的入口操作與錯誤分類可參考Clash 訂閱連結匯入方法。

欄位遺失時如何定位

首先比較訂閱原始內容與用戶端匯入後的節點詳細資訊。若原始內容已缺少欄位，問題在訂閱產生端；若原始內容完整而用戶端缺失，問題可能在用戶端解析器、訂閱轉換或核心支援。VMess 和 VLESS 重點查看 network、servername、ws-opts、grpc-opts、reality-opts 與 flow；Trojan 重點查看 password、sni 和 TLS；SS 重點查看 cipher、password 與 plugin；Hysteria2 和 TUIC 重點查看驗證、SNI、壅塞控制與 UDP 相關選項。

其次查看設定檢查錯誤。YAML 對縮排敏感，清單項目、映射與字串層級錯誤會導致整份設定無法讀取。節點名稱包含冒號、井號或特殊字元時，使用引號可以減少歧義。布林值、數字和字串也不應混用，例如連接埠應維持數字語意，而 UUID、密碼和路徑通常作為字串。手動編輯後，先讓核心完成語法檢查，再啟動系統代理，避免將格式錯誤誤判為網路問題。

mixed-port: 7890
mode: rule

proxy-groups:
  - name: "協定選擇"
    type: select
    proxies:
      - "VLESS-Reference"
      - "Hysteria2-Reference"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,協定選擇
  - MATCH,協定選擇

這段設定展示策略組與規則如何引用節點名稱。引用名稱必須與 proxies 中完全一致，包括大小寫與空格；節點改名後，策略組中的舊名稱會失效。實際設定通常還包含 DNS、規則提供者與更多策略組，但排查時可以先縮小到最小結構，確認一個節點能建立連線，再逐步恢復其他部分。大段複製未知設定會同時引入多個變數，不利於判斷問題位置。

訂閱轉換的界線

轉換工具可以將一種容器格式改寫為另一種，但不能憑空補齊伺服器參數，也不能將協定本身轉換成另一種協定。它能做的是映射欄位、產生策略組、篩選節點與調整名稱。對新協定或擴充傳輸的支援取決於轉換器本身的實作；如果轉換器不認識某欄位，即使來源訂閱正確，輸出也可能不完整。涉及 VLESS REALITY、Hysteria2 或 TUIC 時，優先使用伺服器直接提供的 mihomo 格式，並在更新後抽查關鍵欄位。

遇到訂閱為空、格式無法識別或更新失敗時，可先查看常見問題中的安裝設定分類。排查順序應保持明確：位址可存取、回應內容正確、格式可識別、核心支援協定、關鍵欄位完整、節點進入策略組、連線記錄正常。依此順序逐層確認，比頻繁刪除用戶端和重新安裝更容易找到根本原因。