Clash 協定與核心技術參考

一、先建立協定選擇方法

協定、傳輸層與用戶端不是同一層

Clash 用戶端的代理項目通常同時包含協定類型、伺服器位址、連接埠、身分憑證、傳輸方式及多項擴充參數。介面上看到的「VLESS」、「Trojan」或「hysteria2」只代表最外層的協定類型，無法單獨決定實際體驗。同一協定分別在穩定的有線網路與頻繁切換基地台的行動網路上運作時，表現可能完全不同；同一台伺服器若更換壅塞控制、TLS 設定或底層傳輸，連線時間與資源消耗也會改變。

用戶端是設定與核心的外殼。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android 等圖形用戶端負責訂閱管理、系統代理、TUN 開關與記錄顯示，真正解析協定並建立連線的是其核心。判斷某種協定能否使用時，應依序確認用戶端採用哪個核心、核心是否識別協定欄位、訂閱轉換是否保留必要參數，以及執行平台是否允許相應的網路能力。

不要只比較連線速度

選擇時至少應觀察四項：首次握手所需的往返次數、建立連線後的吞吐穩定性、丟包時的恢復方式，以及裝置長時間運作的資源成本。TCP 類協定通常容易理解，系統網路堆疊與家用路由器對其支援成熟；基於 QUIC 或 UDP 的方案更擅長處理高延遲與一定程度的丟包，但會自行維護重傳、壅塞控制及連線狀態，因此參數組合與伺服器實作更為重要。

所謂「連線快」還要區分三個階段。第一階段是 DNS 查詢與尋找伺服器位址，第二階段是建立 TCP、TLS 或 QUIC 工作階段，第三階段才是與目標網站交換資料。若網域解析緩慢，將問題歸因於代理協定會得到錯誤結論；若伺服器負載過高，更換用戶端中的協定名稱也不會改善吞吐。測試時應保持伺服器、線路、時段與目標資源一致，只改變一個變數。

先確認限制，再談偏好

協定選擇通常不是在六種方案中任意挑選，而是先排除目前伺服器未提供、核心不支援或網路環境不適合的類型。訂閱只提供 SS 節點時，用戶端無法在本機直接將它變成 Hysteria2；VLESS 項目缺少伺服器要求的 Reality 參數時，僅修改類型欄位也無法完成連線。正確流程是先讀取完整設定，再在可用集合中比較。

對大多數桌面使用者而言，穩定性、設定透明度與故障可定位性比理論峰值更重要。經常使用行動網路的使用者，則應提高網路切換後的恢復速度與電量權重。需要先安裝用戶端時，可前往Clash 下載頁選擇對應平台；桌面與行動平台都建議優先查看 Clash Plus，其餘用戶端可依作業系統與介面習慣選擇。

二、六類常用協定的設計取捨

Shadowsocks：結構精簡，相容範圍廣

Shadowsocks 通常縮寫為 SS。其設定核心是伺服器、連接埠、密碼與加密方式，協定本身相對精簡，長期累積了廣泛的用戶端與伺服器實作。對 Clash 使用者而言，SS 的主要價值在於設定欄位少、移轉成本低，故障範圍也容易確認。只要雙方使用相同的加密方式與憑證，基本連線通常不需要額外的傳輸層協商。

精簡不代表所有 SS 項目都完全相容。部分伺服器會加入外掛或特定擴充，例如透過 plugin 與 plugin-opts 描述額外傳輸。若核心不支援對應外掛，基本 SS 能力仍然存在，但該項目無法依預期建立連線。現代設定更常使用 AEAD 加密方式；遇到早期演算法名稱時，應先確認核心是否仍接受，而不是在 YAML 中反覆修改大小寫。

VMess：欄位完整，歷史設定較多

VMess 與 V2Ray 生態系關係密切，設定中常見 uuid、alterId、cipher、network、TLS 與 WebSocket 等欄位。它曾被大量訂閱格式採用，因此在舊設定與跨用戶端轉換結果中仍很常見。VMess 的優勢是生態成熟、傳輸組合豐富，代價是設定層級較多，任何一項與伺服器不一致都可能造成握手失敗。

