结论：不要自己从头写 nginx.conf，用 h5bp/server-configs-nginx 作为基线，再按业务场景叠加模块，否则 90% 的“极致”配置实际是负优化。
直接说结论：不要自己从头写 nginx.conf，用 h5bp/server-configs-nginx 作为基线，再按业务场景叠加模块，否则 90% 的“极致”配置实际是负优化。
为什么不能照抄网上流传的“终极高性能配置”
很多所谓“极致模板”把 worker_processes auto、worker_cpu_affinity auto、epoll 全堆进去，但没告诉你这些只在多核 + 高并发 + CPU 密集型场景下生效。在 Docker 容器里或单核 VM 上硬加 worker_cpu_affinity，反而会因调度开销升高导致吞吐下降。
常见错误现象：
- 启用了
gzip_comp_level 9却没配gzip_buffers，CPU 持续 95%+，响应延迟翻倍 - 盲目开启
sendfile on+tcp_nopush on，但在代理 gRPC 或 WebSocket 流量时引发帧粘包 - 把
client_max_body_size放在http{}块全局设为 1G，结果所有接口都绕过上传校验逻辑，被恶意构造大 body 扫描
安全加固必须分层嵌入，不能只靠一个 conf 文件
h5bp 提供的 security/ 目录下每个文件解决一类问题，但它们之间有依赖顺序：
-
cross-origin-policy.conf必须在content-security-policy.conf之前 include，否则 CSP 的frame-ancestors会被覆盖 -
strict-transport-security.conf要求 HTTPS 已就绪，若和自签名证书混用，浏览器直接拒绝加载（不是报错，是静默失败） -
permissions-policy.conf中的geolocation、camera等指令，在非 HTTPS 下会被忽略——这点文档极少提，但实测 Chrome 124+ 严格 enforce
真实部署中，建议用 include 显式控制顺序：
include h5bp/security/cross-origin-policy.conf; include h5bp/security/content-security-policy.conf; include h5bp/security/strict-transport-security.conf;
自动化审计要验证“运行时行为”，不只是语法
nginx -t 只检查语法和文件路径，不验证策略是否生效。比如你写了 add_header X-Content-Type-Options nosniff;，但没关掉 server_tokens，攻击者仍能通过响应头猜出 Nginx 版本。
推荐三个轻量级验证点：
- 用
curl -I https://your.site检查关键 header 是否出现且值正确（如Strict-Transport-Security的max-age是否 ≥ 31536000） - 对上传接口发一个 10MB 的
multipart/form-data请求，确认返回的是413 Request Entity Too Large而不是后端 500 - 用
openssl s_client -connect your.site:443 -tls1_3验证 TLS 1.3 是否启用，避免 fallback 到 TLS 1.2 后被降级攻击
最易被忽略的复杂点：location 块的继承与覆盖关系
很多人以为在 server{} 里设了 client_max_body_size 100m，所有子 location 就自动继承。实际上：
-
client_max_body_size、proxy_buffering、auth_basic这类指令是“继承型”，子块不设则用父块值 -
add_header是“覆盖型”，子location里写的会完全替换父块的同名 header，不会合并 -
proxy_set_header是“追加型”，但只对Host、X-Forwarded-For等少数字段有效，自定义 header 如X-Trace-ID仍会被覆盖
这意味着你给 API 接口加的 add_header X-RateLimit-Limit "1000";，如果在 location /static/ 里又写了 add_header Cache-Control "public, max-age=31536000";，那静态资源响应里就只剩 Cache-Control，RateLimit 头彻底消失——这个细节连很多资深运维都会踩坑。
