Clash 協定與核心技術參考

一、先建立協定選擇框架

協定、傳輸與客戶端是三個層級

Clash 設定中的一個代理節點通常包含三層資訊。第一層是協定本身，例如 Shadowsocks、VMess、Trojan、VLESS、Hysteria2 或 TUIC，規定雙方如何驗證、封裝資料與維持工作階段。第二層是承載協定的傳輸方式，例如一般 TCP、WebSocket、gRPC、HTTP/2、QUIC 或基於 UDP 的自訂傳輸。第三層才是執行設定的客戶端與核心。圖形客戶端負責訂閱管理、策略群組、系統代理與介面操作，mihomo 等核心則負責實際解析節點並轉送連線。

這三層不能混為一談。VMess 搭配 TCP 與 VMess 搭配 WebSocket，在握手次數、封包標頭負擔與連線重用方面並不相同；VLESS 本身很輕量，但加上 TLS、REALITY、gRPC 後，實際連線仍會包含相應傳輸層的計算與往返。客戶端名稱也不能證明其支援某個協定的所有擴充功能。判斷相容性時，應查看核心類型、節點欄位與傳輸組合，而不是只看介面中是否出現相似名稱。

先確認限制，再比較協定

實用的選擇順序是：先確認伺服器端已提供哪些協定，再確認目前客戶端核心能否完整解析，接著考量網路特性與裝置限制，最後才比較速度。使用者通常無法只在本機將現有節點改成另一種協定，因為協定、連接埠、驗證資訊與伺服器設定必須互相對應。訂閱只提供 SS 節點時，客戶端無法透過修改 type 欄位將其轉換為 Hysteria2；這樣只會導致握手失敗。

網路限制至少包括四項：UDP 是否穩定、往返延遲是否偏高、封包遺失是否明顯，以及連線是否經常在 Wi-Fi 與行動網路之間切換。裝置限制則包括處理器效能、背景執行限制、電池容量，以及是否長時間維持大量並發連線。桌上型裝置通常持續供電，較適合優先追求吞吐量與連線恢復；行動裝置則需要同時衡量喚醒次數、持續傳送封包、無線模組活躍時間與背景保活成本。

六個判斷面向

本文統一從六個面向比較協定：握手成本決定首次建立連線需要多少次往返；傳輸效率關注有效負載占比與多工方式；弱網恢復關注封包遺失與抖動下的退化程度；資源占用包括加密、壅塞控制與工作階段維護所帶來的 CPU 和記憶體成本；行動裝置表現重點觀察無線模組是否頻繁被喚醒；生態相容性則檢視訂閱格式、核心與伺服器端的支援範圍。任何協定都可能在某個面向占優，卻在另一個面向付出成本。

因此，選擇協定的目標不是找出全方位最強者，而是避免明顯不匹配。例如 UDP 品質長期不穩定時，優先選擇成熟的 TCP 組合，通常比反覆調整 QUIC 參數更有效；高延遲且存在隨機封包遺失時，Hysteria2 或 TUIC 可能提供更平穩的吞吐量；老舊裝置只處理網頁與訊息流量時，結構簡單、實作成熟的 SS 往往更節省資源。先將需求寫成限制條件，結論會比協定排行榜可靠。

二、SS、VMess、Trojan 與 VLESS 的設計差異

Shadowsocks：結構簡潔、實作廣泛

Shadowsocks 通常縮寫為 SS。其核心概念是使用預先共用的金鑰保護代理資料，並以精簡結構轉送 TCP 與 UDP 流量。早期實作曾提供多種傳統加密方式，現代設定則較常使用 AEAD 加密，例如 aes-128-gcm、aes-256-gcm 與 chacha20-ietf-poly1305。AEAD 同時提供加密與完整性保護，客戶端與伺服器端必須使用完全一致的方法與密碼。

SS 的優勢來自成熟的實作、較少的節點欄位與廣泛的客戶端支援。對一般網頁、軟體更新、即時通訊與多數桌面情境而言，它通常能以較低的設定複雜度提供穩定表現。在具備硬體加速的桌面處理器上，AES 效率良好；ChaCha20 在部分行動裝置或低功耗處理器上可能更合適，但不能只憑演算法名稱判定結果，實際實作與裝置指令集同樣重要。

