Clash 協定與核心技術參考

一、建立協定選擇框架

先區分協定、傳輸層與客戶端

Clash 客戶端是設定與流量調度入口，協定則規定客戶端如何與遠端服務通訊。兩者處於不同層次。設定檔中的 type 決定代理節點類型，例如 ss、vmess、trojan、vless、hysteria2 或 tuic；核心讀取這個欄位，再呼叫對應實作建立連線。圖形客戶端負責匯入訂閱、選擇代理群組、管理規則、設定系統代理與 TUN 開關，但真正執行協定握手、加密、複用與資料轉送的是核心。

同一種協定也可能搭配不同傳輸方式。VMess 與 VLESS 常見 TCP、WebSocket、gRPC 等承載方式，TLS 則是其中獨立的一層。Trojan 通常直接建立在 TLS 之上。Hysteria2 與 TUIC 則以 QUIC 和 UDP 為基礎。看到「VLESS + WebSocket + TLS」時，應拆成三部分理解：VLESS 負責驗證與協定語意，WebSocket 負責資料封裝，TLS 負責加密與伺服器身分驗證。任何一層參數不一致，都可能表現為連線失敗。

客戶端名稱同樣不能取代核心名稱。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等屬於使用者直接操作的圖形客戶端，可能整合 mihomo，也可能因平台與發行方式而使用不同建置版本。選擇客戶端時需要確認其核心類型、更新機制與目標平台；選擇協定時則應確認目前核心是否實作該協定及其擴充欄位。只看介面相似度，無法判斷底層相容範圍。

四個優先判斷條件

第一項是設定來源。若服務提供方已提供可用訂閱，應優先使用訂閱宣告的協定與參數，不要在客戶端中把 SS 節點手動改成 Trojan，也不要只替換 type 欄位。不同協定的驗證資料、傳輸參數與握手流程並不相通，修改名稱不會完成協定轉換。第二項是核心支援。較新的 Hysteria2、TUIC 與部分 VLESS 擴充通常需要 mihomo 或相容實作，舊版原版 Clash 無法完整讀取這些欄位。

第三項是網路條件。穩定、低封包遺失的固定網路通常能讓 TCP 類協定保持平穩表現；波動較大、存在一定封包遺失的行動網路，可能更適合具備現代壅塞控制與快速復原能力的 QUIC 類方案。但 UDP 可達性、電信網路策略與路由設備實作都會影響 QUIC 表現，不能只憑協定標籤預設結果。第四項是裝置限制。行動裝置更關注持續喚醒、背景保活、握手頻率與無線模組活動時間；伺服器或路由器則更關注並發連線、記憶體上限與轉送效率。

為什麼測速不能直接得出結論

一次下載測試通常只涵蓋單一時段、單一路徑與有限連線數。TCP 慢啟動、QUIC 壅塞視窗、DNS 解析、目標網站連線複用及伺服器當前負載都會改變測試結果。短時間測試更偏向握手與首個封包表現，長時間測試則較能反映持續吞吐與壅塞復原。網頁瀏覽關注 DNS、握手、首位元組與小型物件並發；大檔案傳輸更關注穩定吞吐；即時影音則更關注抖動、封包遺失復原與 UDP 轉送。不同任務不能只用同一個峰值數字概括。

更可靠的方法是在相同裝置、相同規則、相同目標與接近的時段進行多輪比較，同時觀察連線成功率、首次開啟時間、長連線穩定性與裝置溫升。若某個協定只在個別時段明顯異常，應繼續檢查路徑與伺服器端狀態，而不是立即判定協定本身有缺陷。協定選擇最終應以持續可用、設定易維護且裝置負擔可接受為準。

二、SS、VMess、Trojan 與 VLESS 的設計取捨

Shadowsocks：結構簡潔的加密代理協定

Shadowsocks 通常簡稱 SS，其核心目標是以相對簡潔的方式完成加密轉送。客戶端根據密碼與加密方法派生工作階段所需資料，再透過 TCP 或 UDP 與伺服器通訊。由於協定結構輕量，成熟實作通常具有較低的處理開銷，設定項目也容易理解。常見節點至少包含伺服器位址、連接埠、密碼與加密方法；現代設定應選擇由伺服器明確提供、且目前核心支援的 AEAD 或 2022 系列方法，客戶端與伺服器的加密方法必須完全一致。

SS 的優點是實作廣泛、資源需求相對可控，跨平台相容基礎也較好。它適合希望減少設定層次、重視穩定轉送與裝置資源的情境。限制在於，SS 本身不等於 TLS，也不包含 VLESS、VMess 那套傳輸擴充語意。部分訂閱會額外宣告外掛參數，外掛必須由客戶端與伺服器共同支援；如果訂閱包含外掛而核心無法識別，節點即使顯示在清單中也可能無法建立連線。

排查 SS 時，應先核對加密方法拼寫、密碼、伺服器連接埠與 UDP 開關。若 TCP 頁面可以存取而 UDP 應用異常，應確認節點、代理群組與客戶端核心是否同時允許 UDP。若設定由訂閱產生，不建議手動替換加密方法，因為伺服器不會隨客戶端設定自動變更。SS 的簡潔性來自較少的協定層，而不是可以省略參數一致性檢查。

VMess：具備時間校驗與使用者識別的完整協定

