協定與線路參考

CONNECTION MODEL

連線分層與比較基準

拆解一次網路存取過程

應用程式送出請求後，流量不會直接進入某個協定。系統會先判斷如何解析目標位址、是否將流量交由代理處理，接著由用戶端尋找入口、建立連線並完成驗證。通過入口後，流量還會經過轉送路徑與出口，最後才抵達目標服務。等待可能發生在上述任何環節。只看到用戶端顯示已連線，就將速度慢歸咎於協定，容易忽略其他更常見的原因。

DNS 負責將網域名稱轉換為位址，路由規則決定流量的去向，代理協定則規範用戶端與代理伺服器之間的溝通方式。這些工作可能互相影響，但並非同一層。網域解析正常，不代表應用程式使用了所選線路；出口位址改變，也不代表所有應用程式都走相同路徑。排查時應分別記錄解析結果、規則匹配情況與應用程式表現，而非用單一狀態圖示取代所有證據。

傳輸層決定資料如何抵達對端。TCP 提供有序且可靠的位元組流，UDP 則提供資料報；使用 UDP 的上層協定也能自行實作可靠傳輸。加密層負責處理身分驗證與內容保護。有些協定名稱涵蓋驗證、封裝與傳輸選擇，有些則只是輕量代理協定。比較前應說明完整組合，不能把名稱相同、底層條件不同的連線視為同一種實作。

連線快，不代表傳輸也快

連線建立時間包含網域解析、連至入口的往返、交握與驗證。網頁有許多分散的小型請求，因此更容易感受到建立連線的成本；持續下載則是在連線建立後長時間傳輸，吞吐量與壅塞處理更為重要。既有連線能否重複使用也會影響觀察結果。首次開啟較慢、再次開啟較快，可能是連線重用或快取所致，不能據此證明線路剛有所改善。

延遲描述往返等待時間，吞吐量代表持續傳輸資料的能力，抖動則是等待時間的變化。三者不能互相取代。線路閒置時可能回應很快，下載時卻明顯排隊；也可能持續傳輸順暢，但初次連線要等較久。選擇時應先確認應用程式對哪些表現較敏感，再觀察相關狀況。直接把下載測速結果當成會議、遊戲或互動工具的表現，往往會選錯。

資源使用也應分項觀察。用戶端的加密運算、連線狀態、規則比對與背景記錄都會消耗處理器或記憶體。同一協定在不同實作上的表現可能不同，裝置是否支援硬體加速也會影響負擔。由於實作、設定與工作負載都不固定，本頁不提供跨裝置的統一排名。較可靠的做法是在自己的裝置上觀察前景回應、發熱、背景活動與連線恢復情況。

建立可重複檢查的比較條件

比較時固定使用同一台裝置、同一個網路與同一個目標應用，每次只更動一項條件。如果同時更換地區、協定與用戶端，即使結果有所改善，也無法判斷是哪項因素造成。先讓正在進行的下載結束，確認系統沒有背景更新，再開始觀察。記錄網路類型、節點名稱、出口地區與應用程式行為，比只存一張速度截圖更方便日後查核。

也要分開記錄冷啟動與既有工作階段。關閉應用程式並重新連線，可觀察連線建立過程；保留工作階段繼續操作，則可觀察持續傳輸。兩種結果應分開記錄，不要混為整體印象。測試期間避免反覆切換規則模式，否則應用程式可能沿用舊連線。需要確認新條件時，應先結束受影響的工作階段，再用相同操作重新送出請求。

比較的對象應是「裝置、網路、協定實作、線路路徑與應用程式」的組合，而非單一協定縮寫。

本頁討論一般運作機制，不代表 VPNBM 承諾提供所有列出的協定。實際入口、可選傳輸方式與節點欄位請以使用者面板為準。安裝與匯入問題請先參閱快速入門；若顯示已連線但不確定應用程式使用哪條路徑，可參考出口 IP 與 DNS 檢查說明進行驗證，再比較協定，避免在錯誤前提下反覆換線。

PROTOCOL TRADE-OFFS

常見協定的設計取捨

Shadowsocks 與 VMess