SS 的限制也與其簡單結構有關。它不是包含複雜傳輸編排的通用協定框架，擴充能力更多取決於特定實作、外掛程式或伺服器端能力。若訂閱包含外掛程式參數，mihomo 必須識別對應的外掛程式類型與欄位；只複製伺服器、連接埠與密碼，可能遺漏關鍵傳輸資訊。遇到能匯入但無法連線的 SS 節點，應先核對加密方式、外掛程式選項與 UDP 開關，而不是反覆切換系統代理。

VMess：包含工作階段資訊的完整協定

VMess 來自 V2Ray 生態系，透過 UUID 等身分資訊完成驗證，並可與 TCP、WebSocket、HTTP/2 等傳輸方式組合。它承擔的協定層工作比 SS 更多，設定欄位也更豐富。舊式設定中還可能看到 alterId 等欄位，但現代伺服器端通常採用不同的建議值；匯入舊訂閱時，核心雖然可能接受這些欄位，伺服器端的實際設定卻未必仍然匹配。

VMess 的價值在於成熟的生態系、多種傳輸組合與廣泛的舊訂閱支援。代價是設定鏈較長：協定驗證、傳輸類型、TLS、伺服器名稱、路徑與請求標頭可能共同決定連線結果。任何一處與伺服器端不一致，都可能表現為逾時或握手中斷。排查時應從訂閱的原始欄位著手，不宜憑經驗刪除看似多餘的參數。

從效能來看，VMess 並非天生較慢，但額外封裝、傳輸層與加密確實會產生一定成本。若多個節點實際使用相同線路，一般 TCP 組合通常比再疊加 WebSocket 與 TLS 的組合擁有較少的握手與框架負擔；不過在真實使用中，線路壅塞往往比這部分差異更顯著。只有在控制變因後，協定層比較才有意義。

Trojan：以 TLS 連線為基礎

Trojan 通常建立在 TLS 之上，使用密碼完成驗證，並將資料承載於受 TLS 保護的連線中。其設定重點包括伺服器位址、連接埠、密碼、伺服器名稱與憑證驗證行為。客戶端中的 sni 或 servername 必須與伺服器端憑證及部署方式相符。任意關閉憑證驗證可能暫時繞過錯誤，但會改變安全邊界，不應作為常規排錯手段。

Trojan 的優勢在於標準 TLS 元件成熟，部署與憑證體系清晰，許多核心都能穩定處理。建立新連線時需要完成 TCP 與 TLS 握手，高延遲環境中的首個封包時間可能因此增加；連線重用與工作階段恢復可以降低部分成本，但實際效果取決於客戶端與伺服器端實作。以大量短連線為主的網頁存取，應同時觀察首個封包時間；持續傳輸時，線路品質通常更重要。

Trojan 訂閱的常見問題集中在 SNI、憑證網域、傳輸層與連接埠不一致。若節點在一個客戶端可用、另一個客戶端失敗，應先比較兩邊匯出的完整節點欄位，特別是網路類型、ALPN、SNI 與憑證驗證選項。只核對密碼不足以確認設定等價。

VLESS：精簡驗證與可組合擴充

VLESS 採用較輕量的協定層設計，本身不像 VMess 一樣負責內建加密，通常依靠 TLS、REALITY 或其他安全傳輸提供保護。它以 UUID 等資訊進行驗證，可與 TCP、WebSocket、gRPC 等承載方式組合。VLESS 的設定可讀性較高，但這不代表節點欄位較少：流量控制、傳輸、安全層、伺服器名稱、公鑰、短識別碼與路徑等參數仍必須與伺服器端一致。

VLESS 常見於較新的伺服器端方案，也能透過組合不同傳輸方式，適應多種部署需求。其協定層負擔較輕，但最終效能取決於完整組合。VLESS 加一般 TCP、VLESS 加 gRPC、VLESS 加 WebSocket 是三種不同的資料路徑，不能將它們視為同一個效能結論。REALITY 相關欄位還依賴核心支援，舊版原版 Clash 通常無法完整解析，而 mihomo 的適配範圍更廣。

選擇 VLESS 時，重點不是「新」這項特性，而是訂閱與核心是否提供完整欄位、伺服器端組合是否穩定，以及目前網路是否適合對應傳輸。若現有 VMess 或 Trojan 節點長期穩定，沒有必要只因協定名稱改變就遷移。更換協定應解決明確問題，例如降低設定複雜度、使用核心支援的新傳輸，或改善特定網路下的連線恢復。

