<p>Nginx 中不存在 proxy_ssl_conf_command 指令；它仅提供 ssl_conf_command（用于服务端 TLS 终止）和 proxyssl* 系列指令（用于代理客户端行为），后者不支持 OpenSSL 底层命令透传。</p>

Nginx 中没有 proxy_ssl_conf_command 这个指令，它并不存在于任何官方版本中。

你可能混淆了两个不同层级的概念：

• ssl_conf_command 是 Nginx ≥ 1.19.4 中用于 *服务端 TLS 终止（即 `ssl_` 配置）** 时，向 OpenSSL 底层透传参数的指令；
• 而 proxy_ssl_* 系列指令（如 proxy_ssl_certificate、proxy_ssl_protocols）仅控制 Nginx 作为客户端去上游 HTTPS 服务建立连接时的行为，它们不支持底层 OpenSSL 命令透传。

也就是说：

• ✅ ssl_conf_command：可用于 server { } 块中，优化 Nginx 对外提供 HTTPS 服务时的 TLS 握手（如曲线、签名算法、协议选项）；
• ❌ proxy_ssl_conf_command：根本不存在，Nginx 不提供对上游代理连接的 OpenSSL 底层直控能力。

---

那么，如何优化 Nginx 代理到上游 HTTPS 服务的 TLS 性能？

虽然不能用虚构的 proxy_ssl_conf_command，但可通过以下真实、有效的方式调优：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• 精简上游支持的协议与套件
  减少协商开销，加快建连：

  proxy_ssl_protocols TLSv1.2 TLSv1.3;
  proxy_ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256;

• 复用 SSL 会话，降低完整握手频率

  proxy_ssl_session_reuse on;

• 指定上游 ECDHE 曲线偏好（间接生效）
  Nginx 自身不暴露 proxy_ssl_ecdh_curve，但若上游服务支持 TLS 1.3，且你已用 proxy_ssl_protocols TLSv1.3，OpenSSL 底层会自动优先使用 X25519（取决于其编译默认或上游通告）；你无法通过 Nginx 配置强制上游选哪个曲线——那是上游服务器的责任。

• 升级底层 OpenSSL 并保持 Nginx ≥ 1.19.4
  只有当 Nginx 编译链接的是 OpenSSL 1.1.1+ 时，proxy_ssl_* 才能真正启用 TLS 1.3 与 modern key exchange。可通过 nginx -V 2>&1 | grep -i openssl 确认。

---

如果你真需要控制「代理出站连接」的 OpenSSL 行为……

目前唯一可行路径是：

• 使用 OpenResty + Lua-OpenSSL：在 access_by_lua_block 或 ssl_certificate_by_lua_block 中调用 Lua 封装的 OpenSSL 接口（需自行编译支持）；
• 或改用 Envoy / Traefik 等现代代理：它们提供更细粒度的 TLS 客户端配置（如 tls_params.curve_groups）；
• 或直接在上游服务侧调优：让其支持 X25519、禁用 draft 协商、精简 signature_algorithms —— 这才是最高效、最可控的方式。

---

不复杂但容易忽略：Nginx 的设计哲学是“安全优先、抽象可控”，它主动拒绝将 OpenSSL 底层命令暴露给代理客户端场景，避免因错误参数导致连接失败或协议降级。所以，别找 proxy_ssl_conf_command，它不在那里。