Clash 協定與核心指南

核心家族與用戶端的分工

介面、核心與設定各自負責什麼

Clash 既是過往專案的名稱，也常泛指一類相容其設定習慣的代理工具。實際運作時，圖形介面用戶端負責管理訂閱、切換系統代理、申請權限及提供操作介面；核心則負責建立連線、比對規則、處理 DNS 與轉送資料。兩者可能分開更新，因此介面看起來相似，不代表支援的協定、欄位與網路功能完全相同。

設定會串起節點、策略群組、規則與 DNS 選項。選擇節點，只會決定某個出口的連線參數；選擇策略群組，則可能觸發自動測試或故障切換；切換規則模式，會影響哪些連線使用這個出口。發生異常時，應先判斷問題所在層級：設定未載入、選錯策略群組與協定交握失敗，是三種不同問題，不能只靠反覆更換用戶端一併處理。

原版、Meta 與 mihomo 的關係

原版 Clash 奠定了常見的 YAML 設定結構、規則比對方式與代理群組概念，原專案已停止維護。Clash Premium 是歷史上的另一條發行分支，部分功能與開源原版不同，不能混為一談。閱讀舊教學時，應特別確認文中所說的 Clash 指的是哪種核心，而不只是看文章標題中的產品名稱。

Clash Meta 從相容 Clash 設定生態的方向擴充協定與功能，後續以 mihomo 之名延續維護。因此，舊資料中的 Meta 與目前所說的 mihomo 有直接的專案沿革關係，並非兩套毫不相關的協定標準。不過，名稱沿革不代表不同時期的版本功能都相同；尤其是較新的協定參數、DNS 行為與 TUN 選項，仍須以實際運作的核心為準。

用戶端可能沿用舊名稱，實際上卻已接入後續核心；反過來說，新版介面也可能搭配較舊的核心版本。可開啟關於、設定或診斷頁面確認核心名稱，再查看啟動記錄中的設定解析結果。不要只憑安裝檔名稱判斷。如果用戶端支援替換核心，請使用官方明確支援的替換方式，避免直接覆蓋不相容的執行檔。

選擇用戶端，先看操作是否順手

一般使用者可先從下載中心的首選用戶端 Clash Plus 開始，確認系統支援與訂閱相容後，再依桌面操作習慣考慮 Clash Verge Rev 或 FlClash。請留意，圖形介面的功能範圍取決於用戶端本身，不能因為使用某個核心，就認定介面一定提供所有進階選項。如果找不到介面入口，也要確認能否透過設定啟用相關功能。

封存的用戶端適合重現既有環境或讀取舊設定，不宜做為選用新協定的預設基準。Clash for Windows 與 ClashX Meta 已停止維護；遇到無法辨識的節點類型時，應先確認核心支援能力，而不是刪除所有報錯欄位。直接使用 Mihomo 核心則須自行管理設定、程序與權限，較適合伺服器、路由器或熟悉命令列維護的使用者。

SS 與 VMess 的設計取捨

SS：相對精簡的加密代理連線

Shadowsocks 通常簡稱 SS，最初以 SOCKS 代理的使用方式為基礎，目標是在用戶端與伺服器之間提供相對精簡的加密轉送。它不要求每條連線都額外套上 HTTP 傳輸層，因此常見設定的結構較直接。用戶端中的伺服器位址、連接埠、加密方式與密碼共同決定連線；其中任何一項不符，都可能造成連線建立後立即中斷。

選用 SS 時，應確認具體的加密方式，而不只是確認節點類型標示為 SS。現代部署常使用附帶驗證的加密方案，部分部署則採用 Shadowsocks 2022 系列；後者對金鑰材料與實作支援另有要求，不能隨意將一般密碼當成相容金鑰。同一協定名稱下的不同加密方式也不能互換，必須與伺服器端設定一致。

