直接在 server 块中配置 ssl_ciphers 并启用 ssl_prefer_server_ciphers on，是实现单域名精细化加密策略最有效的方式；它规避全局妥协，确保高安全域名严格按指定顺序协商 ecdhe+aead 套件，且须与 ssl_protocols、ssl_ecdh_curve 等指令同块配置并实测验证。
直接在 server 块里配置 ssl_ciphers，是实现单域名精细化加密策略最有效的方式。它不依赖全局设置，能避开其他站点的兼容性妥协，让高安全要求的域名（如管理后台、支付接口）真正用上最强套件。
必须显式启用服务端套件优先权
ssl_prefer_server_ciphers on 是关键开关，不能省略。Nginx 默认把选择权交给客户端，哪怕你在 server 块里写了顶级套件，旧客户端仍可能降级到 AES128-SHA 这类弱组合。只有打开它，Nginx 才会严格按你写的顺序从左到右匹配第一个客户端支持的套件。
- 务必写在同一个
server块内，与ssl_certificate、ssl_ciphers等并列 - 不要只在
http块设为on，却在某个server中漏配ssl_ciphers，否则该站点实际无强加密策略 - 对 TLS 1.2 生效，TLS 1.3 下自动忽略但需保留——它是保障旧协议安全的底线
按域名用途定制套件列表
不同域名的安全目标不同：面向公众的静态站要兼顾兼容性，而内部 API 或后台域名可激进禁用老旧算法。直接在对应 server 块中写死套件，避免混用。
- 高安全后台（如
admin.example.com）：只留 ECDHE+AES-GCM/ChaCha20，不加任何 CBC 或 SHA1 套件ssl_ciphers 'TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384'; - 通用主站（如
www.example.com）：末尾可追加少量兼容项，但必须用冒号接续，确保强套件绝对前置:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA; - 完全不接受降级的域名（如
api.example.com）：删掉所有非 AEAD 套件，连ECDHE-RSA-AES128-SHA都不放
配套限制协议与密钥交换参数
再强的套件列表，若允许 TLSv1.0 握手或使用弱椭圆曲线，照样会协商出不安全连接。这些指令必须和 ssl_ciphers 同处一个 server 块：
- 限定协议：
ssl_protocols TLSv1.2 TLSv1.3;（明确禁用 TLSv1.0 和 TLSv1.1） - 指定曲线：
ssl_ecdh_curve secp384r1:prime256v1;（提升 ECDHE 效率，同时覆盖主流设备） - 启用会话复用：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h;（减少重复握手开销，间接鼓励保持强连接）
验证该域名是否真按预期协商
改完 reload 不代表生效。必须针对这个具体域名实测：
- 用 OpenSSL 检查 TLS 1.2 握手：
openssl s_client -connect admin.example.com:443 -tls1_2 2>/dev/null | grep "Cipher is"
确认输出是ECDHE-RSA-AES256-GCM-SHA384而非AES128-SHA - 用 SSL Labs 扫描该域名，重点看 “Handshake Simulation” 表格中各客户端实际拿到的套件
- 检查 Nginx error log，搜索
no suitable signature algorithm或sslv3 alert handshake failure，排查是否因过度收紧导致兼容问题