三、Hysteria2 與 TUIC：面向高延遲與封包遺失的 UDP 方案

為什麼使用 QUIC 或自訂壅塞控制

傳統 TCP 會以連線維護可靠且有序的資料流。發生封包遺失時，重傳與壅塞視窗調整可能讓後續資料等待；若多個邏輯請求共用同一條 TCP 路徑，也可能彼此影響。QUIC 在 UDP 之上實作可靠傳輸、加密與多路串流，將更多傳輸控制放在使用者空間。Hysteria2 與 TUIC 都利用這個方向改善高延遲、隨機封包遺失或頻寬變化明顯情境中的連線表現，但兩者並不是簡單的「UDP 加速開關」。

UDP 方案能否發揮作用，首先取決於端到端 UDP 品質。若本地網路、路由設備或伺服器端入口對 UDP 嚴格限速、映射時間過短或持續丟包，再先進的協定也無法彌補基礎路徑問題。常見症狀包括剛連線時正常、幾十秒後吞吐量驟降，或測速可用但長連線頻繁重建。此時應先與同線路的 TCP 節點比較，確認問題來自協定、線路還是本地網路。

Hysteria2 的頻寬利用思路

Hysteria2 使用基於 QUIC 的傳輸，並針對高延遲與封包遺失環境強調吞吐量利用。設定通常包含伺服器、連接埠、驗證資訊、TLS 伺服器名稱與憑證驗證設定。部分伺服器端還會提供混淆相關參數。客戶端下載訂閱後應保留這些欄位，不要將驗證字串誤當作 SS 密碼，也不要把一般 HTTPS 位址直接填入 Hysteria2 節點。

在長距離、高頻寬延遲積與隨機封包遺失環境中，Hysteria2 可能比較保守的 TCP 壅塞控制更積極。積極傳送有助於維持吞吐量，但網路條件較差時，也代表可能產生更多重傳、CPU 工作與無線模組活躍時間。它適合持續下載、影片傳輸或遠端存取大型檔案，不代表所有短連線網頁都會更快。短請求的體驗還會受到 DNS、QUIC 建立連線、憑證驗證與應用程式本身連線重用的影響。

設定中的頻寬相關參數應反映實際可用能力，而不是越大越好。估值過高可能造成突發傳送、排隊與額外丟包；估值過低則會限制吞吐量。若服務提供者已透過訂閱給出參數，應優先保留原值。需要手動調整時，應在穩定網路下多次測量，設定略低於可持續吞吐量的值，再觀察延遲是否因排隊而明顯升高。

TUIC 的連線遷移與多路串流

TUIC 同樣建立於 QUIC 體系之上，常見設定包含 UUID、密碼、伺服器名稱、壅塞控制器與 UDP 中繼模式。其設計著重低延遲、多路複用與連線狀態管理。QUIC 使用連線識別碼，而非只依賴傳統四元組；在實作與網路條件允許時，裝置從 Wi-Fi 切換至行動網路後可能更容易恢復工作階段。不過「支援遷移」不代表切換過程一定不會中斷，行動系統的背景策略、位址變化與中間設備的映射都會影響結果。

TUIC 的壅塞控制選項會改變吞吐量與延遲之間的取捨。較積極的演算法可能在頻寬充足時快速提升傳送速率，也可能在共用網路上增加排隊；較保守的策略通常更平穩，但在高延遲線路上的提升速度較慢。客戶端應遵循訂閱或伺服器端建議，不宜只根據演算法名稱修改。客戶端與伺服器端對 TUIC 世代及欄位解讀不一致時，最常見的表現是驗證後立即斷線或 UDP 轉送無法使用。

Hysteria2 與 TUIC 的選擇通常由伺服器端支援決定。如果兩者位於相同線路，可以用三項任務比較：連續瀏覽一組短網頁，觀察首個封包與失敗重試；維持十多分鐘的持續傳輸，觀察吞吐量波動；在行動裝置上切換一次網路，觀察恢復時間與耗電變化。結論應建立在實際任務上，而不是單一測速數值。

四、速度、資源占用與行動裝置耗電

將速度拆分為首個封包、吞吐量與穩定性