VMess 源自 V2Ray 生態，使用使用者識別與協定握手組織連線，通常還會搭配 TCP、WebSocket、HTTP/2 或 gRPC 等傳輸方式。它的設定比 SS 更具層次：除了伺服器、連接埠與使用者識別外，還可能包含安全選項、網路類型、路徑、主機名稱、TLS 開關與伺服器名稱。VMess 過去廣泛用於需要多種傳輸組合的部署，因此許多通用訂閱與舊設定仍包含大量 VMess 節點。

VMess 對系統時間偏差較敏感。裝置時間明顯不準時，驗證階段可能失敗，而介面只顯示逾時或握手錯誤。排查時應確保作業系統啟用自動時間同步，並檢查時區與時間是否正常。另一個常見問題是把 WebSocket 路徑、Host 請求標頭與 TLS 伺服器名稱混為一談：路徑是 WebSocket 請求位置，Host 是 HTTP 層欄位，伺服器名稱用於 TLS 憑證驗證；三者可能相同，也可能由伺服器分別指定。

VMess 功能較完整，但協定處理與設定複雜度通常高於純 SS。對於已有且運作穩定的 VMess 訂閱，沒有僅因協定較早就必須遷移的理由；新設定則應根據伺服器支援、核心相容性與維護方案決定。實際表現主要取決於承載方式與網路路徑。例如 VMess over WebSocket 會增加封裝與握手層次，而直接 TCP 的路徑更短，但兩者適用的伺服器架構不同，不能只用協定名稱比較。

Trojan：以標準 TLS 連線為基礎

Trojan 將驗證與資料轉送放在 TLS 連線中，客戶端需要伺服器位址、連接埠、密碼，通常也需要正確的伺服器名稱。TLS 握手會驗證憑證與目標名稱是否相符，因此系統時間、憑證鏈、SNI 與伺服器設定都會影響連線結果。Trojan 的設定概念相對直觀，但「使用 TLS」不代表可以忽略憑證檢查。關閉憑證驗證會削弱伺服器身分確認，只適合受控測試，不應作為長期解決逾時或名稱錯誤的預設方法。

Trojan 常見問題集中在伺服器名稱與位址的關係。節點位址可以是網域或 IP，而 sni 通常應填寫憑證涵蓋的網域。若訂閱已提供 sni，應保留該值。ALPN 等進階參數也必須與伺服器協商範圍一致。對一般使用者而言，優先使用訂閱下發的完整參數，比在圖形介面中逐項猜測更可靠。

從效能角度來看，Trojan 需要完成 TLS 握手，但現代實作可透過連線複用、工作階段恢復與長連線降低重複成本。在穩定網路中，握手開銷通常集中於建立連線階段；頻繁建立短連線、行動網路反覆切換或背景連線被系統回收時，重新連線成本會更明顯。因此評估 Trojan 時應同時觀察首次連線與持續使用，而不是只看長連線建立後的吞吐。

VLESS：精簡驗證層與可組合傳輸

VLESS 同樣來自 V2Ray 生態，設計上減少協定本身承擔的加密職責，通常依賴 TLS 或其他受支援的安全層提供機密性與伺服器驗證。設定通常包含使用者識別、傳輸方式、TLS 設定、伺服器名稱，以及由特定核心支援的擴充欄位。VLESS 本身不是某一種固定傳輸，它可以搭配 TCP、WebSocket、gRPC 等方式，因此討論「VLESS 是否更快」時，必須說明承載形式與安全層。

VLESS 設定的相容難點在於擴充能力。不同核心對 Reality、流控標記、客戶端指紋、傳輸細節等欄位的支援範圍可能不同。原版 Clash 無法涵蓋許多現代 VLESS 設定，而 mihomo 對相關協定與擴充提供了更完整的適配。訂閱可以成功匯入不代表所有欄位都會執行；某些轉換服務可能保留基礎欄位卻遺失擴充參數，最終表現為節點存在但無法連線。

SS、VMess、Trojan 與 VLESS 都可能使用 TCP 作為底層承載，但它們的驗證、加密責任與擴充方式並不相同。SS 著重輕量加密轉送，VMess 提供完整協定握手與多種承載組合，Trojan 以 TLS 為基礎組織驗證，VLESS 則將更多安全責任交給外層並保留組合能力。選擇時應遵循伺服器設定與核心支援，而不是將某個協定視為其他協定的直接替代品。

三、Hysteria2 與 TUIC：基於 QUIC 的連線模型

QUIC 改變了哪些傳輸行為

Hysteria2 與 TUIC 都建立在 UDP 和 QUIC 能力之上。QUIC 在使用者空間組織可靠傳輸、加密握手與多路串流，能避免傳統 TCP 連線中不同邏輯串流完全共用同一個隊頭阻塞狀態。某一條串流發生封包遺失時，其他串流不必總是等待同一序列中缺失的資料，這對並發請求與存在抖動的網路具有實際價值。QUIC 還將 TLS 語意納入連線建立流程，減少協定層之間重複協商的空間。

這種模型不代表 UDP 天然比 TCP 快。UDP 只提供資料報傳送，可靠性、壅塞控制、重傳與串流管理由 QUIC 負責實作。效能取決於具體實作、壅塞控制參數、路徑 MTU、伺服器頻寬與網路對 UDP 的支援。若本地網路封鎖或嚴格限制 UDP，Hysteria2 與 TUIC 可能直接無法連線；若 UDP 路徑品質良好且存在一定封包遺失，它們則可能比反覆觸發 TCP 壅塞復原的方案更平穩。

