Nginx截至2026年9月不原生支持PQC，主因是依赖的OpenSSL尚未在稳定版中集成TLS-PQC扩展，其KEM与签名机制仍处实验阶段，且IETF RFC标准未最终冻结；Nginx自身也未提供相应配置指令或TLS扩展钩子。
目前 Nginx 官方主线版本（截至 2026 年 9 月）**不原生支持后量子密码学（PQC）算法**，也无法直接配置 Kyber、Dilithium 等 NIST 标准化后量子算法用于 TLS 握手。这不是配置遗漏问题，而是底层依赖的 OpenSSL 尚未在稳定发行版中集成 PQC TLS 扩展能力。
为什么 Nginx 还不能开箱启用 Kyber 或 Dilithium？
核心限制不在 Nginx 本身，而在它所依赖的 TLS 库：
-
OpenSSL 仍处于实验阶段：OpenSSL 3.2+ 开始通过
liboqs（Open Quantum Safe）提供可选的 PQC 实验支持，但仅限于命令行工具和 API 层；TLS 1.3 协议栈中的 KEM（密钥封装）和签名扩展尚未进入 stable release，也未被 Nginx 的ssl_*指令识别。 -
Nginx 未实现 TLS 扩展钩子：即使 OpenSSL 编译了 OQS 支持，Nginx 没有暴露配置项（如
ssl_pqc_kem或ssl_pqc_sigalgs）来协商 Kyber768、ML-KEM-1024 等参数，也不支持混合密钥交换（hybrid key exchange）的配置语法。 -
标准尚未冻结落地：NIST 在 2024 年正式发布 ML-KEM（Kyber）、ML-DSA（Dilithium）、SLH-DSA（SPHINCS+）等标准，但 IETF RFC 对其在 TLS 1.3 中的编码方式（如
draft-ietf-tls-hybrid-design）仍在最后修订中，主流服务器软件暂未跟进实现。
想做 PQC TLS 实验，可行路径有哪些？
若目标是验证后量子 TLS 握手流程或测试混合密钥交换效果，需绕过标准 Nginx 配置，采用以下组合方案：
-
用 OpenSSL 自建 TLS 服务替代 Nginx：使用启用了
liboqs的 OpenSSL 3.2 构建自定义s_server，手动指定-kem和-sigalgs参数，例如：openssl s_server -cert server_kyber.pem -key server_kyber.key -accept 4433 -kem kyber768 -sigalgs dilithium2 -
用 Caddy + plugins（更贴近 Web 场景）：Caddy v2.8+ 社区已有实验性插件（如
caddy-pqc）支持加载 OQS-OpenSSL，并允许在 Caddyfile 中写：tls /path/to/kyber_cert.pem /path/to/kyber_key.key {<br> kem kyber768<br> sigalgs dilithium2<br>} - 在 Nginx 前置一层 PQC-aware 代理（如 Envoy + custom filter）：Envoy 已有社区 PR 探索集成 liboqs，可将 TLS 终止卸载到 Envoy 层，再以普通 HTTPS 转发给后端 Nginx——这样 Nginx 保持不变，而面向客户端的连接已具备 PQC 能力。
当前能做的“准 PQC”兼容准备
虽然无法直接启用 Kyber，但可通过以下配置为未来平滑迁移打下基础：
-
确保 OpenSSL ≥ 3.2 且编译时启用 OQS：检查
openssl version -f输出是否含enable-oqs；运行openssl list -kems应能看到kyber512/768/1024等条目。 -
禁用静态密钥交换，强制 ECDHE：在 Nginx 中设置
ssl_ecdh_curve X25519:P-256;并移除ssl_dhparam，为后续替换为 Kyber+ECDHE 混合模式留出协商空间。 -
预留 ALPN 和扩展字段空间：不关闭
ssl_buffer_size（保持默认 4k），避免因 TLS 扩展变长导致握手截断；确认日志中无tls-extension-too-large类错误。
真正把 Kyber 带进生产级 Nginx，还需等待 OpenSSL 正式发布 TLS-PQC 支持、Nginx 主线合并对应 SSL 模块适配，以及主流 Linux 发行版将相关组件纳入稳定仓库——预计最早在 2027 年中后期才可能见到较成熟的部署实践。
