Clash 協定與核心選擇

選擇順序：先釐清五個層次

Clash 設定中的 SS、VMess、Trojan 等名稱，描述的是代理端點之間如何驗證身分、封裝及轉送資料，並不直接說明應用程式流量如何進入用戶端。瀏覽器使用系統代理、應用程式連線至本機 SOCKS 連接埠，以及透過 TUN 接管系統路由，是不同的流量入口。入口會影響接管範圍，卻不會把伺服器上的一種協定變成另一種。選擇時應先分清本機入口與遠端協定，避免把接管問題誤認為協定效能問題。

分開判斷用戶端介面與核心能力

用戶端負責管理訂閱、顯示代理群組、切換系統代理及申請權限；核心則負責解析設定、比對規則、解析網域名稱並建立外連。介面顯示某種協定名稱，不代表目前執行的核心一定支援所有擴充功能。反過來說，核心能讀取某個欄位，用戶端的編輯器也可能還沒有提供對應的輸入欄位。確認支援範圍時，應一併記錄用戶端名稱、實際執行的核心名稱，以及節點使用的傳輸組合。

協定名稱之外，還可能疊加傳輸層與安全層。以 VLESS 為例，連線可使用不同傳輸方式，也可能搭配 TLS 或 REALITY；VMess 則要區分協定驗證與外層傳輸。只比較兩個節點的協定簡稱，等於忽略連線路徑中的重要環節。伺服器位址、線路距離、電信業者互連、出口壅塞和伺服器端限制，都可能比協定本身的處理開銷影響更大。

連線成功、首位元組與持續傳輸量是不同指標

建立連線所需時間包含網域名稱解析、傳輸交握、驗證及可能的安全交握。網頁首位元組也會受到目標網站回應與規則處理影響；大型檔案的傳輸量則更受壅塞控制、頻寬和伺服器資源左右。某種協定初次連線可能較慢，但重用連線後表現穩定；另一種協定短請求反應快，長時間下載卻可能受到伺服器速率限制。測試前應先釐清要評估的工作，不要只看用戶端顯示的單一延遲數值。

UDP 支援也要逐層確認。節點協定支援轉送 UDP，不代表目前的應用程式已透過 UDP 入口進入代理；節點設定啟用了 UDP，也不代表伺服器端接受相應的轉送。遊戲、語音及部分即時通訊應用尤其需要確認這一點。至於以 QUIC 為基礎的外連協定，用戶端連至伺服器本身也需要 UDP 可連通；這和代理內部承載的應用流量是否使用 UDP，是兩個獨立問題。

建立可供複查的選擇依據

實際操作可分四步：先核對服務端提供的完整參數，再確認用戶端核心是否支援，接著驗證流量入口與規則是否生效，最後比較相同工作下的使用體驗。記錄成功率、首次載入、持續傳輸和切換網路後的恢復情況，不要只記一次偶然出現的最低延遲。若兩個節點不在同一台伺服器或走不同網路路徑，測試結果只能反映這兩項服務的差異，不能據此推論協定整體優劣。將這些限制記錄下來，日後更換用戶端時才有可沿用的判斷標準。

Shadowsocks 與 VMess：輕量轉送與協定驗證

Shadowsocks 通常簡稱 SS，設計重點是以相對直接的方式提供加密代理轉送。常見用戶端會分別處理 TCP 連線與 UDP 資料報，不強制加入網頁傳輸層，因此設定通常較精簡。簡潔來自明確的協定界線，不代表能自動解決所有網路問題。實際安全性與可用性取決於加密方法、金鑰管理、用戶端實作及伺服器設定，不能只憑 SS 這個統稱下結論。

區分傳統 AEAD 方法與 Shadowsocks 2022

常見 AEAD 方法會結合加密與訊息驗證，接收端能偵測密文是否遭到竄改。Shadowsocks 2022 是另一組需要明確支援的協定方法，不能視為舊方法的別稱。它對金鑰格式等參數另有要求，有些服務也涉及多使用者的相關規範。把原節點的加密方法名稱改成另一種，並不能完成遷移；伺服器端與用戶端必須使用相符的實作與認證資料。

