没有“开箱即用”的极致加固模板，所有所谓“极致”都必须基于业务路径、流量特征和合规基线做裁剪；盲目堆砌配置反而会引发502、499或TLS握手失败等线上故障。
直接说结论：没有“开箱即用”的极致加固模板，所有所谓“极致”都必须基于业务路径、流量特征和合规基线做裁剪；盲目堆砌配置反而会引发 502、499 或 TLS 握手失败等线上故障。
server_tokens 和 headers-more-nginx-module 的取舍
只设 server_tokens off; 只能隐藏版本号，但响应头仍带 Server: nginx —— 这是默认行为，攻击者一眼识别技术栈。想彻底移除，必须编译安装 headers-more-nginx-module 并使用 more_clear_headers Server;。
但要注意：
- 该模块不内置，需在
./configure阶段显式添加--add-dynamic-module=../headers-more-nginx-module - Nginx 1.21.4+ 原生支持
server_tokens build;（显示构建时间而非版本），但依然无法清除Server头 - 若用 OpenResty，已预编译该模块，可直接启用
limit_req_zone 和 limit_conn_zone 的真实压测表现
这两个指令常被当成防刷万能药，但实际效果严重依赖 key 的选择粒度和共享内存大小：
-
limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;：对单 IP 限速，但 IPv4 NAT 环境下会误伤大量用户 -
limit_req_zone $cookie_session zone=session_limit:10m rate=5r/s;：更合理，但需前端写入有效sessioncookie，否则退化为按$remote_addr限速 -
limit_conn_zone $server_name zone=host_limit:10m;：适合多租户场景，防某域名突发流量打垮整机 - 共享内存区（如
10m）太小会导致limit_req日志中频繁出现limiting requests, excess: ... by zone，但不报错，容易被忽略
SSL/TLS 配置中容易被忽略的三个硬约束
光写 ssl_protocols TLSv1.2 TLSv1.3; 不够，客户端兼容性和服务端稳定性还卡在三个地方：
-
ssl_ciphers必须排除含RC4、DES、MD5的套件，但也不能过度收紧——例如去掉所有EECDH会导致部分 Android 4.x 设备握手失败 -
ssl_buffer_size 4k;是关键：Nginx 默认 16k，但在 TLS 1.3 下可能触发某些 CDN 或中间设备的分片处理异常，4k 更稳妥 -
ssl_session_cache shared:SSL:10m;和ssl_session_timeout 4h;必须成对出现；缓存区过小（如1m）在高并发下会快速打满，导致新建连接反复握手，CPU 暴涨
access_log 和 error_log 的审计级日志落盘要点
合规要求的“全方位审计”不是简单打开日志，而是确保字段可追溯、权限受控、轮转不丢数据：
- 自定义
log_format至少包含：$http_x_forwarded_for（真实客户端IP）、$request_time（处理耗时）、$upstream_response_time（后端耗时）、$status、$body_bytes_sent - 日志文件权限必须为
640，属主为root:nginx，防止 worker 进程意外覆盖或读取敏感字段 - 禁用
access_log /path/to/access.log main;这类裸路径写法，改用access_log /var/log/nginx/access.log custom_audit_buffered buffer=64k flush=1s;—— 带缓冲 + 定时刷盘，兼顾性能与断电不丢日志 -
error_log级别建议设为error，不是warn或info；后者在高并发下日志量爆炸，且无助于审计定位
真正难的不是加多少条配置，而是每一条都得回答清楚：它挡住了什么风险？放行了哪些合法流量？出问题时怎么快速回滚？比如 limit_except GET POST { deny all; } 看似安全，但若后端依赖 OPTIONS 预检或 PATCH 更新，就会直接阻断业务。
