Clash 協定與核心選擇

協定、傳輸方式與核心各司其職

圖形介面不等於協定實作

在 Clash 中看到一個連線項目，背後其實涉及多個層次。協定定義身分驗證、目標位址描述及資料封裝方式；傳輸方式決定資料如何透過 TCP、WebSocket 或其他載體傳送；TLS 等安全層則負責加密及驗證伺服器身分。這些資訊常被放在同一個分享連結中，但不能混為一談。看到 VLESS 這個名稱，不代表一定啟用了 TLS，也無法據此確認底層使用哪種傳輸方式。

圖形用戶端負責管理訂閱、系統匣選單、系統代理及編輯設定；核心則負責建立連線、比對規則、處理 DNS 與轉送資料。介面顯示某個協定名稱，不代表內附核心支援該協定的所有擴充功能；核心能辨識參數，也不代表介面編輯器可以完整保留這些參數。判斷相容性時，應一併查看用戶端說明、實際執行的核心，以及最後交由核心處理的設定，而非只看安裝檔名稱。

原版 Clash、Meta 與 mihomo 的關係

原版 Clash 奠定了代理項目、策略群組、規則及設定檔的基本使用方式。Clash.Meta 在此生態中擴充協定與網路功能，後來以 mihomo 之名持續發展。因此，舊資料中的 Meta 核心與現有 mihomo 資料有明顯的承襲關係，但不代表任何舊設定都能直接沿用。功能何時加入、欄位是否更名、預設行為是否調整，都應以實際使用的核心文件為準。

尤其要分清原版開源核心、舊版 Premium 分支與後續衍生核心。舊教學提到的指令碼、規則提供者或虛擬網卡功能，可能是為不同分支設計，不能只憑「Clash 設定」幾個字就照搬。遷移時先保留代理項目與簡單策略群組，再逐步還原 DNS、規則集與 TUN；一次加入所有進階欄位，解析錯誤與執行行為變化便會交錯發生，不易找出原因。

先確認功能支援，再比較介面

Windows 新手可先從下載頁推薦的 Clash Plus 開始，再依設定需求比較 Clash Verge Rev、FlClash 或 Clash Nyanpasu。挑選介面時，優先確認能否匯入訂閱、所需協定是否可用，以及系統代理與服務模式是否容易管理。兩款用戶端都能匯入同一個連結，不代表它們的 DNS、覆寫順序與 TUN 行為完全相同。

已停止維護的用戶端更需謹慎看待。Clash for Windows 已停止維護，適合保留舊環境或查閱歷史設定，但不適合用來判斷新協定的支援狀況。更換核心也不是通用的升級方法：用戶端可能依賴特定控制介面、啟動參數或目錄結構。若介面沒有提供明確的核心管理入口，應採用官方支援的更新方式，不要直接覆蓋執行檔。

SS 與 VMess：加密封裝與連線組成

SS 的精簡設計與加密方法相容性

Shadowsocks 通常簡稱 SS，設計重點是較直接的加密代理封裝。用戶端與伺服器會約定伺服器位址、連接埠、加密方法及金鑰資料，再轉送目標連線。它不要求每條連線都模擬網頁請求，也不強制套用完整的憑證架構，因此在設定簡單、雙方功能明確的環境中較容易管理。不過，架構精簡不代表任意組合都能連線；加密方法不一致仍會在初期就失敗。

檢查設定時，先確認 cipher 與 password。傳統 AEAD 方法與 Shadowsocks 2022 系列採用不同的金鑰約定；後者對金鑰長度與表示方式有明確要求，不能直接填入一般的短密碼。若伺服器提供的分享連結含有特殊字元，請保留原始編碼；手動拆解再貼上時，多出空格、解碼錯誤或漏掉後綴，都可能導致連得上連接埠卻無法完成通訊。

