Clash 通訊協定與 mihomo 核心參考

核心系列與客戶端分工

Clash 是一個生態系名稱，不代表某個特定安裝套件。圖形介面客戶端負責視窗、訂閱管理、系統代理開關與權限申請；核心則負責讀取設定、解析網域、比對規則並建立對外連線。兩者可能由不同專案維護。判斷功能時，應查看客戶端實際使用的核心與發布說明，不能只看應用程式名稱是否含有 Clash。介面上有某個選項，也不代表目前使用的核心已支援對應欄位。

原版 Clash、Meta 與 mihomo 的關係

原版 Clash 奠定了 YAML 設定、策略群組與規則分流的基礎架構。歷史上也有功能各異的開源版本與 Premium 核心，因此談到「原版支援哪些功能」時，必須先確認具體分支。Clash.Meta 在此生態系基礎上擴充通訊協定與網路功能，後來以 mihomo 之名持續發展。舊教學提到的 Meta 核心，以及部分客戶端中的 Meta 標籤，通常指這條延續路線；名稱相近並不能取代實際的功能確認。

mihomo 保留了許多熟悉的設定結構，例如 proxies、proxy-groups、rules 和 dns，同時也支援 VLESS、Hysteria2、TUIC 等協定及相關參數。相容性主要來自基礎結構的延續，不代表所有分支都能雙向相容。mihomo 能讀取的設定，交給較舊的核心時，可能因不支援的協定、規則類型或 DNS 欄位而無法啟動；也可能要等到使用相關功能時才出現問題。

分開判斷協定、傳輸方式與流量入口

節點的 type 代表代理協定；TCP、WebSocket、gRPC 或 QUIC 則是使用的傳輸方式或傳輸基礎；TLS 提供連線身分驗證與加密保護。系統代理和 TUN 則決定應用程式流量如何進入核心。啟用 TUN 不會讓 SS 節點變成 QUIC 節點，改用 Hysteria2 也不會自動讓所有應用程式遵循系統代理。這些功能分屬不同層次，排錯時應分別檢查。

選擇客戶端可從下載中心開始，優先查看 Clash Plus 對應平台的下載選項，再依桌面整合或管理習慣考慮 Clash Verge Rev、FlClash 等選擇。不要因為都屬於 Clash 生態系，就認定每個客戶端都能直接匯入相同檔案；有些會轉換訂閱，有些會將設定交給不同核心處理，各平台也可能限制背景網路行為。

遷移舊設定時，請保留一份原始檔，並先以最基本的功能確認連線。確認基礎節點可用後，再啟用規則提供者、TUN 與進階 DNS。如此一來，就能分辨問題來自協定相容性還是系統整合。完整啟動方式請見mihomo 使用說明；本頁後續章節則會說明這些設定為何會造成差異。

SS、VMess 與 Trojan 的設計差異

這三種協定常同時出現在訂閱中，但不能互相替換。伺服器端採用哪種協定，客戶端就必須使用相符的實作與驗證參數。修改節點名稱不會改變協定；把 type 從一個名稱改成另一個名稱，也無法完成轉換。它們的差異主要在加密與驗證方式、傳輸組合、部署要求及歷史相容性，而不是固定的速度排名。

Shadowsocks：較精簡的加密代理架構

SS 是 Shadowsocks 的常用縮寫。它採用相對精簡的協定架構來承載代理連線，常見設定包含伺服器、連接埠、加密方式與密碼。使用時應區分傳統 AEAD 加密方式與 Shadowsocks 2022 系列：兩者的金鑰要求、握手設計與實作支援並不完全相同。伺服器端指定哪種方式，客戶端就應完全一致；不能只因清單上都標示 SS，就認為可以通用。

