Clash 協定詳解與 mihomo 核心選擇指南

連線分層：協定、傳輸與出站模式

先區分用戶端接管與遠端連線

代理連線可分成兩段：應用程式將請求交給本機用戶端，用戶端再透過選定的遠端節點轉送。系統代理、TUN 虛擬網卡屬於前一段；SS、VMess、Trojan 等節點協定則屬於後一段。因此，啟用 TUN 不會把 SS 變成其他協定，切換規則模式也不會改變節點的加密方式。兩端都正常運作，應用程式的請求才會依預期送達目的地。

系統代理通常透過作業系統設定，告知應用程式使用本機 HTTP 或 SOCKS 入口；應用程式是否遵循設定則由自身決定。TUN 會透過虛擬網路介面接收 IP 封包，再由用戶端處理連線。遊戲、命令列工具和瀏覽器的接管方式可能不同。若瀏覽器能用、其他應用程式卻無法連線，應先確認本機接管範圍，而非直接判定遠端協定失效。

相同的協定名稱，可能對應不同的連線堆疊

協定層負責驗證、封裝和轉送語意；傳輸層則負責將資料送到伺服器。VMess、VLESS 等協定可搭配不同傳輸方式，例如直接使用 TCP，或再加上 WebSocket。TLS 則負責身分驗證與連線加密。節點名稱中的縮寫往往分屬不同層，不能只看其中一個名稱，就判定兩份設定相同。

以使用 WebSocket 和 TLS 的節點為例，連線可能依序經過網域名稱解析、TCP 連線、TLS 交握、WebSocket 升級和代理驗證。若伺服器還設定了反向代理，路徑和標頭也必須相符。少了路徑欄位就可能連線失敗，但這不代表協定本身不相容。排查時應沿著連線層次逐一確認：先檢查網域名稱和連接埠，再檢查安全層、傳輸層與身分參數。

規則決定流量去向，不會修復節點

規則模式會依設定由上而下比對請求，符合後選擇直連、拒絕、特定節點或策略組。全域模式會將請求交由全域策略處理，但仍須選擇實際可用的出口。直連模式主要用來對照本機網路。若某個網站在全域模式可用、規則模式卻不行，應先查看符合的規則與策略組，而不是馬上更換協定。

DNS 也可能參與規則判斷和連線建立。有些規則直接比對網域名稱，有些則需要目標 IP 或地理資料庫。用戶端是否保留網域名稱資訊、是否使用 Fake-IP，以及 DNS 請求透過哪個出口，都可能改變比對結果。DNS 選項與協定功能相關，但不屬於協定效能排名；任意同時修改 DNS、節點和模式，會讓故障難以重現。

實際操作時，先在用戶端確認已選取目前使用的設定，再開啟代理頁面確認節點類型與策略組選擇。接著查看連線頁面或記錄中的目標、符合的規則及出站名稱。只有在請求確實進入用戶端並選用預期節點時，協定測試才有意義。想了解規則優先順序，可接著閱讀自訂規則寫法與比對順序。

SS 與 VMess：輕量封裝與驗證機制

Shadowsocks 的特色是連線結構相對直接

Shadowsocks 通常簡稱 SS，最初是為加密 SOCKS 代理使用情境而發展，連線結構相對簡潔。用戶端會依據密碼或金鑰及加密方式處理資料，伺服器解封裝後再連線至目標。它不是完整的設定管理系統，也不負責規則分流；訂閱、策略組和介面設定是用戶端在協定之上提供的功能。因此，支援 SS 的程式不一定能直接讀取完整的 Clash 設定。

現代 SS 部署常使用 AEAD 加密方式；較早期的串流加密方案，安全特性與 AEAD 不同。SS 2022 又採用不同的金鑰和工作階段處理要求，不能把這些方案視為只有名稱不同的選項。伺服器要求哪種方式，用戶端就必須支援並正確設定；不要為了提高速度自行更改 cipher，否則兩端將無法正確解密。

加密方式的資源消耗會受裝置硬體影響。具備相關硬體加速的桌上型處理器與低耗電手機，適合的演算法未必相同。AES 系列的效率取決於指令支援和實作；在其他裝置上，ChaCha20 系列可能更合適。若只有一份既定訂閱，通常無法自行選擇演算法；先確認伺服器參數和用戶端核心支援即可。