Shadowsocks 著重於加密代理轉送，通常由用戶端將應用程式連線導向代理伺服器，再由代理伺服器存取目標。設定重點包括加密方式、驗證資訊與傳輸支援。不同實作對連線重用、UDP 轉送及外掛擴充的處理方式不盡相同，因此「設定欄位較少」不代表資源消耗一定較低。選擇時應先確認用戶端能完整讀取訂閱中的實際參數。

Shadowsocks 的加密保護範圍是代理連線，不會取代目標網站本身的安全連線。存取 HTTPS 服務時，應用程式與目標網站之間仍有自己的加密層。系統時間錯誤、憑證信任問題或應用程式網路設定異常，都無法靠更換代理加密方式解決。若驗證失敗，應檢查匯入內容是否完整、節點是否仍有效，不要自行修改金鑰，也不要將設定貼到公開討論區。

VMess 在代理通訊中使用自己的驗證與訊息封裝機制，並可搭配不同傳輸方式。額外封裝帶來更多相容方式，也增加了需要配對的條件。用戶端與伺服器端對傳輸、加密及時間相關驗證的設定必須一致。有些驗證問題可能與系統時鐘偏差有關，但並非所有連線失敗都是時間造成。記錄中的驗證、解析與連線錯誤應分開處理。

Trojan 與 VLESS

Trojan 常與 TLS 連線搭配，透過驗證辨識代理請求，再轉送實際應用程式流量。伺服器位址、驗證資訊、伺服器名稱與憑證驗證都是重要條件。TLS 交握成功只代表加密連線已建立，不代表驗證或後續轉送一定成功。用戶端提示憑證錯誤時，應核對訂閱與系統時間，並保留憑證驗證；不要把關閉驗證當成一般修復方式。

VLESS 採用較輕量的代理協定結構，本身不提供內容加密，必須搭配安全傳輸機制。輕量指的是這一層的設計，不代表整條連線的總成本較低。設定中還可能包含 TLS、其他安全層或不同承載方式。脫離這些條件，單獨宣稱 VLESS 更安全或速度更快，都不準確。完整連線的安全範圍必須依實際設定判斷。

比較 Trojan 與 VLESS 時，常被簡化成「哪個比較快」。在相同路徑下，連線重用、伺服器資源、交握處理與用戶端實作，可能比協定名稱的差異更明顯。若入口路徑本身已經壅塞，減少少量封裝也無法消除排隊。若用戶端不支援必要欄位，理論上較輕量的設定也無法正常運作。在討論效能之前，必須先確認協定可用且參數相符。

不要把附加承載方式當成協定本身

WebSocket、HTTP 類承載方式與直接連線，都會改變資料封裝與連線處理流程。這些方式可能用於配合部署環境，但也可能增加額外中間層。中間層的連線逾時、緩衝策略與容量都會影響使用體驗。代理協定相同但承載方式不同，不能直接歸納成同一種效能；反過來說，承載方式相同但入口不同，也可能有截然不同的穩定度。

連線重用可讓多個應用程式請求共用底層連線，減少重複建立連線的成本，但也可能讓它們一起受到該連線壅塞影響。是否適合啟用，須視實際實作與應用型態而定。大量短請求可能受益；持續大量傳輸與即時應用則應觀察彼此影響。不要只因設定名稱含有「最佳化」就全部開啟，訂閱提供的預設組合更適合作為比較基準。

實際選擇時，可先保留用戶端能穩定解析的協定，確認網頁、持續傳輸與網路切換都正常後，再嘗試其他選項。如果更換後只有首次連線有所改善，結論就應限於連線建立階段；如果只有某個入口改善，結論就應限於該線路。用條件式描述局部觀察，比追求不分情境的協定排名更有用，也能避免換裝置後照搬不適用的設定。

QUIC AND UDP

Hysteria2 與 TUIC 的傳輸條件

UDP 不代表不可靠

QUIC 建立在 UDP 之上，但會自行處理加密、確認、重傳與壅塞控制，並非將應用程式資料交給 UDP 後就不再管理。與 TCP 的位元組流不同，QUIC 可在同一連線中安排多個資料流，使單一資料流的遺失不一定會阻塞其他資料流的有序交付。不過，各資料流仍共用網路容量與壅塞狀態，因此彼此並非完全不受影響。

