為什麼 VPN 會拖慢連線？慢多少才算正常

一開 VPN，網頁就變得沉重，影片一直緩衝，通話也開始斷斷續續。這是正常現象，還是哪裡出了問題？多少會變慢是預期中的事，因為 VPN 確實改變了路徑，也改變了封包。但如果速度大幅下降，通常是某個特定原因造成的——最常見的是伺服器太遠或負載過重——而不是「VPN 這個概念」本身有問題。以下說明四大成因，以及如何量測你實際損失了多少。

重點摘要

• 拖慢 VPN 連線的因素有四個： 經由 VPN 伺服器繞遠路、每個封包多出的標頭開銷、你的裝置或路由器上的加密運算，以及伺服器及其上游的負載。
• 不存在放諸所有 VPN 皆準的「正常」百分比。 任何一個宣稱適用於所有 VPN 的數字都是編造的；你的損失取決於伺服器、協定、裝置與電信業者。
• 延遲與吞吐量是兩種不同的損失。 距離主要影響延遲；額外開銷、CPU 與伺服器負載主要影響吞吐量。
• 自己量測： 使用同一個測速伺服器，分別在關閉與開啟 VPN 的情況下各測數次，並分開比較延遲與吞吐量。
• VPN 改變的是你的 IP，而不是瀏覽器指紋——而且有些網站可能因此對你起疑。

1. 額外的距離：繞經 VPN 伺服器的路程

沒有 VPN 時，封包會依電信業者選擇的路由，從你的裝置直接送到網站。使用 VPN 時，封包要先到 VPN 伺服器，再轉往網站，回應也沿原路返回。如果伺服器位在另一個國家，這段繞路會增加往返時間，這是任何軟體都無法消除的：光纖中的訊號傳播速度有限，所以距離決定了延遲的下限。

這個影響比大家預期的更大，因為單一連線的吞吐量也取決於延遲。TCP 連線在必須等待確認之前，能同時在途中的資料量有限，所以往返時間越長，同樣的頻寬所能達到的單連線速度就越低。在同一個方案下，近處的伺服器往往比遠處的快得多。

2. 封裝開銷與 MTU 問題

隧道會把你的每個封包包進另一個封包裡。這層外殼——新的 IP 標頭、UDP 或 TCP 標頭，以及 VPN 協定本身的標頭與驗證資料——會佔用空間，所以每個封包能攜帶的實際資料就少了一點。在正常的環境下，這對速度的影響通常不大。

更棘手的是 MTU（最大傳輸單元，也就是一條連結所能承載的最大封包）。一般乙太網路路徑通常允許 1500 位元組，但隧道的外殼也得塞在這個大小之內，所以隧道內可用的大小會更小。如果封包太大，就必須被分片或直接丟棄。RFC 4459 說明了網路內隧道所帶來的這類 MTU 與分片問題。當路徑上的某台設備默默丟棄過大的封包，而發送端始終沒有收到通知時，連線就可能卡住或慢得像在爬：小請求正常，大量傳輸卻停擺，有些網站只載入一半。這就是典型的「黑洞」故障。

現代的網路堆疊會嘗試自動找出可用的大小。RFC 8899 定義了封包化層路徑 MTU 探索（PLPMTUD），它會主動探測實際能通過的最大尺寸，而不是依賴常被防火牆擋掉的錯誤訊息。若想以淺顯的方式了解路徑 MTU 探索在實務上如何運作又如何失靈，可以參考 Cloudflare 的說明文章。如果 VPN 只在特定網站或大檔案下載時異常緩慢，MTU 設定過高是典型的嫌疑犯，在用戶端把隧道 MTU 調低是常見的解法。

隧道本身跑在哪種傳輸協定上也有影響。多數現代 VPN 協定，例如 WireGuard 以及預設 UDP 模式的 OpenVPN，都是透過 UDP 承載你的流量。有些用戶端為了穿越嚴格的防火牆會改用 TCP 模式，這時你自己的 TCP 連線就跑在另一條 TCP 連線裡面。一旦掉封包，內外兩層會同時重傳、同時降速，少量遺失也可能被放大成明顯的卡頓。如果用戶端可以選擇，UDP 通常比較快。

3. 加密會消耗 CPU