SS 的資源使用情況通常較容易預測，但仍會受到處理器指令集、加密實作、並行連線數與伺服器效能影響。桌上型處理器與低功耗路由器處理同一種演算法的能力可能差異很大。如果設定啟用了外掛程式或額外的傳輸封裝，原本精簡的連線結構就已改變；外掛程式名稱、參數與本機支援情況都應納入相容性檢查，不能再以基礎 SS 的開銷估算。

VMess：更多驗證與傳輸組合

VMess 源自 V2Ray 生態，在驗證、資料保護與傳輸組合方面採用自己的設計。常見分享連結除了伺服器位址與使用者識別碼，還可能包含傳輸類型、TLS、路徑與要求主機等欄位。用戶端必須一併解析這些欄位；若只保留位址、連接埠與使用者識別碼，通常不足以還原原本的連線。使用門檻主要來自組合較多，而不是某個設定特別複雜。

VMess 的驗證與系統時間有關，裝置時間偏差過大可能導致驗證失敗。排錯前先啟用系統自動校時，比修改加密欄位合理。舊資料也可能提到過時的驗證方式與額外識別參數，不宜直接照搬至目前的部署。應以伺服器提供的完整設定及核心目前支援的功能為準，避免不了解用途就把舊欄位照填進新用戶端。

同樣是 VMess，原生 TCP 與透過 WebSocket 傳輸的連線，在路徑、交握與中介服務需求上都不同。使用 WebSocket 時，路徑與要求標頭必須符合入口服務設定；若啟用 TLS，還要確認憑證與伺服器名稱。連線失敗不一定代表 VMess 本身無法使用，也可能是傳輸路徑遭到改寫、入口設定不符，或訂閱轉換時遺失了附加欄位。

如何比較 SS 與 VMess 才有意義

如果已經有穩定的 SS 節點，日常瀏覽網頁與一般下載通常不必只為了協定名稱而遷移。如果服務提供者給的是完整 VMess 設定，應優先保留原有的傳輸組合，再進行實測。這兩種協定都不能光憑名稱保證 UDP 應用可用：用戶端、核心、伺服器與流量接管方式都必須支援；設定中的 UDP 選項也無法憑空增加伺服器端的能力。

比較時先固定線路與測試項目，分別觀察首次連線、重複存取與持續傳輸。如果一個節點使用 WebSocket 加 TLS，另一個採用直接加密傳輸，測試結果反映的是整體部署差異，而非單一協定的優劣。保留易讀的記錄，標明錯誤發生在解析、連線、驗證還是應用程式回應階段，比把所有異常都稱為節點逾時更有助於後續處理。

Trojan 與 VLESS 的安全界線

Trojan：在連線基礎層使用 TLS

Trojan 採用以 TLS 為基礎的連線設計，建立受保護的通道後再進行驗證並承載代理要求。常見設定看起來精簡，但憑證鏈、伺服器名稱與密碼缺一不可。用戶端填寫的連線位址可以是網域或 IP 位址，TLS 驗證所使用的伺服器名稱則必須符合伺服器憑證與入口設定；兩者彼此相關，但不一定是同一個欄位。

TLS 提供加密與伺服器身分驗證，因此不應把停用憑證驗證當成連線失敗後的常見修復方式。憑證過期、系統時間錯誤、名稱不符與系統缺少信任鏈，都可能造成相似的交握錯誤。正確做法是先查看記錄找出原因，再修正憑證或名稱設定。如果伺服器使用自建信任體系，應透過用戶端支援的憑證信任方式處理，而不是長期忽略驗證。

Trojan 的日常表現與 TLS 實作、連線重用及線路狀況有關。首次連線通常需要建立底層傳輸連線並完成 TLS 交握；後續要求能否重用既有通道，則取決於實作與設定。不能因為使用 TLS 就推論所有小型要求都很慢，也不能因為某次熱連線測試很快，就認定切換網路後的冷啟動也一樣迅速。測試時應區分這些狀態。

