延遲、抖動與掉包各自影響什麼
玩家說「卡」，往往混著三件不同的事。延遲是封包從裝置到遊戲伺服器再返回的時間，以毫秒計，決定操作與回饋之間的間隔；抖動是延遲的波動幅度，決定這個間隔穩不穩；掉包是封包在鏈路上沒有送達，決定操作在伺服器端算不算數。
三者的體感差別很大。延遲偏高但穩定，是可以適應的：你會自然提前半拍，重新建立肌肉記憶。抖動則很難適應，同一套連段有時判定成立、有時落空，節奏永遠對不上。掉包的破壞最直接——位置回彈、技能無效、明明躲開卻被判定命中，這些通常不是幀數問題，而是狀態同步沒跟上。
還有一個容易忽略的差別：下載和看影片走 TCP，掉包會被重傳補上，你只覺得慢一點；即時對戰多走 UDP，不重傳，掉一個封包就是一次狀態不同步。所以「測速夠快」和「遊戲不卡」是兩件事，頻寬數字幫不上忙。
| 指標 | 遊戲裡的感受 | 常見成因 | 先查什麼 |
|---|---|---|---|
| 延遲 | 操作慢半拍，但節奏穩定 | 物理距離遠、路由繞行 | 到目標伺服器的往返路徑 |
| 抖動 | 同一套操作時快時慢，難以形成肌肉記憶 | 鏈路壅塞、無線干擾、共享頻寬 | 本地網路與晚間尖峰時段 |
| 掉包 | 位置回彈、技能無效、瞬移 | 鏈路壅塞、UDP 被限速、無線掉封包 | 線路類型與 UDP 轉發是否正常 |
延遲與掉包會隨電信業者、時段、目標伺服器變化，任何固定數字都沒有參考價值。有意義的是方法與順序：先測出問題在哪一段，再決定要不要加速。測試時用持續 ping 觀察五到十分鐘的延遲分布與掉包計數，不要只看一次結果。
加速器與全域代理的運作方式差在哪
全域代理把裝置上的所有流量交給同一個出口，設定簡單，適合網頁瀏覽與跨區存取。代價是遊戲流量和系統更新、語音、下載擠在同一條鏈路上，任何一項占滿頻寬，遊戲就跟著抖。
遊戲加速器一般只接管指定處理程序或指定規則的流量，其餘直連；同時對遊戲常用的 UDP 做針對性轉發，並依目標伺服器挑選線路。一句話概括：代理解決「能不能到達」，加速解決「到達得穩不穩」。
| 比較項目 | 直連 | 全域代理 | 遊戲加速器 |
|---|---|---|---|
| 接管範圍 | 無 | 裝置全部流量 | 依規則或依處理程序 |
| UDP 支援 | 原生 | 取決於協定與客戶端實作 | 通常明確支援 |
| 鏈路選擇 | 電信業者預設路由 | 固定單一出口 | 依目標伺服器選線路 |
| 對下載與影片的影響 | 無 | 共用同一條鏈路 | 幾乎不占用 |
| 適用情境 | 本地伺服器、單機 | 網頁與跨區存取 | 海外伺服器對戰與連線 |
協定看承載方式，不看名字
訂閱連結裡常見的 Shadowsocks、VMess、Trojan、VLESS 都以 TCP 承載為主，再透過各自的方式承載 UDP；Hysteria2 與 TUIC 基於 QUIC，本身跑在 UDP 上，在掉包較多的鏈路上更有優勢，但對網路環境也更敏感。選擇順序建議是：先確認客戶端支援，再看鏈路是否穩定，最後才比較峰值速度。
分流規則與 DNS 洩漏
分流規則決定哪些網域或 IP 走線路、哪些直連。規則沒有涵蓋到遊戲的登入與對戰網域，就會出現「客戶端顯示已連線、延遲卻一點沒變」。DNS 洩漏是另一個常見問題：解析請求仍由本地電信業者處理，結果是連上了線路，卻對應到不合適的區域，延遲沒有改善甚至更差。
不少客戶端預設只代理 TCP。遊戲走 UDP，如果 UDP 沒有被接管，介面看起來是連上的，實際對戰仍走本地網路。先確認 UDP 轉發或 TUN 模式是否開啟，再談線路選擇。
海外伺服器延遲高的原因，按這個順序排查
先說結論：換線路能解決的是繞行與壅塞，解決不了物理距離與伺服器端狀態。把這兩類分開，排查會快很多。
物理距離決定延遲下限。資料在光纖裡以接近光速傳播，跨洲往返本身就有固定耗時，任何軟體都抹不掉這段距離。加速能做的是讓路徑更直、更少排隊，而不是把距離變短。
- 先排除本地因素：優先使用有線連接；無線環境注意頻道占用與干擾；暫停背景更新與同步；路由器長時間運作後重新啟動一次。
- 再看時間規律：只在晚間尖峰變差，通常是國際段共享鏈路壅塞；全天都差，更可能是路由繞行，或目標伺服器本身距離過遠。
- 看路徑而不是只看結果：用系統內建工具或第三方工具觀察每一跳的延遲變化，判斷問題出在本地出口、國際段還是目標端。
- 最後才懷疑伺服器端：官方維護、排隊、區域伺服器負載，這類問題換任何線路都一樣。
線路類型：直連、中轉與 IEPL 專線
直連是資料從本地直接到目標，路徑由電信業者決定，成本最低，但國際段在尖峰時段容易與其他流量爭搶。
中轉是先接入一個中轉節點，再從中轉節點到目標。它繞開的往往是壅塞最嚴重的幾跳，實際效果取決於中轉節點的頻寬、位置與承載的流量規模。
IEPL 專線屬於企業級專線，鏈路相對固定，不與其他公共流量爭搶，穩定性更高，成本也更高，通常用在固定時段、對穩定性敏感的情境。
依使用頻率選擇即可：偶爾連線，中轉類線路夠用；固定時間打積分對戰，優先選專線類線路。判斷線路好壞不要只看一次測速，觀察晚間尖峰時段的延遲與掉包變化更有參考價值。
線路是否真的可用，可以用幾個可驗證的數字核對：覆蓋範圍、線路數量與退款期限。以 VPNCZ 為例，線路列表裡可以查到 120+ 國家與 180+ 線路，退款期限為 30 天。
哪些情境值得用，哪些用了也沒用
把情境分清楚，能省下很多白費的功夫。
- ✅ 海外伺服器對戰與連線合作，且延遲或抖動在晚間尖峰明顯變差
- ✅ 遊戲走 UDP，而目前網路對 UDP 限速或不穩定
- ✅ 需要固定出口：與朋友同區、參加固定時間的活動
- ✅ 多裝置共用網路，下載與遊戲互相排擠，需要把遊戲流量單獨接管
- ❌ 單機遊戲與本地伺服器對戰：流量本來就沒有連外
- ❌ 官方維護、排隊或全區故障：線路改變不了伺服器端狀態
- ❌ 本地無線環境差、路由器老舊：先修本地，再談線路
- ❌ 帳號停權與地區限制：這是帳號與規則問題，不是網路問題
- ❌ 本地伺服器已經低延遲：多一層轉發只會多一個環節
判斷標準不是遊戲類型，而是問題發生在哪一段：問題出在連外之後的國際段，加速才有意義；出在本地或伺服器端，加速只是在中間多繞一層。
客戶端、訂閱連結與分流規則
訂閱連結匯入是最常見的連線方式：一條連結裡包含節點、協定與部分分流規則，客戶端會定期更新節點列表。要注意，訂閱連結等同於帳號憑證，外洩就等於把線路交給別人使用——不要轉發，不要貼到公開場合，發現異常時在控制面板中重設。帳號層面，VPNCZ 的註冊只需要使用者名稱與密碼，無需電子郵件地址。
平台差異
- Windows 與 macOS：桌面客戶端通常支援處理程序級分流與 TUN 模式，可以把單一遊戲處理程序單獨接管。
- iOS 與 Android：行動端受系統限制，以規則分流為主；在 Wi-Fi 與行動網路之間切換後，要確認連線是否仍然生效。
- Linux：多數以核心或命令列客戶端為主，設定更接近手寫規則，分流規則需要自己維護。
匯入之後先核對三件事
- 遊戲處理程序或對應規則是否已被涵蓋，而不是一律全代理的全域模式。
- UDP 轉發是否開啟，目前協定與客戶端是否支援遊戲所需的承載方式。
- DNS 解析是否走線路，出口地區是否與目標伺服器所在區域一致。
出口 IP、DNS 解析與處理程序接管三項都正確，剩下的差異基本來自線路本身；其中任何一項不對，先修設定，換線路不會有幫助。
現象對照：先處理哪一個
把常見現象與更可能的原因對應起來，可以少走彎路。
| 現象 | 更可能的原因 | 先做什麼 |
|---|---|---|
| 延遲穩定但整體偏高 | 物理距離遠或路由繞行 | 核對出口位置，換線路類型 |
| 延遲忽高忽低 | 鏈路壅塞或無線干擾 | 改有線、避開尖峰、記錄時段規律 |
| 畫面回彈、技能無效 | 掉包，UDP 未走線路或被限速 | 確認 UDP 轉發與處理程序接管 |
| 只有某一個遊戲有問題 | 分流規則未涵蓋該遊戲 | 補規則，或改為依處理程序接管 |
| 顯示已連線但延遲沒變化 | 流量沒有走線路 | 核對出口 IP 與 DNS 解析 |
最後一行最值得留意：客戶端顯示已連線、延遲卻沒有任何變化，多半是流量根本沒有走線路，屬於規則或 DNS 問題，換線路不會有幫助。