QUIC 將安全交握與傳輸建立結合，並具備連線恢復等機制；這些功能是否生效，取決於伺服器、用戶端與工作階段條件。首次連線與恢復工作階段不能混為一談；代理連線內的應用程式也可能仍需自行交握。看到協定採用 QUIC，就推斷每次開啟網頁都會更快，會忽略入口往返、網域解析與目標回應等仍需等待的環節。

UDP 路徑可連通是前提。有些網路會限制 UDP，部分閘道器的連線狀態保留時間較短，也有裝置不擅長處理較大的資料報。這時 TCP 連線可用、QUIC 連線失敗，並不矛盾。應先確認相同入口的 UDP 路徑能否建立，不要直接把失敗歸咎於帳戶問題。若沒有提供該協定選項，也不能自行改寫節點類型來勉強相容。

Hysteria2 的頻寬與壅塞取捨

Hysteria2 使用 QUIC，並採用與頻寬利用相關的設計。實際壅塞行為會受到設定與實作影響，尤其是依頻寬估算調整傳送的策略，需要合理判斷網路路徑。把頻寬參數設得很高不會憑空增加線路容量，反而可能讓傳送速度持續超出路徑負荷，引起佇列累積、丟包並拖慢其他應用程式。參數應依實際部署條件設定，而非照搬宣傳的頻寬數字。

在容易丟包的路徑上，不同壅塞策略的表現可能有所差異。有些策略遇到丟包時會明顯降低傳送速率，有些則更重視估算可用容量。前者可能犧牲吞吐量，後者可能增加共用線路的負擔；不能脫離網路條件宣稱某種策略永遠較好。下載變快但會議變卡，表示整體使用需求並未滿足。選擇時也要檢查互動延遲，不應只看傳輸是否跑滿。

行動網路的容量變化明顯，固定的頻寬估算可能很快就不再符合實際狀況。訊號變化、基地台調度與網路切換都會影響路徑。在這類環境中，應優先保留面板與用戶端提供的有效設定，不要從其他網路照搬頻寬參數。如果連線能建立，但一開始傳輸就不穩，先停止背景下載、重新比較網路，再判斷是壅塞設定還是 UDP 路徑問題。

TUIC 與裝置相容性

TUIC 同樣採用 QUIC，提供代理轉送、連線重用與 UDP 處理機制。它與 Hysteria2 不能只因底層相似就共用設定。驗證方式、連線參數與用戶端支援都需要各自配對。訂閱中出現無法辨識的欄位時，應更新訂閱並確認用戶端支援情況；不要刪除不理解的參數後，就把勉強匯入視為完整支援。

QUIC 的連線識別碼提供了因應路徑變化的機制基礎，但實際恢復效果仍取決於應用程式、代理實作與伺服器策略。切換網路後能否保留工作階段，必須實際測試，不能從協定介紹推論成服務承諾。即使底層連線恢復，出口位址或目標服務的工作階段驗證也可能改變。進行重要操作時，仍應盡量維持網路與出口條件穩定。

QUIC 的加密、確認與計時器通常在使用者空間處理，資源消耗取決於實作與負載。有些裝置在大量資料報下會較忙，另一些裝置則表現正常。耗電差異應結合連線數量、背景活動與網路品質觀察。使用時間較短、螢幕亮度不同或同時下載更新，都可能掩蓋協定因素，因此不適合據此作出確定的耗電排名。

UDP 路徑可連通、參數相符，且負載下回應正常，才是選用 QUIC 類協定的實際依據。

如果目前的網路環境中 QUIC 持續連線失敗，而現有 TCP 類設定可以正常運作，可先保留後者完成日常工作，再向客服提供已去除個人資訊的錯誤情況。此結論只適用於當下路徑，不代表 QUIC 普遍較差。更換網路後應重新檢查。保留可用的基準設定與退回方案，比讓所有裝置固定使用新協定更穩妥。

ROUTE TOPOLOGY

直連、中轉與專線的路徑差異

入口與出口各自負責什麼

