WireGuard 握手成功但沒有資料時，雙方最近已完成身份驗證，卻未能說明測試封包去了哪裏。產生一條受控流量，對照兩端新鮮的傳送與接收增量，就能判斷應檢查本機路由和 peer 選擇、外層路徑、遠端轉送與回程，還是 DNS、MTU 等後續層。

完整 VPN 指南涵蓋全部工作階段。本文只從預期 peer 的 latest handshake 已更新開始。

關鍵要點

目前握手證明 peer 已互相驗證，並不證明某個應用程式流量使用隧道。［1］

只比較同一測試前後的計數增量，不使用混合背景流量的累計值。

本機 TX 不增長，先檢查路由或 peer 選擇；只傳送不接收，代表有單向缺口。

TX、RX 均隨測試增長後，應轉查 DNS、MTU、傳輸或應用層。

不要分享私鑰、PSK、完整設定或原始診斷 dump。

怎樣診斷 WireGuard 握手成功但沒有資料？

WireGuard 握手會在預先知道靜態公鑰的 peer 之間建立新的工作階段密鑰；傳輸數據是握手後的另一類訊息。［1］目前握手是有力的身份及當時可達性證據，但並非通往目標的完整測試。

wg 顯示最近握手與累計傳輸位元組。［2］只有在窄範圍探針前後記錄，這些數字才有定位用途。保活、其他 App 或早前流量可令總數非零，但目前要求可能從未進入隧道。

cryptokey routing 令目的與來源前綴參與 peer 選擇：出站封包按目的位址分配 peer，入站封包則按傳送 peer 的允許來源核實。［3］與 peer A 握手成功，不能證明作業系統沒有把測試包送到另一介面或 peer B。

七步數據路徑檢查

步驟 1：定義一條受控數據探針

選取一個你獲准測試的目的位址及協議，最好是在遠端網絡上有已知預期回應的服務，例如內部閘道位址或受控 Web 端點。記錄準確時間、目的地、位址族、來源介面與預期結果。

不要一開始便用主機名稱。DNS 會引入第二個要求、解析器路由、快取，以及可能多個 IPv4 與 IPv6 結果。先用數字位址，封包路徑正常後才測試名稱。

探針前立即記錄目標 peer 兩端的最近握手時間及 TX/RX 總量。然後只送出一個小型、有邊界的要求，再次記錄相同欄位。不要持續產生流量，因為重疊的探針會令增量難以歸屬。

到此停止：若預期 peer 的最近握手並不新鮮，這是握手或身份問題，而不是本文處理的握手後狀態。可用伺服器回應但握手失敗指南分開可達性與驗證階段。

步驟 2：解讀 TX/RX 增量矩陣

方向以測試發起端的角度標示：「客戶端 TX」指發起端 peer 送出的加密傳輸位元組；「伺服器 RX」指對應 peer 收到的加密位元組。確切位元組數可能包含協議開銷，不必完全相同；要找的是與探針時間及方向吻合的變化。

本次探針的新鮮觀察	首先檢查	原因
客戶端 TX 不增長	路由、來源政策、peer 選擇	探針沒有成為該 peer 的傳輸數據
客戶端 TX 增長，伺服器 RX 不變	外層端點路徑、過期端點、防火牆、NAT 狀態	加密數據已送出但未抵達
伺服器 RX 增長，未見轉送包	來源前綴、本機輸入/轉送、防火牆	WireGuard 收到數據，下一跳失敗
已轉送，沒有回應	目的服務、上游過濾、NAT 或回程	要求離開 peer，回應未返回
回應到伺服器，客戶端 RX 不變	返回 peer、允許來源、外層回程	回應未成為客戶端接收數據
客戶端 TX、RX 均增長	DNS、MTU、TCP/TLS 或應用	加密路徑已有雙向數據

每一行只指出下一個證據邊界，不是最終結論。變更設定前，用同一探針重現兩次。

步驟 3：本機 TX 不變時檢查選擇過程

查詢作業系統為確切目的所選的路由、介面及來源位址。即使介面活躍、peer 剛完成握手，較明確的主表路由、策略規則、本機子網或另一隧道仍可獲選。

再把目的與所有 peer 的 AllowedIPs 對照。重疊項目或意外的窄前綴可選中另一 peer；多 peer 環境應記錄所有可能候選的計數，而不是只看你預期的那一個。

確認 App 沒有綁定到另一介面或位址，而且它所在的網絡命名空間看到的路由與你檢查的一致。容器、虛擬機器、按 App 的 VPN 控制及分流排除項，所見網絡可與主機 shell 不同。

只作一項受支援的路由或 peer 選擇修正。再測同一探針；若選中的介面或計數增量沒有變化，便還原原狀。

步驟 4：數據送出而未到達時檢查外層路徑

最近的握手與遺失的傳輸封包可以同時存在，因為握手後網絡狀態仍可改變，例如遠端漫遊、NAT 映射逾時、流動網絡切換路徑，或防火牆對後續封包採用另一政策。

比較兩端目前記錄的端點與預期工作階段，但不要不必要地公開私人位址。如果是漫遊 peer 發起了最近的握手，對端通常會學到它最新的已驗證端點。［3］網絡切換前的舊觀察並不足夠。

在外層介面使用獲准的封包擷取或防火牆計數，尋找首個缺失方向。不要洩露私鑰，也不要關閉主機防火牆。若新握手立即令數據抵達，這個時間關係較支持路徑狀態問題，而不是密鑰不符。