QUIC 執行於使用者空間，帶來快速迭代與彈性控制，也意味著加密、封包排程與重傳處理會占用 CPU。桌面裝置通常較容易消化這部分成本，行動裝置與低功耗路由器則需要留意持續高吞吐時的溫升與電量。協定的網路效率與裝置能效不是同一個指標：更快完成傳輸可能讓無線模組更早休眠，但較高的持續 CPU 負載也可能抵銷這部分收益。

Hysteria2 的頻寬與壅塞控制思路

Hysteria2 面向高延遲、存在封包遺失或頻寬波動的路徑，設定通常包含伺服器位址、驗證資訊、TLS 伺服器名稱，以及可選的上傳與下載頻寬提示。頻寬值不是客戶端測速結果，也不是強制保證，而是用於協助壅塞控制建立合適的傳送行為。填寫遠高於實際線路能力的值，可能造成佇列堆積與封包遺失；填寫過低則會主動限制可用吞吐。沒有明確依據時，應優先使用伺服器或訂閱提供的設定。

Hysteria2 的驗證欄位可能以字串形式出現，TLS 相關欄位仍要求伺服器名稱與憑證設定一致。部分設定會包含混淆或跳躍連接埠等擴充，但這些能力需要伺服器、客戶端核心與設定格式三方同時支援。通用訂閱轉換器若不認識擴充欄位，可能只輸出一個基礎節點，導致匯入後無法連線。此時應檢查原始 YAML，而不是在圖形介面中不斷切換代理模式。

路徑 MTU 是 QUIC 類連線中容易忽略的因素。若鏈路中某一段無法承載較大的 UDP 資料報，而分片或路徑探索又運作異常，連線可能表現為握手成功但大量流量停滯、部分網站能開啟卻在下載時中斷。排查時可先關閉額外傳輸層、恢復訂閱原始參數，再換到另一個網路比較。若只有某個區域網路或路由器下異常，應繼續檢查路由器 UDP 工作階段、MTU 與防火牆策略。

TUIC 的多路複用與行動網路切換

TUIC 同樣基於 QUIC，強調低延遲連線、多路串流與高效轉送。常見設定包括伺服器位址、連接埠、使用者識別、密碼、TLS 伺服器名稱、壅塞控制演算法與 UDP 中繼模式。不同 TUIC 協定世代的欄位可能不同，客戶端與伺服器必須使用相容實作。若訂閱只寫「TUIC」卻未保留所需驗證欄位，核心無法靠猜測補齊。

QUIC 具備與連線遷移相關的能力，但客戶端、作業系統與具體協定實作是否運用該能力，需要結合實際版本與平台判斷。手機從無線區域網路切換到行動網路時，本地位址會變化；理想情況下連線可以更快恢復，但系統背景限制、VPN 介面重建、DNS 更新與客戶端生命週期仍可能觸發完整重連。因此不能把 QUIC 的連線遷移等同於所有行動端應用都能保持工作階段。

TUIC 的壅塞控制選項不應隨意照抄他人的設定。演算法需要與網路路徑及伺服器能力匹配，某些實作會提供預設值，訂閱也可能明確指定。對一般使用者而言，先保留訂閱值，再透過長期穩定性觀察是否需要調整，比只追求測速峰值更可靠。若高負載時延遲突然增加，應檢查上行是否已滿載、路由器是否出現 UDP 佇列堆積，以及頻寬管理是否與 QUIC 流量發生衝突。

何時不必優先選擇 QUIC 類協定

固定網路穩定、TCP 節點已持續可靠、裝置算力有限，或所在環境的 UDP 行為不可預測時，沒有必要只因協定較新就強制切換。路由器上的低功耗處理器需要同時負責 NAT、DNS、規則比對與加密轉送，QUIC 的使用者空間處理可能更早觸及 CPU 上限。行動裝置若主要進行輕量網頁瀏覽，QUIC 的吞吐優勢也未必能抵銷背景連線與加密處理成本。

反過來，當網路存在明顯抖動、長距離鏈路偶爾遺失封包、應用包含較多並發串流，且 UDP 路徑穩定時，可以將 Hysteria2 或 TUIC 納入候選。正確方法是保留一個運作穩定的 TCP 類節點作為對照，在相同規則與接近時段下觀察數日，而不是用一次短時間測速決定長期預設節點。

四、連線速度、資源占用與行動裝置電量

把速度拆成四個階段

使用者感知的「速度」至少包含名稱解析、建立連線、首位元組抵達與持續傳輸四個階段。DNS 決定如何取得目標位址；客戶端與代理伺服器完成協定與安全握手；伺服器再與目標建立連線；最後進入穩定資料傳輸。網頁開啟很慢但下載正常，問題可能出在 DNS、握手或小型物件並發。下載開始很快但之後波動，則更可能涉及壅塞控制、封包遺失、伺服器限速或本地無線品質。

SS 的協定處理相對直接，在 CPU 較弱的裝置上容易維持可預測的開銷。Trojan 需要進行 TLS 處理，但成熟 TLS 函式庫通常已充分最佳化。VMess 與組合式 VLESS 設定的開銷會顯著受到傳輸層影響，WebSocket、gRPC 與額外 TLS 會增加封裝與記憶體緩衝。Hysteria2 與 TUIC 需要在使用者空間維護 QUIC 狀態、串流與重傳，CPU 使用量可能較高，但在特定封包遺失路徑上也可能更快完成任務。

