協定與核心技術指南

一、選擇協定的四項考量

協定、傳輸、核心與介面各有不同層級

用戶端中的節點名稱通常由服務提供者自行命名，名稱裡的「高速」、「專線」不能取代技術資訊。實際連線至少涉及四個層級：協定規定用戶端與伺服器如何驗證身分及轉送資料；傳輸方式決定資料透過 TCP、UDP 或其他通道傳送；核心負責實作協定、解析設定並套用規則；圖形介面則提供訂閱管理、系統代理與記錄檔等功能。同一介面換用不同核心後，支援的節點類型可能改變；同一協定搭配不同伺服器與線路，使用體驗也可能截然不同。

因此，選擇時應先確認連線兩端能否正常通訊，而不是比較協定名稱的新舊。用戶端必須配合伺服器使用的協定、驗證參數、傳輸方式與安全設定。節點類型支援 VLESS，不代表支援所有 VLESS 組合；介面顯示某個名稱，也不表示正在執行的核心理解其中所有欄位。查看用戶端的核心資訊與實際設定，比只看應用程式名稱更可靠。

分開觀察連線時間與持續傳輸速度

開啟網頁會經過網域解析、連線至伺服器、驗證、連線至目標網站，以及等待第一個位元組等步驟。第一次載入緩慢，可能是其中任何一步造成。下載大型檔案則更仰賴持續傳輸能力、壅塞控制、伺服器出口頻寬與目標網站的速度限制。某個節點可能很快收到第一個位元組，卻無法長時間維持傳輸速度；另一個節點建立連線稍慢，下載速度卻更穩定。兩種情況並不矛盾，也無法用單一延遲數值概括。

行動網路還受到網路切換與無線休眠影響。裝置從 Wi-Fi 切換至行動網路後，本機位址、對外 IP 位址，甚至路徑品質都可能改變。部分連線需要重新建立，有些傳輸實作則能嘗試移轉連線，但最終仍取決於核心、伺服器與中間網路是否共同支援。協定具備某項機制，只代表設計上提供這項能力，不代表所有部署都已啟用，也不保證應用程式工作階段一定能持續。

先排除不符合條件的選項

實際選擇時可以逐步排除。若網路無法穩定傳送 UDP，就先別把以 QUIC 為基礎的協定當成唯一入口；若裝置上的核心不支援某種安全組合，也不要為了強行匯入而刪除不熟悉的欄位；若伺服器只提供一種協定，用戶端也無法自行把它改成另一種。篩選出可用組合後，再於相同時段、相同裝置和相同目標下比較體驗。如此得出的結論適用於目前環境，而不是脫離條件的協定排名。

二、SS 與 VMess 的設計取捨

SS：協定範圍精簡，設定加密參數

Shadowsocks 通常簡稱 SS，最初是為輕量加密代理轉送而設計。設定內容相對直接：伺服器位址、連接埠、加密方式與密碼。用戶端會將本機應用程式的請求轉成協定資料，再由伺服器連線至目標。常見的傳統 AEAD 加密方式結合加密與訊息驗證，可偵測資料是否遭到竄改。加密方式不是可以任意更換的速度選項；兩端設定不同，或驗證資料不相符，連線就無法正常建立。

SS 後續發展出不同的協定規範與擴充方式，其中也包括採用不同金鑰要求的現代方案。不能因為都標示為 SS，就把舊設定中的密碼文字直接套用到另一種加密方式。有些方式接受一般密碼，有些則要求特定長度與編碼格式的金鑰。用戶端也可能支援外掛擴充，其他用戶端卻未必有相同的外掛實作。若匯入成功但交握持續失敗，應先核對加密方式、金鑰格式與外掛參數，而不是反覆修改本機混合連接埠。

就資源使用而言，SS 的基本架構較精簡，但實際成本取決於加密方式、處理器指令支援、實作品質與流量規模。TCP 和 UDP 轉送也必須分別獲得連線兩端支援。節點支援 UDP，不代表所有應用程式的 UDP 請求都會經過它：系統代理通常只影響遵循代理設定的程式，其他流量可能需要 TUN 或應用程式自己的 SOCKS 設定。排查語音或遊戲連線時，應同時檢查流量入口與節點出口。

VMess：具備驗證機制的代理協定