每個封包在送出前要加密，收到時要解密。在現代筆電或手機上這成本很低，許多 CPU 也對常見的加密演算法提供硬體加速。但在老舊手機、自己執行 VPN 用戶端的低功耗路由器，或忙碌的單核心裝置上，密碼運算可能成為瓶頸，把吞吐量壓得遠低於你的線路速度。一個明顯的徵兆是：傳輸期間 CPU 使用率飆高，而且即使連到近處的伺服器，速度也始終追不上方案的標稱速率。

4. 伺服器負載與業者的上游線路

VPN 伺服器是共享的。如果同時有很多人使用，或它連往廣域網際網路的線路壅塞，你就只能分到剩下的部分。業者自己到目的地的路由也很重要：一台離你很近、但與你要連的網站之間連線品質很差的伺服器，仍然可能很慢。這就是為什麼換一台不同的伺服器，即使在同一座城市，速度有時也會大幅改變。

慢多少才算正常？

對任何通用的數字都要保持懷疑。對你來說什麼是正常的，幾分鐘內就能量出來：

1. 選定一種測試並保持不變。 使用同一個測速伺服器、同一台裝置、同一個網路，讓唯一的變數是 VPN。
2. 先關閉 VPN 測一次，再開啟 VPN 測一次。 使用 BrowserInsight 的網路測速，它能直接在瀏覽器中回報下載、上傳、延遲與抖動。每種狀態至少跑三次；單次結果只是快照，不是定論（請參閱為什麼測速結果總是不一樣）。
3. 分開比較延遲與吞吐量。 延遲變高但下載速度相近，指向距離問題。下載速度大幅下降但延遲變化不大，則指向額外開銷、CPU 或伺服器負載。M-Lab 開放的 NDT 測試是另一個可以獨立交叉驗證吞吐量的方式。
4. 一次只改一個變數。 先試試更近的伺服器，再換不同的協定（或把 TCP 模式改成 UDP），然後調低 MTU。每次調整後都重新測試。

如果你不確定這些數字代表什麼，網路速度指標詳解介紹了頻寬、延遲與抖動，而上傳與下載速度則說明了為什麼兩個方向的速度常常不同，所以要分開比較。如果通話只在別人也在使用網路時才變差，那很可能根本不是 VPN 的問題，而是緩衝區膨脹；如果是時斷時續而不是單純變慢，請參閱抖動與封包遺失。

也要了解測速能告訴你什麼、不能告訴你什麼。它量測的是你的瀏覽器到本站邊緣節點之間的路徑，所以能顯示你在開啟與關閉 VPN 時的連線速度。它無法偵測你是否使用 VPN，也不會量測你的 MTU。

VPN 有可能讓網路變快嗎？

偶爾會。如果你的電信業者對某些流量限速，或它到目的地的預設路由品質很差，隧道可以繞過這個問題，結果反而可能改善。這是有可能的，但並不常見，只有在你自己的前後對照測試顯示如此時才值得相信。

關於隱私的提醒

VPN 改變的是網站看到的 IP 位址；它不會改變你的瀏覽器指紋，而且有些網站會對 VPN 位址抱持懷疑。想了解各種工具實際隱藏了什麼，請參閱隱私工具比較；想知道網站如何辨識 VPN 流量，請參閱網站如何偵測 VPN。若要查看連線後網站看到的是什麼，可以執行 VPN 檢測。

常見問題

我的 VPN 為什麼突然變得這麼慢？

多數突然的變化都來自伺服器：它變得擁擠，或其上游線路壅塞。先改連另一台伺服器，並重新跑一次前後對照測試，再去調整其他設定。

VPN 一定會降低速度嗎？

通常會增加一些延遲，因為路徑變長了。吞吐量的損失在近處、負載輕的伺服器上可能很小，在遠處或超載的伺服器上則可能很大。

為什麼小網頁能載入，大檔案下載卻卡住？

這種現象通常指向 MTU 問題：小封包能通過，大封包被丟棄。試著調低隧道的 MTU 設定。

搭配 VPN 時，有線連線會比較好嗎？

有線連線可以排除 Wi-Fi 的不穩定因素，讓你的 VPN 對照測試更乾淨，但它無法解決伺服器太遠的問題。

結論

VPN 會拖慢速度有四個原因：距離、隧道開銷、加密運算與伺服器負載。慢多少取決於你的環境，所以請在關閉與開啟 VPN 的情況下各量測一次，並將延遲與吞吐量分開看。接著一次只改一個地方——通常先從換伺服器開始。