部分 SS 項目也需要外掛程式。外掛程式負責額外的傳輸方式或封裝，不是 SS 核心協定的必要組成。核心支援某種加密方法，不代表也支援分享連結所需的外掛程式及其選項。疑難排解時，應分別核對伺服器、加密方法、外掛程式名稱與參數；單純刪除外掛欄位以消除設定錯誤，往往只是讓問題延後到交握階段才出現。

VMess 的身分驗證與舊版選項

VMess 源自 V2Ray 生態，結合使用者識別、請求驗證與資料加密機制，常見設定會以 UUID 識別使用者。它可透過較直接的 TCP 連線運作，也能搭配 WebSocket、TLS 等方式使用。實際成本取決於整套組合：若比較一個純 TCP 項目與一個額外套用 TLS、WebSocket 的項目，觀察到的差異不應全歸因於 VMess 協定本身。

舊資料常會提到 alterId。這是舊版相容設定，不宜照舊教學任意填寫。現代 AEAD 用法通常設為零，但最終仍須符合伺服器要求。系統時間也值得檢查：涉及時間範圍的驗證機制，可能因時鐘明顯偏差而失敗。Windows 從睡眠模式喚醒、虛擬機器暫停或手動調整時間後，先同步系統時鐘，比不斷更換 UUID 更有助於排除問題。

傳輸參數必須一起理解。WebSocket 路徑、請求 Host 與 TLS 伺服器名稱可能相同，也可能各自負責不同用途；路徑填錯時，遠端可能回傳一般網頁或拒絕升級連線，而不會明確顯示「協定參數錯誤」。請依照伺服器提供的完整參數設定，不要看到一個網域就把它複製到所有欄位，也不要以瀏覽器能開啟該網域，就認定代理交握正常。

如何在兩種協定間取捨

若現有 SS 設定穩定可用，日常主要用於瀏覽網頁、連線程式碼儲存庫及一般應用，就不必只因其他協定名稱較新而遷移。SS 參數較少，較容易找出錯誤；但擴充外掛與新加密方法會增加相容條件。VMess 則常見於既有的 V2Ray 設定環境，優點是能沿用目前的部署與傳輸組合，代價是必須同時維護更多互相關聯的欄位。

UDP 應另外驗證。項目能開啟網頁，只能證明相關 TCP 服務路徑可用，不能證明遊戲語音、即時通訊或其他 UDP 流量也能轉送。還需核對協定實作、伺服器設定、設定中的 UDP 開關，以及應用程式流量是否確實經過用戶端。測試時應維持相同網路、目標與流量接管方式，否則難以分辨是協定能力還是本機路由造成差異。

Trojan 與 VLESS：驗證機制與安全層分離

Trojan 為何需要正確的 TLS 設定

常見的 Trojan 部署會以 TLS 承載代理請求，並在安全連線中進行密碼驗證及轉送目標流量。成熟的 TLS 功能是其重要基礎，因此憑證驗證並非可有可無的選項。設定中的伺服器位址可以是 IP，但憑證所對應的名稱通常是網域；這時應理解連線位址與 TLS 伺服器名稱各自的用途，而不是要求所有欄位都填入同一個字串。

用戶端建立 TLS 連線時，會檢查憑證鏈是否受信任、有效期限是否正確，以及名稱是否相符。任何一項失敗，都可能使後續 Trojan 驗證無法進行。遇到憑證錯誤，應先確認網域、系統時間與伺服器憑證設定；長期略過驗證會降低確認遠端身分的能力，也可能掩蓋連到錯誤伺服器的問題。應明確區分臨時疑難排解與長期設定。

密碼正確也不代表傳輸方式一定相符。有些部署使用直接 TLS，有些還會加上 WebSocket 或其他承載方式，用戶端必須依實際組合設定。若伺服器只接受直接 TLS，本機卻多設了 WebSocket 路徑，密碼正確也不會讓連線自動協商成功。匯入訂閱後，尤其要檢查轉換工具是否保留網路類型，以及目前使用的核心是否辨識相關擴充功能。

