VpnHood 工作原理

VpnHood 应用将设备流量导入加密隧道并传送到您的服务器，再由服务器转发至互联网。本文将带您了解流量传输的全过程。

在设备端

应用通过系统分配给 VPN 应用的虚拟网卡捕获设备流量。支持传输三种流量类型：TCP、UDP 和 Ping。其他类型的数据包将被自动丢弃。

分流同样在设备端完成。用户排除的流量（按应用、国家、域名或 IP 地址）将直连互联网，绝不经过您的服务器。详情请查看分流功能说明。

应用还会自动配置设备的 DNS：优先使用用户在应用中指定的 DNS 服务器，默认则采用服务器端配置（默认为 Google Public DNS）。无论分流设置如何，所有 DNS 查询均在隧道内安全完成。

加密隧道

默认情况下，应用通过 TLS（即 HTTPS 所用的加密协议）连接到服务器的 TCP 端口（未修改时为 443），并像 Web 应用一样使用 WebSocket 消息进行通信。隧道内的所有流量，从首字节到末字节，均由 TLS 全程加密。

在发送任何数据之前，应用都会验证服务器的证书。它仅接受由证书颁发机构针对访问密钥中指定域名签发的证书，或与密钥中所含指纹完全匹配的证书。正因如此，服务器既可以使用自签名证书启动，也能在续订受信任证书时确保原有密钥依然有效。

在协议设置中，用户可以选择 UDP 或 QUIC 来代替 TCP。UDP 使用 AES-GCM 加密的数据报将设备的数据包发送到服务器的 UDP 端口。QUIC 则在自带的 TLS 基础上，传输与 TCP 相同的消息。服务器会告知应用其支持的协议；若选择的协议不可用（例如位于反向代理之后），应用将自动回退到 TCP。不过，若网络屏蔽了 UDP 端口，设置为 UDP 的应用将无法传输流量，直到用户切回 TCP。

任何非 VpnHood 应用向服务器发出的请求，都只会收到 HTTP 错误响应，就像访问需要登录的网站一样。

TCP：数据包模式或单连接单请求模式

默认情况下，应用将 TCP 作为数据包通过隧道传输，服务器则像路由器一样通过自身的网络适配器转发它们。这是速度最快、最省电的方式。

在Cloak Mode下，应用会在设备本地终止各个连接，并向服务器发起独立请求以建立连接。随后服务器亲自连接目标网站并双向转发数据。对于网络监控者而言，流量不再表现为一条持久的长隧道，而是看起来像浏览器发出的分散请求。这会略微消耗速度和电量，应用会复用已完成请求的连接以供后续使用。

在以下情况下，即使未开启 Cloak Mode，应用也会按这种方式工作：服务器没有独立的网络适配器（如在 Docker 中运行），或用户启用了按域名分流。

UDP 与 Ping

无论应用使用何种协议，UDP 始终作为数据包在隧道中传输。Ping 也同样如此，且仅支持该类型的回显请求（Echo Request），其他 ICMP 数据包均会被丢弃。服务器会通过其网络适配器转发这两者；若没有网络适配器，则会通过自身的套接字代设备执行 Ping。

服务器端机制

安装在 Linux 上的 VpnHood! SERVER 拥有独立的网络适配器，并像路由器一样通过 NAT 将数据包转发到互联网。Docker 容器由于没有此类适配器，因此服务器会作为代理运行：应用按每个连接发送单个 TCP 请求，服务器则自行建立连接、UDP 套接字并处理 Ping。应用会自动切换至该模式。

无论采用哪种方式，它都不会将流量转发至服务器自身的地址或其所在的局域网。

服务器需要开放 TCP 端口，以及在首次启动时为设置为 UDP 的应用所选取的 UDP 端口。QUIC 默认处于关闭状态，除非您手动开启。请参阅配置服务器 IP 地址了解如何查找 UDP 端口。

受管服务器通过 HTTPS 访问 access.vpnhood.com 处的 VpnHood! MANAGER，以便在应用连接时验证密钥并上报使用情况。MANAGER 从不主动连接服务器，应用也从不直接与 MANAGER 通信。此外，MANAGER 还可以将应用引导至服务器集群中的其他服务器。独立服务器则直接通过本地文件验证密钥。

访问密钥包含的内容

访问密钥包含应用寻找并信任服务器所需的全部信息：域名、IP 地址、端口、证书名称或指纹，以及密钥自身的凭据。密钥经过编码但未加密：任何持有密钥的人都可以读取其中的服务器地址并进行连接。请仅将密钥提供给您的受信任用户，并参阅防止服务器 IP 地址被封锁了解网络可能如何处理已知地址。