處理 VMess 時要特別區分協定身分資訊與傳輸資訊。uuid 屬於身分憑證，network 決定底層傳輸，ws-opts 或 grpc-opts 描述具體路徑與主機欄位，tls 與 servername 則會影響安全工作階段。若訂閱轉換器只保留 uuid 與位址，卻遺失 WebSocket 路徑，產生的項目看似完整，實際上仍無法使用。alterId 多見於歷史設定，新設定是否需要此欄位應以伺服器輸出為準。

Trojan：基於 TLS 的清晰組合

Trojan 的典型項目由密碼、TLS 伺服器名稱與選用的傳輸參數組成。它依賴標準 TLS 能力建立安全工作階段，在設定閱讀上比多層 VMess 組合更直接。對已具備穩定 TLS 部署的伺服器而言，Trojan 往往是容易維護的選擇。用戶端最常見的問題並非協定本身，而是 servername、憑證名稱、系統時間或傳輸路徑不一致。

將 skip-cert-verify 設為 true 可能繞過憑證驗證錯誤，但不應視為常規修復手段。更合適的順序是檢查裝置時間、伺服器名稱、憑證鏈與訂閱欄位。若伺服器使用 WebSocket 或 gRPC，Trojan 項目仍需帶有相應參數；看到 TLS 並不表示底層一定是普通 TCP。

VLESS：進一步拆分身分與傳輸能力

VLESS 的設計著重於較輕量的協定層，並將加密與傳輸安全交由 TLS、Reality 等外部機制處理。設定中仍以 uuid 識別使用者，但實際能否連線高度取決於 flow、network、servername、reality-opts 等組合。它適合需要明確控制傳輸結構的部署，也要求訂閱與核心完整理解這些擴充欄位。

Reality 是常見的 VLESS 配套能力，而不是可以脫離 VLESS 單獨填寫的一般加密選項。用戶端通常需要 public-key、short-id、servername 等資訊。若訂閱轉換後欄位名稱改變或層級遺失，記錄可能只呈現握手失敗。排查時應比對原始分享連結、轉換後的 YAML 與核心記錄，確認問題發生在來源、轉換或執行階段。

Hysteria2：面向波動線路的 QUIC 方案

Hysteria2 基於 QUIC 與 UDP，重點在於高延遲、存在丟包或頻寬快速變化時的傳輸效率。它能減少傳統 TCP 在部分弱網環境中的隊頭阻塞影響，並可透過頻寬、混淆與 TLS 相關參數調整行為。優勢成立的前提是用戶端到伺服器之間的 UDP 通道穩定，且伺服器參數與憑證設定正確。

Hysteria2 並不是把頻寬數字填得越大越好。設定中的上行與下行頻寬會參與壅塞控制判斷，明顯高於真實線路能力的數值可能造成排隊與丟包，明顯偏低則會限制可用吞吐。部分 mihomo 設定允許省略頻寬，改用更通用的壅塞控制方式，應遵循伺服器提供的項目，不要根據測速峰值任意放大。

TUIC：偏向低延遲連線與行動性

TUIC 同樣建立在 QUIC 之上，常見設定包括 uuid、password、壅塞控制演算法、UDP 中繼模式與 SNI。它重視連線建立、並行串流及網路變化下的可用性，在支援良好的行動環境中通常表現自然。與 Hysteria2 一樣，TUIC 對 UDP 品質與實作版本的配合更敏感。

TUIC 設定需要注意協定版本與欄位語義。不同歷史實作之間可能存在憑證格式或中繼模式差異，不能只憑「TUIC」名稱判斷是否互通。由伺服器產生訂閱時應盡量原樣匯入；手動移轉則要參照目前 mihomo 設定語法逐項對應。若網路對 UDP 的處理不穩定，TUIC 的理論優勢可能變成頻繁重新連線，此時成熟的 TCP 類協定反而更穩定。

三、連線速度、資源使用量與行動裝置電量

握手次數決定首次連線的部分成本

首次連線耗時由 DNS、傳輸層握手、安全握手與協定驗證共同組成。SS 在一般 TCP 情境下結構較短，但目標連線仍需經過完整的網路往返；Trojan、使用 TLS 的 VMess 或 VLESS 需要完成 TLS 流程，啟用工作階段恢復後，後續連線可能明顯快於第一次。Hysteria2 與 TUIC 借助 QUIC 結合安全與傳輸協商，並能在一個工作階段中承載多個串流，適合大量短連線，但首次建立仍受 UDP 路徑品質影響。