VLESS 驗證輕量，不代表具備完整加密

VLESS 同樣源自 V2Ray 相關生態，設計上減少協定本身的部分負擔，將更多安全保護交由外部傳輸層處理。常見部署使用 UUID 識別使用者，並搭配 TLS 或其他受支援的安全機制。最重要的是釐清一點：VLESS 這個名稱本身不保證連線已加密。應檢查實際的安全層與傳輸參數，不能只看用戶端列出的協定標籤來判斷連線受到何種保護。

VLESS 的相容性問題往往出在擴充組合，例如特定的 flow、傳輸類型或 REALITY 相關欄位。支援 VLESS 基本協定，不代表支援所有擴充功能，也不表示可以任意搭配。部分流量控制選項只適用於特定傳輸與安全組合；直接將其他地方看到的參數加進設定，可能通過剖析器檢查，卻在連線時失敗。請以伺服器約定及目前核心的支援範圍為準。

REALITY 也不能簡化成「換一個伺服器名稱」。連線涉及公鑰、短識別碼及其他協商參數，用戶端與伺服器必須設定一致。公鑰是必須準確提供的設定資料，不是讓使用者任意產生字串填入。匯入內容不完整時，應取得適用於目前用戶端的訂閱，或逐項核對原始設定；不要用隨機值補上缺少的欄位，只為通過介面檢查。

各網域欄位分別負責什麼

連線伺服器位址決定封包要送往何處；TLS 的 SNI 用於交握時的名稱指示；憑證驗證名稱用來確認伺服器身分；HTTP Host 則屬於應用層請求資訊。簡單部署中這些欄位經常相同，但概念上並不相同。疑難排解時，先註明各值的來源，再確認是否符合伺服器要求，比把所有網域都改成某個「能開啟的網站」可靠得多。

選擇 Trojan 或 VLESS，應先考量現有伺服器支援情況與設定是否完整。若伺服器提供標準的 Trojan TLS 參數，且憑證管理清楚，通常較容易依一般 TLS 流程檢查。若伺服器明確要求 VLESS 的某項擴充功能，就應選用已確認支援該組合的用戶端與核心。不要為了少填幾個欄位而移除安全層，也不要為了追求新功能，在穩定設定中加入不需要的擴充項目。

Hysteria2 與 TUIC：QUIC 傳輸的取捨

QUIC 帶來的改變與必要條件

QUIC 在 UDP 之上提供安全連線、多工與壅塞控制等功能。相較於多個邏輯串流共用一條 TCP 連線，QUIC 能避免某個串流遺失資料時，直接在傳輸層阻塞其他獨立串流；但同一串流內仍須依規則處理遺失資料。它無法消除封包遺失，也不會讓頻寬受限的網路憑空增加容量。討論相關協定前，首先要確認網路是否允許持續使用 UDP 通訊。

Hysteria2 與 TUIC 都使用 QUIC，但兩者並非可互換名稱的同一種協定。驗證方式、UDP 轉送機制、壅塞控制選項與具體參數都有差異。伺服器使用其中一種時，不能只在用戶端切換協定類型，其他欄位仍照舊沿用。尤其不要將舊版 Hysteria 設定直接當成 Hysteria2 設定，兩者在協定與設定上明確不同。

Hysteria2 的頻寬估算與傳送行為

Hysteria2 著重在高延遲、封包遺失等複雜網路環境下的傳輸表現，並提供與頻寬設定和壅塞控制相關的機制。設定中的上行與下行頻寬不是測速結果的顯示值，而可能會影響實際傳送策略。填入遠高於可用網路的數值，不一定會更快，反而可能造成佇列堆積、額外封包遺失與互動延遲。頻寬參數應依目前版本說明、伺服器限制及實際網路能力設定。

