Nginx配置ssl_conf_command时，如何优先使用ChaCha加密优化移动终端性能？

本文共计691个文字，预计阅读时间需要3分钟。

plaintextssl_conf_command Options PrioritizeChaCha是OpenSSL 1.1.1引入的配置指令，通过ssl_conf_command传递给底层OpenSSL，强制将ChaCha20-Poly1305加密套件优先级提升到最高。它不改变Nginx自身的ssl_ciphers列表顺序，而是直接干预OpenSSL的运行时协商逻辑，对移动设备（尤其是Android 4.4-9、旧版iOS）有明显的性能提升——因为这些平台CPU缺乏AES-NI指令集，ChaCha20软实现比AES-GCM快2-3倍。

为什么只在 TLSv1.3 下才真正生效

ChaCha20-Poly1305 在 TLSv1.2 中仅作为可选套件存在，且需客户端明确支持并主动发起协商；而 TLSv1.3 将其列为标准套件之一，并默认启用。OpenSSL 在 TLSv1.3 握手中会严格按 Options PrioritizeChaCha 的指示调整套件排序，只要客户端也支持（绝大多数现代浏览器和 Android/iOS 系统都支持），就会优先选中 TLS_AES_128_GCM_SHA256 或 TLS_CHACHA20_POLY1305_SHA256 中的后者。

• 若只配了 ssl_protocols TLSv1.2，该指令基本无效——OpenSSL 不会在 TLSv1.2 中重排 ChaCha 套件
• 若同时启用 TLSv1.2 和 TLSv1.3，但客户端只支持 TLSv1.2，仍不会触发 ChaCha 优先逻辑
• 必须确保 ssl_protocols 明确包含 TLSv1.3，例如：ssl_protocols TLSv1.2 TLSv1.3

和 ssl_ciphers 的关系容易搞混

ssl_ciphers 控制的是 TLSv1.2 及更早版本的密码套件白名单，对 TLSv1.3 无效；ssl_conf_command Options PrioritizeChaCha 则专用于 TLSv1.3 的套件调度。两者不是替代关系，而是分层作用：

• 你仍需用 ssl_ciphers 限制 TLSv1.2 的可用套件（如禁用弱算法）
• 但 TLSv1.3 的套件由 OpenSSL 内置固定列表决定，Nginx 无法用 ssl_ciphers 修改，只能靠 ssl_conf_command 干预其优先级
• 常见误配：ssl_ciphers 里硬写 CHACHA20 相关字符串——这在 TLSv1.3 下被忽略，纯属冗余

实际部署要注意的硬性前提

这条指令不是加了就起效，依赖三个不可妥协的条件：

• Nginx 版本 ≥ 1.15.5（推荐 ≥ 1.19.0 或 1.29.1，后者修复了 QUIC/HTTP/3 场景下的 ChaCha 协商稳定性）
• 编译时链接的 OpenSSL ≥ 1.1.1（验证命令：nginx -V 2>&1 | grep -i openssl；运行时：openssl version）
• 必须放在 server 块内，且与 ssl_early_data on、ssl_protocols TLSv1.2 TLSv1.3 共存——单独加这一行没意义

如果你用的是宝塔、AMH 等面板，注意它们默认可能关闭 TLSv1.3 或未启用 ssl_conf_command 支持，得手动改配置并重载。