瀏覽器開啟網頁時經常重用既有的 HTTP/2 或 HTTP/3 連線，因此使用者感受到的「秒開」不完全等於代理握手速度。比較時應先關閉舊連線或等待工作階段失效，再分別觀察第一次與連續造訪。Clash 記錄能顯示代理選擇與錯誤階段，但一般 info 層級不會提供每個協定內部步驟的精確計時。不要把策略組的延遲測試值直接解讀為網頁載入速度，它通常只代表指定測試位址的一次連線結果。

吞吐量取決於線路，而不只是加密

現代裝置對常見 AEAD 與 TLS 加密具備良好的軟體或硬體最佳化，單純的加密計算往往不是桌面端的首要瓶頸。伺服器 CPU、單核心效能、網路出口、丟包與路徑 MTU 更容易限制吞吐。SS 的協定開銷較容易預測；VMess、VLESS 與 Trojan 的額外消耗會隨傳輸層變化；WebSocket 會增加封裝，gRPC 依賴 HTTP/2，QUIC 類協定則在使用者空間處理更多傳輸邏輯。

資源有限的路由器需要更加謹慎。QUIC 會維護加密、重傳、壅塞視窗與多個串流狀態，在低效能處理器上可能比由系統核心負責大部分 TCP 工作時佔用更多 CPU。另一方面，線路丟包明顯時，QUIC 避免跨串流隊頭阻塞所節省的等待時間，又可能抵銷計算成本。因此不能只看閒置記憶體或某一秒的 CPU 峰值，應在真實傳輸持續數分鐘後觀察溫度、負載與速率穩定性。

行動裝置耗電由喚醒頻率與覆蓋範圍共同決定

手機上的電量差異通常來自無線模組喚醒、背景保活、網路切換重新連線與 TUN 處理範圍，而不是協定名稱本身。持續產生小封包的連線會頻繁喚醒基頻；詳細記錄、短間隔健康檢查與過於頻繁的自動測速也會增加背景活動。Hysteria2、TUIC 在弱網恢復方面可能減少等待，但若 UDP 路徑不穩導致持續重試，同樣會增加耗電。

系統代理只會影響遵循代理設定的應用程式，覆蓋範圍相對有限。TUN 模式需要接管更多流量，並處理 DNS、路由與不主動使用系統代理的應用程式，因此通常承擔更多工作。Android 上還要考慮系統背景限制與 VPN 服務生命週期；iOS 用戶端則會受到 Network Extension 執行方式影響。比較協定耗電量時，必須保持代理模式、規則集、健康檢查週期與使用的應用程式一致。

建立可重複的本機測試

有效測試應在同一裝置、同一網路及相近時間內完成。先關閉自動選擇策略組，固定使用一個項目；記錄首次造訪、連續造訪、長時間傳輸與網路切換後的恢復情況；再更換同一台伺服器提供的另一種協定。若伺服器不是同一台，測試結果只能說明整條線路的差異，不能證明某個協定更快。

四、傳輸層、TLS 與關鍵設定參數

network 欄位改變的是承載方式

VMess、VLESS 與 Trojan 常透過 network 欄位選擇 tcp、ws、grpc 等承載方式。協定負責身分與資料格式，network 決定這些資料如何裝入底層連線。WebSocket 設定通常需要路徑與 Host；gRPC 通常需要 service-name；普通 TCP 可能還有額外標頭選項。伺服器使用何種方式，用戶端就必須逐項對應，不能僅憑連接埠是 443 就推斷某種傳輸。

WebSocket 容易與一般 Web 服務的部署方式組合，但每個訊框都會增加額外封裝。gRPC 基於 HTTP/2，適合多路複用，不過中間網路設備與伺服器反向代理必須正確支援。普通 TCP 路徑直接，故障定位也較簡單。選擇時應以現有伺服器輸出為準；對一般訂閱使用者而言，手動更換 network 通常不會憑空提升效能，只會讓用戶端與伺服器失配。

servername、Host 與伺服器位址各有職責

server 欄位決定用戶端連線至哪個主機或 IP，servername 常用於 TLS 的 SNI 與憑證名稱驗證，WebSocket 的 Host 則屬於 HTTP 請求標頭。三者有時相同，也可能不同。若訂閱轉換器將它們合併，常見結果是 TCP 已連通，但 TLS 或上層請求失敗。排查時先看記錄是否出現 DNS、connect、certificate、handshake 或 timeout，再定位對應層級。