VMess 源自 V2Ray 生態系，設計包含使用者身分驗證與請求封裝，並可搭配不同傳輸方式。常見設定會包含 UUID、加密選項、傳輸類型與 TLS 設定。這些欄位各自屬於不同層級：UUID 用於身分識別，傳輸欄位描述連線的承載方式，TLS 則負責相應連線的安全封裝。釐清各層的用途，才能理解為何同樣是 VMess，有的節點可直接使用 TCP，另一些則需要 WebSocket 路徑與請求主機資訊。

VMess 驗證與時間有關，系統時鐘若有明顯偏差，可能導致連線異常。排查時請確認裝置已正常同步時間，並核對伺服器記錄檔。舊設定中也可能出現 alterId 等欄位；現代部署與早期部署有所不同，不應任意增減數值來猜測相容性。請優先使用服務提供者針對目前核心提供的完整設定；若要遷移舊訂閱，再另外確認驗證模式，不要把舊欄位當成通用的最佳化參數。

舊節點不代表已無使用價值

SS 與 VMess 已累積許多部署案例，現有裝置仍持續使用它們，往往是因為相容範圍廣。選擇時應關注伺服器是否持續維護、加密設定是否合理、線路是否穩定，而不是只看協定問世的時間。若現有節點已符合需求，遷移至其他協定應有明確目的，例如解決特定的傳輸相容問題或統一設定。單純更換類型名稱不會提升線路容量，錯誤轉換反而容易遺失外掛與傳輸細節。

兩種協定的速度沒有固定高下。比較時應盡量使用相同的伺服器位置、出口與目標；若跨服務提供者測試，實際上往往是在比較伺服器與網路。若所有協定都很慢，可繼續閱讀網速慢的分層排查方式，先區分本機入口、節點負載與線路品質，避免把共同故障誤判為特定協定的固有缺點。

三、Trojan 與 VLESS 的安全層

Trojan：仰賴正確設定 TLS 連線

Trojan 將代理轉送置於 TLS 連線中，並以密碼驗證身分。它採用成熟的 TLS 安全機制，因此用戶端除了要設定伺服器位址、連接埠與密碼，也必須正確驗證伺服器身分。憑證是否在有效期限內、網域名稱是否相符、憑證鏈是否完整，都可能影響連線。密碼正確無法補救憑證問題；反過來說，TLS 交握成功也不代表代理驗證已通過，應搭配記錄檔判斷失敗階段。

有兩個名稱容易混淆：連線位址決定網路請求的目的地；SNI 則會在適用的 TLS 交握中，告知伺服器預期的主機名稱。兩者可以相同，也可能因部署方式而不同。若使用 IP 位址連線，不能任意將憑證驗證目標也改成該 IP；應使用伺服器明確提供的網域參數。用戶端中的 sni 或對應介面項目屬於身分與路由設定的一部分，不是填入熱門網站網域就能改善連線的選項。

憑證驗證失敗時，請先檢查裝置時間、憑證網域與伺服器憑證鏈。長期略過驗證會削弱用戶端確認伺服器身分的能力，不應當成一般的相容設定。若伺服器採用私人憑證體系，應依用戶端支援的方式建立明確的信任關係，而不是忽略所有驗證錯誤。排查期間即使暫時變更驗證選項，也應了解其影響，並在確認原因後恢復符合部署要求的安全設定。

VLESS：精簡驗證，不代表具備獨立加密

VLESS 同樣源自 V2Ray 相關生態系，著重精簡的身分驗證與代理請求格式。與具備自身加密機制的協定不同，VLESS 本身不提供完整的傳輸加密，必須搭配合適的安全層。用戶端顯示 type: vless 只是第一步，還要確認 TLS 或 REALITY 等安全設定、傳輸方式，以及伺服器要求的 flow。移除安全欄位可能導致設定無法使用，也可能違反原本的安全前提。

REALITY 是可搭配相關代理使用的安全機制，不是把任意節點轉成 VLESS 的切換開關。公鑰、短識別碼與伺服器名稱等參數，都必須符合伺服器端的設定。公鑰不是由用戶端自行產生後任意填入的值，短識別碼也不是節點名稱。只有連線兩端及相應傳輸方式都支援時，才能使用 flow；範例中出現這個欄位，不代表其他 VLESS 節點也應照抄。

一併考量額外傳輸層的效益與成本

WebSocket、HTTP 類傳輸或其他封裝，常用於配合既有部署架構，但不會自動帶來速度提升。增加封裝可能帶來額外的標頭、交握步驟與中間代理限制，也可能透過既有基礎設施改善連線可達性。選擇時應先確認它能解決什麼實際問題。若直連傳輸已很穩定，額外封裝未必有幫助；若伺服器只透過特定入口提供服務，則必須完整保留路徑、主機名稱及相關參數，不能為了減少層數自行刪除。

