Clash 代理協定與核心技術參考

一、選擇協定先看哪些層面

用戶端、核心與節點，各自負責不同環節

用戶端是操作入口，負責管理訂閱、切換系統代理、編輯設定及顯示記錄；核心負責解析設定、比對規則並建立實際連線；節點則是伺服器提供的連線入口。介面上出現某個協定名稱，不代表目前裝置就完整支援，還得確認核心實作、建置選項及平台的網路權限。反過來說，核心已支援的欄位，也可能尚未出現在用戶端的圖形化編輯器中。

選擇時應從現有訂閱開始，而不是先挑一個聽起來比較新的名稱。先確認伺服器提供哪些協定、是否允許轉發 UDP，以及是否要求憑證網域名稱，再檢查用戶端能否直接匯入。節點的協定類型通常不能任意在本機改寫：把設定中的 SS 改成 Trojan，並不會讓伺服器改變監聽方式，只會讓雙方在連線開始時無法解析彼此傳送的資料。

別把協定、傳輸方式與安全層混為一談

代理協定規定如何表示目標位址、身分資訊與資料；底層傳輸決定資料經由 TCP 或 UDP 傳送，以及是否使用 WebSocket、gRPC 等封裝；TLS 則負責安全連線中的身分驗證與加密。同一個 VLESS 名稱底下，可能搭配不同的傳輸方式與安全設定，實際握手次數、可用網路環境及參數要求也會不同。因此比較時，至少要記下完整組合，而非只看清單中的類型標籤。

也要分清節點協定與本機流量接管方式。系統代理、TUN、混合連接埠，是裝置將流量交給用戶端的途徑；規則、全域、直連，則是流量選擇出口的策略。啟用 TUN 不會自動把 SS 變成 QUIC 協定，選擇全域模式也不會讓原本不支援 UDP 的伺服器突然能傳送遊戲資料。遇到應用程式無法連線，應先確認流量有沒有進入核心，再檢查出口是否可用。

比較結果時要控制變因

連線速度至少包含三個階段：解析伺服器位址、建立代理連線，以及透過伺服器存取目標服務。一次節點測速往往只反映其中一部分，也會受測速網址、快取與連線重用影響。清單上的數字比較小，不代表網頁上的每個資源都載入得更快，也不表示影片比較不會卡頓。伺服器負載、出口線路及與目標網站的距離，往往比協定多出的幾個欄位更重要。

實際比較時，可固定裝置、網路、目標網站與大致時段，每種組合重複測試幾次，分別記錄首次開啟、連續瀏覽、檔案傳輸，以及待機後恢復的狀況。別把無線訊號變化或伺服器忙碌誤認為協定差異。手機尤其要留意，切回前景後的第一次請求可能包含喚醒無線連線的時間，與持續下載時的表現並非同一項指標，應分開觀察。

以下內容會依照這套架構進行比較，目的不是替所有協定排出固定名次，而是找出目前裝置上容易維護、參數完整且表現穩定的組合。能判斷問題出在哪個環節，比記住「某個協定比較快」更實用；換了網路或用戶端後，這套判斷方式依然適用。

二、SS 與 VMess：簡潔資料流與結構化驗證

SS 的背景與實作限制

Shadowsocks 通常簡稱 SS，透過用戶端與伺服器共用金鑰來轉送連線，設計重點是相對簡潔的加密代理資料流。它不是單一且固定的加密演算法：設定中的加密方法會決定金鑰、隨機數與資料記錄的具體處理方式。討論 SS 時必須一併確認加密方法，不能把不同方法、實作及硬體上的資源消耗混在一起比較。

常見的 AEAD 方法結合加密與完整性保護，有助於理解現代 SS 的基本運作方式；較新的方法系列則有各自的金鑰格式與實作要求。訂閱中顯示 SS 類型，不代表所有 SS 方法都受到支援。匯入後若提示不認得加密方法，應優先確認核心功能與金鑰格式，不要隨意換個方法名稱試試，因為伺服器也必須使用相符設定。