VLESS：分開理解協定層與安全層

VLESS 在設計上簡化了代理協定本身的處理，將資料保護交由選用的安全層或傳輸方式負責。它通常使用使用者識別碼進行驗證，但使用者識別碼不等於傳輸加密。查看設定時，不能只看到類型是 VLESS 就認定連線具備完整的機密性與身分驗證；還必須確認 TLS、REALITY 或其他受支援組合的實際設定，以及伺服器端是否使用相對應的設定。

在支援的部署中，REALITY 使用不同於一般憑證設定的身分驗證參數。公鑰、短識別碼與伺服器名稱等欄位都有明確用途，不能當成可任意修改的備註。相關參數能否使用，也取決於用戶端整合方式與核心實作。分享連結可能包含這些資訊，但匯入後仍應重新確認設定，尤其要留意轉換工具是否直接捨棄無法辨識的參數。

VLESS 的傳輸方式與流量控制選項也要分別確認。某個節點能在其他生態系的用戶端使用，不代表任何 Clash 類用戶端都能原樣運作；即使協定類型相同，只要傳輸擴充不同，仍可能不相容。不要把不明的流量控制值改成看起來相近的值來嘗試修復，因為這可能改變通訊語意。較穩妥的做法是取得明確適用於目前核心的設定。

驗證、加密與流量接管方式不可混為一談

密碼或使用者識別碼用於驗證，TLS 等安全層用於保護連線，TUN 與系統代理則負責將應用程式流量送入核心。這三類設定位於不同層級。啟用 TUN 無法補上缺少的 TLS 參數，切換規則模式也無法解決憑證名稱錯誤。反過來說，先透過系統代理確認基本連線，再逐步擴大接管範圍，有助於找出問題，也能避免同時更動多項條件。

實際選擇時，Trojan 常適合已有完善 TLS 部署、希望集中管理參數的情境；VLESS 則較適合需要明確傳輸組合，且已確認伺服器與核心支援能力的情境。兩者都無法脫離線路品質保證速度。對用戶端使用者而言，完整、易維護且保留驗證機制的設定，通常比選一個聽起來較新的協定名稱更重要。

Hysteria2 與 TUIC 的 QUIC 傳輸路徑

QUIC 能解決什麼問題，又有哪些依賴

QUIC 以 UDP 為基礎提供可靠傳輸，並整合新式 TLS 交握機制。它能在同一條連線中承載多個串流；單一串流的資料遺失，通常不必像單一 TCP 位元組串流那樣阻塞其他串流的資料傳送。這為多要求並行與部分封包遺失的環境帶來更多設計空間，但 QUIC 仍需要重傳、壅塞控制與加密處理，並非能避開頻寬、延遲與伺服器負載限制的捷徑。

使用 QUIC 類代理前，先確認所在網路能否穩定傳送 UDP。有些網路雖然能正常瀏覽網頁，卻會縮短 UDP 工作階段的存續時間、限速或直接丟棄封包。因此，TCP 類節點可用，但 Hysteria2 或 TUIC 逾時，並不矛盾。啟用用戶端的 UDP 轉送選項，也無法改變接取網路對 UDP 的處理方式；必要時須更換網路或使用合適的備用出口。

Hysteria2：頻寬設定會影響傳送行為

Hysteria2 採用以 QUIC 為基礎的代理傳輸方式，其協定世代與早期 Hysteria 不相容，不能只改節點類型名稱就完成遷移。驗證、TLS 與其他協定參數必須在伺服器端與用戶端保持一致。如果訂閱只標示含糊的 Hysteria 名稱，應先向設定提供者確認協定世代與目標格式，避免把交握不符誤判為伺服器暫時負載過高。