「速度快」至少包含三種不同指標。首個封包時間是從應用程式發起連線到收到第一段有效資料的時間，會受到 DNS、協定握手、TLS 或 QUIC 建立連線，以及伺服器端處理影響；持續吞吐量描述大型檔案或影片在穩定階段的傳輸能力；穩定性則關注一分鐘到數小時內是否出現斷流、重連與明顯抖動。協定可能在持續吞吐量上占優，卻因首次建立連線較複雜而無法改善短網頁體驗。

比較時應保持伺服器端位置、線路、裝置、時段與客戶端核心一致。兩個名稱不同且線路也不同的節點，測試結果主要反映線路差異。建議分別使用網頁載入、持續檔案傳輸與即時語音三類任務，每類執行多次，並記錄中位數體驗，而非最高峰值。Clash 的策略群組延遲測試適合篩除明顯不可用的節點，不適合作為完整吞吐量基準。自動策略群組的差異可進一步閱讀url-test、fallback 與 load-balance 選擇說明。

CPU、記憶體與並發連線

協定資源占用來自加密運算、資料複製、壅塞控制、連線重用、日誌與規則比對。SS 的協定結構較簡潔，通常具有較低的常駐負擔；AES 與 ChaCha20 的實際成本取決於硬體加速。VMess 與多層傳輸需要處理更多封裝。Trojan 借助成熟的 TLS 函式庫，但大量短連線會反覆承擔握手成本。VLESS 本身較輕量，若再加入 gRPC、TLS 或複雜流量控制，最終負擔仍取決於完整組合。

Hysteria2 與 TUIC 的 QUIC 處理位於使用者空間，需要維護封包遺失偵測、壅塞視窗與多個邏輯串流。在高速傳輸或弱網重傳較多時，CPU 占用可能高於簡單 TCP 協定。現代桌面裝置通常能夠負荷，但低功耗路由器、舊手機或小型伺服器需要留意持續負載。就記憶體而言，節點數量、規則集、GeoIP 資料、連線面板記錄與 DNS 快取往往比單一協定物件更顯著，不能看到客戶端占用增加就直接歸因於協定。

診斷資源問題時，先固定同一份規則與 DNS 設定，只更換一個節點協定；關閉連線詳細資訊頁面的持續重新整理，並將日誌層級維持在一般程度。分別觀察閒置、一般瀏覽與持續傳輸三種狀態。如果閒置時資源仍然偏高，原因更可能是圖形介面、規則更新、DNS 迴圈或系統代理衝突；如果只在高速傳輸時升高，則更接近加密與傳輸處理成本。

行動裝置耗電不只取決於協定名稱

行動裝置的主要耗電通常來自螢幕、無線基頻、CPU 喚醒與背景保活。代理協定會透過封包傳送頻率、重傳數量、連線維持與加密運算間接影響電量。持續傳送小封包會讓無線模組維持活躍更久；弱網下大量重傳會同時增加網路與 CPU 成本；過短的連線保活可能頻繁喚醒系統，過長的保活則可能維持不必要的工作階段。

日常輕量瀏覽中，成熟的 SS、Trojan 或 VLESS TCP 組合通常容易獲得可預期的耗電表現。Hysteria2 與 TUIC 在行動網路品質良好且持續傳輸明顯時，可能用更短時間完成任務，抵銷部分瞬時負載；但在 UDP 封包遺失嚴重的網路中，重傳與連線維護可能增加耗電。是否省電必須以完成相同任務所需的總時間與總電量判斷，不能只比較某一刻的 CPU 百分比。

Android 與 iOS 也會限制背景網路活動。客戶端遭系統暫停、VPN 服務被節能策略回收，或網路切換後未及時重建，都可能表現為協定斷線。Android 使用者應確認客戶端的 VPN 權限與背景執行策略；iOS 使用者應使用系統允許的客戶端與網路延伸方式。需要選擇對應軟體時，可在Android 下載區或iOS 下載區查看 Clash Plus 等客戶端。

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

原版 Clash 的定位

原版 Clash 建立了設定檔、規則分流、策略群組、DNS 與多平台代理入口等基礎模型。大量現有設定仍沿用其形成的欄位與結構，例如 proxies、proxy-groups、rules、mixed-port 與 mode。理解這些基礎結構仍然有價值，因為 Meta 系列與 mihomo 保留了廣泛的相容性。