入口是用戶端首先連線的位置，出口則是目標服務看到的流量來源位置。兩者可能在同一個節點，也可能分散於不同轉送路徑。入口離使用者近，不代表出口也離目標服務近；出口地區合適，也不代表通往入口的網路順暢。線路名稱通常只呈現部分資訊，無法單靠地區名稱還原完整路徑，更不能據此推斷實際延遲。

直連通常表示用戶端透過公網直接連到目標代理入口，之後由該節點存取目標服務。架構較直接、中間轉送環節較少，但仍受電信業者路由、國際網路互連與目標網路影響。「直」描述的是拓撲，不代表地理距離最短。公網路徑可能繞行，跨網路互連也可能在尖峰時段排隊，因此是否適合直連，仍須視實際網路與目標服務而定。

中轉是在用戶端與出口之間增加轉送環節。合適的中轉可將不穩定的網路區段換成較容易控管的路徑，也可能減少部分公網互連的不確定性。不過，新增設備同樣需要容量、連線管理與維護。中轉節點資源不足或通往出口的線路壅塞時，反而會成為瓶頸。環節較多不一定更慢，環節較少也不一定更穩。

專線改善的是哪一段

IEPL 這類專線描述的是特定承載線路的交付方式，並不等同於整段存取過程的結果。即使入口到出口之間採用專用承載，使用者到入口仍有本地網路，出口到目標服務也仍需經過網路傳輸。家中無線網路干擾、行動網路訊號變化或目標服務回應緩慢，不會因中間某一段使用專線就消失。討論專線時，應明確指出涵蓋的區段。

專線的價值通常在於路徑與容量較容易管理，但可控不代表容量無限，也不代表所有時段都沒有競爭。入口設備、出口資源與目標網路仍須相互配合。判斷時可觀察尖峰時段的互動是否穩定、持續傳輸是否影響其他工作，以及相同目標是否反覆出現恢復等待。不要把線路類型標籤直接當成服務等級保證。

協定與線路是兩個獨立面向。同一協定可以透過直連、中轉或專線承載；同一種線路也可能提供不同協定入口。更換協定改善交握，不代表國際路徑也會改善；更換線路減輕壅塞，也不代表加密機制有所改變。遇到問題時，應先判斷異常發生在哪一段，再決定要更換入口、出口或協定，避免漫無目的地全部更換。

地區選擇與服務範圍

選擇出口地區時，應先確認應用程式本身的地區需求，再檢查用戶端到入口的連線狀況。地圖上較近的地區不一定有更好的網路互連，較遠的出口也可能透過更合適的路由提供穩定傳輸。互動應用應優先考量往返等待；持續觀看則更需要穩定吞吐與平台辨識相符。地區篩選只是縮小候選範圍，不能取代實際測試。

串流影音或線上工具能否使用，還受到帳戶地區、授權、目標服務政策與出口辨識影響。某個地區有節點，不代表該地區的所有服務都能使用；網頁能開啟，也不代表播放、登入或長時間工作階段都正常。應依具體功能逐一測試，避免只看國旗就推定應用程式支援範圍。線路清單中的類型與可用狀態，也應以面板現況及實際測試為準。

VPNBM 的涵蓋範圍為 90+ 個國家／210+ 條線路。這表示服務涵蓋範圍，不代表每個地區都有相同拓撲或提供所有協定。查看全球節點與線路說明時，請先確認可選地區及欄位定義，再回到用戶端核對實際入口。本文的拓撲說明旨在協助理解差異，不會臆測城市、線路分配或應用程式支援狀態。

值得長期保留的不是聽起來較高階的標籤，而是在常用網路與應用程式下表現穩定、可重複驗證的候選設定。網路條件改變後，再用相同方法重新檢查。記錄入口名稱、出口地區與受影響功能，有助於分辨是本地問題還是線路問題。只記下「專線不好用」或「直連很快」，卻沒有路徑與應用情境，難以作為下次選擇的依據。

LOSS AND QUEUES

丟包、抖動與尖峰時段壅塞

丟包的成因不只一種

資料未能如預期抵達，可能是無線干擾、線路錯誤、設備緩衝區溢位或網路策略處理所致。不同原因對協定的影響各不相同。無線訊號不佳時，資料可能在本地就需要重傳；線路負載超過容量時，佇列累積後也可能丟棄資料。發現丟包就認定遠端節點故障，會忽略使用者到入口之前可能已經發生的問題。

