Clash 協定與核心參考

01 / 判斷順序

協定選擇的四層關係

客戶端、核心、協定與線路

客戶端是使用者操作的介面，負責匯入設定、儲存選項及申請系統權限；核心負責解析規則、建立連線與轉送資料。協定則規範客戶端與伺服器如何驗證身分、組織資料及處理傳輸。線路包含本地連線、途中路由與伺服器出口。四個層面彼此配合，卻不能互相取代。更換介面不一定會更換核心，更換協定也不一定會改變出口，更不能因此推論所有應用程式都會變快。

例如，同一台伺服器同時提供 SS 與 Trojan，兩者仍可能共用處理器、出口頻寬及上游路由。晚間壅塞時，兩種協定都可能變慢；只看名稱，容易把線路負載誤判為協定缺陷。反過來說，同一種協定部署在不同伺服器上，憑證設定、壅塞控制、使用者限速及連線數限制也可能不同。因此比較時，應先確認測試對象是否共用線路，再討論協定額外帶來的成本。

拆解單一連線的各個階段

開啟網頁通常會經過網域解析、建立連線、安全交握、送出要求及下載內容。節點測試顯示的單一時間數值，可能只涵蓋其中幾個階段，並不代表網頁完整載入時間。瀏覽器也會同時要求圖片、字型與指令碼，並重複使用已建立的連線。測試結果較快、網頁卻較慢，可能是目標網站回應、解析位置或規則選擇不同，不應直接歸因於加密演算法較複雜。

傳輸層也要和代理協定分開理解。TCP 提供可靠且有序的位元組串流，資料遺失時需要重新傳送；UDP 提供資料報，不會自行保證依序送達。QUIC 執行於 UDP 之上，加入加密、可靠串流與壅塞控制，並非單純取消可靠性。節點支援 UDP 轉送，也不代表節點本身使用 QUIC；應用程式的資料類型，以及客戶端到伺服器的承載方式，是兩個不同層面。

建立可重現的比較條件

比較前記錄裝置、連線網路、代理模式、目標網站與測試時間。盡量使用相同出口，關閉其他裝置的大量傳輸，先開啟一般網頁確認連線正常，再測試持續下載與互動回應。每次只變更一個項目，例如保留規則與 DNS 設定，只切換協定。重複測試並記錄波動範圍，比只保留最佳的一次結果更能反映日常體驗，也能避免把短暫快取誤認為優勢。

安全性判斷也需要分層。傳輸加密保護的是相應鏈路，不會自動改變伺服器營運者的權限，也不能取代網站本身的 HTTPS。應用程式仍須正常驗證網站憑證。節點中的伺服器名稱、憑證名稱與實際連線位址可能不同，但必須符合部署方式。遇到憑證錯誤，應檢查名稱、時間與信任鏈，不要為了連線而停用驗證。

實際選擇時，可依序考量相容性、穩定性、資源消耗與峰值傳輸量。先排除裝置不支援或網路不允許的類型，再確認長時間使用是否穩定，最後在可接受的耗電與流量成本內比較速度。若目前設定已能滿足網頁、會議與檔案傳輸需求，就不必只因協定較新而遷移。後文的差異可用來縮小候選範圍，並非替協定排定固定名次。

02 / 成熟協定

SS 與 VMess 的設計取捨

SS：精簡的資料轉送架構

Shadowsocks 通常簡稱 SS，著重於加密代理轉送，協定架構相對精簡。它的設計重點不是在協定中包辦複雜路由，而是保護客戶端與伺服器之間的資料並轉送至目標。規則比對、策略組與應用程式接管仍由客戶端和核心負責。由於實作普及，SS 常用於重視相容性與部署簡便的環境，但不同實作支援的加密方法並不完全相同。

檢查 SS 設定時，至少要同時確認伺服器、連接埠、加密方法與密碼。加密方法不是可任意調整的本機最佳化選項，必須與伺服器設定一致。較早期的串流加密方式與後來的 AEAD 方案不能視為相同設定；SS 2022 也有獨立規範與金鑰要求。訂閱只標示 SS 並不足以確認可用，還要查看目前核心是否支援指定方法。

常見 AEAD 實作會提供 AES-GCM 或 ChaCha20-Poly1305 等選項。具備硬體加速的處理器可能較適合某些 AES 實作，另一台低耗電裝置的表現則可能不同。不能只看演算法名稱就推測手機續航，也不建議單獨更改訂閱中的方法來測速。若伺服器提供多種設定，應在相同線路與實際負載下比較，並留意處理器使用率是否長時間偏高。