但原版專案停止持續擴充後，較新的協定與傳輸並不在其完整支援範圍內。包含 VLESS 新擴充、Hysteria2、TUIC、REALITY 或較新 DNS 能力的設定，不能假定原版核心可以解析。部分舊客戶端介面仍使用 Clash 名稱，但內部核心可能已不同，因此需要查看客戶端的關於頁面、核心設定或執行日誌，而不是根據產品名稱猜測。

Clash Meta 與 mihomo 的延續關係

Clash Meta 在原版設定模型上擴充協定、DNS、規則提供者、TUN 與網路堆疊能力。mihomo 是這條核心路線延續使用的名稱。在實際討論中，「Meta 核心」與「mihomo」常用來指同一技術家族在不同時期或包裝方式下的稱呼。新設定應優先以 mihomo 文件與目前客戶端實際使用的核心為準；舊教學中的 Meta 欄位多半仍具參考價值，但不能機械式照搬所有預設值。

mihomo 的主要價值不只是增加協定數量，而是讓協定、策略群組、規則、DNS 與 TUN 在同一核心中協同運作。它能處理 SS、VMess、Trojan、VLESS、Hysteria2、TUIC 等多類節點，並支援更豐富的規則集與 DNS 行為。能夠解析協定不等於節點一定能連線：伺服器端參數、憑證、傳輸欄位與本地網路必須同時正確。

圖形客戶端與核心應分開理解。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等提供不同的介面、更新方式與系統整合；真正決定設定語法與協定能力的是其內建或呼叫的核心。客戶端可能為某些欄位提供圖形化開關，也可能只允許透過 YAML 修改。首推 Clash Plus 是基於全平台圖形化操作與常用設定涵蓋範圍，並不改變底層協定必須與伺服器端匹配這項事實。

設定相容性是「基礎相容加上擴充識別」

一份只使用基礎連接埠、一般策略群組、DOMAIN-SUFFIX 規則與 SS 節點的設定，通常容易在多個 Clash 家族核心之間遷移。加入 mihomo 專屬協定、規則集格式、DNS 選項或 TUN 擴充後，遷移至舊核心可能失敗。失敗方式有三種：設定檢查直接回報未知欄位；未知欄位被忽略，導致行為與預期不同；節點能夠顯示，但連線時因缺少協定實作而失敗。第二種最隱蔽，因此遷移後必須驗證實際流量路徑。

設定檢查是成本最低的第一步。mihomo 可透過指令檢查語法與欄位是否能被目前核心接受。指令中的路徑應替換為本機實際的設定位置：

mihomo -t -f config.yaml

檢查通過只代表 YAML 結構與已知欄位基本有效，不代表訂閱位址可存取、節點驗證正確或 DNS 路徑符合預期。接著應啟動客戶端，查看執行日誌是否出現 provider 更新、憑證、DNS 或監聽連接埠錯誤，再分別驗證直連規則、代理規則與最終 MATCH 規則。

六、訂閱格式、節點欄位與相容性判斷

分享連結、YAML 與訂閱轉換

常見訂閱可能回傳完整的 Clash YAML、節點分享連結集合，或由伺服器端依客戶端類型動態產生內容。完整 YAML 可以同時攜帶節點、策略群組、規則與 DNS；分享連結通常只描述單一節點；訂閱轉換服務則會將上游資料重新組成某種客戶端格式。三者包含的資訊量不同，成功匯入也不代表內容完整。

SS 分享連結通常包含加密方式、密碼、伺服器與連接埠；VMess 舊式連結常將 JSON 資訊編碼後傳送；Trojan、VLESS、Hysteria2 與 TUIC 多使用 URI 查詢參數表達 SNI、傳輸、安全層與其他擴充功能。中間工具若不認識新欄位，可能保留節點名稱卻遺失關鍵參數，最後形成「清單存在但全部逾時」的設定。

優先使用服務提供者明確標示為 Clash Meta 或 mihomo 的訂閱格式。只有原始分享連結時，應使用能識別對應協定與擴充欄位的匯入工具。不要連續經過多層轉換，因為每一層都可能重新命名欄位、刪除未知參數或改變轉義。訂閱解析失敗的系統檢查可參考訂閱連結失效或解析失敗的自查步驟。

用最小節點檢查欄位是否完整