連線複用會改變短連線成本。若多個請求共用一條已建立的連線，可以減少重複握手與系統呼叫；但過度複用也可能讓大量邏輯串流集中在單一連線中，當該連線異常時影響範圍更大。不同核心對複用的實作與預設值不完全相同，不應從其他工具複製參數後直接套用到 mihomo。只有在確認伺服器支援、問題可重現且有明確測量方法時，才適合調整複用選項。

CPU、記憶體與並發連線

協定資源占用不能只看閒置時的工作管理員數字。實際負載與吞吐、連線數、規則數量、DNS 模式、日誌層級與 TUN 轉送共同相關。高吞吐會增加加密與資料複製工作；大量短連線會增加握手與連線表維護；複雜規則集會增加比對過程；詳細日誌持續寫入也會帶來額外 I/O。比較協定時必須保持其他設定一致，否則測到的是整個客戶端設定的差異。

桌面系統通常擁有較寬鬆的記憶體與排程空間，Clash Plus、Clash Verge Rev、FlClash 或 Clash Nyanpasu 的介面程序也會帶來各自的圖形執行環境開銷。評估核心時應區分介面程序與核心程序。Linux 伺服器直接執行 mihomo 核心時，資源構成更單純；路由器則需為系統服務、連線追蹤表與 DNS 快取預留記憶體。記憶體接近上限時，任何協定都可能因系統回收或程序終止而不穩定。

並發連線數量與單一連線吞吐不是同一個指標。網頁、軟體更新與同步工具可能建立許多連線，即使總流量不高，也會增加檔案描述元、連線狀態與 DNS 查詢。QUIC 多路串流可以把多個邏輯串流放入較少的底層連線，但核心仍需維護每條串流的狀態。SS、Trojan 等方案也能借助核心層級複用降低連線數量，不過伺服器與客戶端設定必須一致。

行動端耗電由哪些因素組成

行動裝置電量主要受無線模組活躍時間、CPU 喚醒、背景保活、資料傳輸量、VPN 介面處理與網路切換影響。協定加密演算法只是其中一部分。持續低速傳輸可能讓無線模組長時間維持高耗電狀態；較高吞吐若能快速完成任務，反而可能更早進入休眠。同時，複雜握手、頻繁重連與高強度使用者空間加密也會增加處理器工作，因此不能簡單地將「更快」直接換算為「更省電」。

在 Android 上使用 Clash Plus、Clash Meta for Android、FlClash 或 Surfboard 時，系統通常會透過 VPN 服務接管流量。省電策略可能限制背景程序，導致鎖定螢幕後連線被回收；恢復螢幕後客戶端需要重新建立代理連線。iOS 客戶端受 Network Extension 生命週期管理，背景行為與桌面系統不同。比較行動端協定時，應在相同系統設定、相同訊號條件與相近使用強度下觀察，而不是同時更換客戶端與協定。

TCP 類長連線在穩定網路中通常具有成熟的系統級最佳化。QUIC 類連線可能在網路抖動與切換時減少部分復原等待，但使用者空間資料處理也可能增加 CPU 活動。輕量瀏覽、訊息同步與長時間待機更應關注背景穩定性與喚醒次數；影片、大檔案與雲端同步則更關注單位任務完成時間與溫升。若裝置持續發熱，應先檢查是否有異常重試、DNS 循環、日誌高頻寫入或 TUN 路由衝突，不要只替換協定。

一套可重複的比較方法

先選擇兩個伺服器位置與線路條件接近的節點，確保只有協定或傳輸方式不同。固定客戶端、核心、規則模式、DNS 設定與網路環境，關閉會干擾結果的背景下載。第一輪測試冷連線，記錄首次開啟與連線失敗情況；第二輪測試持續傳輸，觀察吞吐穩定性；第三輪測試多應用程式並發；行動端再加入鎖定螢幕復原與無線網路切換。每輪在不同時段重複，避免單次伺服器負載造成誤判。

結果應以「是否滿足任務」記錄，而不是只排列峰值。例如網頁首次開啟穩定、影片不中斷、鎖定螢幕後能正常復原、裝置溫升可接受，通常比某次吞吐高出少量更重要。若兩個協定都能滿足使用需求，應優先選擇設定更簡單、客戶端支援更完整、伺服器維護更明確的一項。穩定性與可解釋性本身就是重要的效能指標。

五、原版 Clash、Clash.Meta 與 mihomo 的核心關係

原版 Clash 的定位與界線

原版 Clash 奠定了設定檔、代理群組、規則比對、DNS 與控制介面等核心使用方式。大量 YAML 欄位與客戶端互動模型都由這個生態普及。它能處理 SS、VMess、Trojan 等常見類型，並透過規則決定請求走代理、直連或拒絕。許多教學中的 proxies、proxy-groups、rules 結構至今仍然適用。

原版專案停止持續演進後，其協定支援與平台適配停留在既有範圍。較新的 VLESS 擴充、Hysteria2、TUIC、規則提供器增強功能、TUN 與 DNS 新能力，通常不應假設原版核心可用。舊版客戶端即使能匯入一份現代訂閱，也可能忽略未知欄位、略過節點或在啟動時回報設定錯誤。保留舊版客戶端只適合維護既有環境，不適合作為現代協定選擇的預設基準。