VMess：分層設定驗證與傳輸

VMess 源自 V2Ray 生態系，包含使用者驗證與資料保護機制，經常搭配不同傳輸方式使用。介面中的 VMess 節點可能使用一般 TCP，也可能搭配 WebSocket 或其他實作支援的傳輸方式。額外的 TLS 層、反向代理與路徑設定都會影響連線過程。因此，即使兩個節點都標示為 VMess，其交握步驟、伺服器架構與故障位置仍可能大不相同。

VMess 設定通常包含使用者識別碼、安全方式與傳輸參數；舊資料中的相容欄位不能直接套用到目前的實作。協定驗證要求時間同步，裝置時鐘若明顯不準，可能在網路正常時仍驗證失敗。若持續連線失敗，應先啟用系統自動校時，確認伺服器資訊仍有效，再查看核心記錄。不要把驗證錯誤誤認為 DNS 問題而反覆更換解析伺服器。

不能只看節點名稱判斷外掛程式與封裝

部分 SS 設定需要額外外掛程式，分享連結可能透過參數描述外掛名稱及其選項。客戶端能匯入基本 SS 資訊，不代表能執行相應外掛；有些只支援少數相容實作，有些則完全沒有外掛程式入口。VMess 也有類似情況：訂閱解析成功只代表欄位可讀取，實際傳輸組合仍須由核心支援。選擇時應請服務提供者說明完整組合，而不是只問是否支援 SS 或 VMess。

這兩類協定都不能只憑名稱保證應用程式的 UDP 可用。客戶端的 UDP 開關、核心支援、伺服器轉送設定及中間網路都可能造成限制。網頁正常，但語音或遊戲異常時，可先查看應用程式流量是否套用預期策略，再確認 UDP 轉送條件。盲目切換成全域模式可能掩蓋規則問題，卻無法補足伺服器缺少的能力。

已有穩定 SS 設定的使用者，可優先保留成熟組合，並確認加密方法與外掛程式相容性；已有 VMess 設定的使用者，則應特別留意傳輸欄位、裝置時間與訂閱來源。新環境不必為了追求特定協定標籤而疊加多層傳輸。每多一層，就多出一組必須保持一致的參數，也會增加憑證、路徑或反向代理設定出錯時的排查成本。

03 / TLS 與驗證

Trojan 與 VLESS 的組合限制

Trojan：以 TLS 保護傳輸

Trojan 的常見部署會在 TLS 連線中處理代理驗證與資料轉送，並利用成熟的 TLS 實作保護鏈路。對使用者來說，節點能否使用不只取決於密碼與連接埠，也與伺服器名稱、憑證鏈及伺服器端 TLS 設定有關。這種設計可沿用既有憑證與伺服器維護經驗，但不代表連接埠開啟就一定能連線，也不代表所有標示為 Trojan 的延伸實作都能互換。

連線位址是客戶端實際撥號的位置；SNI 是 TLS 交握時宣告的伺服器名稱；憑證驗證則會檢查名稱與信任關係。這些值有時相同，有時會因部署方式而分開。訂閱若提供伺服器名稱，應依伺服器要求保留，不能因為連線位址是 IP 就直接刪除。憑證過期、裝置時間錯誤、名稱不符或憑證鏈不完整，都可能在代理驗證前就中斷連線。

Trojan 常見的組合是在 TCP 上使用 TLS，首次連線必須經過相應的建立程序。重複使用連線可減少再次建立的成本，但實際效果取決於客戶端、伺服器與應用程式的要求模式。瀏覽器造訪多個網站時，連線組織方式也會影響使用感受。不能把某次冷啟動的等待直接解讀為協定持續速度較慢，也不能用單次下載峰值證明網頁首次開啟一定更快。

VLESS：驗證層不等於完整安全方案

VLESS 同樣源自 V2Ray 相關生態系，主要處理驗證與轉送，協定本身不提供與 VMess 相同的資料加密層。實際部署通常仰賴 TLS 或其他受支援的安全傳輸組合。看到設定中的加密欄位空白，或標示不額外加密，不能立刻認定連線沒有保護；還需檢查外層安全設定。反過來說，若外層沒有建立有效保護，也不能只憑 VLESS 名稱認為鏈路天生安全。