裝置時間也是 TLS 驗證的一部分。系統時鐘偏差過大時，Trojan、VLESS TLS、Hysteria2 與 TUIC 都可能回報憑證有效期問題。此時更換協定或反覆重新整理訂閱沒有意義，應先恢復自動校時。對 Reality 設定，則要同時核對 public-key、short-id、servername 與 fingerprint；這些欄位屬於同一組，缺少其中任何一項都可能導致握手階段終止。

UDP、MTU 與分片問題

Hysteria2 與 TUIC 依賴 UDP，其他協定也可能轉送 UDP 應用程式流量。UDP 封包經過家用路由器、行動網路與隧道時，可用 MTU 可能低於實體網卡標稱值。過大的封包若無法正確分片，會表現為小請求正常、大資料卡住，或部分網站可用而部分連線逾時。TUN 模式下還能透過用戶端的 MTU 設定影響虛擬介面封包大小，但沒有現象依據時不應盲目調低。

合理的排查順序是先保留訂閱預設值，確認 TCP 類流量正常後，再檢查 UDP 協定項目。若 QUIC 連線持續逾時，可切換到同一服務提供者的 TCP 類協定進行對照；若 TCP 正常而所有 UDP 方案都失敗，應優先檢查本地網路、路由器與伺服器 UDP 連接埠。只調整用戶端的 skip-cert-verify 無法修復 UDP 通道問題。

一段易讀的 mihomo 設定

以下範例展示欄位層級，不代表可直接連線的服務。網域與憑證均為文件範例，實際使用時應採用伺服器產生的完整設定。手寫 YAML 時請使用空格縮排，不要使用定位字元。

proxies:
  - name: "SS 範例"
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "Trojan 範例"
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: service.example.com
    udp: true

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "SS 範例"
      - "Trojan 範例"

rules:
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

設定能被 YAML 解析，只代表語法成立，不代表伺服器參數正確。匯入後應查看用戶端記錄：若出現 unsupported proxy type，表示核心不識別該類型；若出現欄位解析錯誤，表示鍵名或層級不相容；若項目成功載入但連線逾時，則繼續檢查位址、連接埠、傳輸與網路路徑。更多 YAML 基礎詞義可搭配Clash 術語表閱讀。

五、Clash 原版、Meta 與 mihomo 的核心關係

核心決定設定檔能否執行

Clash 生態系中的「用戶端」與「核心」經常混用。原版 Clash 是較早形成設定語法與規則模型的核心實作，提供代理組、規則分流、DNS、外部控制介面等基礎能力。圖形用戶端則圍繞這些能力增加設定管理與系統整合。後來出現的 Clash.Meta 在相容大量原版語法的基礎上，擴充協定、DNS、規則集與 TUN 能力；mihomo 是目前常用的這個擴充核心專案名稱。

因此，「Meta 設定」與「mihomo 設定」在多數日常情境中指向同一條演進路線，但歷史文件、訂閱產生器與用戶端介面仍可能保留 Clash.Meta 字樣。判斷相容性時不要只看名稱，應查看用戶端實際核心說明與執行記錄。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 與 Clash Meta for Android 等現代用戶端通常圍繞 mihomo 生態系提供能力，但不同平台的核心更新節奏與可用選項不一定完全一致。

原版相容是基礎，不代表反向相容

大部分基礎 SS、VMess、Trojan、代理組與傳統規則都能從原版設定移轉至 mihomo。反方向則不成立：包含 VLESS、Hysteria2、TUIC、GEOSITE、新式 rule-providers 或擴充 DNS 欄位的 mihomo 設定，舊版原版核心可能直接拒絕載入，或忽略無法識別的欄位。設定檔看似仍是 YAML，不代表任何名為 Clash 的程式都能執行。

相容性問題大致分為三類。第一類是不支援代理類型，記錄通常會指向 type；第二類是欄位結構變更，例如某些 TLS、Reality 或 QUIC 參數需要巢狀物件；第三類是行為差異，同一欄位雖可解析，但 DNS、規則或介面繫結的預設行為不同。移轉時應先讓最小設定通過解析，再逐步恢復 DNS、TUN、規則集與腳本能力，避免一次匯入整份複雜檔案後無法定位問題。

圖形介面不會自動修復核心差異