UDP 功能必須在連線各環節都可用

SS 可以承載 UDP，但伺服器必須啟用相應轉送、本機應用程式的 UDP 流量必須進入用戶端，而且中間網路也必須允許相關資料通過。節點啟用 UDP 選項，只代表用戶端會嘗試使用此功能，不代表整條路徑已經暢通。若瀏覽網頁使用 TCP 正常，卻無法即時語音，應檢查應用程式是否被接管、節點是否支援 UDP，以及出口是否限制目標連接埠。

部分 SS 節點還需要額外外掛程式。外掛程式可能加入不同的傳輸或交握方式，因此用戶端、核心和外掛程式的實作都必須相容。匯入後若出現無法辨識的外掛程式名稱或參數，不宜直接刪除欄位後嘗試連線；刪除欄位可能改變伺服器預期的連線方式。應請訂閱提供者確認目標用戶端格式，或改用明確支援該部署方式的用戶端。

VMess 在協定中處理身分與請求資訊

VMess 源自 V2Ray 生態系，透過使用者識別碼和協定本身的驗證機制處理代理請求。現代部署通常使用 AEAD 驗證；舊設定可能仍保留歷史驗證相關欄位。使用者識別碼和加密選項必須與伺服器一致，不能複製其他節點的識別碼來替換，也不能只因欄位存在就推斷伺服器使用舊版驗證模式。

VMess 對時間條件較敏感，系統時鐘偏差可能造成驗證失敗。若網域名稱可解析、連接埠似乎也可連線，卻持續出現驗證錯誤，應先啟用系統自動校時，再確認身分參數與伺服器狀態。憑證錯誤則屬於另一層問題，應搭配記錄判斷。反覆更換節點連接埠通常無法解決時鐘造成的驗證失敗。

VMess 可搭配 TCP、WebSocket 等傳輸方式，也能組合 TLS。實際消耗不只來自協定驗證，也受傳輸方式、加密和中間轉送層影響。使用直連 TCP 的 VMess 節點，和經過反向代理的 WebSocket 節點，建立連線的過程可能差異很大。測試時應一併記錄這些條件，不要把所有 VMess 節點都歸在同一個效能等級。

一般瀏覽網頁和日常傳輸檔案，兩者都可能符合需求。SS 的連線結構通常較直接；VMess 則需要確認更多驗證與傳輸組合。若匯入後只有部分節點無法使用，可先檢查失效節點是否集中於某種加密方式、外掛程式或傳輸類型，再決定更新核心或請提供者調整設定。比起逐一隨機嘗試，這樣更容易找出共同原因。

Trojan 與 VLESS：TLS、安全層與參數組合

Trojan 常以 TLS 作為連線基礎

Trojan 的常見部署會以 TLS 連線承載代理請求，並透過密碼進行使用者驗證。TLS 提供連線加密與伺服器身分驗證；代理協定則負責轉送目標和驗證資訊。這種設計採用成熟的 TLS 機制，而非讓使用者在協定中選擇多種獨立加密方案。實際使用仍須確認憑證、網域名稱和傳輸參數，不能只填入密碼就假設連線設定完整。

伺服器位址和 TLS 使用的名稱不一定相同。伺服器位址用來定位連線入口；SNI 在 TLS 交握時宣告目標名稱；憑證驗證名稱則用來確認遠端身分。不同用戶端可能將後兩者合併在同一欄位，或依設定推導。即使以 IP 位址作為伺服器位址，仍可能需要提供正確的服務名稱。三者的關係應以伺服器部署資訊為準。

出現憑證錯誤時，應檢查裝置時間、憑證效期、憑證涵蓋的網域名稱，以及設定中的名稱。略過憑證驗證會降低伺服器身分確認的安全性，不適合作為長期解決方式。若先前可正常使用，更新訂閱後才失敗，請比對更新前後的服務名稱，不要直接放寬驗證。更完整的判斷方式請參閱啟用代理後的 HTTPS 憑證錯誤說明。