SS 的基礎架構相對精簡，但「架構簡單」不代表在所有裝置上的運算負擔都較低。具備硬體加速的平台使用 AES 系列可能表現良好；缺少相關加速的裝置則可能更適合 ChaCha20 系列，實際效果仍取決於實作、處理器與流量型態。使用外掛程式的 SS 節點還需要額外的傳輸設定；只複製密碼，卻漏掉外掛模式、主機名稱或路徑，常會出現驗證資訊看似正確、實際上卻無法連線的情況。

VMess：歷史生態系與傳輸組合

VMess 源自 V2Ray 生態系，提供較完整的使用者識別、驗證與資料傳輸設計。它可搭配不同的傳輸方式，因此訂閱中兩個同為 VMess 的節點，實際握手流程與連線負擔可能不同。排錯時須一併核對 UUID、加密選項、傳輸類型、TLS 與路徑參數。系統時間明顯不準也可能影響驗證；應先確認系統時間同步正常，不要反覆更換策略群組。

舊教學可能包含為了維持歷史相容性而保留的參數，不能直接視為目前通用的建議。尤其不要把舊設定中的驗證參數照搬到新伺服器。VMess 的優勢之一是已有許多部署環境與工具鏈；若現有服務穩定、客戶端支援完整，通常保留原設定會比單純為了更換協定而遷移更合理。是否升級，應依核心支援、安全維護與連線表現評估，而非看節點清單上的名稱新舊。

Trojan：以 TLS 連線為基礎

Trojan 通常透過 TLS 連線傳送驗證資料與代理流量。客戶端必須正確設定密碼、伺服器位址與憑證驗證資訊。連線位址、SNI 與憑證涵蓋的網域可以合理不同，但必須符合伺服器端的部署方式。憑證過期、信任鏈不完整或主機名稱不符，都會導致握手失敗。直接關閉憑證驗證只會掩蓋問題，不應作為一般連線方式。

Trojan 的連線成本會受到 TLS 握手、工作階段恢復與網路往返時間影響，不能簡單認定「加上 TLS 就一定比較慢」。長時間下載與頻繁建立短連線的網頁，感受到的成本並不相同。如果再搭配 WebSocket 等傳輸方式，路徑、Host 與伺服器轉送規則也必須一致。基礎 Trojan 與搭配額外傳輸方式的 Trojan，應視為不同組合分別測試，不要混在同一輪比較後就下結論。

這三種協定都能用於日常瀏覽，但是否支援並實際啟用 UDP，還須一併檢查協定實作、伺服器設定與客戶端流量路徑。應用程式能開啟網頁，只能證明部分 TCP 請求成功，不能代表語音、遊戲或其他 UDP 服務也已正常運作。這也是比較 QUIC 類協定時，必須保留的測試界線。

VLESS、Hysteria2 與 TUIC 的適用範圍

新協定通常會針對既有連線模式的特定問題調整設計，但無法消除網路路徑本身的限制。VLESS 著重精簡驗證與承載層設計；Hysteria2 和 TUIC 則以 QUIC 為基礎。它們常被放在一起討論，是因為較新的核心多半已支援這些協定，不代表它們的傳輸行為相同。匯入前務必確認協定版本與具體參數。

VLESS：分離驗證層與安全傳輸

VLESS 源自 V2Ray 相關生態系，採用比 VMess 更精簡的協定設計。特別要注意的是：VLESS 本身不提供一套獨立的資料加密層，通常須依賴 TLS、REALITY 等外部安全機制保護連線。節點能以 UUID 完成驗證，不代表連線已具備充分的機密性保護。設定時應依伺服器提供的完整傳輸方案填寫，不要只輸入伺服器位址和 UUID。

VLESS 的實際表現很受傳輸組合影響。直接以 TCP 承載、使用 WebSocket 或 gRPC，在連線建立、代理路徑與中介服務支援方面各有要求。部分部署也會使用特定的 flow；這不是通用的加速開關，必須與伺服器及底層傳輸方式相符。REALITY 相關的公鑰、短識別碼與伺服器名稱也各有用途，漏掉任何一項都可能導致握手失敗。

Hysteria2：QUIC 與頻寬運用

