X25519:prime256v1是proxy_ssl_ecdh_curve最有效配置，它强制Nginx出站连接优先使用高性能X25519曲线、prime256v1兜底，需OpenSSL≥1.1.0支持且必须在location或upstream块中严格按大小写及冒号格式书写。
直接在 Nginx 的 proxy_ssl_ecdh_curve 指令中写入 X25519:prime256v1，是强制升级后端出站连接椭圆曲线算法最有效的方式。它不改变上游服务配置，只控制 Nginx 作为反向代理与后端（如 API 服务器、内网微服务）建立 TLS 连接时使用的密钥交换曲线。
为什么用 proxy_ssl_ecdh_curve 而不是 ssl_ecdh_curve
ssl_ecdh_curve 管理的是客户端到 Nginx 的入站连接；proxy_ssl_ecdh_curve 管理的是 Nginx 到上游服务器的出站连接。两者独立生效，必须分开配置。
- 若只配
ssl_ecdh_curve，客户端连得快，但 Nginx 连后端仍可能用 slow 的 secp384r1 或 fallback 到非 ECDHE - 若后端是 Java（如 Spring Boot）、旧版 OpenSSL 或某些金融中间件，默认可能不启用 X25519，此时必须由代理层主动指定
- 常见合规场景（如政务云、银行内网）要求出站连接必须使用国密或特定 NIST 曲线，
proxy_ssl_ecdh_curve是唯一可控出口策略的指令
正确写法与顺序规则
该指令必须写在 location 或 upstream 块内，且大小写敏感、冒号无空格：
- ✅ 推荐配置：
proxy_ssl_ecdh_curve X25519:prime256v1;——X25519 优先，prime256v1 兜底 - ✅ 合规兼容写法：
proxy_ssl_ecdh_curve secp384r1:prime256v1;——适用于明确要求 NIST 曲线的内网系统 - ❌ 错误写法：
proxy_ssl_ecdh_curve x25519（小写）、proxy_ssl_ecdh_curve X25519, prime256v1（逗号或空格）、proxy_ssl_ecdh_curve auto（不可控）
必须满足的底层前提
Nginx 编译时链接的 OpenSSL 版本决定能否真正启用 X25519：
- OpenSSL ≥ 1.1.0：支持 X25519，但建议 ≥ 1.1.1（更稳定）
- 执行
nginx -V 2>&1 | grep -o 'OpenSSL [0-9.]+'，确认输出版本号 - 若显示
OpenSSL 1.0.2或更低，即使配置正确，也会静默降级为 prime256v1 - 不依赖后端是否支持——只要 Nginx 自身能生成 X25519 密钥对，就会在 ClientHello 的 key_share 扩展中发送
如何验证出站连接真正在用 X25519
不能只看 Nginx 配置语法是否通过，要抓取 Nginx 与后端之间的 TLS 流量：
- 在 Nginx 服务器上运行：
tcpdump -i any -w proxy-to-upstream.pcap port <em>upstream_port</em>，然后触发一次请求 - 用 Wireshark 打开 pcap，过滤
tls.handshake.type == 1 && tls.handshake.extensions.key_share.key_exchange.length == 32 - 检查 Server Hello 中的
key_share.group字段：值为x25519（0x001D）即成功 - 也可在后端服务器日志中开启 TLS debug（如 Java 的
-Djavax.net.debug=ssl:handshake），查看协商结果