在不使用額外外掛的常見組合中，SS 的連線結構較直接，不必另外進行一套外層 TLS 握手。這可能省下一部分連線準備時間，但不代表速度一定比較快。如果設定要求外掛，用戶端與核心也必須支援相應的外掛形式。手機與桌面版可能提供不同的外掛，若只複製伺服器、連接埠和密碼，漏掉外掛選項，就可能在驗證前中斷連線。

為什麼 VMess 欄位比較多

VMess 源自 V2Ray 生態系，代理資料中包含身分驗證等結構，並可搭配多種傳輸方式。常見欄位包括使用者識別碼、加密選項，以及傳輸所需的路徑或主機資訊。這種結構可以支援更多組合，也代表排除問題時不能只檢查密碼欄位。若伺服器採用現代驗證方式，沿用舊教學中的歷史參數，可能會出現匯入成功卻無法建立連線的情況。

VMess 驗證會受到時間影響。裝置系統時間若有明顯誤差，即使位址與使用者識別碼正確，也可能驗證失敗。如果多個 VMess 節點同時異常，其他協定卻正常，可先檢查系統是否自動校時，再查看核心記錄中的驗證相關資訊。別一開始就重裝整個用戶端。舊設定中出現的額外識別參數，應依服務提供者目前的說明處理，不要照著過時的截圖自行新增。

TCP、UDP 與外層封裝的差異

SS 與 VMess 都不能只憑協定名稱就認定 UDP 一定可用。還要確認伺服器已啟用相應轉發、用戶端有將應用程式資料交給核心，以及中間網路允許這條傳輸路徑。網頁能正常開啟，只能證明相應的網頁連線成功，不代表語音、遊戲或即時會議的資料也能順利傳送。測試時應使用真正依賴相關傳輸方式的應用程式，並搭配記錄確認，不要只看一次網頁測速。

VMess 外層再套上 WebSocket 或其他傳輸方式時，會增加相應的封裝處理與連線準備。如果內層資料仰賴單一可靠的 TCP 連線傳送，發生封包遺失時，後續資料可能得等待前面的位元組重新傳送。能否透過連線重用降低短連線負擔，取決於伺服器與實作方式；重用也可能讓多項服務共用同一處壅塞與故障影響，因此不應預設所有情境都要開啟重用。

日常瀏覽、文件同步與中等規模的檔案傳輸，可用參數清楚的 SS 作為簡潔基準；若已有完整的 VMess 服務，則應著重確認驗證方式與外層傳輸相容。兩者如何選擇，主要取決於服務品質與設定可靠度，而非某類協定在所有裝置上都必然比較省記憶體或省電。

三、Trojan 與 VLESS：了解 TLS 與傳輸組合

Trojan 在安全連線中進行驗證

Trojan 常見的運作方式是先建立 TLS 安全連線，再於其中完成代理驗證與資料轉送。它運用成熟的安全傳輸機制處理加密與伺服器身分驗證，代理協定本身則相對直接。用戶端設定除了伺服器、連接埠與密碼，也要留意驗證憑證時使用的名稱。連線位址可以是 IP，但憑證通常是簽發給網域名稱，兩者不一定是同一個欄位。

SNI 用來在 TLS 握手時告知伺服器預期連線的名稱；用戶端也必須依實作與設定檢查憑證身分。填錯可能會連到不相符的網站，或觸發憑證錯誤。若服務提供者提供了獨立的伺服器名稱，請完整保留，不要因連線位址已有網域名稱就把它刪掉。憑證過期、裝置時間錯誤或信任鏈缺漏，也會在代理驗證前中止連線，應分別排查。

VLESS 輕量，不代表本身就提供加密

VLESS 同樣源自 V2Ray 生態系，著重於較精簡的代理協定結構，常見使用方式是依靠外層安全機制保護傳輸。使用者識別碼提供協定所需的身分資訊，但它不是萬用的加密開關。看到設定中的加密欄位為空白或填了特定停用值，不應因此忽略 TLS 等外層設定，就斷定整體連線未加密；反過來說，也不能認為 VLESS 這個名稱本身就保證安全。