這兩種協定適合具備明確 TLS 部署條件、需要相關生態系功能的情境。一般用戶較穩妥的做法，是匯入服務提供者標明支援 mihomo 的設定，再檢查核心記錄檔是否接受所有欄位。了解參數用途有助於排查問題，但不代表一定要手動重建節點；保留原始設定副本，通常比憑印象重新填寫更可靠。

四、Hysteria2 與 TUIC 的 UDP 條件

共同基礎：QUIC 不等於一般 UDP 轉送

Hysteria2 與 TUIC 都透過 QUIC 建立代理傳輸。QUIC 以 UDP 為基礎，並整合安全交握、可靠資料流與壅塞控制等機制。不能把它理解成「改用 UDP 就不必重傳」；可靠資料仍須確認與復原，只是相關邏輯由 QUIC 實作負責。多條資料流可減少傳統單一 TCP 連線中的部分互相阻塞問題，但同一資料流內的資料順序、共用路徑上的壅塞與伺服器處理能力，仍會限制實際表現。

這類協定首先要求用戶端至伺服器的 UDP 路徑可用。網路允許透過 UDP 進行網域解析，不代表允許對任意目標連接埠建立持續的 QUIC 工作階段。訪客網路、防火牆、電信業者網路與伺服器安全性群組都可能影響連線。若 TCP 節點可用，但兩種 QUIC 節點都逾時，請先檢查 UDP 對外連線、伺服器監聽狀態與連接埠轉送，不要立刻更改驗證密碼。NAT 對應的存活時間也會影響長時間閒置後的連線恢復。

Hysteria2：以可調整的傳送策略因應複雜網路

Hysteria2 是為高延遲、封包遺失等複雜網路條件設計，透過 QUIC 傳送代理流量，並提供相應的壅塞控制與頻寬設定機制。常見設定包含驗證資訊、TLS 名稱，以及依部署需求使用的混淆或頻寬欄位。第一代 Hysteria 與 Hysteria2 並非只改名稱的同一種線上協定，不能只替換類型欄位就期待兩者互通。訂閱轉換器必須辨識正確的版本，並保留目前核心所需的參數。

頻寬參數尤其容易誤用。這些參數可能會影響傳送行為，不是顯示在介面上的預期速度。若上行或下行設定遠高於可用頻寬，可能增加排隊、封包遺失，並加劇與其他應用程式的競爭；設定過低則可能限制傳輸速度。應依實際部署所用的壅塞控制模式理解欄位，並以穩定線路的測量結果為依據。伺服器也可能透過協商或策略限制實際行為；用戶端填入更大的數值，無法增加伺服器出口頻寬。

TUIC：多資料流與壅塞控制仍需兩端相符

TUIC 同樣以 QUIC 建立代理連線，著重資料流多工與 UDP 轉送等需求。常見設定包含 UUID、密碼、伺服器名稱與壅塞控制相關選項。不同協定版本與實作之間存在相容界線，不能只因為都標示為 TUIC，就認定彼此相容。用戶端應使用伺服器要求的協定版本與驗證方式，壅塞控制名稱也必須獲目前核心接受。未知選項可能被忽略，也可能直接造成錯誤，請查看實際載入記錄。

部分實作支援早期資料或工作階段恢復，以縮短重新建立連線時的等待時間。不過，首次連線、恢復連線與工作階段失效時的處理方式並不相同，不能把恢復連線的優勢套用到每次請求。早期資料也涉及重播風險與伺服器策略，是否啟用應遵循實作文件。一般用戶保留服務提供者給定的預設組合，再進行重複連線測試，通常比一味追求最短交握時間更有意義。

實際使用時，若 UDP 路徑品質良好，Hysteria2 或 TUIC 可以列入考慮，但不宜在未經測試的環境中當成唯一入口。保留一個穩定的 TCP 類候選，有助於區分協定問題與網路限制。這兩種協定也無法保證行動網路切換時連線不中斷：連線識別、移轉機制、伺服器策略與用戶端生命週期都會影響結果，應以切換後的實際恢復狀況為準。

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

分階段測試，不要只看單一測速數字

節點探測通常會向特定位址發出請求，並顯示該次請求所花的時間。不同用戶端可能使用不同目標、連線重用策略與逾時規則，因此兩個介面顯示的數值未必能直接比較。探測成功只能表示當時的特定測試順利完成，不能證明觀看影片、存取程式碼儲存庫或即時通話也會有相同表現。目標網站的地理位置、解析結果與連線策略不同，實際的網路路徑也可能不同。