排查 SS 節點時，先確認 cipher 是否受支援，再檢查密碼或金鑰格式、伺服器連接埠及 UDP 開關。有些節點還需要外掛程式；外掛程式負責的傳輸封裝並非 SS 核心協定的一部分。訂閱轉換若遺漏外掛程式參數，可能會出現節點名稱與位址都正常，卻無法連線的情況。此時應回頭查看原始節點說明，而不是反覆更換本機監聽連接埠。

VMess 的設計重點與驗證界線

VMess 源自 V2Ray 生態系，將使用者身分驗證與代理請求封裝納入協定設計，並能搭配不同的底層傳輸方式。它和 SS 的差異不只是把密碼換成 UUID。VMess 有自己的請求格式、驗證機制及資料保護方式，連線也可能再疊加 TLS、WebSocket 等層次。使用時必須同時符合使用者識別碼、協定設定與外層傳輸參數；其中任何一層不一致，都可能導致交握失敗。

閱讀舊設定時，可能會遇到 alterId 或 alter-id。這些欄位涉及舊版相容方式；目前常見的 VMess AEAD 設定通常使用零值，但不能因此任意修改服務提供者給的其他參數。不同軟體對欄位名稱的表示方式也不盡相同。閱讀舊教學時，應放回特定核心的脈絡理解，避免把另一種設定格式中的物件直接貼進 Clash YAML。

VMess 的驗證機制與系統時間有關。裝置時間明顯不準時，即使位址和 UUID 正確，也可能無法通過驗證。排查時應確認系統自動校時正常，而不是降低憑證驗證標準。系統時鐘也會影響 TLS 憑證的有效期限判定，但這是不同的故障環節。若記錄檔顯示時間或驗證錯誤，應先校正裝置時鐘，再重新連線。

如何比較資源開銷與適用情境

在網路穩定、端點實作成熟且沒有額外封裝的情況下，SS 的處理流程通常較直接，適合需要廣泛相容性的日常轉送。評估 VMess 的實際開銷時，則必須一併考量傳輸組合：直接傳輸與經過 WebSocket、TLS 的連線，在交握次數和封裝流程上都不同。不能把經過多層封裝的 VMess 和直接連線的 SS 測試結果，簡化成兩種協定天生存在固定速度差異。

行動裝置還要留意連線數量與背景執行情況。持續下載時，加密運算可能是資源消耗的一部分；在零星訊息的情境中，無線模組喚醒、DNS 請求和維持連線往往更關鍵。選用 SS 或 VMess 時，應優先採用服務端明確支援、目前用戶端能完整解析的組合。如果舊節點只能依賴已缺乏維護的用戶端，應評估伺服器端的遷移方案，而不是長期綁定舊程式。

Trojan 與 VLESS：驗證與安全傳輸的分工

Trojan 與 VLESS 常和 TLS 一起出現，但兩者並非同一種協定換了名稱。常見的 Trojan 部署會以 TLS 連線承載代理請求，並透過與密碼相關的驗證資料識別使用者；VLESS 則著重精簡代理協定本身，將傳輸保護交由外部安全層處理。比較時應分清使用者驗證、防止傳輸內容遭到讀取，以及驗證伺服器身分等不同目的；這些功能並非由同一個欄位一併完成。

Trojan：先完成 TLS，再確認代理驗證

標準 Trojan 連線需要正確的 TLS 設定。用戶端連線的伺服器位址可以是網域名稱或 IP，但 TLS 驗證涉及憑證所代表的身分。sni 通常用來傳送伺服器名稱，並參與相關連線處理；不能填入任意網域，期待系統自動配對。伺服器憑證、預期名稱、連接埠和密碼都必須正確。有些部署會透過前置服務分配連線，相關額外設定也必須由服務提供者說明。

Trojan 可承載 UDP 轉送，但在常見實作中，應用程式的資料報仍會透過 TLS 使用的可靠位元組串流傳送。這表示本機看似使用 UDP 的應用程式，遠端傳輸路徑仍可能受到 TCP 隊頭阻塞影響。是否適合即時通訊，應實測實際封包遺失和互動體驗，而不只是檢查節點的 UDP 標記。不同的擴充實作可能提供其他傳輸方式，不能將其行為視為所有 Trojan 服務的共同特性。

VLESS：協定精簡不代表傳輸預設加密

VLESS 的身分參數通常使用 UUID，但 UUID 是驗證識別碼，不能取代 TLS 加密開關。經典 VLESS 設定中的 encryption: none 表示該協定層不提供相應的資料加密，不代表整條連線一定沒有保護；安全與否要看外層實際使用的 TLS、REALITY 或其他明確支援的方案。反過來說，缺少安全層的設定也不能因為使用 VLESS，就被視為已經加密。

