WireGuard 中的 PersistentKeepalive 有甚麼作用？

WireGuard PersistentKeepalive 在某個 peer 達到出站閒置間隔後傳送驗證空封包，用來維持 NAT 或狀態防火牆映射，讓其後的 peer 閒置時仍可達。它不偵測互聯網健康、不修復斷路，亦不保證 App 連線連續。

VPN 完整指南解釋整條受保護路徑。本文只說明這個按 peer 設定的可選計時器，讓你判斷閒置連線是否需要它。

關鍵要點

• PersistentKeepalive 預設關閉，並為每個 peer 分別設定。
• 只有出站方向達到閒置間隔時，它才傳送不含應用程式負載的驗證封包。
• 它用來更新 NAT 或狀態防火牆狀態，並非隧道健康檢查。
• 25 秒是官方常用例子，不是所有網絡必須採用的固定值。
• 通常由需要在 NAT 後維持可達的 peer 傳送；到處開啟只會增加流量及裝置喚醒。

WireGuard PersistentKeepalive 是甚麼

wg(8) 把 PersistentKeepalive 定義為 1 至 65,535 秒的可選間隔。若達到間隔仍未向該 peer 傳送流量，WireGuard 便會送出驗證空封包。零或 off 會停用它，而且預設關閉。［1］

「驗證」表示封包屬於既有 peer 關係並經正常密碼學處理；「空」表示沒有隧道 App 負載，外層仍是帶協議開銷的 UDP 數據報。因此 App 未產生資料時，封包擷取仍會看到少量流量。

設定屬於個別 peer，並非介面共用的全域心跳。同一裝置可能只須向一個遠端保活，對穩定公網 peer 則不需要。間隔由設定方決定，遠端不能命令其採用某個週期。

這種區分亦符合VPN 協議比較的分層：WireGuard 處理加密 UDP 隧道及 peer 狀態，作業系統、接入網絡和應用程式仍有各自的計時器與失效行為。

為何閒置 NAT 與防火牆狀態會到期？

不少客戶端位於路由器後方。路由器把私有來源地址及連接埠轉成臨時公網映射；狀態防火牆也保留記錄，以准許相符的 UDP 回程封包。裝置無法永久保存不活躍資料流，會按實作和政策在閒置後刪除狀態。

家中 peer 先向伺服器送出封包時，路由器建立映射，伺服器便可回覆。若雙方在映射到期前沒有足夠流量，伺服器稍後主動傳來的封包或不再符合有效狀態。它雖記得上次的外層地址，但該地址與連接埠已不是可用回程路徑。

WireGuard 白皮書指出：當 NAT 或狀態防火牆後的 peer 必須在閒置期間維持可達，keepalive 封包便有用。文件同時說明大部分 peer 應避免使用，因為 WireGuard 本來會在沒有資料時保持安靜。［2］靜默可節省頻寬，亦讓流動裝置更充分休眠。

圖例：1 是邊緣裝置後方保持安靜的 peer；2 是臨時 NAT 或狀態防火牆映射；3 是其後可能要主動回傳資料的遠端 peer；4 是閒置間隔完結後，用來更新映射的驗證 UDP 空封包。箭嘴只表示數據報方向，並非健康檢查回應。

為何普通流量可能已經足夠

每個有效 WireGuard 出站封包都能更新網絡狀態。通話、檔案傳送或頻密請求可能毋須保活便能維持映射。只有隧道靜默後仍須接收遠端流量時，計時器才有價值。

「隧道全日有流量」與「閒置 peer 全日可達」是兩種要求。應測試閒置情況，不要因週期封包看似通用可靠性開關便啟用它。

為何常見值是 25 秒但並非必須？

手冊及官方快速入門均以 25 秒作為維持多種 NAT、防火牆映射的合理例子。［1］［2］這個值短於常見 UDP 閒置逾時，但並非協議常數。WireGuard 接受其他非零間隔，實際網絡亦可能更早或更遲清除狀態。

間隔越短，數據報與裝置喚醒越多；越長則可能讓中間裝置先刪除映射。合適值應低於實際閒置逾時並留有餘量；不同網絡裝置的時限可能不同。

不要從 ping 延遲推算間隔。來回時間只反映路徑正常時封包需時多久，無法指出中間裝置保留閒置 UDP 映射多久。同樣，把設定縮短至一秒也不會令被封鎖或路由錯誤的路徑恢復。

情況	通常如何設定	原因
公網可達的伺服器	通常關閉	已能接收新的驗證起始封包
只主動發起流量的 NAT 後客戶端	通常關閉	新出站流量會按需要重建狀態
閒置後仍須接收資料的 NAT 後客戶端	通常有用	週期出站封包可維持回程映射
持續雙向傳送的隧道	通常不需要	現有流量會更新狀態
路徑封鎖 UDP	無法補救	增加 UDP 封包不會解除封鎖

PersistentKeepalive 不會做甚麼

PersistentKeepalive 不是要求遠端回答的 echo request。傳送方不能只因已送出封包便判定連線「健康」。最近握手時間與傳送計數可提供線索，但保活封包本身不是完整存活協議，也不驗證 DNS、路由、互聯網接入或應用程式是否可達。

它亦不負責選擇遠端地址。Endpoint 說明處理外層 IP 或主機名稱與 UDP 連接埠。保活同樣不決定哪個內層目的地屬於哪個 peer；那是 AllowedIPs 以及獨立系統路由的工作。