TCP 通常會重傳遺失的資料，並調整傳送方式。應用程式可能出現等待、吞吐量下降或間歇性停頓，而非直接顯示丟包。QUIC 也有確認與復原機制，但多資料流架構與壅塞處理方式會帶來不同表現。協定能復原資料，不代表復原沒有成本：重傳會消耗網路資源，也會增加等待時間。丟包嚴重時，更換封裝方式無法取代修復實際路徑。

抖動關注延遲變化。平均等待時間看起來不高，偶爾排隊仍可能使即時語音中斷、遊戲回應不一致。持續觀看有緩衝空間，較能掩蓋短暫變化；即時互動則需要資料準時送達，遲到的資料即使最後完整抵達，也可能派不上用場。因此同一條線路在不同應用中的評價不同，並不表示觀察結果互相矛盾，而是應用程式的容忍度不同。

尖峰時段與緩衝區積壓

尖峰時段代表共用資源的需求增加，瓶頸可能出現在本地網路、電信業者互連、中轉設備或出口網路，不能只看時間就鎖定某一段。如果關閉所有代理後，一般本地網頁也需要等待，應先檢查網路；如果只有特定出口連線的目標異常，就更值得檢查那條路徑。判斷時需要對照，不要把所有晚間問題都歸為同一個原因。

緩衝區積壓會讓頻寬與延遲同時造成誤判。大型下載仍可能有不錯的吞吐量，但即時請求排在佇列後方，使用體驗反而變差。測速程式持續灌入資料，可能正好製造這種情況。下載測試結束後再判斷會議狀態，不一定能反映會議單獨運作時的表現。應分別觀察閒置與持續傳輸時的互動情況，並在記錄中註明競爭負載。

家中的無線網路也會共用無線頻道資源。裝置距離、遮蔽物、鄰近干擾與其他裝置的傳輸，都會讓同一條外部線路呈現不同結果。條件允許時，可改用較穩定的連線方式重新檢查，或靠近網路設備再比較。如果改善網路後所有候選線路都一起變好，應優先處理本地環境，不必繼續調整遠端協定設定。

了解測試的限制

網路探測結果只反映特定探測方式，並不完全等同於實際服務資料的路徑。中間設備可能降低探測回應的優先順序，卻仍正常轉送應用程式流量。某一跳沒有回應，不代表流量就停在那裡；某一跳回應較慢，也不一定表示應用程式後續會有同樣的等待。應搭配目標連線狀況與實際應用表現判斷，避免只憑路徑圖中醒目的異常就下結論。

出口伺服器的處理能力、連線數量與目標服務的限速，也會影響吞吐量。如果不同網路連線到同一個目標都很慢，而其他目標正常，應考慮目標端因素。反過來說，如果同一入口的多個無關目標都受到影響，則更值得檢查入口或網路路徑。藉由擴大或縮小受影響範圍，可以逐步定位問題，不必先猜測是哪台設備故障。

高負載時，先確認互動是否變慢。下載速度漂亮，不代表共用線路上的其他工作也正常。

排查順序可以保持簡單：先結束背景傳輸、確認本地網路，再比較不同入口，最後比較同一入口的可選協定。每次變更後，都要重新建立受影響的工作階段。如果只有停止下載後才改善，應記錄為負載競爭；若更換入口後有所改善，則記錄為路徑相關。不要同時重裝用戶端又切換網路，否則容易失去真正有價值的比較依據。

遊戲情境還須區分帳戶伺服器、遊戲伺服器地區與代理路徑。一般代理不等於專為遊戲路徑設計的加速服務，遊戲是否支援相關轉送也需要確認。若要了解延遲與丟包在不同應用中的差異，可接著閱讀遊戲情境下的延遲與丟包說明。本頁說明運作機制，不會把單次觀察改寫成普遍效能保證。

ENDPOINT CONDITIONS

裝置資源與行動裝置電量

耗電來自整體工作負載