VLESS 的實際相容性往往取決於組合參數，例如傳輸類型、TLS 設定及伺服器要求的 flow。某些部署也使用 REALITY，這是必須另外確認的安全交握方案，不是換個名稱的普通 TLS 欄位。公鑰、短識別碼、伺服器名稱與客戶端支援狀況都必須相符。混用兩套範例中的設定，可能在匯入時通過語法解析，連線時卻始終失敗。

傳輸名稱相同，也要確認細節

WebSocket 組合需要確認路徑、要求標頭與反向代理的轉送關係；gRPC 組合可能涉及服務名稱及 HTTP/2 設定。路徑通常會區分具體字元，結尾斜線的差異也可能影響伺服器路由。連線被接受後立刻中斷，不一定是使用者憑證錯誤，也可能是要求送到了錯誤的後端。應先確認 TLS 是否完成，再檢查傳輸層是否建立，最後確認協定驗證。

部分參數主要是讓客戶端相容特定伺服器交握行為，不能當成通用加速開關。多路複用也要確認協定組合是否支援、連線如何隔離及伺服器限制。將多個要求集中在少數連線中，能減少交握次數，也可能讓受損連線影響更多要求。預設設定已可使用時，先保留預設值；只有在問題可重現時，才比較修改前後的差異。

實際選擇時，已有規範憑證與明確部署說明的 Trojan 設定通常較容易分層排查；VLESS 則應將完整組合視為一體檢查。初學者不宜自行拼接不同文章中的參數。優先使用服務提供者為目前核心產生的完整設定，並保留原始檔案供比對。如果客戶端提示未知欄位，應先確認核心能力，不要刪除欄位後便把匯入成功當成問題已解決。

這兩種協定都可能適用於日常瀏覽與長連線服務，但不能保證哪一種一定比較省電。外層傳輸、交握頻率、連線保活與無線訊號，往往比驗證層差異更顯著。若要比較手機表現，應維持相同的網路、應用程式與背景權限，並分別觀察待機與使用兩種狀態，避免把訊號變化或系統清理背景程式誤認為協定特性。

04 / UDP 承載

Hysteria2 與 TUIC 的網路條件

共同基礎是 QUIC，不是任意 UDP

Hysteria2 與 TUIC 都採用以 QUIC 為基礎的設計，目標之一是在特定網路條件下改善代理傳輸體驗。QUIC 將可靠串流、加密與壅塞控制整合在使用者空間的協定實作中，底層使用 UDP 資料報。這讓它們在排程上有別於傳統 TCP 組合，但前提是本地連線、中間路徑與伺服器都允許相應的 UDP 通訊。UDP 受到限制時，協定名稱再合適也無法發揮效果。

QUIC 的不同串流不必像同一條 TCP 位元組串流那樣共同等待有序交付，因此能減少某些跨串流等待。不過所有串流仍共用可用頻寬與壅塞狀態，遺失的封包仍須復原，也不可能憑空增加實體鏈路容量。網路壅塞、無線重傳與伺服器處理能力不足，依然會影響體驗。若把 QUIC 誤認為不怕封包遺失或不受延遲影響，就會對調整設定產生錯誤期待。

Hysteria2：頻寬資訊與壅塞策略

Hysteria2 是獨立於早期 Hysteria 的新一代協定，不能只把舊設定中的類型名稱改掉就直接使用。其設計著重於高延遲或有損網路上的傳輸量，並提供不同的壅塞控制路徑。部分部署會使用與頻寬相關的設定值，這些數值表達預期條件，不是測試結果。客戶端與伺服器支援的策略、伺服器限制，以及是否提供頻寬資訊，都會共同影響實際運作。

手動填寫頻寬時，應參考目前網路連線可持續達到的速度，而不是寬頻方案標示的速率；更不能把數值調大當成加速按鈕。估得過高可能造成排隊、封包遺失或頻寬競爭，使同一網路上的會議與網頁回應變差；估得過低也可能限制傳輸量。經常在行動網路與 Wi-Fi 之間切換的裝置，網路環境變化很大，宜先採用服務提供者建議值或實作預設值，再進行受控比較。

TUIC：連線組織與實作相容性