VLESS 精簡的協定標頭不等於完整的安全方案

VLESS 同樣源自 V2Ray 相關生態系，後續也在 Xray 等實作中持續發展。常見 VLESS 部署會將使用者驗證與外部安全層分開，協定本身的結構較精簡。傳統設定中常見 encryption 為 none，代表該協定設定未啟用這一層的資料加密，不代表整條連線必然是明文；實際安全性仍須看 TLS、REALITY 或其他明確支援的組合。

REALITY 的參數體系與一般憑證 TLS 不同。用戶端通常還須確認公鑰、短識別碼和服務名稱等資訊；其中公鑰用於驗證，不是需要保密的伺服器私鑰。一般使用者應從可信任的訂閱取得完整欄位，不要自行拼湊不同節點的參數。名稱相似的欄位，也不代表能在其他協定或核心中直接沿用。

VLESS 設定也可能指定 flow，例如 Vision 相關的值。flow 不是可任意填寫的速度開關，而是需要伺服器、傳輸方式與核心實作共同支援。將 flow 加到不相容的傳輸方式上，可能遭到拒絕或造成連線異常。成功匯入只代表設定通過部分解析檢查，仍應確認實際交握和連線結果。

額外傳輸層的優點與代價

WebSocket 可配合某些既有 Web 服務部署方式，但會增加升級請求、路徑和標頭等設定。gRPC 類型的傳輸則有不同的服務名稱和連線行為。這些方式解決的是部署和承載問題，不應預設為加速選項。若伺服器只提供一種部署方式，用戶端就必須與之相符；選擇協定不能脫離連線入口實際支援的功能。

Trojan 和 VLESS 都能提供適合日常使用的連線，但不存在普遍適用的效能排名。使用既有憑證架構的部署，Trojan 的參數關係通常較容易理解；需要特定 VLESS 組合時，則應優先確認核心支援及訂閱欄位是否完整。在用戶端選擇節點時，先確保安全參數有效，再比較線路、穩定性和資源消耗，通常比追求某個協定標籤更可靠。

Hysteria2 與 TUIC：採用 QUIC 的連線取捨

QUIC 改變傳輸機制，但無法消除網路限制

QUIC 以 UDP 為基礎，在傳輸層整合安全交握、可靠資料流、多工和壅塞控制等機制，並透過 TLS 1.3 建立安全連線。Hysteria2 和 TUIC 都運用 QUIC 的功能，但屬於不同代理協定，驗證方式和參數並不通用。節點標示採用 QUIC，只能說明連線基礎相近，不能因此將一份設定的類型欄位改成另一種。

多工讓多個邏輯資料流共用一條連線。與多個資料流共用單一 TCP 連線相比，QUIC 可降低傳輸層跨資料流的隊頭阻塞影響：某個資料流缺少資料，不必在傳輸層阻擋其他獨立資料流交付。不過，各資料流仍共用網路頻寬並受到壅塞限制；嚴重丟包時也會一同受影響。因此，多工不代表所有請求都能獨占順暢的線路。

使用 UDP 也代表入口網路必須允許 UDP 封包抵達節點連接埠。有些公共網路、企業網路或行動網路環境會限制 UDP，或縮短 UDP 對應關係的保留時間。若使用 TCP 的節點可正常瀏覽網頁，QUIC 節點卻交握逾時，這就是合理的排查線索。先確認 UDP 是否可連線，再調整協定參數，比反覆匯入相同訂閱有效。

Hysteria2 的頻寬設定應符合實際線路

Hysteria2 適用於包含高延遲、丟包等狀況的網路環境，支援以 QUIC 為基礎的代理傳輸。部署時可能涉及頻寬提示、壅塞控制選項和額外混淆參數。頻寬欄位不是購買的方案速率，也不是伺服器網卡標示速度，應依目前線路的實際可用上下行頻寬判斷。填入過大的數值可能加劇排隊、丟包及共用網路上的競爭。

用戶端和伺服器如何協商頻寬、是否允許用戶端指定參數，以及省略參數時如何處理，都取決於實作和伺服器策略。一般訂閱使用者應優先保留提供者產生的設定值。若要自行調整，一次只改一個方向，並記錄持續傳輸時的延遲及其他應用程式的回應；只看下載瞬間峰值，可能忽略整條網路已明顯壅塞。