排查相容性問題時，可以從訂閱中複製一個節點至獨立測試設定，保留伺服器端提供的全部欄位，再建立一個 select 策略群組。以下範例展示欄位層級，不包含真實伺服器資訊。縮排使用空格，協定參數必須替換為伺服器端的實際值：

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: SS-Test
    type: ss
    server: server.example
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - SS-Test

rules:
  - MATCH,PROXY

這份最小設定適合確認核心能否監聽連接埠、解析節點並建立基本連線。它不應直接覆蓋原有設定，因為其中沒有正式環境所需的 DNS、規則集與本地網路選項。若最小設定可用而完整訂閱不可用，問題通常位於策略群組引用、規則提供者、DNS 或重複的節點名稱；若最小設定也失敗，應回頭檢查協定欄位、驗證資訊、伺服器端狀態與本地網路。

欄位對應比檔案副檔名更重要

檔名為 YAML 並不能保證內容符合 mihomo 結構。有效文件需要正確縮排，清單項目與映射層級必須清楚。訂閱可能以文字形式回傳錯誤頁面、登入提示或逾時資訊，客戶端隨後便會回報解析失敗。檢查時先確認回傳內容開頭是否符合 YAML 或節點連結格式，再查看 HTTP 狀態、編碼與更新日誌。

不同核心對同一概念可能接受別名，但不應依賴未記錄的隱式轉換。例如伺服器名稱可能表示為 sni 或 servername，略過憑證驗證可能使用不同欄位，WebSocket 路徑與請求標頭也有特定的巢狀層級。最可靠的方法是保留訂閱產生器的輸出，並對照目前核心支援的格式。手動遷移時一次只修改一個欄位，修改後立即執行設定檢查。

策略群組還會引用節點名稱或 provider 名稱。重新命名節點後若未同步更新群組內的引用，核心可能回報找不到代理。provider 更新失敗時，既有快取有時仍會讓舊節點顯示，容易誤判訂閱正常。應查看更新時間、日誌與實際選項，確認客戶端使用的是新內容。節點清單為空、某類協定遭到篩選，或更新後欄位遺失，通常都與訂閱格式及核心能力有關。

訂閱安全邊界與本地覆寫

訂閱包含伺服器、驗證與策略資訊，應只匯入信任來源。分享設定前需要移除真實驗證內容。客戶端提供覆寫或合併功能時，應明確哪些欄位來自遠端訂閱、哪些由本地補充。常見做法是讓遠端內容提供節點，本地設定維護策略群組、規則與 DNS；如此訂閱更新不會反覆覆蓋個人規則，但合併順序錯誤也可能造成同名群組被替換。

每次大幅調整前，先儲存可用的設定副本，並記錄目前核心類型。更新訂閱後若連線異常，可以先回復設定，而不是同時更換客戶端、協定與 DNS。一次改變多個變數會讓問題無法定位。常見問答與錯誤現象可在常見問題中繼續查找。

七、依網路、裝置與任務選擇協定

桌面辦公與一般瀏覽

Windows、macOS 與 Linux 桌面環境通常供電穩定，系統也允許客戶端長時間執行。辦公網頁、文件同步、程式碼託管與即時通訊更重視連線穩定性、首個封包的一致性與相容性。已有成熟的 SS、Trojan 或 VLESS TCP 節點時，應優先使用穩定選項，不必為了追求較新的協定名稱而頻繁遷移。SS 設定簡單，Trojan 的 TLS 部署清晰，VLESS 則適合已採用較新伺服器端組合的環境。

就客戶端而言，Clash Plus 適合需要圖形介面、系統代理、TUN 與訂閱管理的使用者；Clash Verge Rev、FlClash 與 Clash Nyanpasu 也可依作業系統與操作偏好選擇。伺服器或腳本環境則可直接使用 mihomo 核心。客戶端差異主要在介面與系統整合，協定能否連線仍由核心與節點欄位決定。安裝入口集中在下載中心。

辦公網路中若 UDP 表現不確定，先使用 TCP 協定建立穩定基準，再決定是否測試 Hysteria2 或 TUIC。策略模式建議維持 rule，讓業務網域依規則進入對應策略群組；全域模式適合短時間診斷，不宜用來掩蓋規則錯誤。使用 url-test 選擇節點時，要理解它是依測試位址的延遲選出較佳者，不會持續評估所有業務的真實吞吐量。