代理運作時，耗電不只來自加密。無線收發、處理器喚醒、連線保活、重傳、規則比對與背景應用程式都會消耗電量。訊號較弱時，網路設備可能需要更頻繁地運作；連線頻繁失敗時，反覆恢復也會增加活動量。若直接把系統電量頁面中用戶端的耗電量視為協定成本，就忽略了用戶端正在替其他應用程式處理網路資料。

比較耗電量時，應盡量讓應用程式工作、螢幕使用與網路條件保持一致。持續播放與背景待機是不同工作負載，不能用前者推論後者。用戶端顯示的背景執行時間，也不代表處理器一直滿載。更有效的觀察方式是：閒置時是否持續發熱、網路切換後是否反覆重新連線、記錄中是否不斷出現相同錯誤，以及連線恢復正常後這些現象是否消失。

保活可用來維持連線，或偵測路徑是否已失效；但越頻繁的保活也會增加無線網路喚醒次數。間隔太長則可能讓中間設備清除連線狀態，導致下一次請求重新連線。合適的設定取決於網路與實作，不能一概宣稱間隔越短就越穩定。優先使用用戶端或訂閱的預設值；只有明確遇到閒置斷線時，再檢查相關設定，不必在沒有問題時追求持續連線。

系統接管方式與背景限制

系統代理通常只影響遵循系統代理設定的應用程式；虛擬網路介面則能在網路層接管更廣泛的流量。但涵蓋範圍更廣，不代表所有流量都以相同方式處理：路由規則、應用程式自身的網路堆疊、DNS 處理與系統權限仍會影響結果。如果瀏覽器正常、其他應用程式卻異常，應先檢查接管方式與規則，不要因為使用相同平台就假設所有應用程式都走同一條路徑。

行動作業系統會自行管理背景工作。省電策略、應用程式限制與網路切換都可能影響連線存續狀態。可能會出現連線圖示仍在，但底層工作階段需要恢復的情況。請先回到用戶端確認連線狀態與錯誤提示，再重新開啟受影響的應用程式。為了診斷而暫時調整背景限制時，應記錄變更，檢查完後恢復必要的電量管理，避免長期增加背景活動。

桌上型作業系統也有類似限制。從睡眠狀態喚醒後，舊的網路介面、DNS 快取與既有應用程式連線可能仍沿用先前狀態；切換網路後，也可能需要重新確認實際匹配的規則。應先讓用戶端重新建立連線，再檢查出口與應用程式。把睡眠後的異常當成某協定長期不穩定，容易忽略系統恢復階段的問題，造成原本正常的設定被無謂修改。

多裝置同時使用與用戶端取得方式

VPNBM 支援 Windows / macOS / iOS / Android / Linux，裝置同時上線數量不限。此說明僅指裝置數量，不代表各裝置具備相同的協定支援能力，也不代表共用網路的總容量無上限。多台裝置同時下載時，入口與家用網路仍會互相競爭資源。建議先分別確認單一裝置的狀態，再觀察並行工作是否造成額外等待。

同一帳戶在不同平台上使用，不必勉強選用相同協定。某個平台的實作較成熟，另一個平台對特定參數支援有限時，可以分別保留適合的設定。重點是訂閱正確、規則目標明確，且應用程式結果符合預期。家用裝置的數量限制與共用條件，可參考多裝置與家庭共用說明，避免將裝置數量與頻寬分配混為一談。

用戶端請統一從使用者面板的用戶端頁面取得，需登入後才能取得訂閱。不要從來源不明的設定檔複製驗證資訊，也不要把匯入失敗直接歸因於平台無法使用。iOS 的下載、設定授權與用戶端差異，可參考iPhone 用戶端選擇說明。本頁僅說明裝置條件，不提供靜態安裝檔或訂閱直連。

SCENARIO SELECTION

依應用情境選擇協定與線路

網頁、AI 工具與持續觀看

日常瀏覽網頁通常涉及網域解析、多個連線與分散的小型請求，因此連線建立與路徑回應都很重要。先選擇能正常匯入、連線恢復穩定的設定，再比較常用網頁。不要只打開一個快取完整的網站就下結論。若頁面架構很快出現，圖片卻一直載入，可能是部分網域規則、資源服務或連線問題；應先檢查受影響的請求範圍，而非直接全面換用另一種協定。