Hysteria 第一代與 Hysteria2 並非只要改寫類型名稱就能互通。兩者的協定和設定有所差異，若轉換工具未正確支援目標類型，可能遺失驗證或其他重要參數。遇到不支援的節點類型時，應更新至明確支援該協定的核心，或重新取得目標格式；不要嘗試用舊類型略過解析檢查。

TUIC 的資料流與資料報應分開理解

TUIC 以 QUIC 承載代理流量，可轉送 TCP 與 UDP。不同實作可能提供壅塞控制、UDP 轉送方式和連線維持等選項。代理中的 TCP 流量不代表底層又變回 TCP；用戶端可能將其作為可靠資料流，透過 QUIC 連線傳送。UDP 流量則須依所選轉送方式理解可靠性與丟包行為。

TUIC 的協定世代與驗證欄位也必須相符。設定中出現使用者識別碼和密碼，不代表其他採用相似欄位的節點也能直接轉用。核心支援的協定世代、資料報方式和欄位名稱都可能影響相容性。匯入後若驗證失敗，應請節點提供者確認目標核心，不要只檢查是否有使用者名稱。

QUIC 具備連線遷移相關機制，但用戶端、協定實作和網路切換方式是否確實運用這些機制，仍須實際測試。從 Wi-Fi 切換到行動數據後，應用程式仍可能重新連線；背景休眠也可能使連線失效。Hysteria2 或 TUIC 可作為經過測試的替代方案，但不是一次解決丟包、切換網路和訊號不佳的萬靈丹。選擇前也應比較長時間執行後的耗電與溫度。

效能與耗電：分別測試交握、傳輸量與背景活動

用戶端顯示的延遲不等於完整使用體驗

用戶端顯示的延遲通常來自特定方式的探測，可能包含建立代理連線並向測試位址發出請求的過程。這不是協定固有的延遲，也不一定等於伺服器的 ICMP 往返時間。不同用戶端或測試位址提供的結果不能直接比較。節點探測很快，實際瀏覽特定網站仍可能受到目標距離、出口壅塞或 DNS 影響。

短連線更容易反映解析與交握成本。首次開啟網頁時若須建立多條連線，TLS、WebSocket 升級和驗證等步驟都會增加等待時間；已建立的長連線則可能沿用現有通道，省去部分連線成本。測試新協定時，應區分首次開啟和連續瀏覽，否則快取與連線重用可能讓後測節點看起來比較快。

持續傳輸量還會受到出口頻寬、壅塞控制、丟包、加密效率和伺服器負載影響。小檔案很快下載完畢，不足以證明長時間傳輸穩定。反過來說，大檔案下載速度快，也不代表互動延遲低；上傳塞滿線路時，排隊可能讓網頁和語音同時變慢。應依實際工作負載選擇，而不是只看單一速度數字。

資源消耗來自整套連線堆疊

加解密、資料複製、連線數量、規則比對、DNS 快取和記錄輸出都會消耗資源。QUIC 通常會在使用者空間實作較多傳輸邏輯；TCP 的部分工作則由系統網路堆疊處理。但兩者的實際消耗取決於實作品質、系統最佳化和流量規模，不能只依使用者空間或核心空間，就為所有裝置排出固定的 CPU 效能名次。

對行動裝置而言，無線通訊模組維持作用中的時間往往同樣重要。持續傳送心跳、頻繁探測、大量短連線和失敗重試，都可能增加喚醒次數。訊號較差時，重傳和無線耗電又會放大差異。因此，同一設定在家用 Wi-Fi 和通勤時的行動數據下，耗電表現可能差異很大，不能直接用桌上型電腦的測試推論手機結果。

TUN 也會擴大接管範圍，讓更多背景請求經過用戶端。啟用後耗電增加，可能是原本未被接管的應用程式開始產生代理流量，不一定是 TUN 本身的處理成本。比較時應保持背景應用程式、接管模式和 DNS 設定一致；否則即使節點協定沒變，測試的流量也已經不同。

