代理協定與核心參考.

分清用戶端、核心與協定

用戶端是操作介面，負責顯示節點、匯入設定、管理系統代理及申請必要權限；核心負責解析設定、比對規則並建立連線；協定則規範用戶端與伺服器如何驗證身分、封裝及轉送資料。同一個介面可能支援切換核心，同一個核心也可能由多種介面使用。因此，用戶端名稱含有 Clash，不代表它支援所有 Clash 設定，更不能據此判斷某個節點一定連得上。

節點也不只是協定類型。完整連線通常包含伺服器位址、連接埠、驗證資訊、傳輸方式、加密或 TLS 設定，以及可能用到的路徑、主機名稱與其他選項。兩個都標示為 VLESS 的節點，可能分別使用 TCP 與 WebSocket，憑證和伺服器部署方式也可能完全不同。比較前應先展開節點詳細資訊，確認這些條件；只看清單上的類型標籤，容易把線路差異誤認為協定差異。

先確認支援範圍，再比較效能

第一步確認服務提供者實際提供哪些類型，以及是否提供 mihomo 可直接讀取的設定。第二步檢查用戶端目前使用的核心，不要只看應用程式商店的介紹。第三步確認目前網路是否支援對應傳輸方式，尤其是以 QUIC 為基礎的方案需要 UDP 路徑可用。前三項都符合後，才值得比較網頁開啟速度、長時間下載是否穩定、視訊會議會不會卡頓，以及手機待機後的連線恢復狀況。

依照這個順序檢查，能省下不少重複操作。若核心根本不識別某種類型，換測速網址無法解決解析錯誤；若伺服器只監聽 TCP，用戶端勾選 UDP 也不會讓伺服器多出 UDP 支援；若憑證主機名稱不符，修改規則群組也無法修復 TLS 交握。先判斷問題發生在匯入、解析、連線還是應用程式請求階段，再調整對應設定；每次只更動一類變數，通常比反覆重新安裝用戶端有效。

不要把連線模式當成協定類型

規則、全域與直連模式決定連線路徑；系統代理與 TUN 則決定哪些應用程式的流量會交由核心處理，兩者都不等於節點協定。啟用 TUN 可以讓更多不讀取系統代理設定的應用程式套用規則，但不會把 SS 變成 Hysteria2，也不會自動補上伺服器端的 UDP 轉送。接管範圍擴大後，原本未出現的 DNS、區域網路存取與其他虛擬網卡衝突也可能浮現。

一般使用者應先用已能匯入的設定完成一次穩定連線，再逐步擴大接管範圍。挑選桌面或行動裝置用戶端時，可以先看看首選的 Clash Plus；Linux 桌面則依下載頁選擇 Clash Verge Rev 或 FlClash。各平台的下載入口與安裝格式請參閱用戶端下載頁。此處的推薦是操作介面的建議，不代表不同用戶端中的同名節點會自動擁有不同的線路品質。

比較前也要先訂出明確目標：日常瀏覽關注首次回應時間與失敗率，大型檔案關注持續傳輸速率，遠端終端機關注互動延遲，行動裝置則要看網路切換與背景恢復。沒有明確目標的綜合排名，容易讓人為不需要的功能增加維護負擔。協定只是連線路徑的一環，伺服器負載、出口壅塞、DNS 解析位置與應用程式本身都可能才是主要瓶頸。

Shadowsocks：精簡的協定架構

Shadowsocks，常簡稱 SS，以加密代理轉送為核心，設定方式相對直接，常見必要欄位包括伺服器、連接埠、密碼與加密方法。它不像完整的隧道管理系統那樣負責所有路由策略；哪些網域直連、哪些連線轉送，通常由用戶端規則處理。這樣的職責劃分讓基本設定容易理解，也方便部署在資源有限的裝置上；不過，實際資源消耗仍取決於實作方式、演算法、並行連線數與流量規模。