Hysteria2 的壅塞控制與頻寬協商會影響連線表現。實際使用 Brutal 相關傳輸方式時，尤其要留意上行與下行頻寬設定；數值並非愈大愈好。設定值明顯超過線路實際能力，可能增加封包遺失、排隊延遲，並讓其他應用程式等待更久。應依可持續取得的頻寬保守設定，並留意單位；伺服器端策略及用戶端的實際實作也會影響最終行為。

如果部署使用其他壅塞控制方式，就不應硬套另一份設定中的頻寬參數。先確認目前核心如何解析這些欄位，再一次調整一個變數並重複測試。可選的混淆參數也必須與伺服器端一致，不能以為填入後就一定能改善連線。一般使用者通常保留經設定提供者確認的完整設定，比頻繁嘗試未經說明的進階選項更穩定。

TUIC：多串流連線與 UDP 轉送

TUIC 同樣透過 QUIC 承載代理連線，並設計了相應機制來處理多串流通訊與 UDP 轉送。不同協定世代的驗證欄位與行為可能不同，目前常見的設定會包含使用者識別碼、密碼、TLS 與壅塞控制等資訊。匯入時應依伺服器明確支援的世代處理，而不是認為所有 TUIC 分享連結都能由同一個舊版核心辨識。

TUIC 的 UDP 轉送方式、連線保活與壅塞控制選項，會影響不同工作情境下的表現。大量並行要求、即時資料封包與長時間下載，對連線的需求並不相同；某種設定適合下載，不代表也適合語音通話。涉及零往返交握的選項時，還須考量重播風險與實作預設值，不應只為縮短測速時間就啟用；建議優先採用用戶端與伺服器端建議的組合。

保留 TCP 備用路徑

Hysteria2 與 TUIC 都值得在高延遲或有封包遺失的網路中實測比較，但結果應包含連線成功率，而不只是成功連線時的速度。無線網路切換、裝置休眠與電信網路的 UDP 策略，都會影響長期可用性。建議保留經測試的 TCP 類節點做為備用，並確認自動策略群組的測試結果符合目標應用需求，避免網頁探測成功、即時應用卻持續失敗。

如何比較連線速度與資源使用

將連線過程拆成數個階段

一次網頁要求至少可能經過網域名稱解析、連往代理伺服器的傳輸連線、協定驗證、遠端目標連線與應用程式回應。控制面板的延遲測試通常測量的是對某個探測位址送出要求所需的時間，不是單純的實際往返時間，也不是下載頻寬。不同用戶端的測試位址、逾時設定及是否重用連線各有不同，顯示數值不宜直接跨軟體比較排名，更不能用單次測試結果取代長期觀察。

冷連線需要建立新的傳輸與安全狀態；熱連線則可能重用既有工作階段。短時間瀏覽網頁、頻繁開啟小型 API，以及持續下載，對這兩種狀態的敏感程度不同。若要比較首次開啟速度，應在一致條件下重新建立連線；若要比較日常瀏覽，則應連續存取並觀察連線重用情況。不要一邊使用既有的長連線，另一邊卻讓不同協定每次都重新交握。

以相同工作測試完整連線路徑

盡量選擇相同地區、伺服器條件相近的節點與相同目標資源，固定裝置及網路，並暫停其他高流量工作。先記錄是否連線成功，再觀察首次回應與持續傳輸表現。至少分開測試一般網頁、大型檔案與實際使用的即時應用。每輪只改變一項條件，重複幾輪後觀察波動範圍，不必為了得到漂亮的單一數字而反覆挑選最佳結果。

資源使用情況應搭配工作量一起評估。相同時間內傳輸更多資料時，CPU 使用率較高不一定代表實作效率較差；大量閒置連線、規則集、DNS 快取與圖形介面也會占用記憶體。如果要比較核心本身，應盡量固定用戶端介面狀態與規則設定，並區分用戶端程序和核心程序，避免將介面繪製的負擔誤算為代理協定的成本。

連線重用、並行處理與線路瓶頸

