HTTP/3 是跑在 QUIC 上的网页协议，QUIC 以 UDP 承载并把加密握手与传输合在一起；VPN 是另一层隧道，把包括 QUIC 在内的数据包再封装后送往节点。两者互相影响的，是外层能否转发 UDP、两次握手各对谁，以及丢包时由谁重传。

先分清两层：网页传输与隧道封装

一个可独立引用的定义句：HTTP/3 是浏览器与网站之间的应用层协议，承载在 QUIC 上；QUIC 是基于 UDP 的传输协议，并把 TLS 1.3 握手集成进连接建立。VPN 是设备与节点之间的另一条隧道，负责把已经形成的 IP 包（其中可以包含 QUIC）封装、加密并转发。

据 IETF 公布的 RFC 9114（HTTP/3）与 RFC 9000（QUIC），这两份文本到 2026 年仍是理解「网页如何跑在 UDP 上」的主要公开规范。它们不定义 VPN。把两套名词放进同一个下拉框，才会出现「我开了 VPN，所以 HTTP/3 消失了」这类归层错误。

概念上的路径是：

浏览器  --HTTP/3 / QUIC / UDP-->  网站
                ↑
        这一整段被装进
设备  --VPN 隧道-->  VPN 节点  --解封装后转发-->  网站

本地接入商看见的是外层隧道；网站看见的是 VPN 出口发来的 QUIC。中间这一跳的形态，取决于隧道是 IP 级转发，还是只能搬某一种传输层。架构分层见 现代 VPN 技术架构。

封装之后，内层 UDP 还在

QUIC 的承载是 UDP。VPN 外层可能是 UDP，也可能是 TCP。内层协议不会因为进了隧道就改名。

外层内层 HTTP/3 实际怎样被搬运丢包时谁在恢复
UDP 隧道（典型 WireGuard 即如此）QUIC 仍是 UDP 数据报，外面再套一层 UDP主要由 QUIC；外层不保证送达
TCP 隧道（部分 OpenVPN 等模式）内层 UDP 包被放进外层 TCP 字节流QUIC 与 TCP 都可能重传、排队
只转发 TCP 的代理到网站的 UDP 可能根本没有被转发浏览器常改走 TCP 上的 HTTP/2

第三行不是「HTTP/3 坏了」，而是这条路径没有把 UDP 交到网站。系统隧道与只转发 TCP 的代理差在哪一层，见 SOCKS5 与 VPN 与 TCP 还是 UDP。协议族本身的差异，见 WireGuard 与 OpenVPN。

外层已经是 UDP 时，再跑 QUIC，并不等于「两层都不可靠所以数据会丢」。QUIC 自己负责重传、排序与拥塞控制。外层 UDP 只是不在隧道这一层再做一次可靠字节流。

握手有两次，对端也不同

要进隧道的流量，隧道得先能转发。这是第一次会话：设备 ↔ VPN 节点。浏览器随后才与网站做 QUIC 握手，这是第二次会话：浏览器 ↔ 网站。据 RFC 9001，QUIC 的加密握手与 TLS 1.3 集成；它替换不了 VPN 自己的密钥交换。

会话两端成功说明什么不说明什么
VPN 握手设备与节点隧道密钥协商完成，封装路径可用网站支持 HTTP/3
QUIC 握手浏览器与网站站点与浏览器同意用 HTTP/3外层隧道的加密套件
QUIC 0-RTT（若使用）仍是浏览器与网站在已有票据时少一轮往返可以省略 VPN 握手；0-RTT 数据还有重放方面的公开限制

浏览器往往通过 Alt-Svc 响应头或 HTTPS 的 DNS 记录得知「这个源可以用 HTTP/3」。发现过程若走了隧道外的解析，本地网络仍可能看见域名。解析路径与隧道是否一致，见 DoH、DoT 与 VPN DNS。

丢包与队头阻塞发生在哪一层

QUIC 在一条连接里把数据分成多个流。某一个流丢包，不应挡住同一连接里其他流的交付。这是它相对 TCP 的传输层设计。

这条优点只在 QUIC 自己的包能独立丢失、独立重传 时成立。外层若是一条 TCP 隧道，许多互不相关的内层连接被塞进同一条可靠字节流：外层丢掉一个段，后面的隧道帧都要等重传。现象叫队头阻塞。此时内层即使是 QUIC，也会被外层的排队拖住。

现象更可能落在哪一层
只有某一个下载卡住，同连接其他请求仍在走更接近 QUIC/应用自己的流
一切网页一起停住，直到隧道恢复更接近外层 TCP 的队头阻塞，或隧道整体重连
到节点的探测延迟不高，但多标签页很卡对照外层是 TCP 还是 UDP，见 延迟、抖动与丢包
隧道频繁断开后网页全部重来外层会话没了，内层 QUIC 的路径一并消失

外层 UDP 映射若被中间设备回收，隧道会中断，内层 QUIC 也不会单独「穿过去」。保活与重连是隧道自己的问题，概念见 保活与重连。