VLESS 的實際組合可能包括 TCP、WebSocket、gRPC，以及 TLS 或 REALITY 等安全設定。這些名稱各自解決不同問題，支援 VLESS 不等於支援所有組合。REALITY 還會用到公鑰、短識別碼與伺服器名稱等參數，流量控制選項也有相應的組合限制。介面能儲存欄位，不代表該平台上的核心就能執行；最好依據實際記錄與維護者的功能說明確認。

為什麼相同協定的連線負擔不同

一般 TCP 搭配 TLS 時，連線準備包括建立底層連線與安全握手；再加上 WebSocket，通常還得完成相應的升級程序。gRPC 仰賴 HTTP/2 等機制，具有自己的串流管理與實作特性。連線重用、工作階段恢復，以及既有連線是否仍有效，都會改變後續請求的成本。因此首次載入較慢、連續瀏覽卻正常，可能是連線準備較繁複，而非持續傳輸頻寬不足。

頻繁建立短連線的工作，握手、解析與排程所占比例通常較高；持續下載則更能反映線路容量與壅塞控制的差異。若伺服器提供多種組合，可先選擇參數較少且用戶端明確支援的一種作為基準，再比較外層封裝是否帶來效益。不要只因某種傳輸名稱比較熟悉，就刪除服務提供者指定的路徑、服務名稱或主機欄位；這些資訊可能用於伺服器端路由。

排查問題時，憑證錯誤應透過修正名稱、時間或伺服器憑證處理，而不是長期關閉驗證。停用驗證會降低對伺服器身分的確認，也會把設定錯誤掩蓋成暫時可用。對新手而言，完整訂閱通常比手動輸入複雜組合更可靠；想了解訂閱會保留哪些欄位，可接著閱讀本頁的訂閱相容性章節。

四、Hysteria2 與 TUIC：採用 QUIC 的取捨

QUIC 改變的是連線承載方式

QUIC 在 UDP 之上提供安全連線、可靠串流與壅塞控制等功能。它不是把可靠性完全交給應用程式處理，也不會因為使用 UDP 就自然比 TCP 快。在部分封包遺失的情況下，它能減少不同資料流彼此等待，但同一資料流仍需依序傳遞，所有資料流也仍受共用線路容量限制。無線訊號不佳、出口壅塞或伺服器負載過高，都不會因改用 QUIC 就消失。

Hysteria2 與 TUIC 都運用 QUIC 相關功能，但並非可以互換的協定。兩者在驗證、轉送方式、參數與壅塞控制選項上各有不同，伺服器類型必須與用戶端設定相符。舊版 Hysteria 設定也不能只改類型名稱就當成 Hysteria2 使用。匯入時若遇到不支援的類型，應先確認協定版本與核心支援範圍，再處理欄位對應。

Hysteria2 的頻寬參數不是測速結果

Hysteria2 為高延遲或有封包遺失的線路提供另一種傳輸選擇；常見實作可依設定使用預期頻寬來調整傳送行為，也有不同的壅塞控制方式。訂閱中的上行與下行參數，通常是設定目標或提示，並非用戶端實際測得的可用速度。伺服器也可能限制連線行為，因此不能把介面上的頻寬數字直接視為效能保證。

若預期頻寬設定遠高於網路實際能力，可能造成排隊與封包遺失，進而影響通話和網頁瀏覽。家庭共用網路尤其要留意：單一下載看似跑得更滿，不代表整體體驗更好。若用戶端提供相關設定，請先保留服務提供者指定的數值；要調整時，應考量網路頻寬、上行瓶頸與其他裝置的使用量，逐步測試並記錄高負載時網頁能否即時回應。

使用 TUIC 也要確認實作與驗證方式