AI 工具常見的使用方式包括登入、持續工作階段、串流回應與檔案上傳，這些階段的網路需求各不相同。頁面能開啟不代表工作階段可以持續，文字回應正常也不代表上傳路徑正常。應分別測試常用功能，並維持出口地區與帳戶條件一致。若只有長時間工作階段中斷，應優先觀察連線逾時、網路切換與背景狀態，不要先把問題歸因於頻寬不足。

串流影音更重視持續吞吐量與緩衝恢復，也會受到帳戶授權、地區政策及出口辨識影響。協定可能影響傳輸，但無法取代平台的使用條件。播放失敗、畫質變化與緩衝停頓應分開記錄：失敗可能發生在授權階段；畫質可能是平台調整自適應串流策略；停頓則較直接與持續傳輸有關。只看首頁能否開啟就判斷服務可用，證據並不足夠。

會議、遊戲與檔案傳輸

即時會議仰賴資料準時送達，抖動、排隊與丟包復原都會影響聲音與互動。開會時應盡量暫停大量背景傳輸，並保持網路穩定。如果只在啟用代理後某項會議功能異常，應檢查該應用程式的流量是否需要代理、是否依賴 UDP，以及規則是否涵蓋相關網域。一般代理設定無法自動保證所有即時通訊功能都相容。

選擇遊戲連線方式時，應先確認遊戲服務地區、連線方式與目標路徑。啟動器、資源更新與對戰連線可能使用不同位址及傳輸方式；登入正常不代表對戰資料已依預期轉送。不要為了涵蓋所有流量就直接擴大接管範圍，擴大後也要確認延遲與本地服務。實際選擇應依遊戲行為判斷，不應宣稱一般代理適用於所有遊戲或都能加速。

檔案傳輸應關注穩定吞吐量、重試行為與工作復原。大型檔案進入持續傳輸後，交握節省通常不是主要因素。此時更值得檢查路徑壅塞、裝置負載與目標端限速。切換線路可能中斷現有工作，也可能改變出口位址並觸發目標端檢查。需要保留傳輸狀態時，應等工作完成後再比較，不要在重要上傳途中反覆測試。

將選擇寫成條件，而非排名

挑選候選設定時，可先從相容性著手。設定能完整匯入、驗證正常且目標功能可用，是基本條件；接著觀察常用網路中的連線恢復，再比較負載下的互動與持續傳輸。如果 UDP 路徑可靠，可將 QUIC 類設定納入比較；若網路環境有明顯限制，則保留 TCP 類設定作為基準。這個順序不偏向特定協定，而是優先降低使用上的不確定性。

選擇出口地區時，應以應用程式需求與路徑表現為依據，不要一味追求地理位置更近。對帳戶工作階段敏感的應用程式，頻繁更換出口可能引發額外驗證，讓網路比較受到帳戶因素干擾。適合長期使用的組合，應在常見工作中保持穩定，並有明確可行的退回方式。記錄「目前無線網路下，會議正常且下載沒有明顯拖慢互動」，比記錄「某協定最好」更有參考價值。

同時使用多種應用程式時，還要考慮規則分流。讓原本不需要代理的本地服務維持原路徑，可減少不必要的轉送，也避免地區辨識改變。分流不是協定本身的能力，修改後應確認 DNS 與應用程式連線是否一致。如果只讓部分網域使用代理，卻讓其他相關資源維持原路徑，功能可能只會部分失效。規則應依完整功能檢查，不要只看單一網域。

先選擇能完整完成工作的組合，再比較連線建立速度、負載表現與資源消耗。沒有脫離使用情境、永遠勝出的協定。

流量需求與技術選擇也應分開考量。月訂閱流量依開通日每月重置，中途升級的價差會按剩餘天數折算；流量包用完為止，永久有效。詳細方案請見方案頁。流量額度屬於計費條件，不是協定頻寬保證，也不代表較高級方案會自動解決本地壅塞。應先找出效能問題，再依實際使用量選擇額度，避免把容量與連線品質混為一談。

REPEATABLE VERIFICATION

驗證紀錄與故障排查順序

簡單記下必要的測試資訊