Clash for Windows 屬於已停止維護的圖形客戶端，歷史上與原版 Clash 生態關係密切。它仍可能出現在舊設定說明中，但面對新訂閱與新協定時相容範圍有限。需要下載目前仍維護的客戶端時，應優先從客戶端列表選擇 Clash Plus，或依平台考慮 Clash Verge Rev、FlClash、Clash Nyanpasu 等方案。

Clash.Meta 擴充了什麼

Clash.Meta 在相容 Clash 設定結構的基礎上，擴充協定、規則、DNS、TUN 與平台網路能力。它讓使用者繼續使用熟悉的代理群組與規則語法，同時支援更多節點類型與現代傳輸。許多標示「Meta 核心」的客戶端因此取得 VLESS、Hysteria、TUIC 等擴充能力。設定層面仍以 YAML 為主，但新增欄位只有 Meta 系列實作能夠識別。

「相容 Clash 設定」不等於所有方向都能完全互逆。原版 Clash 設定通常較容易由 Meta 系列讀取；包含 Meta 擴充功能的設定，則不能保證回到原版核心後仍能運作。具體風險包括未知節點類型、額外 DNS 欄位、TUN 參數、規則提供器行為與代理群組擴充。遷移時應把相容理解為「基礎結構延續」，而不是「任何欄位都能跨核心互換」。

一些訂閱轉換工具會提供 Clash 與 Clash.Meta 兩種輸出目標。若訂閱包含 VLESS、Hysteria2 或 TUIC，應選擇面向 Meta 或 mihomo 的格式；選擇舊 Clash 範本可能導致這些節點被刪除或降級。若訂閱只包含 SS、VMess 與 Trojan，兩個輸出目標在基礎節點上可能都能讀取，但 DNS 與規則部分仍需核對。

mihomo 是目前延續的核心名稱

mihomo 是 Clash.Meta 後續使用的核心名稱，延續其設定體系與擴充能力。實際客戶端介面可能仍顯示「Meta」字樣，設定文件也常將兩者並列提及。判斷時應查看客戶端的核心資訊或專案說明，不要只根據介面品牌猜測。對於新安裝與現代協定，mihomo 通常是更合適的相容基準。

mihomo 負責協定連線、DNS、規則比對、代理群組、TUN 與控制介面。圖形客戶端則在其外層提供設定管理、系統匣、訂閱更新與平台權限處理。客戶端更新與核心更新可能採用不同節奏：介面版本變化不一定代表核心功能變化，核心更新也可能由客戶端靜默整合。因此遇到新協定無法識別時，應同時確認客戶端發行狀態與實際核心資訊。

伺服器或路由器使用者也可以直接部署 mihomo 核心，不使用桌面圖形介面。這種方式便於透過設定檔與系統服務管理，但要求使用者自行處理權限、日誌、啟動順序、DNS 連接埠與防火牆。一般桌面或行動端使用者更適合使用完整客戶端，因為系統代理、TUN 權限與訂閱管理已由介面封裝。

設定遷移的安全順序

從舊客戶端遷移到 mihomo 客戶端時，先保留原設定副本，再匯入訂閱或 YAML，不要立即覆蓋舊檔案。啟動後檢查設定解析日誌，確認代理節點數量、代理群組名稱與規則提供器都已載入。接著測試一個基礎 TCP 節點，再測試 Hysteria2 或 TUIC 等擴充節點。最後開啟系統代理或 TUN，避免在設定尚未通過時同時引入系統路由變數。

若設定解析失敗，應從日誌指出的欄位或行號著手。YAML 對縮排敏感，Tab、重複鍵、引號與冒號位置都可能導致錯誤。若設定可載入但個別節點缺失，應檢查節點類型與欄位是否屬於目前核心支援範圍。若所有節點正常但規則行為改變，再核對規則順序、規則集格式與 DNS 模式。將遷移過程拆成解析、節點、代理群組、規則、系統接管五個階段，可以明顯縮小問題範圍。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: "Example-SS"
    type: ss
    server: 192.0.2.10
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "Example-SS"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,節點選擇
  - MATCH,節點選擇

以上片段用於說明基礎結構，範例位址僅供文件用途。真實節點參數應由伺服器或訂閱提供。設定可以由 mihomo 讀取，不代表範例節點能夠連線；實際部署時還需依平台補充 DNS、TUN 或控制介面設定。

六、訂閱格式、YAML 欄位與轉換相容性

訂閱連結返回的內容不只一種

使用者在客戶端中貼上的「訂閱連結」只是取得設定的入口，返回內容可能是完整 Clash YAML、Base64 編碼的通用節點清單、單一分享連結集合，或由伺服器根據客戶端識別資訊動態產生的格式。客戶端能否匯入，取決於其訂閱解析器是否認得返回內容。連結能在瀏覽器中開啟，不代表內容就是 Clash 設定；連結顯示一段難以閱讀的字元，也不代表資料損壞。

完整 Clash YAML 通常包含 proxies、proxy-groups 和 rules，有時還包含 DNS、規則提供器與連接埠設定。通用訂閱可能只有節點，沒有代理群組與規則，客戶端匯入後需要自行產生預設群組。分享連結則以協定方案開頭，例如 ss://、vmess://、trojan:// 或 vless://。Hysteria2 與 TUIC 也有各自的表達方式，但不同客戶端對單一連結與批量訂閱的支援範圍不完全一致。