部分實作會依頻寬設定或協商條件採用不同的壅塞控制行為，因此「留白一定比較快」和「填滿一定比較快」都不成立。共用網路中，其他使用者與應用程式也會競用上行佇列；即使下載頻寬充足，上行塞滿仍會影響確認訊息與互動。測試時應觀察網頁回應、語音穩定度與持續傳輸表現，而不是只看一次大型檔案下載的峰值。

連接埠跳躍、混淆及其他選用功能都需要伺服器配合。啟用後，如果本機防火牆、網路設備或伺服器規則未開放相應的 UDP 範圍，可能會偶爾連線成功，隨後又中斷。這些功能並非解決效能問題的萬用開關。基本連線尚未穩定時，應先使用伺服器確認可用的簡單設定，再逐項恢復其他選項。

TUIC 的連線多工與 UDP 處理

TUIC 同樣著重運用 QUIC 傳送代理流量，常見設定包括 UUID、密碼、壅塞控制與 UDP 中繼模式。不同協定版本不保證互通；訂閱轉換若只保留類型名稱，卻遺失驗證欄位，即使成功匯入也無法連線。UDP 中繼模式會影響封包承載方式，請確認用戶端與伺服器支援相同的行為，不要把網路上看到的某個模式名稱當成所有環境的固定答案。

零往返相關選項在符合條件時可縮短恢復連線的等待時間，但不是普遍適用的首次連線加速功能。它涉及工作階段恢復、安全取捨與伺服器支援；協定函式庫具備相關功能，也不代表應用程式每次都會使用。對一般使用者來說，穩定的憑證、正確的驗證資訊與合適的閒置逾時設定，通常比盲目啟用所有低延遲選項更值得優先檢查。

如果網路對 UDP 限制較多，Hysteria2 與 TUIC 可能都不適合作為唯一連線方式。保留一個經過驗證的 TCP 類項目作為對照，有助於分辨伺服器問題與網路接入限制。切換 Wi-Fi 與行動網路後應重新測試，因為兩種網路的 UDP 閒置對應、路徑 MTU 與壅塞狀況可能不同；不能直接把辦公室的測試結果套用到通勤情境。

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

將「快」拆解成可比較的指標

連線速度至少涉及三個不同問題：建立新連線需要多久、互動請求多久收到回應，以及長時間傳輸能達到多少吞吐量。某種協定縮短交握等待，不一定能提高大型檔案的下載速度；某種設定適合持續傳輸，也可能讓小型請求等待更久。用戶端顯示的延遲通常只反映特定測試位址與測試方式，不等於所有應用程式的往返時間，更不能直接代表網頁完整載入時間。

影響結果的因素包括本機網路、伺服器負載、目標網站回應、路由路徑、加密實作與傳輸封裝。比較協定時，應盡可能固定相同裝置、網路、相近的伺服器位置與相同目標。若兩個設定分別連線至不同地區、頻寬也不同的伺服器，差異首先反映的是整條網路路徑，而非協定優劣。缺乏這些控制條件時，記錄「目前較適合」會比列出效能排名更準確。

CPU 與記憶體不能只看協定標籤

加密演算法能否運用處理器指令，會影響實際 CPU 負載；使用者空間網路堆疊、TUN、規則集規模與連線數量也會影響資源使用量。Windows 工作管理員中看到的用戶端處理程序可能只有介面，真正負責傳輸的核心可能是另一個處理程序。應一併觀察相關處理程序，不能因介面占用率低，就推斷整個代理連線幾乎不耗資源。

連線多工可以減少重複建立連線及交握的次數，但也增加連線生命週期的管理工作。它對大量短請求可能有幫助，對少數長連線則未必明顯。規則提供者更新、訂閱重新整理、連線記錄與頻繁測速，同樣會增加背景工作。排查資源使用異常時，先暫停密集測速與詳細記錄，再分別觀察閒置及傳輸狀態；不要在所有背景工作同時執行時，直接把資源占用歸因於某個協定。

手機耗電更受喚醒次數與網路狀態影響