Hysteria2 以 QUIC 為基礎，適用於高延遲、丟包等網路環境。它需要可用的 UDP 路徑，並結合可靠傳輸、加密握手與壅塞控制等機制。它與第一代 Hysteria 的參數和協定並不通用，訂閱必須標明正確類型。節點清單寫著 Hysteria，不能取代對 hysteria2 類型與伺服器支援情況的確認。

頻寬設定應依實際連線與伺服器策略判斷。在某些模式下，頻寬估值會影響傳送行為；填入遠高於實際連線能力的數值，可能造成排隊、丟包或影響其他服務，不會憑空增加傳輸量。若伺服器有限速，客戶端一味調高參數也無法突破限制。建議先依服務提供者的說明使用預設值或合理估值，再透過長時間傳輸與同時瀏覽觀察穩定性。

TUIC：QUIC 連線與多工

TUIC 同樣採用 QUIC，透過連線多工等設計承載代理流量。身分驗證欄位、協定版本、壅塞控制與 UDP 轉送模式都必須符合伺服器設定。不同版本不能只看 TUIC 名稱就認定相容。若匯入工具轉換了舊分享連結，應檢查實際產生的節點類型與驗證欄位，不要等到連線失敗後才反覆切換 DNS。

QUIC 可在同一條連線中提供多個資料流；單一資料流發生資料遺失時，不必像同一條 TCP 位元組串流那樣阻塞所有後續資料，但這些資料流仍共用連線的壅塞控制與網路路徑。因此，多工不代表完全隔離，也不代表每個並行連線都能獲得獨立頻寬。行動裝置切換網路時，也不能只因 QUIC 支援連線遷移，就認定服務一定不會中斷；代理實作、伺服器策略與作業系統都會影響結果。

如果目前網路的 UDP 支援不佳，QUIC 類節點可能會握手逾時或間歇性斷線。此時應先用已知可用的 TCP 類方案進行對照，不要直接判定是裝置效能不足。反過來說，若網路確實有丟包且 UDP 路徑穩定，可以將 Hysteria2 或 TUIC 納入測試；但仍須依實際服務表現下結論，不能只看一次測試結果。

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

「哪種協定比較快」可以拆成幾個問題：首次連線需要多久、網頁何時開始顯示、持續下載能達到多少速度，以及背景連線會耗用多少資源。這些指標未必一致。某個節點的持續下載速度較快，但握手流程較長，短時間請求可能反而較慢；另一個節點測速普通，日常瀏覽卻更穩定。協定只是影響因素之一，伺服器負載與網路路徑通常也同樣重要。

分開評估握手、吞吐量與使用體驗

首次請求可能包含網域解析、連線至伺服器、TLS 或 QUIC 握手、代理驗證與連線至目標網站。重複使用連線與工作階段恢復可降低後續成本，因此冷啟動和已建立連線的測試不能混為一談。若一個客戶端已在背景預先建立連線，另一個卻剛啟動，直接比較首次開啟網頁並不公平。測試前應確認是否清除連線、是否使用快取，以及是否有其他流量同時執行。

延遲測試通常只反映目前策略存取特定 URL 的表現，無法完整代表影片、程式碼儲存庫、大型檔案與互動式應用程式。持續傳輸速度則會受到伺服器出口、目標網站限制、壅塞控制與本地頻寬影響。若比較的節點來自不同地區、不同電信網路，即使協定不同，測得的差異往往來自網路路徑，而非協定本身。

處理器與記憶體負載從何而來

加密演算法、使用者空間網路堆疊、資料複製與連線數量都會消耗處理器資源。QUIC 的加密與傳輸處理通常在使用者空間實作，資源使用方式與 TCP 類方案不同，但不能因此斷定一定更耗電。實作最佳化、硬體能力、資料量與丟包重傳都可能改變結果。若系統已接近頻寬上限，處理器使用率升高也可能只是因為傳輸了更多資料。