VLESS 的傳輸組合較多，用戶端支援與否必須細分到所需功能。flow 不是可以任意填寫的最佳化標籤，而是必須搭配特定資料流處理機制及端點實作的參數。例如使用 Vision 相關流程時，須確認伺服器端、核心、傳輸方式與安全層都符合要求。直接複製其他節點的 flow，可能讓原本能建立的連線直接失敗。

REALITY 並非普通 TLS 開關的另一種寫法。使用相關方案時，公鑰、短識別碼、伺服器名稱及相關交握參數都必須符合伺服器端設定。不同軟體格式中的欄位名稱可能不同，應以目前使用的核心文件為準。瀏覽器指紋類參數會影響特定交握行為，但無法修正錯誤的連接埠、無效的使用者識別碼或不相符的公鑰，也不應當作通用的加速選項。

傳輸選項如何影響選擇

WebSocket、gRPC 等傳輸方式常用來配合既有服務架構，會增加各自的路徑、服務名稱、請求標頭或中介層要求。多一層封裝不一定比較慢，因為實際瓶頸可能在網路線路而非處理器；但設定項目更多，排錯時也需要檢查更多條件。一般使用者若沒有明確的架構限制，應優先選擇服務提供者說明完整、用戶端原生支援且參數較少的組合。

Trojan 與 VLESS 都不應靠關閉憑證驗證來彌補部署錯誤。憑證過期、伺服器名稱不相符及系統時間偏差，應分別處理；略過驗證會改變安全界線，還常常掩蓋真正的問題。如果匯入節點後需要額外填寫敏感參數，應直接在本機用戶端處理，不要把完整訂閱和認證資料放進公開截圖。分享排查資訊時，只要保留協定類型、錯誤類別與欄位名稱即可。

Hysteria2 與 TUIC：以 QUIC 為基礎的不同取捨

Hysteria2 與 TUIC 都採用 QUIC，但不代表兩者能互相匯入或共用驗證參數。QUIC 在 UDP 上實作加密傳輸、可靠資料流與連線管理，為協定提供有別於 TCP 的基礎。Hysteria2 更著重複雜網路路徑下的傳輸與頻寬運用；TUIC 則以 QUIC 建構代理請求與資料轉送，並提供自己的驗證及 UDP 處理機制。兩者的設定欄位和伺服器端都必須分別相符。

QUIC 能解決什麼，又有哪些限制

QUIC 能在同一條連線中承載多個資料流；其中一個資料流發生封包遺失時，不必像單一 TCP 位元組串流那樣，讓所有資料流都等待同一段遺失資料。不過，連線內的壅塞控制、可用頻寬和部分資源仍由各資料流共享，因此不能視為各項請求完全互不影響。QUIC 也無法消除實體距離、嚴重壅塞或伺服器效能限制。若網路直接封鎖 UDP，以 QUIC 為基礎的連線甚至無法建立。

連線遷移是 QUIC 的能力之一；實際上能否在 Wi-Fi 與行動網路切換後繼續使用，還取決於代理實作、伺服器端策略和用戶端的執行狀態。行動作業系統可能暫停程式或回收資源，用戶端也可能主動重建通道。測試切換網路後的恢復情況時，應觀察應用程式請求能否再次成功、連線是否穩定；不能只因協定有連線識別碼，就斷定所有切換都能維持服務工作階段。

Hysteria2：頻寬參數應符合實際網路

Hysteria2 與早期 Hysteria 的設定格式不能任意互換。選擇 hysteria2 類型後，應使用對應的驗證、TLS 與其他選用參數。混淆相關設定也必須符合伺服器端設定，不能為了嘗試連線而任意啟用。標準連線仍須正確驗證伺服器身分與憑證；採用 QUIC 並不代表可以省略這些要求。

Hysteria2 的頻寬協商與壅塞控制行為取決於兩端設定。用戶端可能會用 up、down 等欄位表示上傳與下載頻寬，但並非所有部署都要求手動填寫。數值填得越大，不會自動增加可用容量，反而可能造成排隊、封包遺失，並干擾同一網路上的其他裝置。應先閱讀伺服器端要求；若必須明確設定，再依實際可持續使用的頻寬保守調整，不要照無線連線標示的最高速率填寫。