行動裝置除了運算成本，也要考慮無線模組被喚醒及保持連線的時間。過於頻繁的保活、間隔過短的健康檢查與反覆重新連線，都可能延長無線模組的運作時間。TCP 或 QUIC 本身無法決定哪一種一定比較省電：訊號微弱時持續重傳的連線，可能比訊號穩定時使用另一種協定更耗電。背景應用程式數量、系統省電策略與網路切換也會影響結果。

實際比較時，可固定進行閱讀、觀看影片或語音通話等工作，盡量維持相近的螢幕亮度與網路條件，重複觀察電量、溫度及斷線情況。測試前先停止大量自動測速，避免把測試流量算進一般使用耗電。若待機耗電明顯，優先檢查保活間隔、健康檢查頻率與反覆重連記錄；若只有大量傳輸時發熱，再觀察吞吐量、CPU 與加密實作，區分閒置耗電與工作負載。

日常使用應追求速度夠快且穩定，而非一味追求最高峰值。筆記型電腦可分別觀察接上電源與使用電池時的表現；手機則應分開記錄 Wi-Fi 與行動網路的結果。測試時連同條件一起記錄，並保留可還原的設定；想進一步了解用戶端測試項目，可參閱節點延遲與驗證步驟，避免把測試失敗直接視為所有服務都無法使用。

設定檔、訂閱格式與參數相容性

分享連結、節點集合與完整設定

訂閱連結只是取得內容的入口；回傳內容可能是完整的 Clash YAML、經編碼的分享連結集合，或某個應用程式專用的設定格式。副檔名與網頁標題無法可靠判斷格式，應查看用戶端的辨識結果及服務提供者說明。完整設定通常同時包含代理項目、策略群組與規則；節點集合可能只有連線資訊，需要用戶端範本補上其他結構，兩者匯入後的行為並不相同。

單一分享連結可被辨識，不代表所有進階參數都能完整還原。轉換工具可能遺漏傳輸擴充、UDP 模式、用戶端指紋或安全層欄位；目標格式也可能根本沒有對應欄位。出現「匯入後看得到名稱，卻一直無法連線」時，先比對重要欄位是否完整，不要反覆重新整理同一份訂閱。訂閱網址可能包含帳號存取權限，請妥善保管，避免提交給不可信的線上轉換工具。

分別檢查 YAML 語法與設定內容

YAML 縮排決定資料層級，應使用空格，避免混入定位字元。值中包含冒號、井字號或特殊符號時，可適當加上引號，避免被解析為結構或註解。語法檢查通過，只代表檔案可讀取，不代表代理群組名稱存在、規則目標正確或協定參數有效。例如規則引用不存在的策略群組，可能在載入時報錯，也可能導致預期的路由無法建立。

以下是 mihomo 可讀取的最小直連檢查設定，用於確認本機監聽、策略群組與規則結構，不包含遠端代理連線。它不會提供遠端代理功能，也不能用來測試特定協定的效能。使用獨立測試設定前，請先備份目前檔案；如果用戶端會自動合併連接埠或 DNS 設定，也應在介面中檢查最後生效的內容，而非只依照編輯視窗判斷。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: ROUTE
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,ROUTE

這裡的 mixed-port 是應用程式連接本機用戶端的入口，不是遠端伺服器連接埠。allow-lan: false 會限制區域網路存取，適合本機檢查；MATCH 是兜底規則，會將未符合前置規則的連線交由指定目標處理。遷移設定時，常會把本機混合連接埠與伺服器連接埠搞混，兩者應分開列入檢查清單。

覆寫、提供者與規則順序

圖形用戶端可能會對訂閱套用全域覆寫、指令碼處理或設定合併，因此下載的原始檔案不一定與核心實際使用的檔案相同。手動修改訂閱快取，下次更新時也可能被覆蓋。較穩妥的做法是在用戶端支援的位置儲存覆寫內容，並確認套用順序；涉及協定憑證與伺服器參數時，請避免讓通用範本意外覆蓋單一連線的專用欄位。