記憶體使用量不只由協定決定。規則集大小、DNS 快取、連線追蹤、日誌緩衝與圖形介面都可能占用記憶體。比較兩個客戶端時，應盡量使用相同設定、規則集與近似的連線數量。閒置時使用量較低，不代表大量並行連線時也更省資源。排查用量增加時，先區分介面程序、核心程序與系統網路服務，不要把全部用量都歸因於協定。

手機耗電與背景喚醒

行動網路無線電的運作狀態會明顯影響耗電量。頻繁心跳、斷線重連、背景探測與短時間間隔的訂閱更新，都可能讓無線模組持續處於啟用狀態。即使每次只傳送少量資料，也不一定比較省電。穩定維持連線有時比反覆重建更合適，但過於頻繁的保活也會增加喚醒次數。建議先使用客戶端與伺服器推薦的預設設定，再參考系統電池用量記錄調整，不要照抄過於激進的參數表。

休眠、低耗電模式與背景權限也會影響測量結果。螢幕關閉後，系統可能限制背景排程；恢復前景操作時短暫重連，不一定代表協定有問題。iOS 的網路延伸功能與 Android 的 VPN 服務也有不同的生命週期。判斷耗電時，應記錄使用 Wi-Fi 或行動網路、螢幕狀態、使用時間與資料量，並盡量維持條件一致後再更換協定。

桌面版可同時查看核心日誌與系統資源監視器；手機則可搭配系統電池用量統計判斷。若切換協定後傳輸速度增加，應比較完成相同任務的總耗電量，而不只看執行時的瞬間用量。首次連線的確認方式請見選擇節點、測試延遲與確認代理是否生效，其中的檢查順序也適用於協定比較。

DNS、Fake-IP 與規則比對的關係

DNS 負責將網域解析為位址，規則則決定請求交由哪個策略處理，兩者會互相影響。節點握手正常但網頁仍無法使用，原因可能是目標網域解析、規則命中或應用程式快取，而非節點協定。請先區分「解析代理伺服器位址」和「解析服務目標網域」：前者影響能否連上節點，後者影響服務連線與分流判斷，兩者使用的解析路徑不一定相同。

Fake-IP 保留網域與連線的對應關係

Fake-IP 模式會向應用程式回傳一個用於對應的虛擬位址，核心則保存該位址與網域之間的關係，收到後續連線時再依據對應資訊處理。這有助於保留網域資訊，避免只能依目標 IP 猜測服務身分。它不會修改遠端網站的真實位址，也不會把目標網站搬到本機；虛擬位址只是核心識別連線時使用的中介標記。

Fake-IP 常用的位址池來自專用測試位址範圍，而不是一般的公網服務位址。如果應用程式將解析結果長期快取，或切換網路後仍使用舊的對應資訊，就可能發生連線異常。排查時可先重新啟動相關應用程式、清除其 DNS 快取並重新連線。只清除瀏覽器頁面快取並不足夠，因為系統和應用程式可能各自保存位址記錄。

相容性例外與解析路徑

少數區域網路探索功能、必須取得真實位址的應用程式或特定網路設備，可能不適合直接收到虛擬位址。此時可使用 fake-ip-filter 為特定網域設定例外，但篩選清單並非越長越好。排除大量網域會改變原本依賴映射的分流路徑，也可能讓問題更難重現。只新增已確認有效的例外，並記錄它解決了哪種具體異常。

以下內容是結構示意，不能取代完整設定。DNS 服務只監聽本機迴路位址，解析器則使用明確指定的加密 DNS 位址；若要讓應用程式實際使用此設定，還需要由客戶端接管系統 DNS，或透過 TUN 的 DNS 劫持等機制導引查詢。只設定 enable: true，不會自動改變所有應用程式的解析路徑。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://cloudflare-dns.com/dns-query

規則順序與 TUN 的適用範圍