TUIC 同樣以 QUIC 為基礎，包含驗證、連線複用與資料轉送機制。使用時要注意協定世代與實作參數是否一致，不能因為訂閱都顯示 TUIC 就忽略相容性限制。使用者識別碼、密碼、壅塞控制與 UDP 轉送相關選項，都應依伺服器說明設定。不同核心支援的選用欄位可能不同，介面能儲存參數，不代表參數已傳給底層實作。

部分 TUIC 實作提供減少重複交握等待的選項，包括與早期資料相關的機制。這類機制會受工作階段恢復、伺服器策略及安全限制影響，不是每次啟動都能立即受益。使用早期資料時，也要考量重放風險與要求的語意。一般使用者不必為了少等一次連線而自行啟用所有相關選項，優先採用伺服器明確支援且經過驗證的組合。

將 MTU 與網路切換納入條件

通道封裝會增加資料負擔，可用的路徑 MTU 也會隨連線方式改變。若小型要求可正常使用，但較大的傳輸反覆停頓，可配合記錄檢查資料報大小、路徑探測及分片相關問題。不過 MTU 並非所有逾時問題的通用解法，憑證或驗證錯誤也不會因降低 MTU 而修復。確認交握成功且伺服器可連線後，才有必要繼續從傳輸大小與路徑相容性排查。

網路切換後的表現也取決於實作。QUIC 具備連線遷移相關機制，但代理客戶端、伺服器與作業系統未必能在所有情況下維持原有連線。切換行動網路、裝置從休眠恢復或位址變更後，仍可能需要重新連線。應分別測試喚醒螢幕、切換網路及長時間下載，不要只看首次啟動。對行動裝置而言，穩定重新連線通常比單次測試的峰值更重要。

若網路允許 UDP、裝置處理能力足夠，且現有 TCP 組合在有損路徑上的表現不佳，可將這兩類協定列入候選；若所在網路經常限制 UDP，則應準備已驗證可用的 TCP 類設定。它們適合處理特定條件下的問題，並非所有協定的替代方案。實際比較仍應使用相近的出口，避免把伺服器線路優勢誤認為 QUIC 普遍具備的優勢。

05 / 體驗評估

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

分開測量首次回應與持續傳輸量

連線速度至少包含兩種體驗：從點擊到收到第一個有效回應的等待時間，以及建立連線後持續傳輸的能力。前者受解析、交握與目標網站回應影響；後者則更受頻寬、壅塞控制與伺服器負載影響。協定可能在其中一項表現較好，另一項則差異不大。短篇網頁、影片緩衝與大型檔案下載的需求各不相同，不能用單一測速檔案的結果代表所有應用程式。

冷連線與熱連線也應分開測試。冷連線可能需要重新解析網域並完成 TLS 或 QUIC 交握；熱連線則可能沿用既有工作階段。測試前是否重新啟動客戶端、瀏覽器是否已有快取、連線池是否仍有效，都會影響結果。若要觀察實際首次開啟的情況，可在相同條件下重新建立連線；若關注日常瀏覽，則應保留自然的連線複用，避免人為清除狀態後放大額外成本。

資源使用沒有固定的協定排名

處理器負載來自加密、資料複製、協定堆疊處理、規則比對與記錄等環節。硬體加速、作業系統網路介面與核心實作都會影響結果。記憶體使用量則與連線數、緩衝區、規則規模及快取有關。客戶端閒置時使用量較低，不代表高併發轉送時也一樣低；協定額外封裝較少，也不保證搭配複雜規則的整體設定比較精簡。

觀察時，先區分介面程序與核心程序。桌面客戶端介面可能採用不同技術實作，開啟或關閉視窗時的資源使用量也未必相同。只用工作管理員查看單一程序，容易漏掉實際負責轉送的程序。手機則應搭配系統電池統計、螢幕使用時間與背景執行時間判斷；不能只因短時間測試時機身升溫就對協定下結論，尤其是裝置同時下載更新或處理媒體時。

無線喚醒與背景保活

手機耗電不只來自加密運算。無線模組傳送少量資料後，可能仍維持活躍狀態；頻繁的心跳、健康檢查與自動更新也會增加喚醒次數。訊號較弱時，重傳與發射功率變化也可能增加耗電。若裝置待機時仍明顯耗電，應先檢查排程工作與連線保活頻率，再比較協定；單純更換驗證方式，通常無法消除背景輪詢造成的持續活動。