高延遲、隨機封包遺失與持續傳輸

當網路往返時間較高、偶發封包遺失明顯，且任務以影片、遠端檔案或持續下載為主時，Hysteria2 與 TUIC 值得優先測試。它們的 QUIC 傳輸與壅塞控制可能比保守的 TCP 更快恢復傳送。但測試前應確認 UDP 能持續使用，並確保伺服器端位於可比較的線路上。若 UDP 受限，Trojan、VLESS 或 SS 的 TCP 組合通常更可預期。

持續傳輸情境應觀察十分鐘以上，而不是只看開始幾秒的峰值。記錄平均吞吐量、最低吞吐量、斷流次數，以及同時瀏覽網頁時的延遲。如果高吞吐量造成其他應用程式明顯排隊，應降低並發數或調整頻寬參數，而不是繼續提高傳送上限。家庭共用網路尤其需要平衡單一裝置吞吐量與整體延遲。

即時語音、線上會議與互動式遠端桌面更重視抖動與封包遺失恢復，不一定需要最高頻寬。Hysteria2 或 TUIC 在合適網路下可能改善波動，但持續重傳也可能產生反效果。應進行實際通話或互動測試，並保留一個穩定的 TCP 節點作為 fallback。fallback 策略群組會依序檢查可用性，適合明確的主備關係；它與依延遲選擇最佳節點的 url-test 並非同一種邏輯。

行動裝置與頻繁網路切換

Android 與 iOS 的選擇應將耗電、背景限制與網路遷移放在同一層面考量。輕量瀏覽、訊息與電子郵件可以先選擇成熟的 SS、Trojan 或 VLESS 節點；長時間影片與大型檔案任務再比較 Hysteria2、TUIC。若裝置經常在 Wi-Fi 與行動網路之間切換，可以觀察 QUIC 連線恢復是否更平順，但仍需接受系統切換網路時可能短暫重連。

行動端測試至少應持續一個完整的使用週期。保持螢幕亮度、應用程式組合與網路條件接近，比較完成相同任務後的電量變化。瞬時 CPU 占用較高不一定代表總耗電較高，因為更快完成傳輸可能縮短無線模組活躍時間；反之，背景持續傳送小封包與頻繁重試可能看似負載不高，卻延長喚醒時間。客戶端遭系統回收時，應先調整背景權限，而不是立即更換協定。

路由器、低功耗主機與家庭閘道

路由器與低功耗主機的處理器、記憶體及散熱餘裕有限，選擇協定時需要留意持續 CPU 占用。SS 往往是較穩妥的起點，實際加密演算法應配合硬體能力進行測試。Trojan 的 TLS、VMess 的封裝，以及 QUIC 協定在高吞吐量下可能增加計算壓力。裝置無法跑滿線路時，應先查看單核心占用、軟中斷與溫度，再判斷是協定瓶頸還是系統轉送瓶頸。

作為家庭閘道時，連線數與 DNS 請求量通常高於單一裝置。規則集規模、TUN 網路堆疊、連線追蹤與日誌層級都會影響資源。不要只靠更換協定來解決整體負載，也應同時精簡重複規則、避免長期啟用除錯日誌，並為 DNS 快取設定合理策略。mihomo 核心適合需要完整規則與多協定支援的閘道，但圖形客戶端通常更適合個人電腦。

八、驗證、遷移與故障定位方法

建立可重複的驗證流程

協定遷移不應從刪除舊節點開始。先保留目前可用的設定，將新節點加入獨立策略群組，並使用相同規則測試。第一步執行設定檢查，確認 YAML 與欄位能被目前核心解析；第二步在客戶端中選擇新節點，測試基本 TCP 連線；第三步確認 DNS 查詢與規則命中；第四步再測試 UDP、持續傳輸與網路切換。每一步只驗證一個層級，失敗時才能快速回退。

基本連線成功後，應分別驗證短連線、長連線與多並發。短連線可連續開啟多個未快取頁面，觀察首個封包與失敗率；長連線可維持檔案傳輸或影片播放，觀察十分鐘以上的波動；多並發則用於確認策略群組與核心在日常負載下是否穩定。行動端還要鎖定螢幕一段時間，再解鎖觀察連線能否恢復。一次測試無法涵蓋所有狀態。