連線重用可以減少重複交握，但不能預設重用愈多愈好。多個應用程式共用同一條底層連線時，壅塞、重傳與伺服器實作都會互相影響。以 TCP 為基礎的連線重用與 QUIC 多串流也不是同一種機制。若單一連線下載正常，多個應用同時使用卻變得卡頓，應檢查共用連線與並行限制，而不是立刻切換成全域模式。

在低功耗裝置上，加密演算法實作與資料複製可能比線路頻寬更早成為瓶頸；在高速桌上型電腦上，伺服器限速或目標網站回應較慢則更常見。如果持續傳輸時 CPU 長時間滿載、裝置發熱並降頻，改用更複雜的協定未必能改善體驗。先減少不必要的封裝、記錄輸出與並行測試，再評估裝置能力，避免用網路設定處理硬體瓶頸。

自動策略群組也會影響測試結果。url-test 會依探測結果選擇出口，fallback 著重依序使用可用出口，load-balance 則依自身策略分配連線，並不是把所有線路的頻寬直接相加。想了解切換條件，可參閱三種自動策略群組的切換方式。比較協定時，建議先固定手動選擇的出口，排除策略群組切換造成的干擾。

行動裝置耗電與網路切換

耗電取決於整條工作流程

行動裝置上的代理耗電，不能只按 SS、Trojan 或 QUIC 排出固定名次。無線模組啟用時間、行動網路訊號強度、背景喚醒、加密處理、記錄檔與應用程式流量都會共同影響結果。即使兩次使用同一個節點，螢幕亮度、定位工作與網路涵蓋範圍不同，也可能造成明顯差異。應先確認測試期間的工作情境相近，再討論協定本身增加的耗電。

保活封包有助維持工作階段，但也可能讓無線模組頻繁離開低耗電狀態。某些網路中的 QUIC 或 UDP 工作階段需要更積極地維持連線對應；不過，保活間隔太短會增加裝置喚醒次數，太長又可能在恢復連線時重新連線。建議優先保留經驗證的預設值，只有在記錄檔或可重現的現象顯示工作階段經常過期時，才針對問題調整。

背景測試與記錄檔都是可調整的因素

自動策略群組若頻繁探測大量節點，會產生與前景應用程式無關的連線。多個群組各自測試，再加上用戶端同時顯示即時統計，額外負載可能層層疊加。行動裝置通常適合減少不必要的測試範圍，依使用頻率設定合理間隔，而不是持續更新所有節點。設定間隔時應兼顧故障偵測速度，不能為了省電而完全停用必要的可用性檢查。

除錯記錄適合短期找出問題，不適合長期保存所有細節。大量記錄可能增加字串處理、儲存寫入與介面更新的負擔；持續開啟連線面板也可能增加額外耗能。完成排錯後，請將日常記錄等級調低，並關閉不需要的即時檢視。如此測得的耗電表現會更接近一般使用情況，也能減少訂閱網址、目標網域等敏感資訊持續留存在本機記錄中。

TUN、系統代理與平台支援

行動作業系統通常透過系統提供的 VPN 或網路延伸介面接管流量；桌面版的系統代理與 TUN 選項，不能直接等同於相同的行為。Android 的逐應用程式設定、背景限制與電池最佳化，以及 iOS 的網路延伸生命週期與系統休眠，都可能影響連線維持。選擇用戶端時，應以平台實際支援的功能為準，不要照搬其他作業系統的權限設定方式。

TUN 能擴大可處理的應用程式範圍，但不代表每條被接管的連線都會經過遠端代理，最後仍由規則決定。DNS 設定錯誤可能導致重複查詢與重試；規則範圍過廣，則可能讓原本可直接連線的高流量工作繞遠路。改善耗電前，應先確認流量分流符合預期；若仍保留大量失敗重試或錯誤出口，單純更換協定往往無法持續改善。

切換網路後的連線恢復，比單次測速更重要