TUIC 以 QUIC 連線為基礎進行代理轉送，可承載不同類型的資料流，也提供 UDP 轉送相關機制。不同協定版本與實作可能採用不同的驗證方式和設定欄位，不能拿舊連結推定新核心都能匯入。即使不同用戶端都顯示 TUIC，仍應確認伺服器要求的驗證資訊、伺服器名稱與壅塞控制選項，別只填入位址就靠預設值碰運氣。

壅塞控制會根據回饋調整傳送量，並非越積極越好。不同演算法在封包遺失、佇列與公平性上各有取捨，實作方式也會隨維護而演進。沒有控制變因的測試時，不宜宣稱某種演算法一定能提升固定比例的效能。請優先使用伺服器與用戶端都明確支援的選項，除了比較持續傳輸，也要觀察同一網路上的其他應用程式是否受到影響。

使用前提是 UDP 網路可通

部分訪客網路、企業網路或行動網路可能限制 UDP，也可能對長時間傳輸採取不同處理方式。這時，TCP 節點可用而 QUIC 類節點逾時，不能直接證明驗證資訊有誤。可在同一裝置上切換到另一個網路重新測試，並查看記錄是在解析、握手還是驗證階段中止。若伺服器與設定都沒變，切換網路後的差異就是重要線索。

QUIC 也可能支援連線遷移，但手機從 Wi-Fi 切換到行動網路後能否順利恢復，仍取決於用戶端、系統、網路位址映射與伺服器實作，無法保證完全不中斷。玩遊戲時，還要確認遊戲流量已被接管，且節點允許相應的 UDP 轉送；能傳送遊戲資料，與一定能降低遊戲往返延遲，是兩回事。

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

先將效能拆成四種體驗

首次開啟速度會受網域解析、握手與目標網站回應影響；持續傳輸量更取決於線路容量、封包遺失與伺服器出口；互動流暢度關乎請求能否即時完成；連線恢復能力則看螢幕關閉、切換網路或閒置後，多久能重新使用。這四項可能得出不同結論。持續下載很快的節點，不見得適合頻繁喚醒的小型請求；首次載入稍慢，也不一定影響之後的長時間傳輸。

協定只能影響其中一部分。現代裝置可能具備加速加密運算的功能，實際加密方法與處理器實作會影響 CPU 負載；封裝層數、封包頻率與連線重用策略也會改變排程負擔。不能把桌上型電腦的資源使用結論直接套用到低功耗手機，更不能拿不同伺服器的兩次下載結果，推論協定本身的資源使用排名。記憶體用量也包含連線數、規則與快取。

手機耗電通常不只由加密選項決定

手機使用行動網路時，無線連線從低耗電狀態喚醒並維持活躍，都可能消耗電量。頻繁心跳、小封包傳輸、失敗重試與背景應用程式存取，會讓通訊模組持續運作。某個協定單次處理負擔較低，不代表整支手機一定更省電；若設定導致連線不斷中斷再重建，握手與喚醒無線連線的總成本反而可能更高，應觀察整段使用情況。

TUN 接管範圍較廣，可能連原本不會走代理的背景連線也一併處理，因此啟用前後耗電不同，不一定是出口協定變得更耗資源。規則數量、記錄層級、連線嗅探、DNS 請求與自動測速也會增加負擔。排查耗電時應固定流量接管模式，先關閉不必要的頻繁測速及長時間開啟的詳細記錄，再比較節點協定，避免多個變因混在一起。

保活、連線重用與閒置逾時要一併考量

較頻繁的保活有時能維持中間網路的位址映射，降低閒置後重新連線的機率，但也可能增加背景喚醒次數。間隔太長，位址映射則可能先失效，導致下次請求得重新建立連線。適合的設定取決於網路設備、電信業者環境與伺服器逾時設定，不能所有手機都套用同一個固定間隔。若服務提供者已給定設定，請先記錄問題現象，每次只調整一個相關選項。