記錄不需要複雜工具。寫下裝置平台、網路、用戶端狀態、節點名稱、協定與目標功能，再描述實際狀況。分清楚是無法建立連線、驗證失敗、頁面等待、持續傳輸停頓，還是切換網路後失效。只寫「速度慢」無法說明問題發生在哪個階段。能夠重現的操作順序，比沒有條件說明的截圖更方便自行檢查，也能讓客服更容易理解。

先保留一組正常設定作為基準，每次只改變一個條件。比較入口時，盡量維持協定與應用程式工作相同；比較協定時，則盡量使用相同路徑。如果面板無法提供完全相同的條件，應明確記錄差異，不要把結果當成純粹的協定比較。測試結束後恢復原有規則與接管模式，避免診斷設定長期殘留，影響日後判斷正常狀態。

記錄結論時應限定適用範圍。例如「在這個網路下，該入口於持續下載時明顯增加互動等待」已足夠實用，不必延伸成整類線路都不穩定。如果換到另一個網路後問題消失，應補充這項條件；如果目標應用程式更新或帳戶狀態改變，也應重新驗證。筆記可以保留不確定性，技術參考的價值在於清楚交代證據的適用範圍。

從匯入到應用程式逐層排查

匯入失敗時，先確認帳戶狀態、訂閱取得方式與用戶端格式支援。不要手動拼湊面板網址作為訂閱，也不要公開貼出原始連結。既有設定突然無法解析時，可重新取得訂閱並確認用戶端支援情況，同時保留錯誤提示以便聯絡客服。用戶端清單與取得流程請參閱快速入門；iOS 授權步驟另見iOS 設定指南。

連線建立失敗時，先檢查解析、網路連通性、系統時間與驗證提示。憑證錯誤應核對伺服器名稱與信任條件，不要關閉驗證來繞過問題。UDP 類設定失敗時，可用現有可用設定作為對照，再檢查網路差異。如果所有入口都失敗，應優先排查本地網路、用戶端權限與帳戶狀態；若只有某個入口失敗，再進一步檢查該入口的設定與路徑。

連線建立後，請確認出口與規則。瀏覽器顯示的出口，只能代表該次瀏覽器存取所使用的路徑，不能代表所有應用程式。DNS 結果也應搭配解析方式與規則判讀，不要只因看到不同位址就直接認定資料外洩。需要確認某個應用程式時，先結束舊工作階段，再依目前條件重新存取並觀察功能結果。詳細檢查方式請見確認連線是否生效的說明。

負載問題與安全聯絡方式

只有持續傳輸時不穩，應先排除背景負載競爭、裝置過熱與目標端限制，再比較其他入口。如果閒置時正常、下載時所有互動都變慢，應優先留意佇列積壓；如果只有某個目標很慢，則檢查目標服務與出口互連。切換網路後出現異常時，請重新建立連線並結束舊工作階段。按照這個順序，每次調整都有對應的假設，不必反覆清除所有設定。

路徑 MTU 與資料報大小不符，也可能出現小型請求正常、大量資料停滯的情況。封裝會占用額外空間，部分路徑對分片或相關回報的處理也不理想。但這不能當成所有卡頓的預設解釋。只有在問題持續、對照明確，而且用戶端確實提供相關選項時，才依文件確認設定。不要從網路論壇照搬未經確認的參數，更不要同時修改多項底層設定。

聯絡客服時，請保留錯誤類型、發生階段、網路與已進行的比較結果，並刪除密碼、驗證欄位、完整訂閱連結及其他個人資料。可透過使用者面板的客服工單聯絡。無需電子郵件地址，只要使用者名稱與密碼即可建立帳戶；但設定憑證仍應妥善保管。任何診斷都不需要向無關人士公開完整驗證資訊。

VPNBM 的服務範圍為 90+ 個國家／210+ 條線路、裝置數量不限，並提供 14 天無理由退款；付款方式包括支付寶／微信／USDT。實際選擇仍應回到面板中的可用設定與自身應用需求。結論應以證據能支持的範圍為限：設定相符、路徑可連通、功能正常、負載可接受。技術名稱用於理解運作機制，測試紀錄則協助決定保留哪條線路，兩者各有用途。