自 2025 年 3 月 27 日起，我们建议您使用 android-latest-release 而非 aosp-main 构建 AOSP 并为其做出贡献。如需了解详情，请参阅 AOSP 的变更。
改进 VPN 用户体验
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
本页面为网络运营商提供了一些准则，以确保消费者和企业虚拟专用网 (VPN) 应用在他们的网络中提供良好的最终用户体验。Android 为开发者提供了 VpnManager 类来创建 VPN 解决方案，供消费者和企业用于加密其通信或将其路由到不同的网络。
我们建议网络运营商遵循以下准则：
- 支持您网络中的 IPv6 封装安全载荷 (ESP) 协议（Next Header 为 50）数据包，确保此流量的性能与用户数据报协议 (UDP) 或传输控制协议 (TCP) 连接相当。ESP 会话应设置为允许入站到设备，或设置为非常高的超时，并以线路速率转发。
- 设置网络地址转换 (NAT) 和有状态防火墙超时（端口 4500 上的 UDP 连接至少为 600 秒时间），确保 VPN 解决方案可以保持可靠的连接，且不会产生过多的电源费用。
封装安全载荷 (ESP) 是在互联网协议安全 (IPSec) 协议集中定义的数据包格式，用于对 VPN 解决方案中的数据包进行加密和身份验证。Android OS 在其内置 VPN 解决方案中实现了此标准安全协议。
在支持 IPv6 的网络上，ESP 数据包会直接传送到“Next Header”字段为 50 的 IPv6 数据包中。如果网络不能正确支持这些类型的数据包，就可能导致旨在使用此协议而不会进一步封装数据包的 VPN 解决方案无法连接。网络可能会因防火墙配置而丢弃这些数据包。或者，ESP 数据包可能会在网络上遇到缓慢路径，吞吐量性能与 TCP 或 UDP 连接相比大大降低。
互联网工程任务组 (IETF) 建议允许消费者互联网访问服务使用的防火墙使用 IPsec。例如，请参阅 RFC 6092 第 3.2.4 节。ESP 数据包可以安全地允许从两个方向通过防火墙，因为如果设备收到的 ESP 数据包不属于现有安全关联，则设备会丢弃该数据包。因此，设备无需发送 keepalive 数据包即可维护 VPN 连接，从而节省电池电量。我们建议网络始终允许将 ESP 数据包发送到设备，或者仅在长期处于不活动状态（例如 30 分钟）后将 ESP 会话超时。
我们建议网络运营商在其网络上支持 ESP 协议数据包（Next Header 为 50 的 IPv6 数据包），并在硬件中将这些数据包以线路速率转发。这样可确保 VPN 解决方案不会遇到连接问题，并且可以提供与 UDP 或 TCP 连接相当的性能。
设置足够的 NAT 和有状态防火墙超时时间
为了保持连接可靠性，VPN 解决方案需要与 VPN 服务器建立长期有效的连接，以便提供出站和入站连接（例如，接收传入的推送通知、聊天消息和音频/视频通话）。大多数 IPsec VPN 应用都使用封装在目标端口为 4500 的 IPv4 UDP 数据包中的 ESP，如 RFC 3948 中所述。
为了保持这种连接，设备需要定期向服务器发送数据包。这些数据包的发送频率必须高于网络运营商规定的 NAT 和防火墙超时频率。频繁的 keepalive 在客户端非常耗电，对电池续航时间有重大影响。它们还会在网络上产生大量信号流量，即使设备原本就处于空闲状态也是如此。
我们建议运营商将 NAT 和有状态防火墙超时设置得足够高，避免对电池造成影响。IPsec UDP 封装（端口 4500）的建议超时时间为 600 秒或更长。
在移动网络中，UDP NAT 超时通常保持很低，因为 IPv4 地址不足会导致端口重用率较高。不过，建立 VPN 后，设备网络无需支持长期有效的 TCP 连接，例如用于传送入站通知的 TCP 连接。因此，与 VPN 未运行相比，当 VPN 正在运行时，网络需要支持的长期连接数相同或更少。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC)：2025-03-26。
[null,null,["最后更新时间 (UTC)：2025-03-26。"],[],[],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."]]