圖形用戶端可以隱藏複雜欄位、提供開關並顯示錯誤，但不能讓核心執行其不認識的協定。有些用戶端會在匯入時轉換訂閱，有些則將原始 YAML 直接交給核心。前者可能發生欄位遺失，後者可能直接回報語法錯誤。遇到同一訂閱在不同用戶端表現不一致時，應比較兩邊使用的核心家族、匯入後的實際設定與記錄，而不是只比較介面名稱。

Clash for Windows 與 ClashX Meta 已屬停止維護的封存用戶端。它們可用於了解歷史生態系，但不適合作為驗證新協定相容性的基準。需要 VLESS、Hysteria2、TUIC 或較新的 geodata 能力時，應選擇仍採用 mihomo 路線的用戶端。各平台目前可選軟體與維護狀態集中列於下載頁面。

更新核心前先儲存可回復的設定

核心更新可能加入協定能力，也可能收緊錯誤設定的解析。升級前應儲存目前可正常運作的設定與用戶端選項，尤其是自訂 DNS、rule-providers、TUN 路由與外部控制介面。升級後先檢查設定是否成功載入，再檢查代理組是否完整，最後驗證 DNS 與規則命中。若問題只在新核心出現，可以暫時回到已知可用的環境並比較記錄，不要同時修改訂閱、規則與系統網路設定。

六、訂閱格式、分享連結與轉換相容性

訂閱是一種交付方式，不是一種代理協定

使用者常把「訂閱格式」與「協定格式」放在一起討論。實際上，訂閱負責批量描述節點、代理組與規則，節點內部才包含 SS、VMess、Trojan、VLESS、Hysteria2 或 TUIC。一個訂閱可以只包含一種協定，也可以混合多種協定；同一協定也能透過分享連結、通用 JSON、Clash YAML 或伺服器專用回應交付。

用戶端重新整理訂閱時通常會經過下載、識別、轉換、寫入設定與核心載入五個階段。下載失敗表現為網路或授權錯誤；識別失敗表示內容類型與預期不符；轉換失敗可能遺失擴充欄位；寫入失敗與檔案權限有關；只有載入失敗才是 YAML 或核心相容性問題。將這五個階段分開，能避免看到「更新失敗」就反覆更換協定。

Clash YAML 能表達完整結構

Clash YAML 可以同時描述 proxies、proxy-groups、rules、dns、rule-providers 等內容，適合作為用戶端直接載入的完整設定。其優勢是結構清晰、便於審閱與組合；風險則是不同核心支援的欄位集合不同。若 YAML 由面向 mihomo 的服務產生，匯入舊核心時可能出現不支援的代理類型或規則能力。

只包含 proxies 的訂閱不一定會自動產生理想的策略組。部分用戶端會提供覆寫或全域擴充功能，將遠端節點合併至本機範本。此時要注意節點名稱是否重複、策略組引用是否仍存在，以及更新後本機修改是否被覆蓋。需要長期自訂規則時，通常應將遠端節點與本機規則分層管理，而不是直接編輯每次都會重新整理替換的訂閱檔案。

分享連結適合單項移轉，但欄位可能受編碼限制

ss://、vmess://、trojan://、vless://、hysteria2:// 與 tuic:// 等連結便於傳遞單一項目。用戶端讀取連結後，會將查詢參數對應至內部設定。簡單的 SS 或 Trojan 連結通常較直接；攜帶 WebSocket、gRPC、Reality、ALPN、指紋或壅塞控制參數時，連結解析器必須識別完整的參數集。

連結能被識別並出現在節點清單中，不代表所有欄位都已保留。匯入後應查看產生的設定或詳細資料頁，核對 server、port、uuid 或 password、network、servername、路徑與擴充參數。若原始連結來自不同生態系，其參數名稱可能需要轉換。不要透過刪除「不認識的參數」來追求匯入成功，因為遭刪除的欄位可能正是伺服器握手所需的資訊。

分別處理重新整理失敗與協定不可用

訂閱 URL 無法下載時，用戶端甚至還沒有接觸協定設定。此時應檢查連結是否完整、有效期限、存取方式與用戶端請求行為。訂閱成功更新但某個節點失敗，才繼續分析協定欄位。所有新節點都無法載入，通常指向格式或核心；只有單個節點逾時，則更可能是該伺服器、連接埠或項目參數的問題。