自動策略組的測試設定應符合實際需求。測試間隔過短、候選節點過多或切換過於頻繁，都會產生額外要求，也可能中斷既有連線。需要自動選擇時，可先移除不使用的候選項，再確認預設間隔是否足夠。自動策略組的選擇邏輯可參考url-test、fallback 與 load-balance 比較；這些功能並不相同，不能一概視為自動測速。

TUN 模式可能接管更多應用程式流量，系統代理則取決於應用程式是否讀取代理設定，因此兩者的總處理量可能不同。比較耗電前必須固定流量接管方式，否則比較的是兩種不同的流量範圍。Android VPN 服務與背景限制、iOS 網路延伸功能的管理，也會影響連線生命週期。允許必要的背景執行有助於維持穩定，但不應為了單一客戶端而關閉所有系統省電措施。

建議以相近的時間長度分別記錄一般使用與鎖定螢幕待機情況，並重複數個週期。排除系統更新、熱點分享與訊號變化後，再判斷某項設定是否持續較耗電。需要最佳化時，先減少無用測試、過細的記錄與重複服務，再評估協定。網速問題可參考節點、線路與本機設定的分層排查；耗電問題則應一併檢視裝置本身的統計資料。

06 / 實作能力

Clash、Meta 與 mihomo 的關係

設定傳統相近，不代表功能相同

Clash 最初建立了廣泛使用的代理設定與規則生態系，許多客戶端沿用其 YAML 結構與控制介面。Clash Meta 在此生態系上擴充協定與網路功能，mihomo 則延續 Meta 核心的維護脈絡。實際資料中仍會出現 Meta、Clash Meta 或 mihomo 等稱呼。閱讀教學時，應確認指的是核心、客戶端還是訂閱格式，避免把歷史名稱誤認為獨立且完全相容的產品。

原版開源 Clash、曾提供額外功能的 Premium 分支，以及 Meta/mihomo，並不是功能範圍相同的同一種實作。舊教學中的設定能在某個核心執行，不代表其他核心也支援相同的 DNS、TUN 或規則提供者欄位。舊客戶端也可能綁定固定核心；介面仍能開啟，不代表其實作能力仍適用於新的訂閱。應以目前正在執行的核心資訊與實際文件為準。

先確認核心，再查看介面功能

桌面客戶端通常會在「關於」、「設定」或記錄中顯示核心名稱與啟動資訊。確認時不要只看客戶端標題或安裝檔名稱。部分客戶端允許切換或更新核心，切換後應再次確認執行資訊。若客戶端會自行產生執行設定，還需了解介面選項是否覆蓋匯入檔案中的 DNS、連接埠或 TUN 欄位，避免誤以為編輯訂閱就一定會改變實際執行狀態。

協定支援只是能力的一部分。規則類型、規則集格式、網域解析模式、虛擬網卡實作及外部控制介面的行為，都可能影響體驗。兩種核心都能辨識同一節點，實際表現仍可能因預設 DNS、路由優先順序或連線處理方式不同而有所差異。遷移時應先保留最精簡可用的設定，確認基本轉送正常，再逐步加入既有規則；不能只憑成功啟動就認定所有功能都已完成遷移。

平台支援與已封存客戶端

本站 Windows 下載項目還包括 Clash Nyanpasu 與已停止維護的 Clash for Windows；macOS 提供已停止維護的 ClashX Meta；Android 提供 Clash Meta for Android 與 Surfboard；Linux 則提供 Clash Verge Rev 和 FlClash。它們並非同一套介面的不同外觀。尤其是 Surfboard，應依其本身支援的設定格式使用，不能因為同在 Android 下載區，就認定它能直接讀取完整 Clash YAML。

iOS 下載入口提供 Clash Plus 的 App Store 頁面，官方網站為clashplus.io。行動作業系統對網路延伸功能、背景執行與流量接管方式有各自限制，不能直接照搬桌面教學中的系統代理或服務安裝步驟。跨平台遷移時，先確認客戶端支援的訂閱類型與協定組合，再檢查系統權限。即使帳戶憑證相同，也不代表所有平台都應使用完全相同的執行設定。

逐層還原設定，不要整份直接替換

從舊核心遷移前，先儲存原始訂閱與本機覆寫設定，並記錄模式、DNS 與流量接管方式。先用少量節點確認驗證與傳輸，再加入策略組，接著還原規則提供者，最後才啟用 TUN 等系統層級功能。每完成一層，就測試網頁、網域解析與必要的應用程式連線。如此一來，遇到問題時可以退回上一層，不必在完整設定中同時尋找多個不相容欄位。

