ssl_conf_command Options PrioritizeChaCha 是 OpenSSL 1.1.1+ 引入的 TLSv1.3 专用指令，强制将 ChaCha20-Poly1305 套件优先级置顶，仅在启用 TLSv1.3 且客户端支持时生效，对无 AES-NI 的移动设备可提升加解密性能 2–3 倍。
ssl_conf_command Options PrioritizeChaCha 是什么
ssl_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 支持，得手动改配置并重载。