自動更新還可能覆蓋手動修改。需要修改策略組時，優先使用用戶端提供的覆寫、擴充設定或本地設定功能，並保留遠端訂閱原件。關於連結過期、請求方式與自動更新間隔，可繼續閱讀Clash 訂閱更新失敗常見原因與自動更新間隔設定。

七、協定之外的 DNS、規則與 TUN 影響

連線失敗可能發生在選擇協定之前

用戶端建立代理連線前，可能需要先解析伺服器網域。若 DNS 無法取得位址，任何協定都會失敗。記錄中的 lookup、resolve 或 no such host 通常指向解析階段；connect timeout 表示已取得位址但無法完成網路連線；handshake 或 certificate 錯誤則更接近協定與安全層。依錯誤階段處理，比不斷切換節點更有效。

Clash 的 DNS 模組也負責解析目標網域，並可能使用 fake-ip 或 redir-host 模式。fake-ip 會先回傳虛擬位址，再由核心還原網域並套用規則，適合 TUN 與精確網域分流；redir-host 則更接近回傳真實解析結果。兩者在應用程式相容性、快取與規則行為上有所差異，但不會改變遠端節點本身屬於 SS、VLESS 還是 TUIC。

規則決定使用哪個代理組

規則會依序比對，命中後停止繼續向下。DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、GEOSITE 與 MATCH 處理的是流量去向，不負責改變節點協定。如果某條流量總是走 DIRECT，即使策略組內選中了 Hysteria2，該流量也不會經過它。排查時應同時查看規則命中記錄與策略組選擇。

GEOIP 依賴 IP 地理資料庫，GEOSITE 依賴網域分類資料。資料庫過時可能導致規則結果與預期不同，但不會讓代理類型變得不受支援。mihomo 可使用 geodata、MMDB 與規則提供器等機制，具體檔案來源與更新方式應保持一致。相關維護方法請參閱GeoIP 與 GeoSite 資料庫更新說明。

rules:
  - DOMAIN-SUFFIX,github.com,節點選擇
  - DOMAIN-KEYWORD,google,節點選擇
  - GEOSITE,category-ads-all,REJECT
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

上述順序先處理明確網域與廣告分類，再處理 IP 地理規則，最後由 MATCH 作為兜底。若將 MATCH 放在最前面，後續規則永遠不會執行。規則策略名稱必須與 proxy-groups 中的名稱完全一致，包括大小寫與空格。策略組引用不存在的節點時，核心可能拒絕設定，也可能留下無法使用的群組，具體取決於設定結構。

TUN 改變覆蓋範圍，也增加排查層級

系統代理依賴應用程式主動讀取作業系統代理設定，瀏覽器通常支援，但終端程式與部分遊戲可能不會遵循。TUN 建立虛擬網路介面，從路由層接管更多流量，因此能覆蓋更多應用程式，也會引入路由、DNS 劫持、MTU 與系統權限等變數。某協定在系統代理下正常、TUN 下異常時，不應立即判定協定不相容，應先確認流量是否進入 TUN、DNS 是否正確接管，以及目標是否被繞過。

行動裝置通常透過系統 VPN 介面實現類似能力。作業系統可能在休眠、切換 Wi-Fi 與行動網路或啟用省電模式後重建介面。TUIC 與 Hysteria2 的 QUIC 工作階段具備適應網路變化的設計空間，但用戶端、系統與伺服器都必須支援相應行為；實際表現仍需在裝置上驗證。頻繁中斷時，先檢查系統是否終止背景服務，再查看協定記錄。

用記錄建立分層排查順序

建議順序是：確認設定成功載入；確認代理項目出現在目標策略組；確認伺服器網域解析；確認 TCP 或 UDP 連接埠可建立連線；確認 TLS、Reality 或協定驗證；確認規則將目標流量送至該組；最後檢查系統代理或 TUN 是否覆蓋目標應用程式。每一步只回答一個問題，能明顯縮小範圍。

若瀏覽器有效而終端無效，通常是終端未讀取系統代理環境，而不是協定只能支援瀏覽器。若所有應用程式在啟用 TUN 後都無法解析網域，應檢查 DNS 與 TUN 設定。更多常見錯誤可在FAQ 故障排查中依現象尋找；瀏覽器與終端的差異流程請參閱系統代理未生效排查。

八、依裝置與網路情境選擇協定

桌面日常使用：優先穩定與可維護性