核心部署於伺服器或路由器時，還需負責啟動管理、監聽範圍與權限控管。外部控制介面不是對外公開的服務入口，應限制在可信任的本機或必要的受控環境，並依部署需求設定存取保護。一般使用者優先選擇圖形介面客戶端，通常更容易管理系統代理與權限。只有在明確需要自動執行、服務管理或路由器接管時，才直接使用核心並維護相關系統設定。

07 / 設定交換

訂閱格式與設定相容性

分享連結、節點清單與完整設定

訂閱是交付設定的方式，不是代理協定。訂閱網址可能提供完整 Clash YAML、編碼後的分享連結清單，或某種客戶端專用格式。分享連結通常描述單一節點；完整設定還可能包含策略組、規則、DNS 與監聽連接埠。兩者包含的資訊不同，不能因為檔案能下載，就認定匯入後一定具備完整的分流邏輯。

完整 YAML 中，節點通常位於 proxies，策略組位於 proxy-groups，規則位於 rules；使用提供者時，也可能引用 proxy-providers 或 rule-providers。客戶端匯入後，可能將其儲存為設定檔，也可能擷取節點後重新產生設定。應先確認匯入入口預期接收哪種內容。將節點清單貼到完整設定入口，可能造成必要欄位缺漏，也可能只得到缺少預期規則的執行設定。

轉換不會補上缺少的功能

訂閱轉換可以改變欄位表示方式與目標格式，卻無法讓核心突然支援原本不支援的協定。部分分享格式無法完整表達傳輸細節，轉換時可能遺失外掛程式、路徑、UDP 或特殊交握參數。轉換結果即使通過語法檢查，實際連線仍可能失敗。應優先索取目標客戶端可直接使用的訂閱；確實需要轉換時，請保留原始內容並逐項檢查複雜節點。

訂閱連結通常包含存取識別資訊，取得連結的人可能因此讀取相關設定。不要在公開截圖、討論貼文或不熟悉的線上轉換網站中貼出完整網址。尋求協助時，只提供已移除憑證的錯誤訊息、協定類型與相關欄位名稱。需要在本機轉換時，應先了解工具如何處理資料；把連結縮短，並不會改變它本身具有存取權限的事實。

透過小片段理解規則引用

以下是可併入設定的規則片段，用來示範由上而下比對，以及內建 DIRECT 策略的寫法。此片段不含代理節點，也不是完整訂閱；範例網域僅供說明語法。實際分流應依應用程式需求調整，不能直接用這段內容取代所有既有規則。對已建立的連線而言，修改規則後不一定會立即改變流向；驗證時應建立新連線。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT
  - MATCH,DIRECT

規則中的策略名稱必須指向實際存在的策略組或內建策略，只差一個字元就可能解析失敗。訂閱更新後，若節點名稱改變，依名稱篩選的策略組也可能變成空集合。使用提供者時，還要確認資源下載成功且回傳格式正確。只確認主要訂閱更新成功，不能證明所有外部規則集與節點提供者都已正常載入；應在記錄中分別查看相關結果。

覆寫、更新與解析錯誤

許多客戶端提供覆寫、合併或擴充設定功能，避免訂閱更新時覆蓋本機規則。各種功能的合併順序不同，有些會取代整個區段，有些會附加清單，有些則透過指令碼產生結果。使用前應先確認在哪裡查看最終執行設定，修改後也要核對實際結果。不要同時在來源訂閱與覆寫層維護兩份互相衝突的 DNS 設定，否則下次更新時很難判斷哪一層真正生效。

YAML 錯誤常見原因包括縮排、定位字元、清單層級，以及含特殊字元的值。訂閱網址若回傳登入頁面或錯誤頁面，也可能被誤判為設定解析問題。排查時應先確認回應確實是所需設定，再依記錄定位行與欄位；不要把整份檔案貼到公開的驗證工具。更新失敗時，請保留最近一次可用設定，並區分網路取得失敗與取得後解析失敗，兩者的處理方式不同。

GeoIP 與 GeoSite 等資料也是規則執行所需的資源，和節點訂閱並不相同。設定雖已更新，資料庫若未成功載入，部分規則仍可能異常。可繼續閱讀GeoIP 與 GeoSite 資料庫更新說明。訂閱管理應做到來源可追蹤：清楚知道內容從何而來、本機修改位於哪一層，以及失敗後如何復原；而不是不斷更換匯入方式，直到偶然連線成功。