規則通常由上往下比對，首次符合時就採用相應策略。網域規則、規則集、GEOIP 與最終 MATCH 的順序都會影響請求結果。若前面先命中範圍較廣的規則，後面的細項規則就不會執行。有些規則需要解析出真實 IP，有些則能直接依網域判斷；因此調整規則順序，有時也會改變解析次數與對外連線路徑，不只是更換策略名稱。

TUN 透過虛擬網卡處理符合條件的流量，讓更多應用程式流量進入核心，但不會自動確保所有 DNS 請求都依預期處理。瀏覽器內建的加密 DNS、應用程式自有解析器及網路中的其他介面都需要分別確認。協定加密只保護對應連線，不能據此推斷整個系統的解析路徑已一致。檢查時應查看實際查詢與連線記錄，而不只是確認開關狀態。

從 Fake-IP 切換至回傳真實位址的模式後，應重新測試受影響的應用程式，並留意舊快取。若要排查解析路徑，請閱讀DNS 測試與 Fake-IP 設定；若要調整比對順序，請參閱自訂規則說明。分開確認 DNS 與規則，可避免把分流異常誤判成特定協定不穩定。

訂閱格式與設定相容性的範圍

訂閱連結只是取得設定的入口，不代表回傳內容採用統一格式。有些會回傳完整的 Clash YAML，有些只提供節點清單，有些由多行分享連結編碼組成，也有些會輸出其他核心使用的 JSON。客戶端能儲存 URL，不代表能正確解讀回傳內容。匯入失敗時，應先確認內容類型與目標核心，再判斷節點是否過期或網路是否異常。

完整設定、節點訂閱與分享連結

完整設定通常包含連接埠、DNS、節點、策略群組與規則，匯入後即可組成可獨立運作的方案。節點訂閱主要提供連線資訊，還需要既有設定來配置策略群組與規則。單一分享連結通常只描述一個節點，不負責定義完整的分流邏輯。將節點清單當成完整設定啟動，可能會缺少策略群組；將整份設定當成代理提供者讀取，則可能出現格式錯誤。

在 mihomo 中，proxy-providers 用於管理代理來源，rule-providers 則用於管理規則來源，兩者不可混用。策略群組必須明確引用代理來源，規則也必須引用對應的規則集。下載成功只代表遠端檔案已取得，不表示內容已正確引用。更新後若介面沒有顯示節點，請檢查提供者是否成功解析、策略群組是否引用，以及名稱是否完全相同。

格式轉換不等於完整保留原有設定

不同格式能表達的欄位並不相同。轉換工具可能保留基本伺服器與驗證參數，卻遺失傳輸選項、REALITY 參數、UDP 模式或特定協定欄位。即使轉換結果通過語法檢查，實際行為也不一定與原節點相同。較新的協定尤其應逐項比對原始資訊，確認類型、憑證參數、路徑與驗證方式沒有被預設值取代。

訂閱服務也可能依請求特徵回傳不同格式，因此瀏覽器看到的內容與客戶端取得的內容不一定相同。遇到這種情況，應使用服務提供者明確提供的 Clash 或 mihomo 格式入口，不要任意拼接 URL 參數。若遠端回傳登入頁、錯誤頁或其他 HTML，客戶端可能會回報 YAML 解析失敗；此時問題出在取得的內容，不應靠修改本機縮排處理。

覆寫設定與自動更新

客戶端可能會在訂閱原始內容之外套用本機覆寫、合併指令碼或全域設定。原始檔中的 DNS 設定值，實際執行時可能已被介面改寫。排查問題時，應分辨訂閱原文、客戶端產生的執行設定與核心日誌。直接編輯自動下載的檔案，也可能在下次更新時被覆蓋。需要長期保留的規則，應放在客戶端明確支援的覆寫或自訂設定入口。

自動更新間隔應依內容變動頻率與手機背景運作情況調整。頻繁更新不一定更可靠，遠端服務異常時反而會增加請求與日誌。更新失敗時，應先保留最近一次可用設定並確認錯誤原因，不要立刻刪除所有檔案。訂閱網址常含有可識別帳戶的資訊，分享截圖或求助日誌時，請遮蔽完整 URL、驗證欄位及個人節點資訊，避免將存取權限交給他人。