Windows 與 macOS 桌面裝置資源相對充足，協定計算成本通常不是首要限制。若伺服器提供成熟的 SS、Trojan 或使用 TLS 的 VLESS 項目，可優先選擇設定完整且長期穩定的一項。需要大量短連線、網路延遲較高且 UDP 通道穩定時，再比較 Hysteria2 或 TUIC。桌面端測試方便，應保留一個 TCP 類方案作為對照與故障回退。

用戶端方面，建議先從 Clash Plus 開始，再依介面與平台需求比較 Clash Verge Rev、FlClash 與 Clash Nyanpasu。用戶端選擇與協定選擇應分開：更換圖形介面可能改善設定管理體驗，但若兩者使用相近的 mihomo 核心，同一份錯誤設定仍會失敗。移轉用戶端時匯出原始訂閱位址與必要的本地覆寫，不要只複製介面快取檔案。

行動網路：觀察切換恢復與背景行為

Android 與 iOS 經常在 Wi-Fi、行動網路與休眠狀態之間切換。此時應重點觀察連線恢復時間、背景服務是否被系統保留、UDP 路徑是否穩定，以及全天電量變化。TUIC 與 Hysteria2 在條件合適時能提供較平順的弱網體驗，但若目前電信網路的 UDP 品質不穩定，Trojan、VLESS TLS 或 SS 可能更可靠。

行動端不宜透過連續測速來選擇協定。高頻測試本身會喚醒網路與處理器，也不能代表常用應用程式的長期體驗。更實用的方法是分別使用候選協定完成一段完整工作時段，保持相同規則與 TUN 設定，記錄切換網路後的恢復、音影片連續性與電量。一次較高的峰值不應掩蓋頻繁斷線問題。

家用路由器與小型裝置：先看處理器與記憶體

路由器需要同時處理多台裝置的連線、DNS 與規則比對。在較弱的處理器上，簡單 SS 或成熟的 TCP/TLS 方案通常更容易維持穩定負載。Hysteria2 與 TUIC 能改善某些高延遲線路，但 QUIC 的使用者空間傳輸與加密可能提高 CPU 使用量。選擇前應在真實並發情境下觀察，而不是只讓單台電腦完成一次測速。

規則集規模同樣會影響資源。大量 GEOSITE 分類、遠端 rule-providers 與詳細記錄可能比代理協定佔用更多記憶體。若裝置頻繁重新啟動或核心被終止，應先縮小設定：保留一個代理組、少量規則與單一節點，確認穩定後再逐項恢復。mihomo 核心套件適合熟悉命令列與服務管理的使用者，一般桌面使用者則使用圖形用戶端更方便查看錯誤。

高延遲或存在丟包的線路：再考慮 QUIC 方案

當傳統 TCP 在丟包後出現明顯速率下降，而 UDP 可以穩定通過時，Hysteria2 與 TUIC 值得測試。兩者都不會在所有網路上自動變快。Hysteria2 的頻寬與壅塞行為需要符合線路，TUIC 則需要伺服器與用戶端的實作版本、憑證及中繼模式一致。測試時與同一伺服器的 TCP 類項目比較，才能盡量排除線路差異。

如果小資料正常而大型傳輸停止，請檢查 MTU、UDP 分片與路由器狀態；如果首次可用但數分鐘後中斷，請檢查工作階段逾時、NAT 對映與背景限制；如果從未建立連線，請檢查 UDP 連接埠、TLS 名稱與驗證欄位。先將現象分類再調整參數，不要同時修改頻寬、MTU、SNI 與憑證驗證。

最終決策清單

決定使用某項協定前，依序確認六件事：伺服器確實提供該類型；用戶端採用支援它的 mihomo 核心；訂閱完整保留身分、傳輸與安全欄位；目前網路允許所需的 TCP 或 UDP 通道；裝置資源足以持續運作；相同條件下的實際測試結果穩定。六項都成立，才能說明選擇具備可重複性。

如果仍無法判斷，優先使用伺服器明確推薦且設定完整的項目，不要修改進階參數。先完成匯入、選擇策略組、連線與驗證的基礎流程，再用本頁方法進行對照測試。首次連線的操作順序也可參考選擇節點、測試延遲與驗證代理生效。協定沒有脫離環境的永久排名，穩定、可診斷且適合目前裝置，才是更有價值的結論。