08 / 實際選擇

依使用情境選擇與分層排查

桌面日常使用與行動裝置

桌面日常瀏覽應優先考量完整訂閱相容性、連線穩定與維護便利。可從 Clash Plus 開始，再依作業系統與使用習慣比較其他客戶端，並採用伺服器端已驗證的協定組合。若現有 SS、Trojan 或 VLESS 設定穩定，就不必為了追新名稱而更換協定。會議、開發工具與瀏覽器同時使用時，應分別確認規則比對結果，確保工作流程所需連線沒有被錯誤分派到其他策略。

行動裝置應優先考量網路切換與背景恢復。通勤時的訊號波動、行動網路與 Wi-Fi 切換，以及鎖定螢幕後的系統限制，往往比峰值速度更影響體驗。候選協定應測試啟動、待機、恢復與切換網路四種狀態。若 QUIC 類設定在目前網路穩定，可再比較耗電；若 UDP 經常無法連線，則應優先保留已驗證可用的 TCP 類設定作為日常選擇。

大型檔案、即時應用程式與受限網路

傳輸大型檔案時，應留意持續傳輸量及對其他服務的影響。先確認來源網站與出口沒有速度限制，再比較協定；不要同時執行多個下載把網路塞滿後，才評估網頁回應。Hysteria2 的頻寬設定或其他壅塞策略，應符合實際鏈路狀況。若家中有人正在開會，穩定的排隊表現通常比單次跑滿頻寬更有價值；協定無法取代路由器的合理頻寬管理。

語音、遊戲或其他即時應用程式，需要確認應用本身是否使用 UDP，以及該流量是否由客戶端接管並由伺服器轉送。節點測試時間較短，不代表遊戲內延遲較低，因為測試目標可能與遊戲伺服器不同。先查看連線記錄中的目標與策略，再判斷是否需要更換線路。對 UDP 限制明顯的網路，也不要假設切換成另一種基於 QUIC 的協定就能解決基本連線問題。

依失敗階段排查，不要一直更換節點

完全無法連線時，先確認本地網路、伺服器位址解析與連接埠狀況，再檢查憑證或協定交握，最後確認驗證資訊。交握成功但網站無法開啟時，接著查看規則比對、出口連線與 DNS。只有部分應用程式失敗時，優先判斷流量接管範圍與 UDP 條件。每次保留一筆完整錯誤訊息與發生時間，避免同一輪中同時切換模式、修改 DNS、啟用 TUN 並更換協定。

網域無法開啟但 IP 相關測試正常，可能表示解析鏈路異常；不過直接連線至 IP 不一定是有效的網站測試，因為 HTTPS 需要正確的名稱。應在客戶端記錄中確認網域查詢與實際連線，不要停用憑證檢查。Fake-IP 模式下，應用程式看到的合成位址也不代表伺服器位址異常。相關原理與常見處理方式可參閱常見問題，先了解運作機制再修改設定。

以適用條件描述結論

實用的比較紀錄應寫清楚在哪台裝置、哪種網路、什麼時段、使用哪些服務時比較穩定，而不是只說某個協定比較快。若測試對象沒有共用線路，就應將結論限定為這兩個節點的體驗，不要擴大成協定層面的結論。持續失敗也要區分連線可達性、驗證、解析與出口問題，向服務提供者回報時才能提供可重現的資訊，又不必暴露完整訂閱。

後續維護不必每天重新調整所有參數。訂閱更新、系統升級或切換網路後，執行一組簡短檢查即可：網頁解析正常、常用應用程式可連線、必要的 UDP 服務可用、鎖定螢幕後恢復正常。若要了解模式切換的影響，可閱讀規則、全域與直連模式差異；需要重新完成安裝流程時，回到教學依主要步驟操作。

最終選擇應同時符合四項條件：目前的客戶端能實作完整協定組合、伺服器參數明確且有效、所在網路允許相應傳輸，以及裝置資源與耗電成本都能接受。符合這些條件後，再比較效能細節。若部署於伺服器或路由器，還要檢查權限、監聽範圍與重新啟動後的恢復狀況。如此得到的才是容易維護的設定方案，而不是依賴單次測試或某個協定名稱做出的臨時判斷。