proxy-providers 與 rule-providers 分別管理代理集合與規則集合，雖然都能從遠端取得檔案，但內容結構與引用方式不同，不能互換。規則通常依序比對，較寬泛的規則若放在前面，後續較精確的規則可能永遠不會生效。遷移後應檢查群組名稱、提供者引用與兜底目標，而不只是確認代理清單的數量看起來差不多。

訂閱更新失敗時，先分辨是連線失敗、驗證失效、回傳內容異常，還是不支援該格式。相關步驟請參閱訂閱更新失敗與自動更新設定。需要重新匯入時，可對照訂閱匯入教學；先在獨立設定中驗證，再遷移規則與覆寫，避免格式問題和原有環境問題混在一起。

依使用情境選擇協定與用戶端

網頁、開發工具與日常辦公

瀏覽器、文件網站與常見開發服務，通常首先需要穩定的 TCP 連線。現有 SS、Trojan、VMess 或 VLESS 設定若已能滿足需求，應優先檢查連線穩定度、憑證管理與訂閱維護，不必只因協定名稱而遷移。初次選擇 Windows 用戶端，可從 Clash Plus 開始；安裝入口請見Windows 用戶端清單，再依工作習慣比較其他受支援的用戶端。

命令列工具不一定會遵循系統代理。瀏覽器能連線而終端機失敗，可能只是終端機沒有設定代理環境變數，或工具只支援自己的代理選項。這時更換遠端協定通常沒有幫助。先確認應用程式如何連接用戶端，再決定使用明確指定的代理或 TUN；開發環境也要留意容器、虛擬機器與主機的回送位址不同，容器內的本機位址不會自動指向 Windows 主機。

即時通訊、遊戲與複雜網路

語音與即時互動更重視抖動、封包遺失與連線連續性，不只是平均延遲。應用程式可能同時使用 TCP 登入及 UDP 傳送媒體，因此「能登入但聽不到聲音」與「完全無法連線」代表不同的網路路徑出了問題。協定必須支援相應的 UDP 轉送，流量接管方式也必須涵蓋該應用程式；有些應用程式還會繞過系統代理直接建立連線，需從連線清單及規則比對結果確認。

面對高延遲或封包遺失的網路，可將 Hysteria2 與 TUIC 列入候選，但應保留 TCP 類連線作為對照。如果 QUIC 類連線在目前網路根本無法穩定建立，繼續調整壅塞控制參數也沒什麼幫助。反過來說，若 UDP 可連線且長時間表現更穩定，也不必因某種傳統經驗而排除。結論應以實際接入環境為準，切換網路後可以重新評估。

多裝置與長期維護

手機與桌面共用訂閱時，應以所有目標用戶端的共通功能為基礎，不要假設桌面可用的擴充功能在手機上也能使用。Android 可依需求比較 Clash Plus、Clash Meta for Android、FlClash 與 Surfboard；iOS 可從下載頁前往 Clash Plus 的商店頁面。用戶端名稱不同不代表協定一定不通，但仍須分別確認設定格式、網路擴充功能與背景執行行為。

macOS 使用者還需依晶片架構選擇安裝檔；Linux 則要區分圖形用戶端與直接執行核心的部署方式。桌面環境可比較 Clash Verge Rev 與 FlClash；伺服器環境則適合明確管理設定目錄、權限及程序服務。進一步說明請參閱Linux 部署 mihomo 與 systemd 服務設定；系統服務即使穩定執行，也不代表桌面應用程式已自動使用代理。

長期維護時，保留一份經過驗證的基本設定與簡短變更紀錄很有幫助。更新用戶端、更換核心、遷移訂閱及啟用 TUN，盡量分開進行；每一步都確認瀏覽器、終端機與所需的 UDP 應用程式正常，再進行下一項。這樣發生問題時，可以回到明確的狀態，而不必同時面對協定、規則與系統設定的多項變動。