確保測試可重現

先固定網路與用戶端設定，暫停大型檔案同步，再對每個節點執行相同操作。最好交替測試，而不是先測完甲、隔很久再測乙，以降低不同時段網路負載的影響。每輪至少包含一次新連線和一段持續連線，並記錄錯誤類型。若兩個節點的出口不同，結論只適用於這兩條路線，不能推廣成兩種協定的普遍差異。

耗電測試應涵蓋足夠長的日常使用時間，並查看系統電池用量統計中的背景活動。除錯記錄適合短時間定位問題；確認正常後可恢復一般記錄等級，也應依需求調整過於頻繁的健康檢查。不要為了省電，任意把連線維持間隔調得過長；某些網路會因此更容易回收對應關係，反而增加重新連線次數。

最後應優先選擇失敗率低、日常工作回應穩定且裝置溫度可接受的組合。若某種協定峰值速度較快，卻持續造成發熱或切換網路失敗，未必適合手機使用。修改參數前請保留原設定，並一次只改一項。節點持續逾時的系統性排查方式，請參閱節點逾時與無法連線的處理順序。

核心家族：Clash、Meta 與 mihomo 的關係

圖形化用戶端與代理核心應分開判斷

圖形化用戶端負責設定入口、系統整合、訂閱管理、系統匣和介面操作；核心則負責解析設定、建立代理連線、處理 DNS 和執行規則。FlClash 以 mihomo 核心提供用戶端功能，但介面是否提供某項核心功能，仍取決於用戶端的實作。下載頁上的不同用戶端，不能只憑外觀或名稱就推斷功能完全相同。

同一款用戶端也可能透過更新變更核心或設定處理方式。比較相容性時，先在關於、設定或記錄中確認實際核心名稱與建置資訊，再確認是否支援所需功能。只說使用 Clash 用戶端，資訊不足以判斷 VLESS、Hysteria2 或某個 DNS 欄位能否使用；還須區分具體用戶端、核心和設定來源。

Meta 與 mihomo 的名稱沿革

Clash 原版建立了常見的 YAML 設定結構與規則分流方式。Clash.Meta 是其生態系中的擴充分支，後來以 mihomo 核心名稱持續發展。使用者仍可能在舊文件、訂閱選項或用戶端說明中看到 Meta 這個名稱；它有時指歷史分支，有時則是相容目標標籤。不能只憑標籤判斷檔案包含哪些功能。

mihomo 增加並擴充了多種協定、DNS、規則及網路接管功能。許多基礎設定結構仍與 Clash 風格相近，但擴充欄位不保證能由原版或其他分支讀取。原版專案已停止維護，舊用戶端內建的解析器也不會因訂閱標示相容 Clash，就自動理解後來加入的節點類型。使用新功能須搭配相應核心。

設定相容性不是簡單的是或否

相容性至少包含四個層面：檔案語法能否解析、節點類型能否辨識、擴充選項是否生效，以及作業系統是否允許相關網路操作。設定檔可能通過語法檢查，卻因伺服器參數不符而連線失敗；也可能節點正常，但 TUN 權限不足。把這些狀況一概稱為設定不相容，會掩蓋真正需要調整的部分。

用戶端載入訂閱時，也可能合併本機設定、覆寫 DNS 或加入規則。因此，磁碟中的原始訂閱內容，可能與核心執行中的最終設定不同。排查時應優先查看用戶端提供的執行設定或記錄，不要只盯著下載的 YAML。若合併時發生衝突，可先保留一份最精簡的本機設定作為對照，避免多處覆寫互相影響。

不同作業系統也有差異。桌面系統的代理開關、虛擬網卡和權限機制，與行動裝置的網路延伸功能或 VPN 服務介面並不相同。設定檔可跨平台匯入，不代表系統設定也能照搬。iOS 使用者可從下載頁了解 Clash Plus，但仍須依用戶端實際支援的匯入格式和網路功能操作，不要把桌面版 mihomo 的所有開關都當成行動版必備功能。

依明確需求決定是否更新

