雙重 VPN 讓連線先經過兩個 VPN 節點，再前往互聯網；多跳 VPN 是較廣的名稱。額外一跳是否有用，要看保護在哪裏結束、誰營運節點，以及想限制哪種觀察。只數伺服器，不能證明匿名或信任已獨立分散。

關鍵要點：

兩跳描述路徑，不代表統一加密設計。

在明確分層模型中，入口及出口可能有不同可見範圍。

同一機構控制兩部伺服器，不會自動分散機構層面的信任。

額外路徑增加延遲、故障點與診斷複雜度，不能修復終端受侵。

雙重 VPN 是甚麼，多跳又是甚麼意思？

典型兩跳路徑是裝置、入口 VPN 節點、出口 VPN 節點，然後目的地。目的地通常看到該連線最後出口的公網地址。多跳可指多於兩跳，但消費者討論亦常用它描述相同的兩跳概念。

VPN 伺服器鏈描述節點次序，未有交代每條加密隧道的起點與終點。有些設計由客戶端建立內層隧道，再以外層承載；有些則在同一服務控制的節點間轉送流量。簡單直線圖可能相似，節點能接觸的封包內容及目的地資訊卻未必相同。

先讀VPN 完整指南的普通隧道說明，找出第一層邊界，再評估多跳。它不是所有上網任務的必要條件，也不保證加一部機器就令安全倍增。

這張兩跳圖採用甚麼假設？

本文可見性表假設客戶端建立外層加密隧道，在入口結束；另有獨立內層隧道，由客戶端一直到出口。入口轉送仍受保護的內層流量。圖中連線的 DNS 按預期保護路徑處理，瀏覽器對目的地使用 HTTPS。這些是明示假設，不代表所有商業多跳服務。

IPsec 架構提供區分安全關聯與隧道邊界的標準例子，亦討論巢狀安全關聯。它支持端點推理，但不認證任何供應商宣傳的多跳設定。［1］圖示是概念分層模型，不是 IPsec 實作教學。

如果另一種設計先在入口解開客戶端全部 VPN 流量，再向後轉送，入口的存取範圍可能較廣。沒有證據，不能套用本表的入口限制。應查看技術文檔，確認各節點終止甚麼、能處理哪些資訊；宣傳路線圖不足以回答。

在上述假設下，各方能看到甚麼？

參與方	指定模型中可見的資訊	重要限制
本地網絡或接入供應商	你與入口的連線、時間與大小	只靠被動觀察不能讀取內層負載
入口 VPN 節點	你的連接地址、所用出口、時間及大小	內層隧道隱藏受保護的目的地資訊
出口 VPN 節點	入口這個直接網絡對端與後續目的地	移除內層隧道不會移除應用 HTTPS
目標網站	出口地址與它收到的應用數據	登入、Cookie 等識別資料仍可辨認你

這是可見性模型，並非日誌儲存承諾。個別封包處理節點即使視野有限，機構仍可能結合帳戶、管理系統或兩個節點的資料。不同 DNS 處理、繞過隧道的路徑及隧道以外的 App，需要另行分析。

出口可觀察後續網絡目的地，並在 VPN 保護結束後處理流量。HTTPS 仍要保護瀏覽器與網站之間的應用內容。即使有 HTTPS，目的地仍收到你發送的資料，可與已登入帳戶連結。改變公網地址不會抹去這個身份。

加一跳真的分散信任嗎？

至少要分開兩個問題：網絡觀察是否在節點之間分開，以及控制是否在機構之間分開。同一供應商擁有及營運的兩個位置，可以分開實際路徑，卻仍以該供應商為共同信任點。地理距離不證明獨立擁有權，也不證明不會共享資訊。

獨立營運方可能改變信任模型，但也增加管理責任。要了解雙方條款、設定、認證與路由，還要驗證預期的巢狀連線存在，且流量沒有意外繞過某層。單是開啟兩個 App，不能證明條件已成立。

雙方串通，或同一觀察者看到多個位置，都可能破壞預期分離。即使內容加密，時間與流量模式仍可能用作關聯。因此，額外跳點是針對指定觀察者的潛在控制，不是通用匿名屏障。擔心機構信任時，應問誰實際可以合併相關資訊。

獨立付款或不同帳戶亦不能解決全部連結問題。瀏覽器身份、網站帳戶、裝置受侵及操作錯誤仍然相關。可行私隱方案要說明各方取得哪些資訊，以及仍信任哪些人，而不是只計算訂閱數目。

效能與可靠性有甚麼代價？

