最穩定的 VPN 推薦不能只看一次測速，也不能只看用戶端顯示的延遲。真正影響日常使用的，是連線能否順利建立、持續使用時是否意外中斷，以及斷線後能否正常恢復。線路拓撲、協定、接入網路、出口負載和用戶端實作都會改變結果。若把這些變數混在一起測，最後得到的往往只是某個偶然時刻的快照。
更可靠的方法，是先固定測試條件，再分別記錄連線成功率與斷線率。前者回答「能不能連上」，後者回答「連上後能不能維持」。兩項都穩定，才適合長時間瀏覽、遠端協作、串流影音播放或大檔案傳輸。本文不提供脫離使用環境的排名，而是整理一套可重複執行的比較方法。
先把「穩定」拆解成可觀察的結果
連線成功率是成功建立代理工作階段的次數除以全部連線嘗試次數。測試時需要先定義什麼算成功：不能只看用戶端按鈕變成「已連線」，還要確認出口位址已變更、目標網頁能夠開啟，並且 DNS 請求依預期處理。如果用戶端顯示連線完成，但實際流量仍經由原本的網路傳送，這次嘗試不能算成功。
斷線率用來觀察已建立的工作階段是否發生非主動中斷。這裡要排除系統休眠、使用者手動切換節點、路由器重新啟動和應用程式被背景策略終止等情況。否則，作業系統行為會被錯誤歸因於線路。發生中斷後，還應記錄是自動重新連線、需要手動重新連線，還是節點在一段時間內完全無法使用。
| 觀察項目 | 它要回答的問題 | 容易誤判的情況 | 適合的記錄方式 |
|---|---|---|---|
| 連線成功率 | 從未連線狀態開始，能否建立可用的工作階段 | 介面顯示成功，但出口位址和 DNS 路徑沒有變化 | 記錄每次嘗試的結果、節點、協定和接入網路 |
| 斷線率 | 建立工作階段後，能否持續傳輸資料 | 把休眠、切換網路或應用程式退出當成線路斷線 | 記錄中斷時間、當時操作和恢復方式 |
| 重新連線表現 | 網路短暫變化後，用戶端能否恢復 | 只觀察按鈕狀態，沒有重新驗證出口 | 恢復後再次檢查網頁、出口和 DNS |
| 延遲波動 | 互動體驗是否忽快忽慢 | 只保留最低值，忽略持續抖動 | 在相同用途下觀察一段完整的工作階段 |
連線耗時可以作為輔助指標，但不宜單獨決定結果。有些線路握手稍慢，建立後卻很穩定；有些節點很快顯示連線成功，之後卻頻繁重新連線。測試記錄應優先保留原始事件，而不是急著把不同現象合併成一個總分。
為什麼線路拓撲通常比節點名稱更重要
節點名稱通常只能說明出口地區，無法完整呈現流量如何抵達出口。同一個地區可能採用直連、中轉或 IEPL 專線等不同拓撲。它們經過的網路、壅塞位置和故障點不同，所以即使出口看起來相同，尖峰時段的表現也可能差異很大。
直連、中轉與 IEPL 的差異
直連是從目前的接入網路直接前往境外出口。路徑簡單，但更依賴本地電信網路與國際互聯品質。路由繞行、跨網互聯壅塞或國際段波動，都可能直接反映在連線上。直連不一定不穩定，在路徑合適的地區也可能表現良好；問題在於它對使用者所在的網路更敏感。
中轉通常先連線至距離較近或接入品質較好的入口，再由中轉網路送往出口。這樣可以避開部分不理想的直達路徑，但也增加了中轉入口和內部傳輸環節。中轉資源負載過高時，入口延遲看似正常，實際吞吐量和持續連線仍可能下降。
IEPL 是國際乙太網路專線類型，常用於承載跨境段傳輸。它與一般公網直連的主要差異，在於國際段的承載和路由管理方式。實際穩定性仍取決於入口品質、出口容量、調度和服務商實作，不能只憑「專線」字樣判定所有時段都相同。
| 線路類型 | 路徑特點 | 重點觀察 | 常見誤區 |
|---|---|---|---|
| 直連 | 從接入網路直接前往境外出口 | 本地電信網路、跨網路由與國際互聯變化 | 把所有直連都視為相同品質 |
| 中轉 | 先到入口，再經由內部鏈路前往出口 | 入口負載、內部傳輸和出口容量 | 只測入口延遲，不驗證實際存取 |
| IEPL 專線 | 跨境段採用專線類承載 | 入口接入、調度策略與出口狀態 | 只看線路標籤，不做持續測試 |
尖峰時段壅塞「各占多少影響」沒有適用於所有人的固定答案。可以用控制變因法判斷：保持裝置、接入網路、用戶端、協定、出口地區和測試任務不變，只更換線路拓撲；再於不同網路繁忙程度下重複測試。若直連明顯隨時段變化，而中轉或專線較穩定，路徑壅塞的影響就更大。若所有拓撲同時變差，則還要排查本地接入、無線網路和裝置負載。
協定選擇如何改變連線結果
協定決定握手方式、傳輸特徵、加密封裝和壅塞處理，但協定無法修復容量不足的線路。把協定理解成車輛、把線路理解成道路會更合適：車輛設計會影響通行方式，但堵塞的道路不會因為換車就自動暢通。因此，協定測試必須使用相同的入口和出口，不能在切換協定時順便更換節點。
Shadowsocks、VMess、Trojan 與 VLESS
Shadowsocks 是輕量的加密代理協定，用戶端支援廣泛，規則分流也較成熟。它本身不是傳統意義上的全裝置 VPN，是否接管全部流量取決於用戶端的系統代理、虛擬網卡模式和路由設定。
VMess 與 VLESS 常見於相關代理核心生態。VMess 具備驗證與加密設計，VLESS 則更偏向精簡驗證，通常需要搭配 TLS、Reality 或其他傳輸設定使用。兩者的穩定性不只由協定名稱決定，也與傳輸層、伺服器設定、核心版本和用戶端實作有關。
Trojan 通常以 TLS 建立連線，外層行為接近一般加密網路工作階段。憑證、網域解析、系統時間和 TLS 握手異常都可能導致連線失敗。若同一節點在一部裝置可用、另一部裝置握手失敗，應先比較用戶端核心和憑證環境，而不是直接判定線路失效。
Hysteria2 與 TUIC
Hysteria2 和 TUIC 都建立在 QUIC 與 UDP 傳輸之上，適合在有封包遺失或延遲變化的網路中測試。它們能運用自身的壅塞控制和多路複用機制，但前提是目前網路對 UDP 傳輸友善。如果辦公室網路、公共網路或接入設備限制 UDP，連線可能失敗或效能下降，此時切換到基於 TCP 的方案更具參考價值。
- ✅ 相同協定使用相同節點、相同用戶端核心和相同分流模式。
- ✅ 分開記錄 TCP 類傳輸與 QUIC 類傳輸，不要把兩者混成一個平均結果。
- ✅ 切換協定後重新檢查出口位址和 DNS，確認新設定確實生效。
- ✅ 記錄系統休眠、無線網路漫遊和接入網路切換，避免誤判為協定斷線。
- ❌ 不要使用不同地區、不同拓撲的節點來證明某個協定更穩定。
- ❌ 不要把短時間下載峰值當成長期連線品質。
如果某個協定在家庭網路穩定，在公共網路卻無法連線，通常表示網路策略或 UDP 可達性存在差異，不足以證明協定本身「較差」。推薦方案應依使用情境保留備選，而不是只留下單一名稱。
建立可重複的實測流程
一套有用的測試不需要複雜的實驗室，但必須保持一致的測試口徑。開始前先關閉會改變網路路徑的其他代理工具，暫停大流量背景工作，並確認系統時間準確。無線訊號不穩時，先處理本地接入問題，否則所有節點都會受到同一干擾影響。
- 固定環境。選擇相同裝置、相同接入網路和相同用戶端。測試期間不要同時更新系統、切換無線網路或執行大量同步工作。
- 建立記錄。寫下節點地區、拓撲、協定、傳輸方式、用戶端名稱和測試時段。每次嘗試都記錄成功、失敗或假連線，而不是只保留最好的一次。
- 執行冷連線。從完全斷線狀態發起連線，驗證出口位址、目標網站和 DNS。失敗後先保存錯誤資訊，再進行下一次嘗試。
- 執行持續工作階段。維持實際業務運作，包括網頁存取、持續下載或遠端連線。出現停頓時，區分是應用程式卡住、DNS 解析失敗還是通道斷線。
- 檢查恢復。正常使用時遇到網路短暫變化後，觀察用戶端能否重新建立通道，並再次核對出口。按鈕恢復不代表流量已經恢復。
- 只更換單一變數。只改變協定、節點或線路拓撲其中一項。若全部項目一起更換，結果就無法解釋。
連線成功率的分母必須一致。如果一個候選方案只測試少量次數，另一個候選方案測試更多次，直接比較會放大偶然因素。這裡不必追求某個固定次數，但每組樣本都應採用相同規則，並涵蓋平常實際使用的網路時段。
斷線記錄也要定義界線。瀏覽器單一分頁報錯不一定是通道斷線，也可能只是目標網站故障；某個應用程式無法連網，也可能是分流規則未匹配。只有當出口驗證、多個目標存取和用戶端記錄共同指向通道中斷時，才適合記為線路斷線。
DNS、分流與訂閱匯入會製造哪些假象
用戶端顯示已連線，但 DNS 仍由原本的網路解析時，可能出現地區判斷不一致、網站開啟緩慢或部分網域無法存取。這通常稱為 DNS 洩漏，或 DNS 路徑未依預期接管。檢查時不要只看出口位址，還要確認解析請求交由哪個解析器處理，以及解析結果是否符合目前的分流設計。
分流規則會決定哪些網域和位址進入代理，哪些維持直連。規則缺失時，常見現象是瀏覽器可用但桌面應用程式不可用，或者首頁能開啟、媒體資源卻載入失敗。全域模式可以協助判斷問題是否來自規則，但長期使用哪種模式仍應依需求決定。若全域模式正常、規則模式異常，應優先檢查規則匹配、DNS 模式和應用程式是否繞過系統代理。
訂閱連結負責向用戶端提供節點與設定。匯入成功只代表用戶端已讀取訂閱，不代表所有節點都通過連線驗證。更新訂閱後，節點名稱、參數或分組可能發生變化；部分用戶端還會以訂閱內容覆蓋本機修改。測試前應確認實際選取的節點和協定沒有被自動切換。
Windows、macOS、Android 與 iOS 上的用戶端，在系統代理、虛擬網卡、背景常駐和權限模型方面各不相同。桌面用戶端通常更容易查看核心記錄和路由表，行動平台則更受系統背景策略影響。同一訂閱在不同平台出現差異時，應比較用戶端核心、虛擬網卡模式、DNS 設定和背景限制，不能直接把裝置差異算入節點斷線率。
- ✅ 連線後檢查出口位址，並用實際目標網站確認流量路徑。
- ✅ 檢查 DNS 解析是否符合全域或分流設定。
- ✅ 分別驗證瀏覽器、桌面應用程式和命令列工具，排除單一應用程式繞過代理。
- ✅ 更新訂閱後重新確認節點、協定、分組和路由模式。
- ❌ 不要把訂閱匯入成功等同於線路已經可用。
- ❌ 不要在不同平台使用完全不同的模式後，直接比較斷線率。
如何解讀測試結果並做出選擇
測試完成後，先依使用情境分組，不要急著尋找唯一的冠軍。家用寬頻、辦公室網路和公共網路的路由策略可能不同；一個節點在家用網路連線順利，不代表在限制 UDP 的網路中同樣適合。分別保留常用環境的結果，比混合計算更有意義。
如果連線成功率偏低，但連線後很少中斷，應檢查握手、網域解析、憑證環境和協定可達性。這類問題可能透過更換協定或用戶端改善。如果容易建立連線，卻在繁忙時段頻繁中斷，更應關注線路容量、中轉入口、出口負載和路由變化。
如果所有節點同時出現波動，先排查本地無線網路、路由器負載、接入網路和裝置省電策略。只有某個出口異常時，再把注意力放到該節點。只有某種協定異常時，則比較相同線路上的其他協定。依照這個排查順序，可以減少無效切換。
最終可以採用主線路加備用線路的方式。主線路負責最常見的使用情境，備用線路則採用不同拓撲或不同傳輸，以便在接入環境變化時切換。穩定不是找到一個永遠不變的節點，而是知道每種異常該檢查哪裡，並保留可驗證的替代路徑。