TUIC：驗證、壅塞控制與資料報模式

TUIC 常見設定包含 UUID、密碼與 TLS 相關參數，也可能提供壅塞控制及 UDP 轉送模式選項。實際欄位會因 TUIC 協定版本與用戶端實作而異，因此即使標示「支援 TUIC」，仍須確認伺服器端的實作。不能把 Hysteria2 的驗證字串填進 TUIC 密碼欄位，再期待兩者因為共用 QUIC 基礎而相容。

壅塞控制演算法會影響傳送節奏，以及對網路回饋的反應；它不是適用所有網路的速度檔位。UDP 資料報採用哪種機制轉送，也會影響可靠性、延遲和額外開銷。可靠傳輸方式可避免部分應用程式資料報直接遺失，卻可能增加等待時間；不可靠傳輸方式較接近資料報原本的特性，但要求應用程式能處理封包遺失。選擇前應先釐清實際用途，不要把所有選項都設成看似積極的模式。

先確認網路條件，再比較協定表現

公共 Wi-Fi、企業網路閘道和行動網路對 UDP 的處理方式可能不同。如果 TCP 類型的節點可用，但兩個 QUIC 類型的節點都連不上，應優先檢查 UDP 是否可連通、連接埠策略與網路路徑，再檢查驗證設定。連線長時間運作後才中斷，可能與 NAT 對應、閒置逾時或行動裝置的背景限制有關。先在固定網路完成基準測試，再於實際使用情境驗證，可減少多項因素同時改變造成的誤判。

在高延遲、封包遺失且 UDP 可連通的環境中，可將 Hysteria2 或 TUIC 納入候選，但這不代表有固定的推薦排名。較積極的傳送方式可能提高傳輸量，也可能增加處理開銷和無線活動時間。除了下載速度，也應記錄裝置發熱、同一網路上其他裝置的使用體驗，以及服務穩定性。

連線速度、資源使用與手機電量

比較協定效能時，應盡量在一致條件下進行。同一個用戶端、同一台裝置、相同的流量入口模式和相近的測試時段，是最基本的控制條件。如果伺服器位置、出口頻寬或目標網站不同，測試結果只能說明整條服務路徑的表現。協定處理方式確實有差異，但在一般網頁使用情境中，網域名稱解析和遠端伺服器回應可能占更大比重，不能把所有等待時間都歸因於加密或交握。

分開測量短連線、連線重用與持續傳輸

首次請求可能包含 DNS 查詢、建立 TCP 或 QUIC 連線、TLS 交握與協定驗證；後續請求則可能重用已建立的傳輸連線。測試前應註明是冷啟動，還是已完成暖機的連線。連續點擊延遲測試後，數值可能因快取和連線重用而逐漸降低，但真實應用在閒置一段時間後未必享有相同條件。比較短請求時，可分別記錄首次載入與重複載入的穩定性。

測量大型檔案傳輸時，需要足夠長的觀察時間，避免只記錄一開始的突發速率。也要區分單連線與多連線下載：後者可能同時使用更多網路與處理器資源，不能直接證明協定的單一資料流效率較高。重傳、壅塞回饋和伺服器限速也會影響傳輸曲線。速度測試會消耗網路流量並改變當下負載，不宜每次切換節點後都自動執行大量傳輸測試。

處理器與記憶體沒有跨裝置的固定排名

加密演算法是否使用硬體加速、核心如何管理緩衝區，以及並行連線數量，都會影響處理器使用率。某種演算法在一款處理器上效率高，不代表在舊款行動晶片或小型路由器上也有相同表現。QUIC 實作通常需要在使用者空間處理較多傳輸邏輯，但也不能據此推論它在所有工作負載下都更耗資源。應結合實際傳輸量與系統排程狀況觀察。

記憶體使用量也會受到規則集、DNS 快取、連線追蹤、記錄檔層級和介面框架影響。拿包含大型規則集的用戶端與精簡設定的用戶端比較，不能得出協定記憶體使用量的結論。路由器出現記憶體不足時，應先檢查連線規模、規則載入情況和記錄檔，再決定是否更換協定。桌面用戶端顯示的整個程式使用量也可能包含介面，不等於代理核心單獨的使用量。

手機耗電主要取決於無線活動與背景執行策略

