风险不在frankenphp本身，而在http/3的0-rtt机制与业务逻辑交互：frankenphp仅处理已解密请求，0-rtt启用、重放防护及幂等性判断均由底层quic/tls配置和业务代码决定。
有风险，但风险不在FrankenPHP本身，而在HTTP/3的0-RTT机制与业务逻辑的交互上。 FrankenPHP作为嵌入式PHP运行时，不参与QUIC连接建立、TLS握手或0-RTT密钥派生，它只接收已解密的HTTP请求。真正决定是否启用0-RTT、是否允许重放、是否校验重定向边界的，是底层QUIC栈（如quic-go）和TLS 1.3配置，不是FrankenPHP的代码逻辑。
0-RTT重放攻击怎么触发？
0-RTT允许客户端在首次握手完成前就发送加密应用数据（比如HTTP请求），这些数据使用“预共享密钥”加密。问题在于：服务端无法区分该请求是首次发送，还是被网络中间人截获后反复重放的副本。如果这个请求是幂等性弱的操作（如POST /api/transfer?amount=1000），重放就可能造成重复扣款。
常见触发条件包括：
- 服务端未禁用0-RTT对非幂等路径的支持（如未在Caddyfile中用
quic 0rtt off或tls 0rtt off） - 应用层未对关键操作做服务端防重放校验（如缺少
X-Request-ID去重、无时间戳+nonce验证） - 前端在重试逻辑中盲目复用0-RTT缓存的早期数据包
FrankenPHP里哪些地方会放大风险？
FrankenPHP自身不处理0-RTT，但它暴露的PHP执行环境可能无意中成为攻击面放大器：
- 若PHP脚本直接读取
$_SERVER['REQUEST_METHOD']和$_POST并立即执行转账，而没检查$_SERVER['HTTP_TLS_CLIENT_RANDOM']或自定义防重放头，就会跳过所有重放防护 - 使用
file_get_contents('https://...')发起下游调用时，若PHP版本存在CVE-2026-91766漏洞，且目标地址被重定向到恶意域名，0-RTT请求携带的Authorization头可能被转发——这和FrankenPHP无关，但发生在它的PHP进程内 - Worker模式下，若多个请求共享同一PHP上下文（如全局静态变量缓存nonce），可能导致防重放状态失效
Caddy + FrankenPHP配置中必须关掉的选项
FrankenPHP通常由Caddy驱动，而Caddy的QUIC/TLS配置直接控制0-RTT行为。以下配置项不能依赖默认值：
-
quic 0rtt off：全局禁用0-RTT，最简单有效；若必须开启，至少对/api/等敏感路径显式关闭 -
tls 0rtt off：确保TLS层不协商0-RTT密钥 -
header_up X-Forwarded-Proto "https"：避免因协议降级（HTTPS→HTTP重定向）导致凭证泄露，这虽不属0-RTT专属，但常与之共现 - 禁用
php_admin_value auto_prepend_file类全局注入，防止防重放逻辑被绕过
真正难处理的不是“能不能开0-RTT”，而是“哪些请求能承受重放”。幂等性判断必须落在业务代码里，FrankenPHP不会替你做这件事。一个GET /user/profile可以开0-RTT，但POST /order必须强制1-RTT+服务端nonce校验——这个边界，得你自己划清楚。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