連線重用能減少部分連線準備時間，但也可能讓不同工作共用同一連線的壅塞、故障與閒置處理。持續傳輸時省下的握手成本，不一定能抵銷所有情境下的共用影響。特別是互動操作和大型下載同時進行時，要留意網頁是否明顯變慢。不熟悉伺服器功能時，不建議隨意疊加多種連線重用擴充；先使用訂閱的預設設定，建立穩定基準後再比較。

比較耗電量時，至少要使用相近的時間長度與螢幕亮度；查看系統電池用量統計時，也要留意網路服務的耗電是如何歸類的。裝置發熱、系統更新與背景同步都可能干擾結果。發現異常時，先找出持續重試、背景大量傳輸或連線循環等狀況，不要直接更換所有協定。記錄設定與現象後，可搭配常見問題逐一縮小範圍。

六、原版、Meta 與 mihomo 的核心關係

「Clash」可能指整個生態系，也可能指特定核心

原版 Clash 奠定了廣泛使用的規則、策略群組與 YAML 設定習慣。後來出現不同分支、衍生實作與圖形化用戶端，名稱中帶有 Clash 的軟體，不一定使用相同核心。原版專案已停止維護，舊用戶端附帶的核心也不會因訂閱更新而自動增加功能。理解這一點，才能解釋為什麼同一個檔案在某台裝置上正常，換到另一台卻出現未知協定或欄位的提示。

Clash Meta 是這個生態系中的功能擴充分支名稱，mihomo 則是延續其核心專案使用的後續名稱。使用者討論時常交替使用這些名稱，但名稱相同或相近，不代表所有歷代版本都完全相同。較新的協定、安全組合與網路堆疊功能，仍應確認目前用戶端實際使用的核心；歷史教學中的 Meta 專用選項，也要確認是否仍適用於現行文件。

設定相容性分成三個層次

第一層是語法能否解析，例如縮排、清單與欄位類型是否符合 YAML 的解析要求；第二層是核心是否認得欄位，例如某種協定類型或 DNS 選項；第三層是執行環境能否完成操作，例如建立虛擬網卡、監聽連接埠與載入憑證。成功匯入通常只能代表前面的部分檢查已通過，不能證明網路權限完整，也不能證明所有節點都已完成連線測試。

較新的核心通常保留許多常見設定方式，但相容不代表所有舊檔案都能原封不動執行。淘汰的欄位、預設行為變更、規則資源格式與實驗性選項，都可能造成差異。反過來說，將新設定交給舊核心，也不能期待未支援的功能自動降級。遇到錯誤時應保留具體欄位路徑，而不是只記下「設定錯誤」，才能判斷問題出在語法還是功能支援。

圖形化介面可能會覆寫原始設定

用戶端經常透過覆寫、修補或合併設定來管理連接埠、系統代理、DNS 與 TUN。使用者編輯的訂閱檔案，不一定就是最後交給核心的內容。例如在檔案中修改混合連接埠，重新啟動後卻恢復原值，可能是圖形設定在啟動時覆寫了該欄位。應查看用戶端提供的執行中設定或合併預覽，而不是反覆修改會被訂閱更新取代的快取檔案。

遷移時建議先匯出原設定並記錄本機覆寫內容，再將副本匯入新用戶端。先停用 TUN，以規則模式搭配已知可用的節點確認基本連線，接著逐項恢復 DNS、規則資源與虛擬網卡。這樣遇到問題時，較容易判斷是哪個步驟造成差異。一次更換用戶端、核心、訂閱與流量接管方式，雖然操作較快，卻會大幅增加回復與排查的難度。

平台與權限仍是功能限制

Windows 的服務權限、macOS 的網路授權、Linux 的網路管理與防火牆，以及 Android 的 VPN 服務介面，都可能影響實際流量接管效果。iOS 用戶端也必須遵循自身的系統介面與功能實作，不能看到同名軟體就認定它與桌面版使用完全相同的核心功能。選擇用戶端時，應一併查看平台說明與匯入能力，不要把桌面截圖當成手機版的功能保證。