從 Wi-Fi 切換到行動網路後，來源位址、路由與工作階段對應都可能改變。QUIC 的設計支援連線遷移，但代理實作、伺服器設定與作業系統生命週期未必能讓連線每次切換都維持不斷。因此，應實際檢查切換網路後的第一個要求、裝置從休眠喚醒後的連線，以及弱訊號恢復情況；不能因為協定具備某項設計能力，就認定應用程式永遠不會斷線。

實測時可分別記錄待機、輕度瀏覽與持續傳輸三種狀態，每次盡量維持相近的訊號強度與工作時間，並查看系統電池統計中的背景活動。如果主要在閒置階段耗電，應先檢查保活、探測與背景重新連線；如果耗電集中在大量傳輸期間，再觀察 CPU、發熱與無線網路。這兩類問題的處理方向不同，分開測試才能避免錯誤歸因。

訂閱格式與設定相容性

節點連結集合不等於完整設定

常見訂閱內容大致分為節點分享連結集合與完整 YAML 設定。連結集合主要描述如何連線至伺服器；完整設定還能包含代理群組、分流規則、DNS 與運作選項。Base64 是一種編碼格式，不是獨立的代理協定，也不能只因內容經過編碼就認定它相容 Clash。解碼後可能仍是其他用戶端的格式，必須繼續檢查內部結構。

訂閱網址能在瀏覽器開啟，也不代表一定會回傳可用設定。它可能回傳登入頁面、到期通知或其他格式的文字。更新失敗時，應先區分網路要求失敗與內容解析失敗：前者檢查網址是否可連線及授權狀態，後者檢查實際回傳格式與核心錯誤訊息。不要將含有私人授權資訊的訂閱網址提交至公開測試網站，也不要直接貼在公開問題紀錄中。

轉換時可能遺失哪些資訊

轉換工具必須理解輸入協定、附加傳輸參數與目標核心的語法。如果工具無法辨識某個欄位，可能直接忽略，也可能產生能解析卻無法連線的節點。VLESS 的安全層參數、WebSocket 要求標頭、TUIC 世代資訊與 SS 的特定加密方式，都是需要特別確認的項目。節點名稱仍然保留，不代表通訊參數也完整保留。

規則與策略群組遺失同樣值得注意。只有節點的訂閱無法自動還原原有的分流邏輯；轉換時重新命名代理群組，也可能讓規則指向不存在的目標。合併設定時，同名節點還可能彼此覆蓋。匯入後應先確認節點數量與類型是否合理，再檢查策略群組的引用，最後確認規則末端有符合預期的預設處理方式；不要只看匯入成功的提示。

分別檢查 YAML 語法與核心語意

YAML 以縮排表示層級，縮排不同可能讓欄位落在錯誤的物件中。通過語法檢查只代表文字結構可讀，不代表目前的核心支援這些欄位。有些未知欄位可能被忽略，有些型別不符則會直接造成載入失敗。處理錯誤時，應從記錄指出的欄位往上檢查所在層級，優先修正單一明確問題，不要將整份設定換成來源不明的長篇範本。

以下規則片段適用於已有完整設定的情況，用來說明策略引用與比對順序，並非含有伺服器資訊的獨立訂閱。第一條讓範例網域直連，第二條讓私有位址直連，其餘流量則送往名為「手動選擇」的既有策略群組。該群組必須已經定義；實際網域與出口應依需求調整。規則順序改變，結果也可能不同。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,手動選擇

第三方用戶端可能會在載入前合併自身設定、覆寫設定或補上規則，因此直接編輯磁碟上的訂閱檔案不一定能永久生效。下次更新可能覆蓋修改，用戶端介面設定也可能優先於檔案內容。若要長期保留變更，應使用用戶端支援的覆寫、合併或獨立規則功能，並確認最後實際生效的設定。先備份、再更新、最後驗證，比直接修改快取檔案更可靠。

資料檔案也要與設定一併維護