檢查 SS 設定時，先分辨舊式串流加密、常見 AEAD 方法與 Shadowsocks 2022 系列。這些不只是名稱更新，金鑰格式與實作需求也有所不同。尤其是 2022 方法，密碼通常必須符合對應演算法的編碼與長度要求，不能隨意換成容易記的口令。若核心顯示不支援該加密方法，應核對確切的演算法名稱與核心能力，而不是改選清單上的其他選項。

SS 也可能搭配外掛程式。若伺服器要求特定外掛程式，只匯入位址、密碼與連接埠可能還不夠，用戶端也必須支援對應外掛程式與參數。手機介面能匯入分享連結，不代表實作了連結內的所有擴充功能。UDP 也需要連線兩端與中間網路共同支援；若遊戲或語音無法使用，但網頁正常，應檢查 UDP 轉送與接管範圍，不要立刻認定是密碼錯誤。

VMess：驗證方式與傳輸組合

VMess 源自 V2Ray 生態系，節點設定通常以 UUID 作為使用者識別碼，並將協定驗證與底層傳輸組合使用。常見部署可能搭配 TCP、WebSocket 或其他受支援的傳輸方式，也可能再加上 TLS。彈性較高也代表設定欄位更多：除了位址與使用者識別碼，還要確認傳輸名稱、WebSocket 路徑、請求主機名稱與 TLS 伺服器名稱都符合伺服器設定。少一個欄位也可能導致連線一直等待。

部分舊資料會提到非零的 alterId，以及舊式 VMess 驗證方式。現代設定常見 AEAD 方式，在 mihomo 中通常以 alterId: 0 表示。不要為了讓匯入成功，就把舊設定中的值一律歸零；伺服器端的驗證方式也必須相符。VMess 也要求時間同步，系統時間明顯偏差時可能導致驗證失敗。若憑證正確但同類節點全部連不上，可以先檢查自動校時與時區設定。

如何看待相容性與資源消耗

如果現有的 SS 或 VMess 節點穩定、用戶端能完整解析，常用應用程式也運作正常，就不必只因協定問世較早而轉移。成熟設定的優勢在於行為容易預測，發生問題時也有明確的檢查項目。真正值得轉移的原因應是核心停止維護、缺少必要功能、伺服器調整，或目前網路環境下反覆出現且可驗證的效能問題，而不是一次測速排名的變化。

也不能一概認為 SS 比較省電、VMess 比較耗資源。TLS、外層傳輸、多工、連線數量與硬體加密能力都會改變結果。閒置時頻繁探測的簡單協定，耗電量可能高於能妥善休眠的複雜設定；距離較近的 VMess 節點，也可能比壅塞的 SS 節點回應更快。跨線路測試可以協助挑選節點，卻不能單獨證明協定優劣。

QUIC 解決的是哪一層的問題

Hysteria2 與 TUIC 都採用以 QUIC 為基礎的設計，底層通常透過 UDP 傳輸。QUIC 可在使用者空間實作可靠傳輸、安全交握與多工串流管理，避免某條 TCP 位元組串流上的封包遺失，讓所有邏輯串流都依相同順序等待。不過，網路頻寬仍由所有連線共用，傳送速度仍受壅塞控制限制；多工串流不代表每條連線都能取得獨立頻寬，也不代表封包遺失後不必付出恢復成本。

最先應檢查 UDP 路徑。某些訪客網路只允許有限類型的連線，或無法穩定處理長時間 UDP 連線，因此節點可能在一個網路正常，在另一個網路持續逾時。切換系統代理與 TUN 只會改變本機的流量接管方式，無法保證外部網路允許 UDP。保留一個已驗證可用的 TCP 類節點，通常比繼續新增同類 QUIC 節點更有助於排查問題。

Hysteria2：頻寬設定不是越高越好