步驟 5：遠端收到數據後追蹤內層封包

伺服器 RX 增長後，先判斷內層目的在伺服器本身還是其後網絡。本機服務要核對監聽位址、連接埠、位址族及輸入規則；後方目的要核對 IP 轉送、轉送防火牆及出口介面。

然後確認回應如何返回客戶端前綴。NAT 設計需要範圍準確的轉換與狀態；路由設計需要上游知道 WireGuard 客戶端網絡。目的若是另一 WireGuard peer，伺服器的雙向映射必須清晰。

不要自動加入寬泛 NAT。這可以令單一探針工作，卻掩蓋錯誤拓撲。計數指向互聯網閘道後，可用已連線但無法上網清單檢查 DNS、雙棧與完整回程。

步驟 6：雙向數據增長後離開握手層

客戶端 TX、RX 隨探針一起增長，表示加密傳輸數據已雙向移動。用戶操作仍失敗時，應停止輪換密鑰或修改 peer 身份，轉而測試下一層。

先比較數字位址與名稱，再比較小型要求和較大回應，並分開測試 IPv4、IPv6。小型雙向數據成功而大型傳輸停頓，符合 WireGuard MTU 問題；只有名稱失敗則指向解析器。TCP reset、TLS alert、HTTP 錯誤或 App 驗證回應，也證明隧道已把要求送到後續層。

App 逾時需要作關聯。確認 TX/RX 增長屬於本次要求，而不是保活或背景程式。需要時暫停無關流量，使用獨特目的與短時間窗。

步驟 7：保存證據並還原初始狀態

記錄原有握手時間、四組計數快照、路由結果、端點觀察，以及證據首次消失的位置。只保留真正移動缺口且符合設計的最小修正。

移除臨時路由、防火牆規則、數據產生器及測試服務。持久 peer 映射有變時，應核對管理真源，避免重新啟動後恢復故障。不要提交 wg show all dump；它可洩露公開身份、端點、允許前綴及 PSK 狀態。

若目前握手存在但仍懷疑身份設定，先確認該握手實際使用哪一 peer 與密鑰代次。密鑰不符指南提供安全的公鑰對照；沉默或計數缺口本身不能判定錯誤一方。

第二條隧道能否用作對照測試？

當你自己的 peer 能完成握手卻傳不了任何數據時，在同一部裝置上再建立一條獨立隧道，是區分裝置問題和 peer 問題的低成本方法。先中斷你自己的 peer，再安裝 AethoVPN，連接推薦位置，並讓真實數據通過它，例如載入一個網頁或下載一個小檔案：如果傳輸成功，即表示裝置和接入網絡能承載隧道流量，下一個要查的便是你的 peer 的 AllowedIPs、轉發或回程路由。AethoVPN 顯示的是連線狀態，而不是原始 peer 計數或封包擷取，所以 TX/RX 增量比較仍要在你自己的伺服器上完成。比較之前可先用電郵開始 3 日免費試用。

總結

只在預期 peer 最近握手已更新時使用本流程。
圍繞一個數字位址探針比較新鮮 TX/RX 增量。
客戶端 TX 不變指向選路；單向增量可找出缺失方向。
伺服器 RX 增長後，再分開本機服務、轉送、NAT 與回程。
雙向計數增長後應改查 DNS、MTU、傳輸或應用層，而不是握手。
保存範圍最窄的證據、移除實驗改動，切勿分享秘密資料。

常見問題

最近握手能否證明 AllowedIPs 正確？

不能。雙方可以完成身份驗證，但測試目標仍可能選用其他路由或 peer，接收端亦可能不允許該內層來源位址。

測試失敗時為何累計傳輸量仍非零？

累計值可能來自舊工作階段、保活或其他流量。應在一次受控要求前後記錄兩端 TX/RX，只比較該時窗的增量。

網絡路徑改變後，握手仍可顯示為最近嗎？

可以。路徑、端點或 NAT 映射可能在上次交換後改變。把外層介面和端點證據與今次失敗探針對齊。

客戶端 TX 增長而伺服器 RX 不變代表甚麼？

本機 peer 已產生加密傳輸數據，但遠端在該時窗沒有記錄接收。下一步檢查外層端點路徑和過濾。

伺服器 RX 增長但目標沒有收到數據，怎樣處理？

檢查內層來源位址、本機輸入與轉送、防火牆、轉送狀態和出口選擇。加密數據已到達，故障點已越過握手層。

TX 與 RX 都雙向增長時應否輪換密鑰？

不應。雙向增量證明目前 peer 關係可承載該探針，應轉查 DNS、封包大小、傳輸或應用行為。

保活足以證明應用數據正常嗎？

不足夠。保活只維持狀態，不會驗證目標、回應大小、DNS 查詢或應用協議。應另發一條有邊界的要求。

免責聲明：本文只提供一般技術疑難排解資訊。只檢查你獲准管理的系統及流量，盡量減少擷取的數據，切勿洩露私鑰或預共享密鑰。

來源：

WireGuard, "Protocol & Cryptography": https://www.wireguard.com/protocol/
WireGuard Tools, "wg(8)": https://git.zx2c4.com/wireguard-tools/tree/src/man/wg.8
WireGuard, "WireGuard: Next Generation Kernel Network Tunnel": https://www.wireguard.com/papers/wireguard.pdf

Sources checked 2026 年 9 月 12 日。

延伸閱讀：

WireGuard 握手成功但沒有資料：收發增量、節點與回程排查