初始包尺寸与 MTU

据 RFC 9000，客户端必须把承载 Initial 包的 UDP 载荷填充到至少 1200 字节（规范给出的直接原因是限制放大攻击）。副作用是：路径若连这一档数据报都送不到，握手无法完成。VPN 外层还要再占掉自己的头部。虚拟网卡若仍按较大的内层 MTU 发送，真实路径可能丢弃这些握手包。

结果常常是：小流量看起来正常，HTTP/3 握手失败，浏览器改用 HTTP/2。这是包尺寸与路径 MTU 的碰撞，不是 VPN 在协议定义上禁止 QUIC。MTU 与路径黑洞的含义见 VPN 的 MTU。本文只说明碰撞发生在哪一层，不写调整步骤。

条件对 HTTP/3 的典型后果
外层能转发 UDP，且路径容得下约 1200 字节以上的 QUIC 初始数据报握手有机会完成
外层是 TCP，但 MTU 足够HTTP/3 仍可能跑在隧道里，但丢包时受外层排队影响
路径或封装吃掉了初始包所需空间握手失败，浏览器可能回退到 TCP 上的 HTTP/2
路径只允许 TCP、UDP 到不了节点取决于隧道能否在 TCP 外层里继续搬运内层 UDP

沿途谁看见 QUIC

两层加密保护的段落不同。外层隧道正常时，本地网络看不见网站方向的 QUIC 明文；VPN 节点解开隧道后，看见的是发往网站的 UDP，以及目标 IP 和端口。页面正文仍由 QUIC/TLS 保护。

观察者更可能看见通常看不见
本地接入商设备与 VPN 节点之间的外层地址、端口、包长与时序隧道内的网址与页面正文
VPN 节点目标 IP、端口，以及内层是 UDP已被 QUIC 保护的页面正文
网站源地址是 VPN 出口；与浏览器的 QUIC 会话你的家庭宽带地址（隧道未旁路时）

节点看得见目标地址，是单跳 VPN 的结构结果，与内层用不用 HTTP/3 无关。DNS 若在隧道外解析，接入商仍可能从查询里得知域名，即便网页载荷已经进了 QUIC。这一点要用解析路径单独核对，见 DNS 泄漏检查 的概念。

换网络时，迁移发生在哪一层

QUIC 用连接标识支持路径迁移：客户端地址变化时，逻辑连接有机会延续。这个「地址」是网站看到的源地址。流量在 VPN 里时，网站看到的是出口节点的地址，不是手机在 Wi-Fi 与蜂窝之间切换的那个地址。

变化发生在网站侧通常怎样本地网络侧通常怎样
只切换了接入网，VPN 出口未变源地址不变，QUIC 不必迁移外层隧道可能要在新网络上重新映射
VPN 重连后出口 IP 变了网站看到新的源地址，旧的 QUIC 连接可能中断或触发迁移看见的仍是「去往节点」的外层流量
家庭路由器上的 NAT内层 QUIC 不是路由器上的独立会话路由器维护的是外层隧道那一条映射，概念见 NAT 穿越

所以「QUIC 能迁移」描述的是浏览器到网站的路径；「VPN 在漫游」描述的是设备到节点的路径。两句话可以同时为真，也可以只有外层在重连、内层全部重来。

常见误解

误解 1：开 VPN 就会关闭 HTTP/3。
HTTP/3 在隧道里面协商。UDP 能被转发且初始包装得下时，网页可以继续用 QUIC。

误解 2：HTTP/3 已经加密，所以不需要 VPN。
QUIC 保护的是浏览器到网站。它不隐藏你与网站之间的路径，也不把流量改到另一个出口。VPN 保护的是设备到节点这一段，并改变网站看到的源地址。

误解 3：外层用 UDP、内层用 QUIC，等于双重丢包。
外层 UDP 不负责可靠；可靠由 QUIC 承担。会叠加重传的是「外层 TCP 再加内层 QUIC」。

误解 4：退回 HTTP/2 就说明节点不可用。
回退只说明这次没有把 HTTP/3 握下来。外层隧道仍可能在用 TCP 上的 HTTP/2 正常打开网页。

误解 5：两层加密会让节点也读不懂目标是谁。
节点解开的是隧道，不是网站会话。目标 IP 在解封装之后是可见的；不可见的是 QUIC 保护的正文。

把变慢或回退归到层

本文不写客户端选项怎么点。遇到「开了隧道之后网页变慢，或协议从 HTTP/3 回到 HTTP/2」时，按层提问：

  1. 外层是 UDP 隧道、TCP 隧道，还是只转发 TCP 的代理；
  2. 尺寸：路径在加上隧道头部之后，是否还容得下 QUIC 初始包那一档长度；
  3. 恢复：丢包时是内层某个流在重传，还是整条外层字节流在排队；
  4. 解析：域名查询是否与隧道在同一条路径上。

四层各自有公开的机制。把体感直接写成「HTTP/3 与 VPN 不兼容」，会把外层传输、MTU 和回退策略混成一条无法复查的结论。