手機網路模組頻繁喚醒、連線保活過於密集、訊號弱時反覆傳送，以及應用程式在背景發出請求，都可能增加耗電量。維持一條閒置連線和持續傳輸影片的耗電方式不同，因此不存在可信的通用協定耗電排名。評估時至少要分別記錄螢幕開啟時瀏覽、鎖定螢幕待機和持續傳輸的情況，並盡量固定螢幕亮度、訊號強度、網路類型和應用程式負載。

Android 的電池最佳化可能會暫停用戶端，表現為鎖定螢幕後連線中斷；解除相關限制有助於持續執行，但也會讓更多背景活動得以進行。iOS 的網路延伸功能受系統生命週期管理，不能照搬桌面系統的背景執行策略。發生中斷時，應檢查系統設定與用戶端記錄檔，不要直接調高保活頻率。過於頻繁的連線探測，即使能維持連線，也可能為了不必要的在線狀態而額外耗電。

若代理顯示已連線，網頁卻仍無法載入，請先依從系統代理到 DNS 的逐項排查清單檢查網路路徑，避免在流量接管尚未生效時就開始比較效能。選擇能穩定滿足需求的組合，比追求一次測得的最高傳輸量更有意義。

Clash、Meta 與 mihomo：核心家族與介面分工

原版 Clash 建立了以 YAML 設定、代理群組和規則分流為核心的使用方式。後續生態系出現不同的核心分支與擴充實作；Meta 通常指 Clash.Meta 這條演進路線，mihomo 則是後續沿用的專案名稱。它們不是三種可以任意疊加的功能外掛。設定能否執行，取決於實際核心支援的節點類型、規則語法和相關模組，而不是檔名是否包含 Clash。

基本語法相近，不代表功能完全相同

許多常見欄位在不同實作中維持相似結構，例如 proxies、proxy-groups 與 rules，讓基本設定較容易移轉。不過，協定擴充、DNS 行為、TUN 參數及規則功能不保證完全相同。原版設定能使用的基本節點，不代表較新的擴充節點也能由原版核心讀取。遇到未知的代理類型時，應先查閱支援範圍，不要試圖靠修改 YAML 縮排掩蓋錯誤。

閱讀資料時，也要區分歷史上的開源版本、Premium 相關功能，以及 Meta 路線的實作。舊文章可能把某項能力簡稱為「Clash 支援」，實際上卻只適用於當時的特定核心。不能把這些說法拼湊成所有用戶端都具備的功能清單。尤其是 TUN、規則提供者、指令碼或特定規則格式，應回到目前使用的核心文件逐項確認。

用戶端名稱不等於核心名稱

一般使用者可從下載頁首頁推薦的 Clash Plus 開始，依作業系統選擇相應用戶端，再查看它實際支援的協定與匯入格式。Clash Verge Rev、FlClash 等同樣是介面用戶端，設定支援能力仍須依其實際內建的核心判斷。Clash Meta for Android 的名稱反映了它和生態系的關聯，但仍要確認目前安裝版本的實際實作。不要只因品牌名稱相似，就推斷設定擴充功能全部相同。

桌面端更新介面程式，不一定代表執行中的核心也已成功切換；有些用戶端允許獨立管理核心，有些則由安裝套件統一提供。排查時可從「關於」頁面、執行記錄或核心管理頁確認實際執行資訊。如果有多個設定資料夾，應確認用戶端目前讀取哪個檔案，避免修改備份檔後，卻把執行狀況沒有變化誤認為核心缺陷。

Clash for Windows 與 ClashX Meta 在本站下載清單中列為已停止維護的封存用戶端。封存版本適合用來了解舊環境與進行遷移，不應作為取得新協定功能的預設選擇。停止維護不代表原有連線立刻全部失效，但後續系統變更、協定擴充和問題修正都不能預期會持續更新。遷移前請保留原設定，並先以副本測試新用戶端。

依功能模組進行跨核心遷移

遷移時先只保留最少數量的節點與一個手動選擇的代理群組，確認驗證和傳輸能正常建立後，再恢復規則、DNS、提供者與 TUN。這樣可以將故障範圍縮小到特定模組。若一次匯入複雜設定後無法連網，節點錯誤、DNS 迴圈、路由接管衝突和規則引用錯誤會混在一起，難以從記錄檔判斷原因。先確認基本連線正常，再逐步加入功能，通常比整份設定一起除錯更快。

