必须将$ssl_cipher变量纳入专用日志格式并仅在listen 443 ssl的server块中启用access_log，配合ssl_certificate等必要ssl配置和nginx -t/reload生效，才能准确记录https实际协商的加密套件。
只在 HTTPS server 块中启用该日志
HTTP 和 HTTPS 是两套完全独立的请求处理路径。`$ssl_cipher` 等变量在 HTTP 请求中没有意义，值为空或“-”。所以必须把 `access_log` 指令明确写在 `listen 443 ssl;` 的 `server{}` 块内，不能混用或泛放在 `http{}` 或 HTTP server 中。
- 确认 server 块已配置 `listen 443 ssl;`，且有 `ssl_certificate` 和 `ssl_certificate_key` 指向有效证书文件
- 避免把同一份 `access_log` 指令同时用于 HTTP 和 HTTPS 的 server 块，否则日志会混杂且 `$ssl_cipher` 大量为空
- 如果用了多个 HTTPS server（如不同域名），每个都需要单独配置 `access_log` 指向对应格式
定义含 $ssl_cipher 的专用日志格式
在 `http{}` 块顶部或合适位置添加一条 `log_format`，名字建议简短明确（如 `cipher_log`），内容聚焦核心字段：
Accessibility Review
下载
对设计或页面进行 WCAG 2.1 AA 无障碍审计。触发关键词：“audit accessibility”、 “check a11y”、 “is this accessible?” 或在审查设计时使用。
- 推荐组合：`$remote_addr [$time_local] "$request" $status $ssl_protocol/$ssl_cipher "$http_user_agent"`
- 用 `$ssl_protocol/$ssl_cipher` 能同时看到 TLS 版本和套件，便于关联分析（例如识别 TLSv1.2 下仍在用 RC4 的旧客户端）
- 不要用 `$ssl_ciphers`（复数形式），它输出的是客户端支持的全部套件列表，极长、易截断，对实际使用情况无参考价值
确保 Nginx 支持 SSL 变量并正确重载
所有 `$ssl_*` 变量依赖 `ngx_http_ssl_module`。虽然现代发行版默认编译该模块，但需验证：
- 运行 `nginx -V 2>&1 | grep --with-http_ssl_module`，确认输出中包含该字符串
- 若缺失，需重新编译 Nginx 并加入 `--with-http_ssl_module` 参数
- 修改配置后，先执行 `nginx -t` 检查语法，再 `nginx -s reload` 生效，不要用 `restart`
用命令快速查看和统计加密算法分布
日志积累几小时后，就能用简单 shell 命令获取真实使用情况：
- 看前 10 个最常用套件：
awk '{print $6}' /var/log/nginx/cipher.log | sort | uniq -c | sort -nr | head -10 - 检查是否仍有老旧协议：
grep 'TLSv1\.0\|TLSv1\.1' /var/log/nginx/cipher.log | awk '{print $6}' | sort | uniq -c - 确认日志路径有写权限（如 `chown nginx:nginx /var/log/nginx`），否则条目不会写入