首次匯入與更新方式請見匯入訂閱連結。若要將舊設定遷移至 mihomo，建議先建立新的設定項目，保留原項目作為對照，再逐步恢復覆寫規則。這樣既可避免手動修改被自動更新覆蓋，也能更快找出是哪個層級引入不相容欄位。

依裝置與使用情境選擇協定

選擇時應先回答「需要接管哪些流量」，再決定「用哪種協定連線至伺服器」。客戶端平台、權限、伺服器部署與網路路徑都是前提條件。若伺服器只提供一種協定，客戶端應先確認是否完整支援該方案，而不是在介面上嘗試其他類型。只有在確實有選擇空間時，才比較連線建立時間、丟包表現、耗電與管理複雜度。

桌面瀏覽與開發工具

一般網頁與文件瀏覽可先使用設定完整、憑證正確的 TCP 類方案，SS、VMess、Trojan 或 VLESS 都可能適用。重點在於連線路徑穩定、規則明確。開發工具、套件管理器與終端程式不一定會遵循桌面系統代理，有些需要另外設定 HTTP／SOCKS 代理或環境變數。瀏覽器能用、命令列卻失敗時，應先確認流量入口，不要馬上更換節點協定。

Windows 與 macOS 可優先從 Clash Plus 開始，再依使用習慣比較 Clash Verge Rev 或 FlClash；Windows 也可考慮 Clash Nyanpasu。已停止維護的 Clash for Windows、ClashX Meta 應視為歷史相容資料，不宜只因熟悉舊教學截圖，就當成新安裝的預設選擇。實際平台下載選項與安裝說明，請以客戶端下載清單為準。

手機日常使用

手機使用時要同時考量背景連線、網路切換與耗電。Android 可查看 Clash Plus、Clash Meta for Android、FlClash 與 Surfboard 的設定支援；iOS 優先查看 Clash Plus，並透過其官方網站 clashplus.io瞭解產品資訊。不同應用程式解析訂閱的方式可能不同，遷移時應重新核對策略群組與規則，不要只確認節點數量相同。

如果每天經常在行動網路與 Wi-Fi 之間切換，測試時應包含螢幕關閉後恢復、網路切換與背景待機，不要只測前景速度。UDP 路徑穩定時，可以測試 QUIC 類方案，但不應預設它比較省電。穩定的 TCP 類連線也可能更適合某些裝置。請關閉不必要的高頻探測，並參考系統電池用量記錄判斷，不要只憑協定名稱下結論。

高丟包、即時服務與資源有限的裝置

若網路明顯丟包，可比較 Hysteria2 或 TUIC 與現有 TCP 類方案。盡量維持相同的伺服器位置與服務目標，觀察網頁回應、持續傳輸及其他並行工作。如果傳輸吞吐量提高後語音品質變差，原因可能是本機排隊與頻寬競爭；應先檢查壅塞與速率設定。遊戲、語音等 UDP 服務也須確認伺服器支援轉送、規則命中正確且目標路徑可達。

伺服器、路由器與低功耗裝置通常更重視處理器效能、記憶體與長期維護。可直接使用 mihomo 核心，但必須自行管理服務、權限、日誌與設定更新。架構必須相符，不能將桌面安裝套件當成路由器核心使用。Linux 桌面使用者則可考慮 Clash Verge Rev 或 FlClash，減少手動整合系統的工作。各種架構的下載選項請至下載中心的核心區查看。

系統代理與 TUN 的選擇屬於流量接管方式，不能用協定優劣取代。若應用程式沒有將請求交給核心，再好的節點也不會參與連線。若要比較兩種入口方式，請閱讀TUN 模式與系統代理的差異。先確認流量進入正確路徑，再依實際工作完成情況選擇協定，通常比追求單一測速結果更可靠。