Hysteria2 適用於可能有封包遺失與延遲波動的連線環境，提供驗證、TLS 與壅塞控制相關功能。設定中的頻寬參數，必須依核心實作與伺服器端協商方式解讀；它不是訂閱服務提供的頻寬保證，也不是把數值填高就能換得速度。使用依賴頻寬估算的傳送策略時，若設定值遠高於實際線路能力，可能增加排隊與封包遺失，影響同一網路上的其他應用程式。

若伺服器與核心支援協商頻寬資訊，應先依照服務提供者的設定使用；若必須手動輸入，則以目前網路的持續傳輸能力為準，並為互動用途與其他裝置保留空間。手機從 Wi-Fi 切換到行動網路後，原本的估算未必仍適用。Hysteria 與 Hysteria2 也不是只改類型名稱就能互通的同一協定；匯入時必須確認伺服器版本與用戶端實作相符。

TUIC：驗證、壅塞控制與連線維護

TUIC 也透過 QUIC 承載代理連線，常見設定包含 UUID、密碼、TLS 伺服器名稱、ALPN 與壅塞控制選項。不同協定版本與實作之間可能不相容，分享連結看起來相似也不能證明雙方設定相符。若匯入成功卻立即中斷，應核對協定版本、驗證欄位與 ALPN，而不是先縮短心跳間隔。維持一條設定錯誤的連線，無法修復驗證問題。

這兩類協定都可能提供 UDP 中繼、連線保持或交握最佳化選項。部分零往返時間機制仰賴既有連線資訊與雙方支援，也涉及重放攻擊的風險範圍，不適合當成通用加速開關。連線遷移能力同樣取決於實作與網路路徑，無法保證從 Wi-Fi 切換到行動網路後，所有進行中的應用程式連線都能原封不動保留。應用程式仍可能需要重新連線。

在 UDP 可用，而且線路確實有封包遺失或波動的環境中，這兩種方案值得與現有節點一併測試。不過，它們也需要加密、計時器與使用者空間的封包處理，裝置負載與耗電表現應實際測試。不要只因某次大型檔案下載較快，就認定網頁、語音、待機與所有網路切換都會一併改善；效能評估仍應回到具體使用情境。

拆解各階段的等待時間

節點清單中的延遲，通常來自某次特定探測，不等於應用程式瀏覽所有網站的實際耗時。完整請求可能經過 DNS 解析、連線至伺服器、協定驗證、TLS 交握、連線至目標伺服器與等待回應。有些探測會重用既有連線，有些每次都建立新連線；有些經過策略群組，有些則直接測試節點。若兩個用戶端的測試條件不同，顯示的數字就不能直接用同一標準比較。

簡短的網頁請求容易受首次交握與目標回應影響；長時間下載則較容易看出頻寬、封包遺失與持續壅塞的影響；遠端終端機則對偶發排隊與停頓很敏感。多工可能減少重複連線，也可能將更多請求集中到同一條外層連線；遇到壅塞時，體驗是否改善取決於傳輸設計與實作方式。應分別觀察首次開啟、再次瀏覽與持續傳輸，不要只用單一下載速度概括日常體驗。

資源用量不是由協定名稱決定

處理器支援的加密指令、作業系統網路堆疊、核心實作、連線數量與記錄層級都會影響資源用量。在桌上型電腦上差異不明顯的設定，在舊手機或路由器上可能成為瓶頸。QUIC 的使用者空間處理與計時器會增加運算量；傳統協定也可能因外掛程式、多層封裝或大量並行連線而增加負擔。因此，不宜替每種協定列出一組適用所有裝置的記憶體或耗電數字。

查看工作管理員時，應區分用戶端介面與核心程序。視窗動畫、記錄捲動、訂閱解析與背景更新可能消耗介面程序資源，實際流量轉送則由另一個程序處理。測試前先關閉不必要的即時記錄，等訂閱更新完成，並維持應用程式工作一致，再觀察處理器用量與記憶體的持續變化。只看剛啟動時的尖峰，無法推斷長時間使用的成本。

手機耗電常與喚醒頻率有關