裝置由 Wi-Fi 轉到流動網絡後，新路徑及來源映射須透過驗證流量讓遠端學習，這屬於 WireGuard 漫遊。保活可能較早觸發有用流量或維持現有 NAT 條目，卻不定義 peer 身份或漫遊規則。

有效的 WireGuard 隧道亦不代表每個應用程式都能連續運作。TCP 工作階段、即時媒體、DNS 快取、登入門戶、作業系統休眠及 App 重試策略，均可在外層路徑轉變時獨立反應。

應由哪一方傳送

先確認可達性要求。如果 NAT 後的 peer 必須接收遠端主動發起的流量，便在 NAT 後一方設定保活。它送出的封包會更新回程資料所需狀態。只讓公網伺服器週期傳送，未必能重建私網一方已消失的映射。

若兩個 peer 均可隨時主動發出驗證流量，而閒置時無須接收新流量，便保留預設關閉。若兩方各自在 NAT 後，至少仍要有一方知道另一方可用的初始 Endpoint；雙方都無法定址時，週期流量不能憑空建立路徑。

wg-quick(8) 可按 AllowedIPs 推導作業系統路由，但此自動化與保活計時器無關。［3］路由可以存在而 NAT 映射已陳舊，映射亦可有效但系統選錯路由。排查時要逐層分開。

想了解託管客戶端在閒置後的表現，可以在位於同一 NAT 後的手機上連接 AethoVPN，讓它閒置到足以令你自己的 peer 斷線的時間，然後載入一個頁面，記錄它是立即恢復、重新連線，還是需要手動重試。再換一個位置重做一次，以免單一繁忙伺服器影響結論。該產品沒有文件說明 keepalive 設定，也不承諾連線零中斷，所以要記錄客戶端的實際表現，而不是假定有 25 秒的間隔。可用電郵開始免費試用來做閒置測試。

如何判斷是否真正的保活問題

先比較活躍與閒置表現。如果持續傳送一直正常，但安靜到一個相當固定的時間後，遠端便無法聯絡客戶端，狀態到期才是合理原因。記錄該時間，並觀察由客戶端主動送出一個新封包後，通訊是否立即恢復。

然後分開核對證據：

1. 確認 peer 能在目前路徑完成驗證握手。
2. 確認目標內層地址連到正確的 peer 及路由。
3. 觀察閒置後客戶端出站資料能否恢復可達性。
4. 測試低於故障窗口的保守非零間隔。
5. 比較傳送計數與封包，不把「已傳送」當成「已回覆」。

若隧道在持續傳送時也失效，原因通常不是閒置映射。此時應檢查 Endpoint 可達性、UDP 政策、密鑰、時間、路由、MTU 或應用程式行為。窄用途計時器不應掩蓋更廣的故障。

總結

• PersistentKeepalive 在出站方向閒置達到間隔後傳送驗證空封包。
• 它保留 NAT 或狀態防火牆狀態，讓指定 peer 繼續可達。
• 預設關閉；持續活躍或只須主動發起的 peer 通常不需要。
• 25 秒是官方例子，不是所有網絡的最佳值。
• 它不檢查健康、不選擇路由、不學習身份，也不保證 App 連續運作。

常見問題

PersistentKeepalive 會傳送應用程式資料嗎？

不會。它送出不含隧道應用程式負載的驗證 WireGuard 封包，但仍消耗少量流量及處理資源。

PersistentKeepalive 預設開啟嗎？

不會。零或 off 代表關閉，而且這是預設。只有明確需要閒置可達時才設定非零的逐 peer 間隔。

為甚麼例子常用 25 秒？

這是一個實用間隔，目標是低於不少 NAT 及狀態防火牆的 UDP 閒置逾時；它不是協議常數，也不保證適合每個網絡。

兩個 WireGuard peer 都要開啟嗎？

通常不用。典型傳送方是必須保持可達的 NAT 後 peer。只有兩個方向各有已驗證需要時，才考慮雙方設定。

保活封包能證明 peer 在線嗎？

不能。送出封包只證明本機嘗試傳送。要配合握手時間、計數器、日誌及受控流量判斷實際可達性。

PersistentKeepalive 能修復 UDP 被封鎖嗎？

不能。若 UDP 被封鎖、Endpoint 錯誤或路由損壞，週期傳送更多 UDP 封包不會修正底層條件。

PersistentKeepalive 能令漫遊完全無縫嗎？

不能。驗證封包可在地址改變後觸發 Endpoint 學習；保活可以維持或啟動路徑，但 App 工作階段及系統切換有各自連續性規則。

來源：

1. WireGuard Tools, wg(8): https://git.zx2c4.com/wireguard-tools/about/src/man/wg.8
2. WireGuard, “WireGuard: Next Generation Kernel Network Tunnel”: https://www.wireguard.com/papers/wireguard.pdf
3. WireGuard Tools, wg-quick(8): https://git.zx2c4.com/wireguard-tools/about/src/man/wg-quick.8

Sources checked 2026 年 9 月 12 日。

---

延伸閱讀：

• 理解完整 VPN 路徑
• 比較主要 VPN 協議設計
• 排查 VPN 在裝置喚醒後失效
• 分清 WireGuard Endpoint 與隧道路由