協定連線失敗的分層檢查

先找出失敗階段，再調整參數

疑難排解從一筆明確失敗的請求開始：記下應用程式、目標、使用的設定與發生時間，再查看相關記錄。設定無法載入、遠端無法連線、交握驗證失敗及服務請求逾時，分屬不同階段。不要看到逾時就立刻更換協定，也不要因設定成功載入，就認定遠端運作正常。先找出最早出現的有效錯誤；後續大量重試記錄往往只是同一原因一再發生。

設定載入階段應優先檢查未知協定、未知欄位、縮排與群組引用。若提示不支援某種類型，請確認目前執行的核心，而非只查看用戶端安裝名稱。網路連線階段則應檢查伺服器網域解析、位址與連接埠。Windows 可使用以下指令檢查 TCP 連接埠是否能建立連線；網域與連接埠應替換成伺服器實際提供的資訊，範例保留文件用途的網域。

Test-NetConnection -ComputerName example.com -Port 443

這個指令無法驗證代理身分，也不能驗證 Hysteria2 或 TUIC 所需的 UDP 連線。TCP 連接埠測試成功，只能說明相應的 TCP 連線基本上可到達；QUIC 類連線則需搭配核心記錄與伺服器記錄判斷。不要因為相同數字的 TCP 連接埠可連線，就推斷 UDP 也已開放；防火牆與網路設備可能分別處理兩種傳輸。

分別核對交握、DNS 與規則

進入交握階段後，依協定核對驗證資料、加密方法、TLS 名稱與傳輸路徑。憑證錯誤先檢查時間與名稱；驗證錯誤先確認 UUID 或密碼；HTTP 升級錯誤則先查看網路類型、Host 與路徑。記錄不一定會直接指出根本原因，但通常能縮小範圍。若啟用了詳細記錄，排查完成後請調回適當等級；分享記錄前，先移除訂閱網址與敏感連線資訊。

連線建立後仍無法存取，還要檢查 DNS 與規則。網域解析可能由本機系統、核心或遠端處理，結果與路徑不一定相同。若規則將目標設為直連，原本可用的代理項目就不會派上用場；較寬泛的規則也可能搶先比對。應在用戶端連線清單中確認目標、命中的規則與出口策略，而非只看目前選取的策略群組名稱。

全域模式可暫時用來縮小規則變因，但無法修復協定驗證錯誤、伺服器故障，或應用程式未連入用戶端的問題。測試後應恢復原有分流方式，避免測試狀態一直保留。若只有部分網域失敗，檢查目標解析與規則會更有幫助；若所有項目突然失敗，再檢查系統網路、訂閱有效性與伺服器狀態，不要逐一修改原本正確的協定參數。

本機連接埠與 TUN 的疑難排解範圍

瀏覽器顯示無法連線至本機代理時，先確認核心仍在執行，且監聽連接埠與系統代理設定一致。連接埠衝突與遠端協定無關，處理方式請見查找占用 7890 連接埠的程序；修改後也要核對連接埠設定。任意結束占用程序可能影響其他軟體，應先確認程序用途，再決定關閉舊用戶端或更換連接埠。

啟用 TUN 後若出現異常，應將服務權限、虛擬網卡、路由與 DNS 接管視為另一個檢查層面。先關閉 TUN，以明確指定的本機代理測試同一條遠端連線；如果代理正常，再回頭檢查系統接管設定。詳細步驟請參閱TUN 模式與服務模式教學。Windows 市集應用程式也可能涉及回送限制，不能只據此判定協定不相容。

最後保留一份可重現的紀錄：用戶端與核心名稱、協定及傳輸組合、出錯階段、是否只在特定網路發生，以及已驗證的對照結果。記錄實際情況，比堆砌猜測更有助於後續處理。需要重新選擇用戶端時，請回到下載頁；需要確認基本操作流程時，請回到入門指南。先讓最簡單的連線方式正常運作，再逐項恢復複雜設定。