行動裝置除了加密負載，也要考量無線網路模組的啟用時間。頻繁健康檢查、過短的心跳間隔、反覆連線失敗與多個策略群組同時測速，都可能讓裝置不斷喚醒。即使每次傳輸的資料很少，也未必省電。先減少不必要的探測、避免重複更新訂閱，再依實際連線中斷情況調整保持連線設定，比單純更換協定更容易找出原因。

Android 的 VpnService 可讓用戶端接收系統流量，但授權成功不代表系統會允許它永遠在背景執行。電池最佳化、廠商的背景管理與自動啟動設定都可能影響連線恢復速度。相關設定可參閱Android 背景常駐說明。允許背景執行只能確保程序存活，不應把所有耗電問題都歸因於這項授權，也不必為了測試而長期關閉所有系統省電策略。

比較時輪流使用候選節點，記錄網路環境、時間、目標與失敗情形，至少涵蓋平常實際使用的任務。若節點位於不同伺服器，結論應寫成「這個節點在目前條件下較合適」，而不是「某種協定永遠更快」。評估手機時也要留意行動網路訊號強弱與螢幕耗電；這些因素變化很大時，系統電池統計無法單獨證明差異來自協定。

訂閱連結、節點清單與完整設定

訂閱網址只是取得資源的入口，並沒有統一規定回傳內容。一個網址可能回傳完整的 Clash YAML、編碼後的多條分享連結，也可能依請求標頭回傳不同格式。完整設定通常包含節點、策略群組、規則與 DNS；節點清單則只提供節點資料。兩者混用時，常見情況是看得到節點，卻沒有預期的策略群組，或匯入後提示缺少必要結構。

proxy-providers 用來讀取獨立資源中的節點，再由策略群組引用；rule-providers 則提供規則集合。這些設定並非只要填入任何完整訂閱網址，就會自動拆解內容。尤其規則提供者的宣告行為與檔案格式必須相符，不能把網域清單、IP 清單與完整規則列視為相同內容。排查前先確認資源實際回傳的結構，再核對引用位置。

轉換時容易遺失哪些資訊

訂閱轉換需要將來源格式對應到目標核心識別的欄位。基本位址與密碼通常容易保留，但較新的協定選項、外掛程式參數、ALPN、flow、REALITY 設定與部分 UDP 傳輸選項，可能因支援度不足而遺失。轉換成功只表示產生了目標格式，不代表節點的所有設定含義都已保留。若某類節點集中失敗，應逐項比對原始節點資料與匯入後的詳細資訊，而不是重複轉換同一份內容。

若服務提供者能直接提供適用於 mihomo 的設定，通常應優先使用該格式，減少中間轉換。確實需要轉換時，應先了解轉換工具是否支援相關協定，以及是否會替換規則範本與 DNS 設定。訂閱 URL 可能包含個人存取憑證，不要提交給不熟悉的資料處理服務，也不要在公開截圖、問題回報或記錄附件中保留完整網址。

用小範例理解結構，不要拼接未知欄位

以下是 mihomo 可讀取的最小直連設定範例，用來說明監聽連接埠、策略群組與規則之間的關係；其中不包含遠端節點，也不會建立遠端代理連線。建議備份後另存為測試檔，用來檢查語法；不要覆蓋正在使用的訂閱設定。實際節點應由可信來源提供，不能靠修改範例中的名稱產生。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
  - name: Route
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,Route

YAML 以縮排表示層級，清單項目開頭的連字號與同層級鍵的位置都會影響設定含義。合併多個訂閱時，重複的節點名稱可能讓策略群組引用產生歧義，重複的策略群組名稱可能覆蓋原有定義，規則順序變動則會改變最先符合的結果。不能只把兩個檔案首尾相接。應為各來源設定清楚的命名範圍，確認所有群組引用都存在，再檢查最終規則是否仍以預期的預設項目結尾。