GEOIP、GEOSITE 或規則集的引用都依賴相應的資料來源。若節點交握成功但流量分流異常，也要檢查資料是否載入並更新。不同資料格式不能只改副檔名互換。可參閱GeoIP 與 GeoSite 更新說明確認資料來源；需要比較訂閱結構時，請參考訂閱格式與轉換指南。更新核心或資料後，使用同一批目標連線重新檢查結果，確認變化符合預期設定。

情境選擇與排錯順序

先排除不符合條件的組合

選擇時先看基本條件，再比較速度。確認用戶端執行的核心支援該協定與傳輸組合、訂閱包含完整參數、所在網路允許所需傳輸方式，且裝置能承受長時間負載。四項中只要有一項不符，就不應試圖靠反覆測速彌補。接著再比較實際工作的回應速度、穩定度與耗電，最後保留一個日常出口和一條經驗證的備援路徑，通常比維護大量未知組合容易。

日常瀏覽網頁與辦公時，優先使用已穩定運作、驗證與安全參數完整的節點。SS、Trojan、VMess 或 VLESS 都可能符合需求，應以連線成功率、目標回應與維護成本作為選擇依據。如果工作環境經常切換網路，應增加休眠恢復與網路切換測試；若需要讓區域網路裝置連線，還要另外檢查路由、DNS 與直連規則，不要將所有連線都送往遠端。

持續下載或同步大型檔案時，應著重觀察長時間傳輸量、封包遺失後的恢復情況，以及是否影響其他應用程式。Hysteria2 與 TUIC 可列入比較，但前提是 UDP 通訊可靠，且壅塞控制設定合理。即時語音與互動應用則更重視抖動、短暫封包遺失與連線恢復；下載速度快的節點不一定更適合，必須使用實際應用測試雙向通訊。

路由器與低功耗主機尤其需要考量處理器架構、記憶體與散熱。一般桌面使用者優先選擇圖形介面用戶端；伺服器管理者再考慮獨立的 Mihomo 核心。安裝前請至核心下載區確認目標平台與處理器架構，不要只看作業系統名稱就選擇。已有可用設定時，先在新環境驗證，確認正常後再切換主要流量，並保留復原檔案與原有設定。

依失敗階段縮小排查範圍

第一步確認設定是否載入：無法辨識節點類型，通常與核心功能或轉換格式有關；縮排錯誤則指向文字結構。第二步確認是否能連上伺服器：逾時可能來自位址、連接埠、路由或傳輸方式無法連線；連線遭拒則較可能是連接埠未監聽或服務尚未啟動。第三步再檢查驗證與 TLS，分辨密碼錯誤、系統時間問題或憑證問題；不要在這些階段同時修改 DNS 與規則。

第四步檢查目標連線與規則。如果只有部分應用程式失敗，請確認該應用是否經過系統代理或 TUN，再查看命中的規則與實際出口；如果網域無法連線，但直接使用位址正常，應優先檢查 DNS，不要以直接存取位址取代正確的 HTTPS 驗證。若所有節點都逾時，可依節點逾時排查順序檢查共通因素，避免把同一個本機問題重複歸咎於每台伺服器。

連線恢復後，應交叉確認出口資訊與連線面板，而不只是看開關是否已開啟。可參考首次連線驗證流程，記錄應用程式、規則、出口與失敗時間。準備排錯記錄時，請刪除密碼、使用者識別碼、訂閱授權資訊與私人位址，只保留協定類型、核心名稱、網路環境及已去識別化的錯誤資訊。

常見選擇問題

完成選擇後，記錄穩定的組合及其適用網路，後續每次只變更一項重要條件。更換核心、轉換訂閱或調整 DNS 後，請重新執行基本驗證；沒有明確問題時，不必持續追逐所有進階參數。本頁用來說明各種取捨，安裝與匯入的詳細步驟請參閱使用教學；術語定義則可依分類查閱術語表。