Nginx在作为反向代理回源时，如果后端源站支持HTTP/3并且启用了QUIC协议的0-RTT特性，访问日志中就可能记录到使用早期数据传输的请求。这类日志往往让刚接触HTTP/3的管理员困惑，因为传统HTTP/1.1和HTTP/2并没有类似机制。理解它的运作方式，是判断是否需要干预的前提。
什么是HTTP/3与0-RTT
HTTP/3是构建于QUIC传输协议之上的新一代应用层协议，QUIC本身运行在UDP之上，将传输层握手与加密层握手合并，大幅减少连接建立延迟。在经典TCP加TLS场景中，首次建连通常需要一到两次往返，而QUIC借助内置TLS 1.3，可实现首次连接1-RTT完成握手。
0-RTT即零往返时间数据传输，是TLS 1.3提供的早期数据特性在QUIC中的体现。客户端若在之前已与服务器完成连接，再次建连时便可把请求数据随初始包一并发出，服务器若允许便能直接处理，无需等待握手结束。这对回源链路中频繁建立短连接的代理场景有明显加速效果，但也引入了重放风险。
Nginx日志中如何识别回源0-RTT
在Nginx使用proxy_pass配合HTTP/3上游模块（如ngx_http_v3_module或第三方QUIC补丁）时，访问日志的$upstream_protocol变量可能显示为h3，而$request或特定调试日志会暴露早期数据流。部分构建版本会在error.log中以notice级别提示early data accepted from upstream。
更直观的方式是在log_format中加入$upstream_response_time与自定义变量，观察那些响应极短且握手时间近似为零的请求。下表列出常见字段差异，帮助区分普通h3回源与0-RTT回源：
| 日志特征 | 普通HTTP/3回源 | HTTP/3 0-RTT回源 |
|---|---|---|
| 建连往返 | 1-RTT | 0-RTT |
| 首包请求发送时机 | 握手完成后 | 握手包中携带 |
| 源站接受策略 | 默认允许 | 需显式开启early_data |
| 重放风险 | 无 | 存在一定时间窗 |
回源启用0-RTT的潜在风险
0-RTT数据可以被网络中的攻击者截获并重新发送给服务器，由于服务器在握手未完成前就处理了请求，若接口不具备幂等性，就可能造成重复下单、重复扣费等后果。因此RFC规定0-RTT仅适用于幂等请求，如GET、HEAD，而不应处理POST等非幂等操作。
另外，Nginx作为代理回源时，如果自身未对早期数据做限制，而源站全盘接收，就会把风险放大。尤其在多边缘节点共享源站的情况下，某个节点的重放流量可能冲击后端服务。运维必须清楚源站是否真正区分了早期数据与普通数据。
如何在Nginx中控制回源0-RTT
若希望关闭回源侧的0-RTT，可检查Nginx编译参数与上游配置。使用官方原生HTTP/3支持时，可通过quic_early_data off;指令在http或server块中禁用早期数据。对于旧版基于补丁的构建，则需确认proxy_http_version与quic相关指令是否暴露了early data开关。
如果业务确实想保留加速收益，应仅对幂等请求放行。可在Nginx中用if判断$request_method，对非幂等方法强制使用1-RTT回源，或把早期数据转发给源站时打标，由源站按标记做幂等校验。同时建议配合源站设置early data时间窗与单次 nonce 缓存，降低重放成功率。
日常排查与监控建议
建议将h3与0-RTT相关字段纳入常规日志采集，用统计看板观察早期数据占比。若占比突增，可能是客户端库升级或攻击探测。通过分割日志中$upstream_protocol等于h3且响应时间低于阈值的记录，能快速定位异常回源。
此外，保持Nginx与源站QUIC栈版本同步，关注CVE公告。很多0-RTT漏洞源于实现层对重放窗口计算错误，及时升级可避免被动卷入安全问题。对于核心交易链路，宁可牺牲少量延迟也要关闭0-RTT，这是稳妥的工程取舍。
Nginx日志HTTP/3_0-RTT回源配置修改时间：2026-08-10 11:45:34