更完整的說明可參考訂閱連結格式與匯入方法。本頁重點是相容性判斷：若訂閱服務能直接輸出 mihomo 或 Clash.Meta YAML，應優先選擇該格式，因為它能保留代理群組、規則與現代協定欄位；若只能取得通用節點清單，則需要客戶端或轉換器補充群組與規則。

YAML 中決定節點可用性的欄位

所有節點都需要名稱、類型、伺服器與連接埠，但不同協定還要求各自的驗證欄位。SS 使用密碼與加密方法；VMess 通常使用使用者識別，並可能宣告 alterId、安全選項與傳輸網路；Trojan 使用密碼及 TLS 伺服器名稱；VLESS 使用使用者識別、安全層與傳輸擴充；Hysteria2 使用驗證、SNI 及可選頻寬參數；TUIC 通常包含使用者識別、密碼、SNI、壅塞控制與 UDP 中繼設定。

欄位名稱必須符合目標核心語法。某個應用程式匯出的 JSON 設定不能直接複製到 Clash YAML，因為階層與命名規則不同。即使兩個工具都支援 VLESS，它們也可能分別使用不同欄位表達傳輸、安全層與指紋。可靠做法是使用目標核心認可的訂閱範本，或根據 mihomo 文件逐項轉換，並在啟動日誌中確認設定解析結果。

YAML 字串包含冒號、井號、花括號或特殊前綴時，使用引號可以降低解析歧義。縮排應使用空格並保持層級一致。節點名稱如果被代理群組引用，文字必須完全相同，包括空格與大小寫。訂閱更新後節點名稱發生變化，手寫代理群組可能引用舊名稱，表現為代理群組為空或回退到其他項目。規則目標也必須對應現有代理群組名稱。

訂閱轉換會遺失什麼

轉換過程通常需要將來源欄位對映到目標欄位。基礎 SS、VMess、Trojan 節點較容易對映，但現代 VLESS 擴充、Hysteria2 頻寬選項、TUIC 中繼模式、客戶端指紋與特定傳輸參數，可能因範本能力不足而遺失。轉換結果能通過 YAML 語法檢查，只代表文字結構有效，並不代表協定語意完整。

判斷轉換是否完整，可以對照原始節點與輸出 YAML：節點類型是否保留，伺服器與連接埠是否一致，驗證欄位是否存在，TLS 是否開啟，SNI、路徑、Host、ALPN、指紋與協定擴充是否仍在。對於 Hysteria2 與 TUIC，還應檢查 UDP、壅塞控制及驗證欄位。若轉換後某一整類節點消失，通常是輸出目標選擇了舊 Clash 格式，或轉換器不支援該協定。

避免多次串接轉換。每增加一次轉換，都可能重新命名節點、重建代理群組或刪除未知欄位。最理想的路徑是訂閱來源直接輸出 mihomo 設定；其次是從原始通用訂閱轉換一次；不建議先轉換成舊 Clash，再轉換成 Meta。若必須維護自訂規則，可將節點訂閱與本地規則透過客戶端支援的覆寫或規則提供器機制組合，減少每次更新後手動修改整份檔案。

訂閱更新與本地修改的關係

大多數客戶端在更新訂閱時會重新下載遠端內容。本地直接編輯訂閱產生的設定，可能在下一次更新時被覆蓋。需要長期保留的規則、DNS 或代理群組調整，應使用客戶端提供的覆寫、合併設定或腳本機制；如果客戶端沒有此能力，則複製為本地設定並自行管理更新，但節點變更也需要手動同步。

訂閱更新失敗時，先區分下載失敗與解析失敗。下載失敗通常與連結有效性、系統時間、DNS 或目前網路有關；解析失敗則會在日誌中出現 YAML 行號、未知類型或欄位錯誤。若舊設定仍能連線而更新失敗，不要立即刪除舊檔案。保留上一份可用設定，可以在排查期間繼續對照節點欄位與代理群組結構。

在客戶端之間遷移訂閱時，不要只複製快取檔案路徑。不同客戶端對設定目錄、覆寫規則與核心參數的組織方式不同。更穩定的做法是重新匯入原訂閱連結，再遷移必要的本地規則。若使用本地 YAML，應確認路徑權限、檔案編碼與換行符號正常。Windows 上的路徑反斜線若出現在 YAML 字串中，應透過引號與正確跳脫避免被錯誤解讀。

七、客戶端、作業系統與協定支援選擇

圖形客戶端首先看核心與平台整合

協定支援由核心決定，但日常可用性也取決於客戶端如何管理核心。Windows 與 macOS 客戶端需要處理系統代理、服務模式、TUN 權限、開機啟動與系統匣狀態；Android 與 iOS 依賴系統 VPN 介面；Linux 桌面還涉及桌面環境、系統代理變數與權限。一個協定在命令列核心中可用，不代表圖形客戶端已為它提供完整的匯入、編輯與錯誤提示。