如果舊用戶端一啟動就關閉，別急著認定是訂閱協定太新。連接埠被占用、權限不足、設定語法或執行環境問題，也都可能導致啟動失敗。可先參考啟動當機排查清單取得記錄，再決定要更新核心、遷移設定或調整系統選項。

七、YAML、Base64 與 SIP008 的相容性界線

訂閱是提供設定的方式，不是連線協定

訂閱網址負責提供設定內容，其中可以包含節點、策略群組、規則與遠端資源。訂閱的下載方式，與節點使用 SS、Trojan 或 TUIC 並沒有直接對應關係。同一個服務提供者可能提供多種訂閱格式，名稱相似但適用於不同用戶端。優先選擇明確標示適用於目前用戶端或 mihomo 設定體系的入口，通常比事後轉換更能保留原始設定含義。

Clash 格式的 YAML 可能是一份完整設定，也可能只是節點資源。完整設定常見的頂層欄位包括代理清單、代理群組與規則；節點資源則可能只包含提供節點所需的部分結構，必須由主設定引用。把資源網址當成完整設定匯入，可能缺少用戶端所需的代理群組；反過來，把完整設定交給只讀取節點資源的入口，也可能因結構不符而無法匯入。

Base64 只代表編碼方式，不代表內容完整

許多訂閱會將多條分享連結組成的文字以 Base64 編碼。Base64 本身只是編碼方式，不會加密，也不會規定節點協定。解碼後可能混有 SS、VMess、Trojan 等連結，用戶端還必須逐一解析各自的語法。這類內容通常不具備完整規則設定的表達能力，因此匯入後有節點，卻沒有原本的群組與分流規則，不一定表示下載失敗。

SIP008 是提供 Shadowsocks 伺服器資訊的 JSON 格式，可描述一組 SS 伺服器及相關欄位，並非通用於六種協定的訂閱容器。不能因為它也是 JSON，就把 VMess 分享連結常見的 JSON 結構當成相同格式。判斷時應查看檔案的實際結構與用途，而非副檔名或能否在瀏覽器中顯示；訂閱網址的結尾也不一定能看出回傳格式。

轉換容易遺失的是語意，不只是欄位

轉換工具可以將一組分享連結整理成目標用戶端可讀取的節點清單，但無法從缺少的資料中還原原本就不存在的規則、策略群組與健康檢查。目標格式不支援的複雜傳輸欄位，可能會被忽略、降級或直接報錯。名稱相似的欄位，取值範圍也不一定完全相同，因此轉換後的檔案能成功解析，不代表實際連線行為與原設定一致。

訂閱內容可能包含連線驗證資訊，訂閱網址本身也可能帶有存取憑證。不要將真實網址交給來源不明的轉換服務；公開求助前，也應移除密碼、使用者識別碼與網址中的敏感參數。優先使用服務提供者的原生輸出格式，或可信任的本機處理方式。想進一步比較格式結構，請參閱訂閱格式與轉換說明。

將本機規則與訂閱更新分開管理

直接在訂閱下載的檔案中加入本機規則，下次更新時可能會被覆蓋。較穩妥的做法是使用用戶端明確提供的覆寫或合併功能，並確認它是取代欄位還是追加清單。規則通常依序比對，新增在最後不一定會生效：若前面已有預設規則，新規則可能沒有機會執行。代理群組中的名稱引用，也必須與實際節點或群組名稱一致。

mode: rule
mixed-port: 7890
allow-lan: false
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

上方範例是只採用直連的最簡設定，用來說明 YAML 縮排與規則順序，不包含代理節點。混合連接埠供本機應用程式使用，並關閉區域網路存取；範例中的網域規則會先比對，最後一行則處理其他連線。請勿直接用它取代正在使用的訂閱。若要改用代理出口，必須先有實際可用的節點與策略群組，再把規則目標設為確實存在的名稱，不能只修改一行文字。