測試分為三類：短連線測試觀察網頁第一個位元組的時間與失敗次數；持續下載測試觀察傳輸速度能否維持；互動應用則觀察抖動、重新連線與背景恢復情況。每一類都應重複測試，不要只保留最佳結果。比較時盡量固定裝置、網路、伺服器地區與目標位址，暫停其他大量流量工作，並記錄測試是否重用連線。若無法固定伺服器，就應註明比較的是節點整體，而不是單純比較協定實作。

處理器、記憶體與連線數量彼此影響

加密、資料複製、協定封裝與壅塞控制都會占用處理器時間。硬體加速支援、核心編譯方式與系統網路堆疊都會改變資源成本，因此同一協定在不同裝置上的效能排序可能不同。記憶體用量也會受到規則集大小、DNS 快取、連線數量與記錄檔緩衝區影響。發現用戶端資源使用偏高時，別急著歸咎於節點協定；先檢查是否載入大量規則提供器、是否有許多並行下載，或介面是否持續更新連線清單。

連線重用可減少部分重複連線，但也會形成共用資源與故障影響範圍。多個請求共用一條承載連線時，一次壅塞可能同時影響多項工作；不重用則可能增加交握次數與連線數量。巢狀重用也不一定更好，尤其是協定本身已支援多資料流時。除非能說明具體效益，並確認核心與伺服器都支援，否則建議沿用預設設定，避免一次啟用所有看似能降低延遲的選項。

耗電應觀察全天使用情況，而非單次峰值

手機耗電不只來自加密運算，也與無線模組被喚醒的次數及持續運作時間有關。頻繁的連線檢查、過短的保活間隔、重複連線失敗、背景更新訂閱與詳細記錄，都可能增加耗電。某個協定下載時的處理器用量較低，不代表待機時也更省電；若該協定使用的網路 NAT 對應時間很短，用戶端不斷維持或重建工作階段，全天耗電反而可能更高。應分別觀察使用中與待機時的情況。

TUN 通常會讓更多符合路由條件的流量進入核心，因此啟用前後的耗電差異也可能來自流量處理範圍變大，而非協定效率改變。系統代理只會接管遵循系統設定的應用程式，兩者的處理工作量本來就不一定相同。比較耗電時，應固定接管模式、規則與背景應用程式，並涵蓋相近的使用時段，同時留意系統是否限制用戶端在背景執行。用戶端遭系統暫停而「省電」，可能伴隨連線中斷，不能視為最佳化成功。

不建議替六種協定標上固定的「省電等級」或「速度星級」，這類標籤會掩蓋硬體、線路與設定的差異。更有參考價值的是附帶條件的結論：在目前手機、目前網路與固定接管模式下，哪個節點符合使用需求，且背景連線較穩定。每次只變更一項設定，若表現變差就能回復到前一個狀態，不必同時更換核心、協定與 DNS 設定。

六、原版、Meta 與 mihomo 的關係

核心演進與設定脈絡

原版 Clash 建立了廣泛使用的工作方式，包括規則分流、代理群組、設定檔與控制介面。Clash.Meta 在相關程式碼與設定體系上擴充協定和功能，後續則以 mihomo 名稱持續發展。閱讀舊資料時，「Meta 核心」和「mihomo」常指同一條後續發展脈絡中的不同階段，但不代表任一時期的功能完全相同。討論相容性時，應確認實際執行的實作與具體欄位，而非只看歷史名稱。

原版設定中的許多基本概念，在 mihomo 中仍然可見，例如 proxies、proxy-groups 和 rules。這讓使用方式得以延續，但不代表雙向相容。較新的設定若包含原版未實作的協定、規則類型或 DNS 選項，原版不會因為檔案仍是 YAML 就自動理解。遷移方向通常比名稱更重要：從基本設定遷移至擴充版本，與將擴充設定退回舊版，是兩種不同的工作。

用戶端負責管理，不等於核心

Clash Plus、Clash Verge Rev、FlClash 和 Clash Nyanpasu 等用戶端，提供不同的介面與整合方式。下載頁優先列出 Clash Plus，適合先透過圖形介面管理訂閱與常用設定；其他用戶端則可依平台與功能需求選擇。介面中的系統代理、服務模式、TUN 權限與設定覆寫，往往需要用戶端和核心共同處理。介面沒有顯示進階欄位，不代表核心不支援；介面提供按鈕，也不代表已取得所需系統權限。