Clash Plus 是全平台優先選擇，適合希望在 Windows、macOS、Android 與 iOS 之間維持相近操作邏輯的使用者。Windows 與 macOS 也可考慮 Clash Verge Rev、FlClash；Windows 可使用 Clash Nyanpasu；Android 可選擇 Clash Meta for Android、FlClash 或 Surfboard；Linux 桌面常用 Clash Verge Rev 與 FlClash，也可以直接部署 mihomo。Clash for Windows 與 ClashX Meta 已停止維護，較適合處理歷史設定，不應作為現代協定的首選環境。

選擇客戶端時應查看三項事實：整合的核心是否支援訂閱中的節點類型，系統接管方式是否符合需求，以及訂閱與設定管理是否清楚。介面主題、視窗配置與系統匣樣式屬於使用偏好，不能取代協定相容性判斷。完整客戶端列表及系統需求可在客戶端比較和取得客戶端頁面查看。

Windows 與 macOS

Windows 上的系統代理主要影響遵循系統代理設定的應用程式，部分 UWP 應用程式、遊戲或自帶網路堆疊的軟體可能需要 TUN 或額外系統設定。協定連線成功但特定應用程式不走代理時，應先判斷流量是否進入核心，而不是更換節點協定。TUN 模式透過虛擬網路介面接管更廣泛的流量，需要相應權限與正確路由。關於 Windows 安裝、系統代理與常見錯誤，可閱讀Windows 安裝設定完整流程。

macOS 同樣區分系統代理與虛擬網路接管。Apple Silicon 與 Intel 安裝套件的架構不同，但設定檔中的協定語意一致。若客戶端可以啟動而核心程序立即退出，應查看架構、執行權限與設定解析日誌。Trojan、VLESS、Hysteria2 等涉及 TLS 的協定還依賴系統時間與伺服器名稱，時間異常會同時影響多個節點。

桌面端適合進行更完整的日誌排查。先將日誌層級設為 info，重現一次連線問題，記錄是 DNS、協定握手、TLS、逾時還是規則選擇錯誤。不要長期使用過高的日誌層級，因為大量日誌會增加磁碟寫入並使關鍵資訊更難辨識。問題定位完成後恢復一般層級。

Android 與 iOS

Android 客戶端通常會建立本地 VPN 服務，將應用程式流量送入核心。系統省電策略、背景執行權限與常駐通知會影響持續連線。若鎖定螢幕一段時間後連線中斷，而開啟客戶端後恢復，應檢查系統是否限制背景活動。若只有個別應用程式不經過代理，請檢查分應用程式代理、繞過設定與規則命中情況。協定本身通常不是第一個排查項目。

iOS 上的客戶端使用系統網路擴充功能，應用程式可使用的記憶體與背景生命週期受系統管理。Clash Plus 透過 App Store 提供 iOS 版本，並在 clashplus.io 提供產品資訊。行動端不適合匯入體積過大的規則集合後長時間開啟詳細日誌，這會增加記憶體與處理壓力。規則需求較複雜時，應優先使用經過整理的規則集，並減少重複項目。

行動網路切換會改變本地位址、DNS 與可用傳輸。TCP 節點可能需要重建連線，QUIC 類協定可能更快恢復，但仍受系統 VPN 介面與客戶端生命週期影響。比較行動端協定時，至少測試無線區域網路、行動網路、鎖定螢幕復原與網路切換四種狀態。只在桌面測速正常，無法證明行動端設定同樣穩定。

Linux、伺服器與路由器

Linux 桌面可使用圖形客戶端，也可直接執行 mihomo。圖形客戶端適合訂閱與桌面代理管理；直接執行核心適合伺服器、容器與路由器。命令列部署需要明確設定目錄、工作目錄、日誌輸出與服務使用者。設定檔應先在前景啟動驗證，再交給 systemd 等服務管理器，避免啟動失敗後只能看到重複重啟。

路由器部署還涉及轉送鏈、DNS 接管、區域網路存取與連線追蹤。Hysteria2 與 TUIC 對 UDP 路徑有要求，低功耗裝置還需留意 CPU。若路由器核心運作正常但區域網路裝置無法存取，應檢查監聽位址、允許區域網路連線、系統防火牆與客戶端閘道，而不是直接修改協定驗證。部署思路可參考路由器與旁路由部署概覽。

伺服器環境應優先確保可復原性。保留一份已驗證的設定，更新核心前記錄目前啟動參數，修改協定節點後先執行設定檢查或前景啟動。若新設定失敗，可以快速回復。對於多裝置共用的路由環境，穩定的 SS、Trojan 或既有 TCP 節點通常比頻繁調整協定更容易維護；只有在明確需要改善封包遺失路徑或 UDP 應用時，再評估 QUIC 類方案。

八、依使用情境完成協定決策與故障定位

日常網頁與辦公應用程式

日常網頁、文件協作與訊息應用程式通常更重視連線成功率、首位元組時間與長期穩定性，而不是單一連線峰值。已有 SS、Trojan 或 VMess 節點穩定運作時，可以繼續使用，不必只因出現較新的協定就遷移。若需要建立新設定，優先選擇訂閱原生提供、客戶端完整支援且參數層次較少的節點。在規則模式下，還要確認目標請求命中了預期的代理群組。

瀏覽器正常而其他應用程式異常時，首先檢查系統代理的涵蓋範圍。系統代理只影響遵循該設定的程式，TUN 才負責更廣泛的流量接管。瀏覽器首次開啟緩慢但之後正常，應分別檢查 DNS 與握手；所有協定同時解析失敗，更可能是 DNS 設定或系統網路問題。只有某一協定失敗，則依該協定的驗證、TLS 或 UDP 條件繼續排查。