服務模式與管理員權限屬於系統整合條件，不是遠端協定的屬性。核心支援 TUN，不代表一般權限的程式就能直接建立虛擬網卡或修改路由。需要接管更多應用程式時，可繼續閱讀TUN 模式與虛擬網卡說明。伺服器與路由器使用者則應區分圖形介面用戶端和獨立核心部署，並參考OpenWrt 與旁路由部署概覽評估資源和網路拓撲。

訂閱格式相容性：連結、節點與完整設定

訂閱是交付設定的方式，不是獨立的代理協定。訂閱網址傳回的內容可能是完整的 Clash YAML、多個分享連結、經編碼的節點清單，或其他軟體使用的設定格式。用戶端能下載該網址，只代表收到回應，不代表回傳內容可以直接作為目前核心的設定。匯入前先確認內容類型，比看到「格式錯誤」後一再更新更有效。

單一節點分享與完整 YAML 的資訊範圍不同

ss://、vmess://、trojan:// 等分享格式通常描述單一外連節點，欄位編碼方式也可能受生態系規範影響。這些格式不一定包含代理群組、分流規則、DNS 和本機連接埠。完整的 Clash 設定則通常會以這些模組組成執行環境。把節點連結文字存成 .yaml，不會讓內容自動變成 YAML 設定；副檔名不會改變檔案格式。

同樣地，其他核心的 JSON 設定不能只轉換括號與縮排，就變成 Clash 設定。模組界線、路由表達式和 DNS 語意可能完全不同。轉換工具只能對應它能理解的部分，無法保證保留所有行為。涉及 REALITY、特定流量控制、外掛程式或新協定參數時，轉換後尤其需要逐欄確認。節點數量相同，也不代表連線所需資訊完整。

代理提供者不是另一份頂層設定

proxy-providers 可從外部來源載入節點清單，再由代理群組引用。提供者檔案通常只負責節點清單，不應預設會一併合併另一份完整訂閱中的連接埠、DNS 和規則。如果來源實際傳回完整設定，能否擷取節點取決於用戶端或核心支援的處理方式。應依提供者要求的結構準備內容，不要把「主設定匯入成功」的經驗直接套用到提供者。

以下是可獨立解析的本機分流基準設定，不含遠端節點。它用來確認連接埠、選擇群組與規則結構，不適合衡量代理效能。匯入實際節點後，再將節點名稱加入對應的代理群組；若直接使用完整訂閱，請先確認用戶端的合併策略，避免本機規則遭到覆蓋。

mixed-port: 7890
mode: rule
proxies: []
proxy-groups:
  - name: 手動選擇
    type: select
    proxies: [DIRECT]
rules:
  - MATCH,手動選擇

設定解析成功後，還要檢查引用關係

YAML 對縮排、清單層級和字串表示方式都有要求，含有特殊符號的值應使用正確的引號。協定欄位型別也很重要，布林值與字串不能任意混用。不過，語法正確只是第一步：代理群組引用的節點名稱、規則引用的群組名稱，以及規則提供者名稱都必須確實存在。訂閱更新後若節點改名，本機手動設定的群組仍使用舊名稱，就可能造成引用失效。

用戶端常透過覆寫、合併或指令碼保留本機設定。各種機制的執行時機和覆蓋範圍都不同，最後生效的檔案可能不是下載的原始檔案。排查時應檢查執行中的設定，確認節點與規則最終如何組合。不要只在訂閱編輯器中搜尋某個欄位，就認定核心已經讀取。必要時，可暫時停用本機覆寫，先以副本驗證原始訂閱，再逐項恢復設定。

分別處理更新失敗與格式不相容

HTTP 錯誤、重新導向至登入頁、回應內容為空，以及 YAML 解析失敗，都是不同問題。訂閱網址有時包含存取憑證，不應交給不可信任的線上轉換服務；轉換過程會讓服務取得完整節點資訊。請優先使用用戶端內建的匯入功能，或自行掌控處理流程。更新步驟詳情請參閱訂閱更新失敗與自動更新設定。

更新前請保留可正常運作的設定副本；更新後先檢查節點類型與代理群組，再驗證規則和 DNS。如果伺服器端新增目前核心不支援的類型，應選擇相容的訂閱格式或更新受支援的用戶端，不要只刪除錯誤欄位。刪除欄位後或許能通過解析，但驗證或傳輸語意也可能已經改變，反而造成更難排查的連線失敗。