遇到未知節點類型、缺少欄位支援或已知功能問題時，更新用戶端和核心就有明確幫助。更新前請備份設定、覆寫內容和必要選項；更新後先測試一個已知可用的節點，再還原複雜規則。若用戶端提供獨立核心切換功能，務必依照其支援方式操作，不要直接替換成其他平台的執行檔。

初次安裝可先選擇Clash Plus，並確認是否支援目標協定；若需要 FlClash、Clash Verge Rev 等用戶端，再依平台和功能選擇。Clash for Windows、ClashX Meta 已停止維護並封存，較適合用來理解舊環境，不宜預期它們預設支援持續擴充的協定。選擇重點是目前需要的協定與系統整合功能，而非沿用已久的名稱。

訂閱相容性：分享連結、節點集合與完整設定

訂閱網址相同，不代表取得的內容也相同

訂閱本質上是用戶端取得設定內容的入口。伺服器可能依網址參數、請求標頭或用戶端識別資訊，回傳不同格式，因此瀏覽器下載的內容未必與用戶端取得的內容相同。常見格式包括單一協定分享連結、編碼後的節點連結集合、Clash 風格 YAML，以及其他核心使用的 JSON 設定。這些格式不能只靠更改副檔名互相轉換。

單一分享連結通常描述一個節點，包含位址、連接埠、驗證資訊及部分傳輸參數。節點集合會整理多個連線，但未必包含分流規則。完整的 Clash 設定則可能包含 proxies、proxy-groups、rules、dns 等區段。若用戶端提供不同的匯入入口，應依內容類型選擇；把節點分享連結貼到只接受完整設定的遠端設定入口，可能會出現解析錯誤。

另一種設定會透過 proxy-providers 引用遠端節點集合，將節點更新與規則維護分開。此時主設定檔可能很短，但仍依賴被引用內容的可存取性和格式。若主設定檔匯入成功，策略組中卻沒有節點，應檢查 provider 更新狀態、引用名稱與篩選條件，而不是只重新下載主檔案。

轉換時應保留設定語意，而不只是位址和密碼

訂閱轉換工具必須將來源格式的欄位對應至目標核心欄位。基本位址和驗證資訊通常容易保留；傳輸路徑、TLS 名稱、ALPN、flow、REALITY 參數及 UDP 相關選項，則可能因格式或工具支援不足而遺失。轉換後仍看得到完整節點清單，不代表連線設定的語意沒有改變。請選擇明確支援目標協定與核心的輸出格式。

轉換工具無法替不支援該協定的核心補上實作，也無法從缺少的資訊中可靠推算正確參數。若來源未提供必要欄位，應向提供者取得完整設定。使用線上轉換工具也代表將訂閱入口交給第三方，可能洩露其中的驗證資訊。請優先使用提供者直接產生的目標格式；若要使用本機轉換工具，也應先了解相關風險並確認可信度。

先確認檔案，再檢查執行結果

YAML 對縮排和結構很敏感。清單項目、對應關係和字串的層級必須一致，含特殊字元的值也要正確加上引號。瀏覽器回傳的登入頁、錯誤頁或空白回應都不是設定檔，無法靠調整縮排修復。若解析器在檔案開頭就報錯，先查看下載內容的類型和前幾行，再判斷是否遭伺服器拒絕或網址已失效。

以下是規則片段，不是完整訂閱。此片段會讓範例網域直連，其他請求則交給名為 PROXY 的既有策略組；使用前必須確認目前設定確實有這個策略組。規則會依排列順序比對，最後的 MATCH 會接手前面未符合的請求，因此在其後新增一般規則通常不會達到預期效果。

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

GeoIP 和 GeoSite 也依賴對應的規則資料。設定語法正確，但若缺少資料檔或更新失敗，相關規則仍可能無法正常運作。請分清節點訂閱更新與規則資料庫更新，兩者並非同一件事。資料檔用途和更新方式請參閱GeoIP 與 GeoSite 資料庫使用說明。

自動更新也可能覆蓋直接寫入遠端設定的修改。若要長期保留規則，優先使用用戶端明確提供的本機覆寫或合併功能，並確認注入順序。手動修改檔案只適合能掌控更新方式的情況。每次更新後若問題再次出現，應比對原始訂閱、覆寫結果和最終執行設定，而不只是查看更新時間。