判斷代理是否確實生效時，不要只看介面開關。請檢查系統代理或 VPN 狀態、連線面板中的目標網域、規則命中情況與出口結果。首次連線的完整操作可參考選擇節點、測試延遲與確認代理生效。若所有節點同時逾時，再依節點逾時排查順序區分客戶端、節點與本機網路。

依故障層級定位，不要反覆重新安裝

設定解析錯誤通常發生在連線之前，日誌會指出 YAML 行號、未知欄位或策略群組引用。此時應檢查縮排、冒號後的空格、清單層級與核心支援，不需要更改防火牆。節點能顯示但連線逾時時，則檢查伺服器、連接埠、協定類型、驗證資訊與本地網路。TLS 握手錯誤應重點檢查系統時間、SNI、憑證驗證與 ALPN。QUIC 節點在驗證後斷流，則應進一步檢查 UDP 路徑、壅塞控制與伺服器端世代。

只有部分網站異常時，協定本身通常不是第一個嫌疑。應查看規則是否將網域送入預期的策略群組、DNS 是否回傳適合目前模式的結果，以及應用程式是否繞過系統代理。TUN 模式能接管更多應用程式流量，但也會引入路由、權限與 DNS 接管等變數。排查時可以暫時使用最小規則確認連線，再逐項恢復規則與 DNS 設定，避免長期使用全域模式掩蓋規則錯誤。

所有協定突然失效時，優先檢查訂閱更新、系統時間、本地監聽連接埠、系統代理、VPN 權限、防火牆與目前網路。單一節點失敗而同協定的其他節點正常，問題更可能出在伺服器端或節點欄位。若只有某一協定全部失敗，則比較核心支援、訂閱轉換與該協定所依賴的傳輸層。這樣分組判斷，比逐一隨機點選節點更快。

從舊核心遷移至 mihomo

遷移前先列出舊設定中的連接埠、代理節點、策略群組、規則、DNS、TUN 與 provider。第一輪只遷移基礎連接埠、一個可用節點、一個 select 群組與 MATCH 規則，確認核心能正常執行。第二輪加入 DNS 與常用規則，第三輪再加入遠端 provider、TUN 與新協定。分階段遷移能明確找出是哪一組功能造成差異。

原版 Clash 設定中的基礎欄位通常可以繼續使用，但舊教學中的預設值不應直接視為 mihomo 的最佳設定。特別是 DNS 增強模式、Fake-IP 範圍、嗅探、TUN 網路堆疊與規則集格式，應依目前客戶端與系統調整。遇到棄用提示時，請依目前核心文件替換欄位，不要只靠關閉日誌來隱藏問題。

遷移新協定時，保留伺服器端產生的完整節點物件。VLESS 的流量控制與安全層、Hysteria2 的驗證與頻寬欄位、TUIC 的 UUID、密碼與壅塞控制，都不應根據舊節點範本自行補寫。設定通過後，再將節點納入 url-test 或 fallback 群組。自動群組的測試位址與間隔會產生額外請求，行動端不宜設定過短的間隔。

建立長期可維護的設定

穩定的設定應將變更頻率不同的內容分開：訂閱負責更新節點，本地策略群組表達選擇邏輯，規則負責流量分類，DNS 與 TUN 負責系統接入。不要在多個位置重複維護同一節點，也不要讓遠端更新覆蓋關鍵的本地設定。節點名稱應清晰且穩定，策略群組名稱避免頻繁修改，以免規則與應用程式引用失效。

每次變更記錄四項內容：修改了哪個層級、預期解決什麼問題、如何驗證，以及如何回退。若協定遷移沒有明確目標，就應保留目前的穩定方案。SS、VMess、Trojan、VLESS、Hysteria2 與 TUIC 都有適用界線，最終選擇應由可用的伺服器端、網路特性、裝置資源與任務類型共同決定，而不是由協定新舊順序決定。

簡化後的決策路徑是：一般瀏覽先選擇穩定的 TCP 協定；高延遲持續傳輸再測試 Hysteria2 或 TUIC；新協定與擴充功能優先使用 mihomo；行動端額外比較背景恢復與總耗電；訂閱異常先核對格式與欄位；更換協定後依設定、連線、DNS、規則、應用程式五個層面逐項驗證。完成這套流程後，協定選擇就會從一次性測速，轉變為可重複的工程判斷。