不同用戶端也可能產生自己的執行設定。使用者匯入的是訂閱原文，用戶端啟動核心時使用的設定檔，則可能已注入連接埠、合併規則並套用覆寫。排查時必須確認查看的是哪一份設定。直接編輯產生的檔案，可能在下次切換設定或重新啟動後遭到覆寫；修改訂閱原文，也可能被後續更新取代。建議使用用戶端提供的持久化覆寫功能，並確認實際執行的設定已套用修改。

分開檢查遷移與權限

遷移前請保留現有設定、代理群組選擇與覆寫設定，再用新用戶端匯入副本。先停用複雜的覆寫設定，測試基本設定，並確認協定能否辨識、代理群組引用是否存在，以及規則提供器能否取得內容。基本連線確認正常後，再逐項恢復 DNS、TUN 與自訂規則。如此一來，發生問題時便能找出是哪個步驟造成，而不必在多個層面同時變動的設定中摸索原因。

若基本代理可用但 TUN 無法運作，應改查權限、驅動程式、路由與系統服務，不要立刻更換協定。若系統代理已開啟，但只有終端機無法連線，請確認終端機是否讀取系統代理，並參考瀏覽器與終端機分開排查。這些問題發生在入口或應用程式層，通常與伺服器使用 SS 或 Trojan 無關。

七、訂閱格式與設定相容性

同一個「訂閱」入口可能接收不同內容

訂閱是一種提供內容的方式，不是單一檔案規範。連結傳回的內容可能是完整的 Clash YAML、只有節點的清單、編碼後的分享連結列表，或網頁錯誤訊息。完整設定通常包含代理群組、規則與 DNS 等項目；節點清單則只提供伺服器項目，其他內容需由用戶端或範本補齊。因此，「連結能開啟」不代表取得了可執行的設定。匯入失敗時，應先檢查回應類型與結構，再判斷用戶端是否支援。

SS、VMess、Trojan、VLESS 等分享連結各有不同的參數格式，編碼與跳脫方式也不盡相同。轉換器將它們轉成 YAML 時，必須保留驗證、傳輸、安全與擴充欄位。轉換器可能認得協定名稱，卻不認得較新的參數，於是產生表面完整、實際缺漏的節點。尤其是 REALITY、flow、外掛與 QUIC 相關選項，不能因為轉換成功就認定已完整保留。

YAML 可解析，不代表設定正確

YAML 對縮排、列表與對應有明確規則。建議使用空格縮排，並為包含特殊字元的字串選用適當的引號。解析成功只代表檔案結構合法；代理群組若引用不存在的節點，或規則指向不存在的策略，仍可能導致執行失敗。節點名稱重複也會造成選擇上的混淆。處理複雜訂閱時，應分別檢查語法錯誤、欄位錯誤、引用錯誤與執行階段的網路錯誤，不要一概稱為「更新失敗」。

以下片段只示範 mihomo 中本機入口與規則的基本關係，不包含遠端代理伺服器。混合連接埠可接收 HTTP 與 SOCKS 代理請求，區域網路存取則已關閉，所有符合規則的流量都會直接連線。這段設定適合用來理解設定層級，不能取代現有訂閱中的遠端節點設定。實際使用代理時，還需加入真實節點與相應的代理群組，並讓規則指向正確的群組名稱。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

本機連接埠與遠端節點連接埠是不同的端點。修改 mixed-port 後，還需要同步修改手動設定代理的應用程式；遠端伺服器連接埠則必須與伺服器的監聽連接埠一致。訂閱內容中的 allow-lan 也不是節點效能選項，而是控制本機入口是否允許區域網路存取。共用代理前，應先了解監聽範圍、防火牆與身分驗證；不能只因手機需要連線，就對外開放所有網路介面。

遠端提供器、覆寫與更新的界線

proxy-providers 用於取得節點清單，rule-providers 則用於取得規則清單。兩者用途不同，不能把完整的用戶端訂閱隨意放進只接受特定節點結構的提供器。更新失敗也可能是 DNS、連線路徑、伺服器驗證、回應內容或本機檔案權限所致。查看記錄檔時，應確認失敗發生在下載階段，還是下載成功後的解析階段；前者應排查網路與回應，後者則應檢查格式與核心欄位支援。

