生产环境nginx.conf是需逐项验证、分层加固的防御契约，围绕防攻击、防泄露、防误配三类风险审核；一收敛信息暴露面，二隔离运行身份与权限，三白名单约束http方法，四封堵敏感路径与响应头。
生产环境的 nginx.conf 不是写完就能上线的配置文件，而是一份需要逐项验证、分层加固、运行时确认的防御契约。审核不是走形式，而是围绕“防攻击、防泄露、防误配”三类风险，检查每条指令是否意图明确、生效可靠、无副作用。
一、信息暴露面必须彻底收敛
攻击者第一眼就盯 Server 头和错误页——这是最廉价的情报源。仅靠 server_tokens off 只隐藏版本号，Server 字段仍为 nginx。真正有效的做法是：
- 在 http 块中启用：server_tokens off;
- 若已编译 headers-more-nginx-module，追加：more_set_headers 'Server: WebServer';
- 源码部署用户建议修改 src/core/nginx.h 中的 NGINX_VER，重新编译（如改为 "AppServer/1.0"）
- 验证必须覆盖两个场景：curl -I 首页响应头 + curl 触发 404 页面，确认 HTML 源码和响应头中均无 nginx 字样
二、运行身份与文件权限必须隔离到位
以 root 或 nobody 运行 Nginx 是典型高危习惯。最小权限原则要求进程与配置文件都严格限权：
- 创建专用低权用户：useradd -M -s /sbin/nologin nginx
- 在 nginx.conf 全局块顶部指定：user nginx nginx;（第二个 nginx 是组名）
- 主配置文件权限收紧至 640：chmod 640 /usr/local/nginx/conf/nginx.conf，属主 root，属组 nginx
- 日志目录（如 /usr/local/nginx/logs）属组设为 nginx，并赋写权限：chgrp nginx logs && chmod g+w logs
三、HTTP 方法与请求行为必须白名单约束
绝大多数业务只需 GET 和 POST。TRACE、PUT、DELETE 等方法若未显式禁用，可能被用于探测、缓存投毒或绕过攻击：
- 在需保护的 location 块内使用：limit_except GET POST { deny all; }
- 如需支持 OPTIONS（CORS 预检）或 HEAD，可显式加入：limit_except GET HEAD POST OPTIONS { deny all; }
- 避免在全局 http 块使用该指令，防止误伤健康检查等必要请求
- 同时限制请求体大小：client_max_body_size 10m;，防止恶意上传耗尽内存
四、敏感路径与响应头必须主动封堵
目录遍历、配置文件下载、错误页泄露，都是高频入侵入口。防护要覆盖资源访问与响应输出两个维度：
- 关闭目录浏览：autoindex off;（放在 http 或 server 块）
- 拦截敏感后缀：location ~* \.(conf|log|bak|swp|git|env)$ { deny all; }
- 添加关键安全响应头：add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; - 强制 HTTPS 跳转：return 301 https://$host$request_uri;（放在 80 端口 server 块中）
配置改完不是终点，每次 reload 后必须执行三项验证：curl -I 检查响应头、上传超限文件看是否返回 413、openssl s_client 测 TLS 版本。安全不是加得全，而是每一项都真实生效。