更新訂閱後節點消失，應先確認回應內容是否仍為預期格式，再檢查匯入入口、解析記錄與本機篩選條件。有些用戶端會依名稱篩選節點，也可能保留上次選取的策略群組引用。將「回傳內容錯誤」、「欄位不相容」與「篩選後沒有結果」分開排查，比反覆點選更新更有效，也能避免誤刪仍可還原的設定副本。

八、依使用情境選擇，再查看記錄驗證

日常瀏覽、行動使用與持續傳輸

主要用於瀏覽網頁、辦公與同步文件時，先選擇訂閱中參數完整、連線穩定的節點。已有可用的 SS、Trojan 或 VMess，不必為了協定名稱重新建立整套設定。建議先安裝 Clash Plus 等適合目前平台的用戶端，依照快速入門教學完成匯入，再確認規則是否命中。若規則將部分連線導向直連出口，切換節點也不會影響這些請求，這是預期行為。

手機經常關閉螢幕、通勤時切換網路或使用行動數據時，應將恢復速度與背景重試納入比較。可在相同網路條件下比較一個 TCP 類節點和一個 QUIC 類節點，觀察待機後是否頻繁逾時。不要一開始就為了維持連線而縮短所有保活間隔。若只在系統長時間讓應用程式於背景執行後失效，也要檢查省電策略與 VPN 服務狀態，避免把系統暫停誤認為協定斷線。

持續傳輸或遠端互動若對封包遺失較敏感，可在網路允許 UDP 且伺服器設定完整的前提下，試用 Hysteria2 或 TUIC。比較時保留 TCP 類節點作為基準，並同時開啟一般網頁觀察回應。若大型下載占滿上行或下行，導致其他工作變慢，應先檢查頻寬目標與壅塞狀況，而非繼續提高預期傳送量。伺服器出口容量不足時，更換本機協定也無法增加頻寬。

遊戲、區域網路分享與路由器

遊戲與即時音訊／視訊首先要確認 UDP 轉送與流量接管範圍。系統代理通常無法涵蓋所有應用程式流量，必要時再評估 TUN。TUN 如何接入系統網路堆疊、DNS 如何處理，可參閱系統代理與 TUN 機制比較及虛擬網卡接管說明。即使成功接管，仍須確認伺服器路徑；無法保證所有遊戲的延遲都會改善。

手機或電視共用電腦代理時，應區分「裝置連到電腦的本機代理協定」與「電腦連到節點的出口協定」。混合連接埠可以同時接收 HTTP 與 SOCKS5，但仍要確認裝置是否支援相應的代理設定。啟用允許區域網路連線後，應限制可使用的範圍並檢查防火牆；詳細步驟請參閱混合連接埠與區域網路分享設定。路由器也須考量處理器、記憶體、連線數與規則規模。

依連線發生順序逐步排查

第一步，確認應用程式的請求是否出現在連線或記錄頁面。完全沒有記錄時，先檢查應用程式代理設定、系統代理狀態或 TUN 接管；有記錄再查看命中的規則與策略群組，確認請求沒有被送往預期之外的出口。第二步，檢查伺服器網域是否解析成功，尤其留意 DNS 是否依賴尚未建立的代理路徑。先排除基本解析問題，再檢查節點驗證，否則後續測試可能根本沒有實際進行。

第三步，檢查底層連線與安全握手。連線逾時時，重點檢查位址、連接埠與網路可達性；憑證錯誤時，檢查時間、名稱與憑證鏈；驗證失敗時，再核對密碼、使用者識別碼與協定版本。第四步才檢查目標服務存取與 UDP 轉送。不要把所有錯誤都歸咎於 DNS，也不要透過停用憑證驗證或切換全域直連暫時掩蓋問題，否則會失去排查線索。

最終選擇不必永遠固定。家用網路、行動網路與訪客網路可以使用不同的優先節點，但規則結構與備援方式應盡量清楚。可重複驗證的穩定結果，比單次測速的最低數字更值得採用。需要更換用戶端時，可回到下載頁面確認平台與維護狀況；一般操作問題請參閱常見問題，協定與核心差異則可依本頁目錄繼續查找。