操作方式請參閱訂閱匯入教學；取得訂閱入口與安全注意事項請參閱訂閱來源說明。若只有自動更新失敗、手動匯入正常，可接著查看訂閱更新失敗與更新間隔設定，逐項確認回應內容、存取路徑及格式相容性。

情境選擇：建立可復原的測試流程

依工作需求和網路條件挑選候選方案

在住家或辦公室的固定網路上，若主要使用網頁、文件和程式碼託管服務，應先選擇已穩定運作且憑證與參數完整的節點。SS、VMess、Trojan、VLESS 都可能符合需求；出口品質通常比協定標籤更能左右體驗。若網路明確限制 UDP，應先保留 TCP 類型的候選節點；不必為了嘗試 QUIC 而同時重寫 DNS、規則和系統接管設定。

長距離傳輸或網路丟包時，可將 Hysteria2、TUIC 納入比較，但要先確認 UDP 可正常連線。持續下載檔案的使用者也應觀察上傳、網頁和會議是否同時受影響，避免只看塞滿線路時的速度來判斷整體體驗。語音、遊戲等即時服務更應確認應用程式的 UDP 流量確實經過目標節點，而非只看網頁探測結果。

行動裝置應優先考慮重新連線的可靠性、溫度、背景活動和網路切換後的恢復能力。可保留一個主要節點和一個採用不同傳輸方式的備用節點，減少接入條件改變時的中斷。自動策略組需要合適的探測目標與間隔；探測成功只代表該目標可用，不保證所有應用程式都能連線。頻繁切換出口也可能讓已建立的工作階段重新連線。

將測試拆成四個可定位的步驟

第一步，確認設定載入成功。開啟用戶端的設定頁面，選取目標設定，檢查是否有解析或合併錯誤；再前往代理頁面確認候選節點和策略組都存在。若節點沒有出現，應優先排查訂閱內容、篩選規則和核心支援，而非測試網路。初次安裝可依下載頁選擇 Clash Plus 或適用於目前系統的用戶端，再按照教學完成基本匯入。

第二步，確認請求確實進入用戶端。啟動連線後，依需求使用系統代理或 TUN，再瀏覽目標網站並查看連線頁面。若沒有記錄，請檢查應用程式是否遵循系統代理、虛擬網卡權限，以及其他網路軟體是否有接管衝突。若有記錄，請核對符合的規則、策略組和最終使用的節點，避免實際測到直連出口或組內的其他節點。

第三步，根據記錄定位遠端連線失敗原因。名稱解析失敗時先檢查 DNS；交握逾時時檢查入口位址、連接埠和傳輸可達性；憑證錯誤時確認時間和名稱；驗證失敗時確認身分參數；若特定協定的節點全都無法使用，則檢查核心支援和網路條件。不同實作的記錄用語可能不同，不能只憑單一錯誤字樣判定原因，還要搭配失敗階段及其他節點的測試結果。

第四步，在功能正常後觀察日常負載。使用相同應用程式完成網頁瀏覽、檔案傳輸或會議測試，再評估長時間執行和切換網路時的表現。確認新設定穩定前，請保留舊設定；需要復原時，應還原整套設定組合，而不只是節點名稱。若修改了多個參數，應分批還原並重新測試，避免把偶然恢復誤認為單一設定造成的效果。

保留足以解釋測試結果的記錄

記錄不必包含敏感欄位，只要寫明接入網路、用戶端與核心、協定和傳輸組合、本機接管方式、測試工作及錯誤階段即可。向他人求助時，請提供已遮蔽敏感資訊的相關記錄，不要上傳完整訂閱。這有助於判斷類似問題，也方便更新用戶端後重新測試，不必再從隨機更換節點開始。

協定負責連線機制，核心決定實作能力，訂閱提供參數，用戶端則負責將這些功能整合至系統。依照這個順序查閱，能分別處理格式錯誤、線路問題和裝置限制。完成選擇後，請回到快速入門教學確認連線與測試步驟；若遇到本頁未涵蓋的介面或安裝問題，可查看問題排查，避免把所有異常都歸咎於協定。