自 2025 年 3 月 27 日起，我們建議您使用 android-latest-release 而非 aosp-main 建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
改善 VPN 使用者體驗
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本頁面提供網路運營商的指南，確保消費者和企業虛擬私人網路 (VPN) 應用程式可在其網路中提供良好的使用者體驗。Android 提供 VpnManager 類別，供開發人員建立 VPN 解決方案，供消費者和企業用於加密通訊內容或將通訊轉送至其他網路。
我們建議聯播網營運商遵循下列規範：
- 在網路上支援 IPv6 封裝安全酬載 (ESP) 通訊協定 (下一個標頭 50) 封包，確保這類流量的效能與使用者資料包通訊協定 (UDP) 或傳輸控制通訊協定 (TCP) 連線相近。ESP 工作階段應允許傳入裝置，或設為超長逾時時間，並以線路速率轉送。
- 設定網路位址轉譯 (NAT) 和有狀態防火牆逾時值，讓通訊埠 4500 上的 UDP 連線至少有 600 秒的逾時值，確保 VPN 解決方案可維持可靠的連線，且不會產生過高的電力成本。
封裝安全酬載 (ESP) 是封包格式，定義為網際網路通訊協定安全性 (IPSec) 通訊協定組合的一部分，用於在 VPN 解決方案中加密及驗證封包。Android 作業系統會在內建 VPN 解決方案中實作這個標準安全性通訊協定。
在支援 IPv6 的網路中，ESP 封包會直接透過 IPv6 封包傳送，且下一個標頭欄位為 50。如果網路無法正確支援這類封包，可能會導致 VPN 解決方案無法連線，因為這些解決方案旨在使用此通訊協定，而不會進一步封裝封包。網路可能會因防火牆設定而捨棄這些封包。或者，ESP 封包可能會遇到網路上的低速路徑，導致傳輸量效能嚴重降低，相較於 TCP 或 UDP 連線更為嚴重。
網際網路工程任務組 (IETF) 建議允許消費者網際網路存取服務使用的防火牆允許 IPsec。例如，請參閱 RFC 6092 的 3.2.4 節。防火牆可安全地允許 ESP 封包雙向傳輸，因為如果裝置收到的 ESP 封包並非現有安全關聯的一部分，裝置會捨棄該封包。因此，裝置不需要傳送保活封包來維持 VPN 連線，進而延長電池續航力。建議網路應隨時允許 ESP 封包傳送至裝置，或是在 ESP 工作階段長時間閒置 (例如 30 分鐘) 後才逾時。
我們建議網路業者在網路上支援 ESP 通訊協定封包 (下一個標頭為 50 的 IPv6 封包)，並以線路速率在硬體中轉送這些封包。這可確保 VPN 解決方案不會發生連線問題，並提供與 UDP 或 TCP 連線相近的效能。
設定足夠的 NAT 和 stateful 防火牆逾時時間
為維持連線可靠性，VPN 解決方案必須與提供傳出和傳入連線的 VPN 伺服器維持長時間連線 (例如接收推播通知、即時通訊訊息和音訊或視訊通話)。如 RFC 3948 所述，大多數 IPsec VPN 應用程式都會使用封裝在 IPv4 UDP 封包中的 ESP，其目的地通訊埠為 4500。
為了維持這項連線，裝置需要定期傳送封包至伺服器。這些封包的傳送頻率必須高於網路作業員設定的 NAT 和防火牆逾時時間。頻繁的保留機制會耗費大量用戶端端的電力，並對電池續航力造成重大影響。即使裝置處於閒置狀態，也會在網路上產生大量信號流量。
我們建議作業系統提高 NAT 和有狀態防火牆的逾時時間，以免影響電池續航力。IPsec UDP 封裝 (連接埠 4500) 的建議逾時時間為 600 秒以上。
在行動網路中，由於 IPv4 位址短缺，導致通訊埠重複使用因素偏高，因此 UDP NAT 逾時時間通常會維持在較低的程度。不過，建立 VPN 後，裝置網路不需要支援長時間 TCP 連線，例如用於傳送內送通知的連線。因此，在 VPN 執行時，網路需要支援的長效連線數量與未執行 VPN 時相同或更少。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間：2025-07-27 (世界標準時間)。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["缺少我需要的資訊","missingTheInformationINeed","thumb-down"],["過於複雜/步驟過多","tooComplicatedTooManySteps","thumb-down"],["過時","outOfDate","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["示例/程式碼問題","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-07-27 (世界標準時間)。"],[],[],null,["# Improve VPN user experience\n\nThis page provides guidelines for network operators to ensure that consumer and\nenterprise virtual private network (VPN) apps provide a good end-user experience\nin their networks. Android provides the\n[`VpnManager`](https://developer.android.com/reference/android/net/VpnManager)\nclass for developers to create VPN solutions, which are used by consumers and\nenterprises to encrypt their communications or route them to different networks.\n\nWe recommend network operators follow these guidelines:\n\n- **Support IPv6 Encapsulating Security Payload (ESP) protocol (Next Header\n 50) packets on your network**, ensuring this traffic has comparable performance to user datagram protocol (UDP) or transmission control protocol (TCP) connections. ESP sessions should be allowed inbound to devices, or set to very high timeouts, and forwarded at line rate.\n- **Set network address translation (NAT) and stateful firewall timeouts** that are a minimum of 600 seconds for UDP connections on port 4500 to ensure VPN solutions can maintain reliable connectivity without incurring excessive power costs.\n\nSupport IPv6 ESP protocol (Next Header 50) packets\n--------------------------------------------------\n\nEncapsulating Security Payload (ESP) is the packet format defined as part of the\nInternet Protocol Security (IPSec) set of protocols to encrypt and authenticate\npackets in a VPN solution. The Android OS implements this standard security\nprotocol in its built-in VPN solution.\n\nOn IPv6-capable networks, ESP packets are carried directly in IPv6 packets with\na Next Header field of 50. If a network doesn't properly support these types of\npackets, it can cause a lack of connectivity for VPN solutions that aim to use\nthis protocol without further encapsulation of the packets. The network might\ndrop these packets due to firewall configuration. Or ESP packets might\nhit slow paths on the network, with severely degraded throughput performance\ncompared to TCP or UDP connections.\n\nThe Internet Engineering Task Force (IETF) recommends allowing IPsec through\nfirewalls used by consumer internet access services. For example, see\n[RFC 6092 section 3.2.4](https://www.rfc-editor.org/rfc/rfc6092.html#section-3.2.4).\nESP packets can be safely allowed through firewalls in both directions because\nif a device receives an ESP packet that isn't part of an existing security\nassociation, the device drops the packet. As a result, the device doesn't need\nto send keepalive packets to maintain VPN connectivity, which saves battery\nlife. We recommend that networks either allow ESP packets to devices at all\ntimes, or time out ESP sessions only after long periods of inactivity (for\nexample, 30 minutes).\n\nWe recommend network operators support ESP protocol packets (IPv6 packets with a\nNext Header of 50) on their networks and forward those packets in hardware at\nline rate. This ensures VPN solutions don't encounter connectivity issues and\nprovide performance comparable to UDP or TCP connections.\n\nSet sufficient NAT and stateful firewall timeouts\n-------------------------------------------------\n\nTo maintain connection reliability, a VPN solution needs to maintain a\nlong-lived connection to the VPN server that provides outbound and inbound\nconnectivity (for example, to receive incoming push notifications, chat\nmessages, and audio or video calls). Most IPsec VPN apps use ESP encapsulated in\nIPv4 UDP packets with destination port 4500, as described in\n[RFC 3948](https://www.rfc-editor.org/rfc/rfc3948.html).\n\nTo maintain this connection, the device needs to periodically send packets to\nthe server. These packets must be sent at a higher frequency than the NAT and\nfirewall timeouts imposed by the network operator. Frequent keepalives are power\nintensive on the client side, and have a major impact on battery life. They also\ngenerate substantial signaling traffic on the network, even if the device is\notherwise idle.\n\nWe recommend that operators raise NAT and stateful firewall timeouts high enough\nto avoid battery impact. The recommended timeout for IPsec UDP encapsulation\n(port 4500) is 600 seconds or greater.\n\nIn mobile networks, UDP NAT timeouts are often kept low because IPv4 address\nscarcity imposes high port reuse factors. However, when a VPN is established,\nthe device network doesn't need to support long-lived TCP connections, such as\nthose used to deliver inbound notifications. So the number of long-lived\nconnections that the network needs to support is the same or lower when a VPN is\nrunning compared to when a VPN isn't running."]]