額外跳點通常增加路徑與處理工作，實際影響取決於路由、負載及實作。節點相距很遠時，可能增加延遲或降低吞吐量。本文沒有實測倍數，也不聲稱某種地理安排必定較好。

故障亦可能有更多負責方：裝置到入口、入口本身、節點間路徑、出口或最終目的地。某層顯示已連線，不表示整條鏈正常。排查要分別觀察受支援客戶端實際提供的各層資料。

有文檔的設定，可與服務支援的普通連線在相似條件下比較。保持裝置、網絡及任務一致，檢查目標 App 是否工作、觀察出口是否符合預期，以及 DNS 和繞行行為是否符合模型。一個出口 IP 結果不能證明全部屬性。

不要為提速關閉強制保安控制，或自行拼接不受支援路由。複雜程度影響可靠使用時，記錄限制，選擇適合任務的受支援方法。組件增加，可能令誤解連線的方式更多，而非帶來原本想取得的保護。

哪些人可能受益，哪些人未必需要？

有具體理由把本地接入觀察與最後出口資訊分開的人，可能受益於有清晰文檔的分層設計。應按相關觀察者及營運方評估；處理敏感工作時，亦要跟隨機構批准的網絡與裝置程序。

一般瀏覽可能已有適合的單跳連線、HTTPS 及裝置安全。加跳點前，先問剩下甚麼問題，設計是否針對它。惡意軟件、網站憑據被盜或不可信目的地，不會因多一部 VPN 伺服器而解決。

權衡 AethoVPN 的日常連線與特殊多跳威脅模型時，應先確定所需連線及想限制的觀察；Tor 與 VPN 比較有助界定選擇。若要求入口與出口由不同營運者管理，選擇前應在服務文件核實這項具體安排；一般連線不能證明支援多跳。

決定要有停止條件。隧道端點、節點控制方或實際 App 路徑未能確定時，保持未確認，不因安排看似更複雜，就把不確定性描述為較強私隱結果。

與 Tor 有何分別？

Tor 中繼設計通常描述客戶端、入口保護節點、中間節點及出口，再連往一般互聯網目的地。Tor Project 一手中繼資料交代這些不同角色。［2］它與訂閱服務下兩個 VPN 閘道有不同系統及信任模型，即使兩者都有多個節點。

Tor Browser 的預期使用亦處理瀏覽器行為，VPN 路由本身不提供這些屬性。反過來，Tor 不會自動保護裝置上所有程式。用Tor 與 VPN 比較按 App 及觀察者匹配工具，不把跳點數目當成互換指標。

Tor over VPN把 VPN 放在 Tor 連線之前，不等於兩個 VPN 跳點。本文只解釋分別，不重複 Tor 設定教學；系統組合產生另一組端點與假設，應另作評估。

總結

解讀兩跳圖前，找出隧道端點。
可見性結論只適用於支持它的模型。
分清節點觀察、機構控制與日誌。
按具體威脅權衡延遲、可靠性及設定複雜度。
HTTPS、裝置安全與瀏覽器身份仍要考慮。

常見問題（FAQ）

雙重 VPN 會把全部數據加密兩次嗎？

不能一概而論。路徑名稱未指定各層起止位置，須先讀實際設計，再聲稱巢狀加密或節點可見性限制。

入口能看到目的地嗎？

本文假設客戶端建立內層隧道，在此模型下受保護目的地對入口隱藏。其他實作可能不同，沒有相符證據不能套用結論。

兩個國家足以分散信任嗎？

不足。地理分離不證明獨立營運，也不阻止同一機構合併資訊；擁有權、控制、記錄與相關觀察者都重要。

多跳可以令我對網站匿名嗎？

不能。網站仍會收到登入、Cookie 等識別資料，額外 VPN 跳點不會移除你主動發送的應用資訊。

第二跳一定令連線較慢嗎？

它增加路徑與處理工作，但測量影響取決於路由及負載。應比較受支援設定，不假設通用速度倍數。

兩個 VPN App 都已連線，證明鏈路正常嗎？

不能。路由與平台行為可能不同於預期巢狀連線，應用有文檔的受支援設定，驗證相關路徑，不能只看兩個連線狀態。

雙重 VPN 等於 Tor over VPN 嗎？

不等於。兩個 VPN 跳點與 VPN 後接 Tor 電路，有不同參與方及假設，要分別評估 App 覆蓋與信任模型。

來源

Sources checked 2026 年 10 月 5 日。

延伸閱讀:

雙重 VPN 與多跳是甚麼：兩跳路徑、信任邊界及取捨