nginx 本身不实现加密算法，其后量子密码（pqc）落地依赖 openssl 等 tls 库对 kyber、dilithium 等算法的支持，需通过混合密钥交换（如 x25519+kyber768）实现兼容过渡，并受证书生态、性能开销及监控缺失等约束。
Nginx 本身不直接实现加密算法，但它作为 TLS 协议的关键承载层，是部署后量子密码（PQC）最现实、最关键的入口。真正起作用的是底层 TLS 栈（如 OpenSSL）对 PQC 算法的支持程度，而 Nginx 的配置能力决定了这些新算法能否被正确启用、协商和落地。
PQC 在 Nginx 中的落地依赖 OpenSSL 的演进
Nginx 通过调用 OpenSSL（或 BoringSSL、QuicTLS 等兼容 TLS 库）完成密钥交换与身份认证。当前主流稳定版 OpenSSL（如 3.0.x、3.2.x）尚未原生支持 NIST 标准化算法（Kyber、Dilithium 等），但社区已有多个实验性分支提供支持：
- OpenSSL 3.3+ 开始集成初步 Kyber KEM 支持（基于 draft-ietf-tls-hybrid-design），需手动启用编译选项
enable-experimental-kyber； - NIST 官方参考实现（如 liboqs）可被编译为 OpenSSL 的外部 provider，在运行时动态加载 Kyber768/Dilithium3 等算法；
- 部分国产 TLS 库（如 Bouncy Castle for C、国密增强版 OpenSSL）已支持“SM2+Kyber”混合密钥协商模式，适配国内政务/金融场景。
这意味着：想让 Nginx “用上 PQC”，第一步不是改 Nginx 配置，而是确保它链接的 OpenSSL 具备 PQC 能力，并通过 openssl version -a 和 openssl list -kem-algorithms 验证 Kyber 是否可见。
混合密钥交换（Hybrid Key Exchange）是当前最可行路径
纯 PQC 算法（如 Kyber）虽抗量子，但尚未经过长期工程验证；而传统 ECC（如 x25519）仍具强安全性。因此，IETF 推荐采用混合模式——同时执行 ECC 和 Kyber 密钥封装，最终派生出同一共享密钥。这种方式兼顾安全性与兼容性，且对客户端透明（只要支持 TLS 1.3 和对应扩展）。
- Nginx 无需新增指令，只需在启用 TLS 1.3 的前提下，确保 OpenSSL 提供的 cipher suite 包含
TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256并启用 hybrid KEM（如x25519+kyber768）； - 证书链暂无需更换：PQC 目前主要用于密钥协商（KEM），数字签名仍可沿用 ECC 或过渡到 Dilithium；
- 客户端需为新版 curl（8.7+）、Firefox Nightly（支持 draft-ietf-tls-hybrid-design）、或 Chromium 实验性构建版，才能完成协商。
真实部署中需关注的三个实际约束
即便技术路径清晰，落地仍受制于生态成熟度与系统环境：
- 证书签发尚无权威 CA 支持 PQC 签名：Let’s Encrypt、Sectigo 等主流 CA 尚未提供 Dilithium 或 Falcon 签名证书；目前只能使用自签名或私有 CA + liboqs 工具链生成测试证书；
- 性能开销不可忽视：Kyber768 封装/解封耗时约为 x25519 的 3–5 倍，密钥尺寸大 3–4 倍；高并发场景下可能抬升 CPU 使用率与 TLS 握手延迟；
- 缺乏标准化日志与监控指标：Nginx 默认 access_log 不记录协商使用的 KEM 类型；需配合自定义 log_format + OpenSSL 提供的 SSL_get_kem_name() 扩展字段，才能观测 Kyber 是否真实生效。
面向生产环境的渐进式建议
不必等待“完全体”PQC，现在就可以建立迁移基础：
- 将 Nginx 升级至 1.25+，启用 TLS 1.3 并禁用所有 TLS 1.2 下的弱 cipher；
- 在测试环境编译支持 liboqs 的 OpenSSL，用
openssl s_server验证 Kyber 握手，再替换 Nginx 的 OpenSSL； - 配置 fallback 机制：当客户端不支持 hybrid 时，自动降级至 x25519；避免因单点升级导致服务不可用；
- 对关键 API 域名（如 /auth、/key-exchange）单独启用 PQC 测试通道，隔离风险。