更新失敗也不一定是格式問題。請求可能逾時、驗證可能失效、回傳內容可能是網站登入頁，遠端規則集也可能暫時無法連線。先查看下載狀態與回傳類型，再檢查解析錯誤；不要把訂閱更新失敗和節點交握失敗混為一談。訂閱更新的常見狀況請參閱訂閱問題；設定切換與備份則可繼續閱讀Profile 入門。

保留一份可正常運作的設定快照尤其重要。備份內容應包括本機規則、策略群組選擇與覆寫邏輯，而不只是訂閱網址。分享排錯資料時可以保留協定類型、欄位名稱與錯誤階段，但應移除驗證資訊、個人網域與訂閱憑證；這樣既方便重現結構問題，也不會讓復原工作變成另一場憑證轉移。

日常桌面與 Linux 工作環境

主要使用瀏覽器、程式碼託管服務與桌面辦公時，先選擇維護狀態明確、能完整讀取訂閱的用戶端，再從現有的 SS、VMess、Trojan 或 VLESS 節點中挑選穩定的一個。跨裝置使用可先看看 Clash Plus；Linux 桌面則依發行版選擇 Clash Verge Rev 或 FlClash。是否需要新協定，應由實際故障或功能需求決定，而不是非得集齊所有類型才算設定完整。

Linux 使用時還要確認應用程式是否遵循系統代理設定。瀏覽器能連線、終端機工具卻失敗，可能是終端機沒有讀取代理環境變數；容器與獨立網路命名空間也不會自動沿用桌面設定。此時先確認流量接管入口，必要時再參照TUN 模式教學處理授權與路由。遠端伺服器與路由器適合由熟悉服務管理的使用者直接執行核心；一般桌面使用者通常更適合圖形介面。

行動網路、即時應用程式與大型檔案

手機經常在 Wi-Fi 與行動網路之間切換時，應關注連線恢復、背景執行與耗電情況，而不只是首次測速結果。若 UDP 路徑穩定，可以將 Hysteria2 或 TUIC 列入候選；若某些網路環境經常逾時，則保留已驗證可用的 TCP 類節點作為備用。尚未確認伺服器能力前，不要對所有節點一律強制多工或啟用額外傳輸選項，否則可能同時引發原本互不相關的問題。

語音、視訊會議與遊戲應關注實際 UDP 支援、延遲抖動與偶發停頓。協定標籤出現 QUIC，不代表所有即時應用程式都會受益；應用程式的伺服器位置、轉送路徑與系統接管範圍同樣重要。傳輸大型檔案時，應觀察持續速度與裝置發熱，同時為互動應用程式保留頻寬。某條線路能跑滿頻寬，不代表它適合作為多人共用家庭網路的預設選項。

用完整測試流程判斷是否值得保留

先備份目前可用的設定，選定一個候選節點，並固定網路環境與測試目標。依序測試一次網頁瀏覽、一次持續傳輸與一項日常互動任務，再查看連線記錄中的策略群組、比對規則與實際出站節點。確認請求確實經由候選節點後，才能記錄體驗差異。若規則讓目標直連，測速結果就與所選協定無關，應先修正測試條件。

發生問題時，依階段檢查：匯入失敗就查格式，啟動失敗就查欄位與引用，交握失敗就查位址、驗證與 TLS，請求回應異常再查目標服務與規則；只有部分應用程式失敗，則檢查系統接管與 DNS。每次只處理一個階段，成功後再進行下一步。連線記錄可能包含目標位址等資訊；排錯結束後應恢復適合日常使用的記錄層級，不要為了收集細節而長期保留高頻輸出。

最後保留的方案應能說明為何適合目前情境，例如相容現有訂閱、行動網路恢復可靠、長時間下載更穩定，或維護項目較少。節點測速與驗證的具體操作請參閱測速與驗證教學；用戶端介面差異則可繼續查看用戶端比較頁。協定、核心與介面各自解決不同問題；分清這三個層次，比追逐單一排行榜更有幫助。