連線確認與分層排錯流程

排錯時應沿著連線路徑逐層檢查：設定能否讀取、應用程式是否進入核心、規則選用了哪個策略、節點是否握手成功，以及目標請求是否完成。每次只調整一個變數，並保留原始錯誤資訊與可用設定。若同時反覆更換 DNS、協定、規則與 TUN，即使問題偶然恢復，也無法判斷真正原因，下次發生時更難重現並處理。

先檢查設定與本機流量入口

若核心無法啟動，先查看第一個解析錯誤與欄位位置。YAML 縮排錯誤、不支援的類型或引用不存在的策略群組，都可能導致啟動失敗。不要只看最後一則「啟動失敗」訊息。單獨使用 mihomo 核心時，可透過下方指令檢查檔案；圖形介面客戶端通常也有設定檢查或日誌入口。實際執行的設定可能位於客戶端管理目錄，不一定就是最初匯入的檔案。

mihomo -t -f config.yaml

語法檢查通過後，請確認應用程式使用的代理連接埠與核心實際監聽的連接埠一致。若設定中的 mixed-port 是本機的 7890，可用下方指令發出明確經由 HTTP 代理的請求。這只能確認指定路徑，不代表所有應用程式與服務都已由核心接管。若本機連接埠不同，請依實際設定調整；命令列不可填入控制介面或 DNS 連接埠。

curl --proxy http://127.0.0.1:7890 -I https://example.com

接著檢查規則與節點握手

若日誌中沒有對應請求，優先檢查應用程式代理設定、TUN 權限與路由；若請求存在卻命中 DIRECT，應先檢查規則順序與策略群組，而非更改驗證資訊。若策略群組使用自動選擇，請記錄當時實際選中的節點，避免測試期間背景切換造成混淆。為了重現問題，可暫時選擇已知可用的節點；測試結束後，記得恢復原有策略。

應依錯誤類別排查握手失敗。驗證錯誤請檢查密碼、UUID 與協定類型；憑證錯誤請檢查系統時間、伺服器名稱與信任鏈；連線逾時請檢查伺服器位址、連接埠與網路可達性；QUIC 類節點還要檢查 UDP 路徑。若出現「連線已關閉」等含糊訊息，還須一併檢查伺服器部署與傳輸參數，不要只憑一行日誌就認定某種協定失效。

區分目標服務異常與網路堆疊異常

若節點測試成功，但只有特定網站無法使用，請比較該網域的 DNS 結果、規則命中情況與目標服務狀態。若所有網頁正常、只有即時應用程式失敗，則檢查 UDP 支援、應用程式的連線方式與規則。若只有大型請求或持續傳輸異常，可進一步檢查路徑 MTU、丟包與並行連線限制；這些現象都需要對照測試，不能一看到逾時就直接修改 MTU 或關閉憑證驗證。

啟用 TUN 後出現異常，但明確指定的 HTTP 代理請求正常，通常表示協定路徑至少部分可用；接下來應檢查權限、路由、DNS 劫持與其他網路軟體的衝突。Windows UWP 應用程式也可能受到迴送存取限制影響，可參閱UWP 迴送問題。避免同時執行多個會接管相同流量的工具，否則入口衝突可能導致間歇性故障。

修復後應回到實際服務確認，不要只確認錯誤日誌已消失。依序測試網頁、原本失敗的應用程式、背景恢復與網路切換，並確認規則仍依預期運作。若排查時暫時放寬篩選、切換模式或關閉自動更新，請逐項恢復。長期保留臨時設定會讓後續更新與排錯更複雜，也可能改變原本需要的分流行為。

本頁的最終判斷標準是連線路徑可說明、設定來源可追溯、功能範圍清楚。首次連線的主要流程仍請參閱使用說明，常見問題可接著查看FAQ。協定選擇不是一次性的名稱決定，而是在核心支援、伺服器設定與實際網路條件之間，找出可驗證的組合。