訂閱自動更新會重新取得上游內容，直接修改其中的規則通常無法永久保留。較穩妥的做法是使用用戶端支援的覆寫或合併機制保存個人設定，同時了解其套用順序。清單是整份取代還是附加、同名對應如何處理，各用戶端可能不同。每次調整後都應檢查實際執行的設定，確認沒有意外刪除原有代理群組，或把所有分流規則都覆寫成最後一條比對規則。

初次匯入與更新方式請參考訂閱匯入步驟。處理相容性問題時，建議先向服務提供者索取明確支援 mihomo 的格式，再比較原始內容與實際執行設定的差異。只更改訂閱檔案副檔名、只修改節點類型名稱，或反覆編碼解碼，都無法補回已遺失的協定參數。

八、依使用情境選擇與測試

分別確認桌面、行動裝置與伺服器的條件

桌面日常瀏覽應優先考量相容性與可維護性。若已有穩定的 SS、VMess 或 Trojan 節點，無須只為更換協定而遷移；若需要 VLESS 的特定組合，再確認 mihomo 與伺服器參數一致。用戶端可先選擇下載頁優先推薦的 Clash Plus，也可依平台考慮 Clash Verge Rev、FlClash 等選項。桌面裝置通常有較充足的資源，但系統代理、瀏覽器擴充功能與終端機環境變數仍可能各自獨立，需分別測試。

行動裝置應優先觀察背景恢復與網路切換表現。先保留一個已確認穩定的節點，再比較 Hysteria2 或 TUIC 在目前行動網路中的效益。不要同時變更協定、測速頻率與 TUN 模式，否則很難判斷耗電變化的原因。Android 可依裝置架構從下載頁選擇相應用戶端；iOS 的用戶端入口與系統網路延伸機制不同，使用 Clash Plus 時應以其實際支援的匯入格式與功能為準，不要直接套用桌面版 mihomo 的所有欄位。

伺服器與路由器更需考量架構、長時間執行與對外暴露範圍。選擇核心套件前，請核對處理器架構、作業系統與執行環境，並設定獨立的執行目錄與持久化策略。不要將外部控制介面直接暴露於不可信任的網路；本機代理連接埠、控制介面與遠端伺服器監聽連接埠也應分開管理。無圖形介面的部署方式可參考Linux 圖形用戶端與命令列服務部署，先建立便於維護的服務，再處理更複雜的分流設定。

沿著請求路徑逐步排查

從本機開始驗證：確認核心正在執行、連接埠未被其他程式占用，再確認應用程式請求確實進入代理。如果連線清單中找不到相應請求，先檢查系統代理、應用程式設定或 TUN 路由；若有請求但選錯節點，檢查模式、規則與代理群組；選對節點仍然失敗，才繼續檢查驗證、TLS 與遠端連線。依照這個順序，能避免把入口故障誤判為協定不相容，也能避免規則根本未命中時仍反覆測速。

DNS 也需要另外判斷。伺服器網域解析失敗會讓代理連線無法建立；目標網站解析異常則可能導致部分網站無法開啟。使用假位址映射的 DNS 模式時，應用程式取得的位址可能不是目標網站的真實位址，需搭配核心記錄檔判斷，不能只依一次系統解析結果下結論。變更 DNS 後也要留意快取與既有連線，確認新請求確實經過調整後的路徑，再評估效果。

需要確認 HTTP 代理入口時，可以在本機執行以下命令，連線至測試網站。命令會明確指定混合連接埠，適合用來區分終端機未讀取系統代理，與核心本身無法轉送的情況。這個命令只會測試一次 HTTP 請求，不會驗證 UDP、其他應用程式或所有分流規則。若已變更連接埠，請一併更新命令中的連接埠；若測試目標本身無法連線，也應改用已知正常的目標交叉確認。

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

保留可還原的選項，不要堆疊設定開關

最終設定應明確指定主要節點、必要的備用節點，以及能夠說明用途的分流規則。每次只變更一項關鍵設定，並保留修改前的設定副本。確認有效後，應在相近的使用時段重新測試；偶爾快一次，不足以證明適合長期使用。若候選節點經常失敗，先找出網路條件或參數差異，再決定是否放棄，不必讓它繼續參與高頻自動測試，以免增加資源消耗。

本頁的選擇原則可以濃縮為一項技術判斷：先確保端到端相容，再依實際用途比較成本。完成選擇後，請使用連線測試步驟確認應用程式能正常存取；若要接管不讀取系統代理的程式，再參考TUN 模式原理與權限重點。協定定義的是用戶端與伺服器之間的通訊方式，無法取代正確的本機入口、DNS、規則與系統權限。