依情境選擇協定：保留基準，再進行比較

實際選擇時應從現有服務條件出發，不要先指定協定名稱，再設法湊出所有參數。協定必須由伺服器端和用戶端共同支援；本機更改 type 不會讓遠端自動升級。如果服務提供者只提供一種經過驗證的組合，應先確認它能否滿足目前需求。只有遇到明確限制，例如 UDP 無法連通、切換網路後恢復不穩或裝置資源不足，再加入另一種組合進行有目的的比較。

桌面瀏覽與行動日常使用

桌面網頁與辦公應用通常應優先考量穩定性、網域名稱解析與規則比對。SS、VMess、Trojan、VLESS 的成熟相容組合都可列入候選，不必只為了追求較新的名稱而更換穩定連線。用戶端可優先從 Clash Plus 及下載頁的平台清單中選擇；確認架構與系統需求後，再檢查目標節點完整的傳輸支援情況。安裝後的基本操作請參閱使用指南。

行動裝置還應測試鎖定螢幕、切換網路與背景恢復。先在固定 Wi-Fi 網路上測試，再切換至行動網路；若問題只在切換後發生，應觀察用戶端是否重新建立連線，而不是立刻更換驗證參數。若使用 TUN 接管，也要檢查系統 VPN 權限及其他網路延伸功能是否衝突。用戶端遭系統暫停，和代理伺服器拒絕驗證，是完全不同的問題。

高延遲網路與即時服務

當網路延遲較高且有封包遺失時，只要 UDP 可連通，就可將 Hysteria2、TUIC 與現有的 TCP 類方案放在一起比較。測試重點應包括互動等待時間、持續傳輸，以及對其他應用程式的影響，不只是下載峰值。如果 QUIC 類連線在公共網路上頻繁中斷，保留一個已驗證的 TCP 類候選會更實用。備援路徑應事先測試，不要等主要路徑失效後才第一次匯入。

語音、遊戲等即時服務需要確認資料報轉送是否貫穿整條網路路徑，並留意是否出現長時間等待或週期性中斷。可靠傳輸會改變封包遺失的表現，卻不一定改善即時體驗；有些應用程式寧可丟棄過期資料，也不願等待重傳。應以實際服務測試，同時留意目標服務是否會因位址變更而受影響，避免把服務端工作階段失效誤判為代理協定異常。

路由器與低資源裝置

路由器應先評估處理器架構、可用記憶體、並行連線規模和規則集大小。資源有限時，精簡規則、降低不必要的記錄檔，以及避免重複進行健康檢查，通常比單純更換協定直接。不同加密實作與 QUIC 處理開銷，都需要在目標硬體上測試。不能拿桌上型電腦的表現推估小型路由器，也不能把網路埠的硬體速率當成啟用代理後必定達到的傳輸量。

旁路由情境還要確認閘道、DNS 與回程路徑。終端裝置的請求沒有經過代理設備時，選擇哪種協定都不會產生效果；DNS 指向錯誤或路由迴圈，也可能讓所有節點同時失效。先用最精簡的網路拓撲驗證單一終端，再逐步擴展到整個網路。對已穩定運作的裝置，最好分兩次更換核心與協定，才能判斷變化來自哪個層次。

完整的對照測試記錄

1. 記錄裝置、作業系統、用戶端與實際核心，確認沒有同時執行多個流量接管程式。
2. 儲存原始設定，選定固定網路和固定服務，並核對節點驗證、傳輸與憑證參數。
3. 分別觀察首次請求、持續使用、閒置後恢復與切換網路的情況，不要混用不同工作的測試結果。
4. 每次只變更一項條件；發生錯誤時記下錯誤類別，再回到正常基準確認網路仍可使用。
5. 選用能穩定滿足需求的組合，保留已驗證的備用方案，並在重要更新後重新測試。

最終判斷可歸納為三項：設定能否正確表達伺服器端要求、裝置能否在可接受的資源消耗下持續執行，以及實際網路能否穩定承載該傳輸方式。三項都符合後，再比較使用體驗。協定名稱只是查閱資訊的入口，並非品質保證；能在特定裝置與工作情境中重複驗證的結果，才是長期保留某個節點與用戶端組合的依據。