規則設定需要遵循由具體到兜底的比對順序。網域後綴、規則集與地理規則命中後便停止繼續比對，最終由 MATCH 處理未命中流量。若節點連線測試正常但應用程式走錯路徑，應查看連線清單中的規則與代理群組，而不是重複更新訂閱。規則分流的完整寫法可參考Clash 規則分流設定實戰。

影片、大檔案與高吞吐任務

持續傳輸應優先比較伺服器可用頻寬、線路穩定性與壅塞復原。在穩定、低封包遺失的網路中，SS、Trojan、VLESS 或 VMess 都可能取得良好吞吐，協定差異通常小於線路差異。存在明顯封包遺失且 UDP 路徑良好時，可以測試 Hysteria2 或 TUIC，但應觀察長時間吞吐、緩衝中斷與裝置溫升，而不是只看開始階段。

高吞吐異常時，先確認本地無線訊號與上行是否被其他任務占滿，再比較直連網路與代理路徑。若所有節點都在相近速度觸頂，可能是本地網路、伺服器頻寬或裝置 CPU 限制。若只有 QUIC 類連線波動，應檢查 UDP、MTU 與頻寬參數；若只有 WebSocket 或 gRPC 節點異常，應核對路徑、Host、TLS 名稱與伺服器承載設定。

路由器作為全域入口時，裝置 CPU 很容易成為瓶頸。單台桌面客戶端可以達到的吞吐，不代表低功耗路由器也能達到。測試時觀察核心程序 CPU 是否接近單核心上限，並關閉高頻除錯日誌。若 CPU 已滿，繼續調整壅塞控制通常無法解決問題，應改用資源開銷更合適的協定，或將核心部署到效能更充足的裝置。

行動裝置與頻繁網路切換

行動端應將背景復原放在峰值吞吐之前。經常在無線區域網路與行動網路之間切換時，可以比較 Trojan、VLESS 與 QUIC 類節點的復原時間，但需要保持客戶端、規則與 DNS 一致。若切換後所有節點都短暫失敗，可能是 VPN 介面重建或 DNS 尚未更新；若只有 Hysteria2、TUIC 失敗，則繼續檢查新網路的 UDP 可達性。

待機耗電異常時，查看是否存在持續重連。錯誤的伺服器位址、失效訂閱、TLS 名稱不相符或無法連線的 UDP 節點，可能讓客戶端反覆嘗試連線。將預設代理群組暫時切換到一個已確認穩定的節點，觀察背景耗電是否恢復。減少不必要的健康檢查頻率、縮小規則規模與關閉除錯日誌，也能降低持續喚醒。

行動端不必長期保留大量功能重複的節點。代理群組中節點過多會增加健康檢查與訂閱處理負擔。更實用的結構是保留少量穩定 TCP 節點、一個經過驗證的 QUIC 類節點，以及明確的故障回退項目。自動選擇群組應使用合理的檢查間隔，並避免多個代理群組對同一批節點重複進行高頻測試。

從錯誤現象反推問題層次

設定無法載入時，先檢查 YAML 語法、未知欄位與不支援的節點類型。設定載入成功但節點不出現，檢查訂閱轉換與核心相容性。節點出現但立即驗證失敗，檢查密碼、使用者識別、加密方法與協定世代。TLS 握手失敗，檢查系統時間、SNI、憑證名稱與 ALPN。QUIC 節點逾時，檢查 UDP 路徑、連接埠、MTU 與伺服器監聽。節點測試正常但應用程式無法使用，檢查規則、系統代理、TUN 與 DNS。

連線問題應一次只修改一類變數。先保留原訂閱，選擇一個節點，使用規則最少的測試設定確認協定連線；再恢復代理群組；接著恢復規則與 DNS；最後開啟 TUN。若同時修改協定、DNS、規則與系統接管，任何結果都難以解釋。常見錯誤的進一步處理可前往常見問題查詢。

最終選擇建議

如果現有 SS 節點穩定、裝置資源有限且設定需求簡單，繼續使用 SS 是合理選擇。已有 VMess 設定並能長期穩定運作時，無需只因協定歷史較久就立即更換；新建組合式設定則應確認傳輸與 TLS 參數。重視標準 TLS 連線與清晰驗證結構時，可選擇伺服器提供的 Trojan。需要現代擴充，且客戶端使用 mihomo 時，可使用參數完整的 VLESS。

網路存在封包遺失或抖動、UDP 路徑確認正常，且裝置資源足夠時，可以測試 Hysteria2 或 TUIC。兩者都不應脫離伺服器設定單獨選擇，也不應手動互換驗證欄位。行動端應將背景復原與電量作為主要指標，路由器則以 CPU、記憶體與維護複雜度為主要指標；桌面端則可以在相容基礎上更充分地比較傳輸體驗。

無論最終選擇哪一種協定，都應保留一個已驗證的備用節點與一份可回復設定。訂閱更新後先確認節點類型與代理群組，再檢查規則；客戶端更新後確認實際核心；出現故障時依設定解析、協定握手、規則選擇、系統接管的順序定位。協定選擇的目標不是追逐名稱，而是建立一套可驗證、可維護且適合目前裝置與網路的連線方案。