部署一台Nginx很容易，但把一台Nginx配置到"安全"状态，很多人其实没认真想过。我接触过不少项目，应用代码写得不错，结果Nginx层漏成了筛子——目录列表开着、管理后台裸奔、错误信息把内部IP打得到处都是、4核机器被一个循环请求打满。大多数安全问题不是0day，而是配置层面的低级失误。这篇文章不是要讲一个标准答案，而是把我实际加固Nginx的过程、踩过的坑、验证过的配置完整梳理一遍，让读到的人能直接对照着改。
1. 威胁面盘点：Nginx到底在替你挡什么
1.1 暴露面、滥用面、数据面三个维度
入手加固之前，我习惯先把威胁面理一遍。Nginx作为Web服务层，主要面临三方面风险：暴露面、滥用面和数据面。
暴露面指的是那些不该让外部看见的东西却出现在公网上。目录列表打开、配置文件备份被下载、管理后台未做访问控制、版本号暴露给扫描器，这些都属于暴露面问题。攻击者会利用扫描工具全网探测这类特征，只需要几分钟就能定位那些几乎没有防御的目标。
滥用面是指服务本身被当作工具去消耗计算资源或绕过业务逻辑。典型的如高频请求打空连接池、慢速连接占满worker进程、爬虫无限抓取消耗带宽、接口被调用方恶意重放。这类攻击不需要多高深的技术，一台机器、一个循环脚本就够了，但造成的业务影响通常立竿见影。
数据面则和业务数据直接相关，比如SQL注入、路径穿越读取配置和源码、用户敏感信息泄露、错误页回显堆栈和内部IP。Nginx在这一层能做的过滤有限，但确实能挡住相当一部分自动化的探测和低水平的试探。三层理清楚之后，再去写配置就有的放矢了，而不是盲目地抄网上的加固片段。
1.2 为什么说配置错误比0day更常见
很多团队对安全的理解是"别用旧版本、及时打补丁"，这当然正确，但实际遇到过的情况告诉我：配置导致的漏洞往往更容易被忽略，影响范围也更直接。0day可遇不可求，而配置错误是每天都在犯的错。
举一个我印象很深的例子。某次接手一个项目的安全巡检，发现线上Nginx配置里有这样一段：alias /var/www/uploads/;配在了一个带location匹配的路径下。稍微了解过alias与location配合的人都知道，如果location写的是/files，alias指向了实际目录但结尾没带斜杠，就可能出现路径拼接穿越。攻击者构造/files../形式的请求，就存在读取目录外文件的可能性。后来排查确认配置写法确实存在问题，虽然当时因为目录权限设了限制而没有造成实际文件泄露，但那种"差一点就出大事"的感觉，确实让人后背发凉。
类似的案例还有不少：proxy_pass没带URI时行为不同就可能导致路径被改写；root配合location ~ \.php时如果校验不严，可能被利用执行任意脚本；server_name配置了下划线导致匹配混乱，访问直接被非预期站点接收。这些问题用扫描器测不出来，代码审计也发现不了，只有人工盯着配置一行行看才能找出隐患。
说白了，Nginx默认配置是"能用"而不是"安全"，从默认状态到安全状态之间，需要做的决策远比想象中多。绑什么端口、暴露哪些路径、允许哪些方法、返回什么头、什么情况下拒绝访问、日志记哪些字段，这些都是安全决策。早年在配置上偷的懒，迟早要在事故中加倍还回去。
2. 基线加固：一份能直接抄的nginx.conf安全模板
2.1 信息隐藏与服务端标志清理
关于信息隐藏，我遇到过真把公司名称和内部主机名直接放在server_tokens默认返回里的情况。Nginx默认会返回类似nginx/1.18.0的版本信息，配合error_page返回的错误页里还可能带着nginx版本号。扫描器见到版本号之后，会直接去匹配已知的漏洞库，所以版本信息暴露得越少越好。
我的习惯是至少在http块里加两行：
server_tokens off; more_clear_headers Server;第一行是Nginx自带的开关，把响应头里的版本号去掉，只保留nginx字样；第二行需要headers-more-nginx-module这个第三方模块，我一般会直接连Server头一起清掉，让响应里完全没有服务器类型信息。对已经编译好的Nginx如果没有这个模块，也可以用proxy_hide_header Server;隐藏上游返回的Server头，但Nginx自身那层还是会在首次响应时暴露，所以编译时带上这个模块更稳妥。
除了Server头之外，我还会检查默认的index页面。安装Nginx后自带的index.html和50x.html里经常带着发行版的标识文字，最好删掉换成自己定制的页面。还有一个容易被忽视的点：location = /nginx_status这类状态页，如果打开了stub_status，一定要加访问限制。状态页泄露的是实时请求数、连接数、活跃连接等运行指标，攻击者能用这些数据评估你的负载情况，判断什么时候打你最容易造成服务抖动。
2.2 请求方法与体量限制
Nginx默认接受的HTTP方法不多，但很多转发场景里会隐式放行一些本不该开放的方法。比如WebDAV的PROPFIND、MKCOL之类，如果处理PHP或Java的上游应用没做方法校验，就可能被用作探测或触发异常。我通常会在server块里做一个集中限制：
if ($request_method !~ ^(GET|HEAD|POST)$) { return 405; }这里只放行三种常见方法，PUT和DELETE如果业务确实需要，再单独对特定location暴露。相比一步步排查每个location的方法配置，这种集中拦截更省心，误伤的几率也低。需要注意的是if块在Nginx里有一些使用限制，但这个场景是官方允许的return用法，没有安全陷阱。
体量限制同样关键。默认的client_max_body_size是1MB，很多人会为了上传功能临时调大后忘了收回来，结果接口变成无限上传的大嘴巴。我的标准做法是区分场景：正常API接口保持1m到10m，上传接口单独开给指定location并设置一个明确上限，比如50m或100m，看业务需求。同时配合client_body_timeout和client_header_timeout，把读请求体和头的超时时间控制住，防止慢速连接一直占着worker不放：
client_max_body_size 10m; client_body_timeout 10s; client_header_timeout 10s;这里有个使用技巧：client_body_timeout设得太激进会误伤弱网用户，移动端网络环境差时请求体读取超时是常事，所以10秒是我测试下来比较平衡的值，既能把空连接清掉，又不至于影响正常用户。
2.3 HTTP安全响应头配置
响应头是Nginx层最容易做出明显改善的一块，而且见效快、可量化。我配置了一套固定的安全头，在server块统一加上：
add_header X-Content-Type-Options "nosniff" always; add_header X-Frame-Options "SAMEORIGIN" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;nosniff能阻止浏览器对响应内容做MIME嗅探，降低上传内容被当作脚本执行的风险；X-Frame-Options防的是点击劫持，页面被嵌到恶意网站框架里的情况也能一刀切掉；Referrer-Policy控制的是跨站请求携带的Referrer信息，防Referrer泄露URL参数里的敏感信息；Permissions-Policy则直接关掉了一些用不到的浏览器能力。
有一个容易踩的坑是：如果某个location里设置了add_header，那么该location的响应头只包含当前层级定义的头部，不会继承server块的同名配置。也就是说，在location /api里单独写了一个add_header Cache-Control，那X-Frame-Options这些头就从API响应里消失了。这个问题的解决思路是开启more_set_headers或手动把安全头在每个location重复一遍。我一般是在http块统一设置安全头，并且注意不在location里重复使用add_header，一旦某一层需要自定义头，就整体用more_set_headers -t "text/html"这类方式做定向覆盖，避免各层头部丢失。
3. 访问控制实战：IP黑白名单、限流和认证的三板斧
3.1 allow/deny配合real_ip的正确姿势
Nginx的allow和deny指令很多人用过，但配合代理环境时经常出问题。如果你的Nginx前端还有CDN或四层负载均衡，那么$remote_addr拿到的是上一跳设备的IP，而不是真实客户端IP，此时做IP白名单就等于白搭。正确做法是先配set_real_ip_from和real_ip_header：
set_real_ip_from 10.0.0.0/8; set_real_ip_from 172.16.0.0/12; real_ip_header X-Forwarded-For; real_ip_recursive on;set_real_ip_from声明信任哪些来源地址的转发，real_ip_header指明真实IP从哪个头里取，real_ip_recursive on表示在X-Forwarded-For里取最左端那个IP。如果没有real_ip_recursive，Nginx默认取最后一个IP，这个默认行为在多层代理下会产生误判。我遇到过一个案例，因为没开real_ip_recursive，导致访问日志里所有IP都显示成了负载均衡内网地址，基于IP的封禁完全失效。
真正的白名单逻辑建议配合map来写，而不是多个allow/deny层层覆盖。因为allow/deny谁先谁后、内层外层在哪一层生效，规则复杂了很容易把自己绕晕。用map的好处是逻辑集中、可读性强：
map $remote_addr $admin_allowed { default 0; 10.1.2.0/24 1; 203.0.113.123 1; } server { location /admin { if ($admin_allowed = 0) { return 403; } proxy_pass http://backend_admin; } }这样维护白名单只需要改map那一处，出问题时排查路径也短，不需要去翻十几个location里的allow/deny。
3.2 limit_req区域与突发处理参数
限流是Nginx层防刷最常见的手段，但想配置得"不误伤又不放过"，需要对参数有比较清楚的理解。
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s; server { location /api/ { limit_req zone=api_limit burst=20 nodelay; } }rate=10r/s是平均速率，burst=20表示允许短时间超过平均限速的排队请求数，nodelay表示突发请求不等待排队，而是立即被处理。三个参数凑一起的语义是：平均每秒最多处理10个请求，但允许瞬间来30个（10+20），超过30的直接返回503。
使用这个配置时我踩过一个坑：早期给接口配置了rate=5r/s burst=20 nodelay，结果促销活动一开，用户快速点击时请求返回了大量503，前端没有做异常提示，用户直观感受就是"系统坏了"。后来把burst调到50，配合前端加节流，才算平稳。burst和rate的比例取决于业务形态，读多写少可以放大burst，写操作多的要收紧，这个没有银弹，只能压测加观察。
另外limit_req_zone里如果用$binary_remote_addr做键，要注意IPv6地址空间很大，每个IP都能拿到独立的限流桶。某些攻击者会利用IPv6地址池轮换来绕过单IP限流，如果业务面向公网且IPv6连接比例高，可以考虑用limit_conn_zone做连接数限制搭配使用：
limit_conn_zone $binary_remote_addr zone=perip:10m; server { location / { limit_conn perip 10; limit_conn_status 503; } }单IP同时连接数限制在10，对正常用户绰绰有余，但能有效缓解每个IP建立大量并发连接造成的资源占用。值得说明的是，limit_conn限制的是连接数而不是请求数，一个HTTP/2连接里可以承载很多请求，所以它和limit_req是互补关系，而不是替代关系。
3.3 用auth_basic挡住内网管理入口
我维护过的不少服务，把管理后台放在公网路径下，靠应用层的登录体系保护。这本身没有问题，但如果应用层存在未授权漏洞，管理后台就直接暴露了。我习惯在Nginx层再加一道HTTP Basic认证作为前置门槛，成本极低、收益直接。
生成密码文件很简单：
openssl passwd -apr1 你的密码把生成的哈希追加到.htpasswd文件里，然后在location中启用：
location /admin/ { auth_basic "Restricted Area"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://backend_admin; }这里要注意，.htpasswd文件的权限必须设为600或640，属主为运行Nginx的用户，否则Nginx会因为权限过宽直接报错拒绝加载配置。目录权限的问题我踩过一次：某台机器上.htpasswd是644，Nginx直接返回500，排查日志才发现"open() failed (13: Permission denied)"。
还有就是Basic认证在明文HTTP下会暴露密码，所以必须确保这个入口只走HTTPS。如果Nginx同时监听80和443，要防止通过80直接访问管理地址。最简单的方式是在80端口的server里把整个管理路径强制跳走，或者干脆让80端口只做跳转到443的逻辑。
4. 应用层攻击过滤：在Nginx层拦截SQL注入、XSS和扫描器
4.1 白名单优先于黑名单的拦截思路
Nginx层做WAF式过滤，思路很重要。很多人一上来就堆一堆正则，把SQL注入、XSS的特征全部塞进去，结果没过多久就发现误杀严重——正常业务参数里含有"select"或者"union"字样就被拦了，想找个平衡点非常痛苦。我的实践结论是：能白名单的一定白名单，黑名单只兜底。
对参数输入，Nginx层能做的其实有限，真正该做的是在上游应用里做参数化查询和输出转义。Nginx层过滤的价值在于拦截那些明显的自动化探测和轻量攻击扫描，而不是把所有恶意流量都拦干净。想清楚这一点，配置的风格就不容易走偏。
4.2 常见正则拦截规则与误杀问题
如果一定要用正则过滤，我建议把拦截范围控制在URI层面而不是body层面。因为URI的变化相对有限，正则更可控，不会因为POST body是JSON编码而搞得一团糟。
if ($request_uri ~* "(\.\./|\.\.\\|/etc/passwd|/proc/self/environ)") { return 403; } if ($query_string ~* "(union.*select|select.*from|insert.*into|<script|javascript:)") { return 403; }这些规则能挡住最常见的自动化扫描，但对真正经过编码或变形处理的攻击几乎无效。例如攻击者把关键词做URL编码或分块编码之后，简简单单一个正则就漏了。所以我通常把这类规则定位为"降低低级扫描噪音"，而不是安全边界。
误杀的情况在拦截规则上线前务必做充分验证。我曾遇到一个业务系统，搜索关键词支持模糊匹配，用户输入"www.3d.com/apply"这种字符串，被\.\.\/正则命中误判为路径穿越，导致搜索功能间歇性不可用。排查后发现是规则引擎在处理多层转义时过度匹配。后来把这些激进规则全部拿掉，仅保留对/etc/passwd等明确路径特征和高危命令的拦截，误杀率才降下来。
拦截规则上线时要观察一段时间的误杀率，我习惯先在日志模式（只记录不拦截）下运行一周。Nginx的if块不支持直接"记录不拦截"，但可以通过把return 444换成记录日志配合access_log里的特定标记来模拟。具体做法是：命中规则时执行set $attack_flag 1，然后在access.log里记录$attack_flag，等观察期结束再决定哪些规则真正启用403。
4.3 目录穿越与敏感文件请求的拦截
路径穿越类的攻击特征是URI里出现..或反斜杠的编码形式，这类请求的拦截比注入类规则稳定得多。除了上一节的简单正则，还需要注意Nginx对$uri和$request_uri的差异：$uri是经过解码后的URI，$document_uri是等价的，而$request_uri是请求的原始URI，未解码。过滤规则要看清楚到底匹配哪个变量。
比如请求/files/..%2f..%2fetc/passwd，$request_uri里是编码后的形态，$uri里是解码后的形态。有些过滤规则只匹配$request_uri，面对%2f就会漏；只匹配$uri又可能被双重编码骗过。稳妥的做法是同时保留两个变量，一个都不放过，但也要注意不要因此误伤正常请求。
还有一类经常遇到的请求是访问敏感文件名，比如.git目录、.env文件、config.php.bak、web.config等。这些文件的特征是路径片段带点开头或者带备份后缀，一套封禁规则能省去大量扫描噪音：
location ~* \.(env|bak|config|sql|log|tar|gz|zip|ini|old)$ { deny all; } location ~ /\.(git|svn|hg) { deny all; }这两个规则组合之后，至少能拦住大部分自动化扫描器总是尝试的那些文件。坦白讲，这些规则不足以对抗有耐心的攻击者，但它们的价值在于把日志里的噪音大大降低——你翻日志时看到的恶意请求变少了，真正有针对性的攻击反而更容易跳出来被注意到。
5. SSL/TLS加固：HTTPS不是加个证书就完事
5.1 证书链与私钥权限
很多人觉得配HTTPS就是把证书路径和私钥路径写对就完了，实际上证书链的完整性和私钥权限这两个细节经常被忽略。
证书链不完整会导致部分移动端设备校验失败，用户被拦在门外。检查证书链的命令很直接：
openssl s_client -connect example.com:443 -servername example.com观察返回里的verify return code，如果是unable to get local issuer certificate，说明中间证书没配完整。Nginx配置里ssl_certificate指令写的文件应该包含域名证书和中间证书的串联，顺序是域名证书在前、中间证书在后，有些人写反了导致各种奇怪问题。
私钥权限方面，Nginx配置里指定路径后，master进程启动时会读取私钥，如果私钥权限是644且属主是任意用户，虽然运行期可能没事，但机器上其他能读到文件的进程也能拿到私钥。更合理的做法是：
chown root:root /etc/nginx/ssl/example.com.key chmod 600 /etc/nginx/ssl/example.com.key让私钥只有root能读写，Nginx的master进程以root启动时读取私钥不受影响，worker进程则通过继承方式持有密钥信息。这个细节对防内鬼和防低权限进程越权读取都有意义。
5.2 协议版本与加密套件选择
TLS协议版本和加密套件的选择直接决定了客户端能建立起什么强度的加密通道。配置如下（以现代Nginx 1.18+为例）：
ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;TLSv1和TLSv1.1早已被证明存在严重的安全缺陷，直接关闭是底线。ssl_prefer_server_ciphers off是为了优先支持TLS1.3的套件协商逻辑，如果还在支持老客户端可以做适当调整，但现在的环境下建议关掉。
关于加密套件，我最想提的一点是：别为了兼容古董客户端而保留RC4或CBC类套件。曾经有客户为了支持一个老式设备的浏览器，硬是在线保留TLSv1和RC4，结果安全扫描直接给了个最高危评级，后来业务方终于同意下线老客户端才解决问题。兼容性当然重要，但2024年的今天，安全评级不过关对业务的影响往往更大。
5.3 OCSP Stapling、HSTS与安全头联动
证书吊销状态的快速校验是HTTPS体验里容易被忽略的部分，如果每次都去请求OCSP服务器，用户访问速度会受影响，而且万一OCSP服务器不可达，浏览器可能会选择放行或者阻断，行为不一致。开启OCSP Stapling让Nginx自己定期获取证书状态并随握手返回，客户端就不用额外来回查了：
ssl_stapling on; ssl_stapling_verify on; resolver 223.5.5.5 8.8.8.8 valid=300s; resolver_timeout 5s;resolver是Nginx用来解析OCSP响应服务器域名的DNS服务器，这里可以根据部署环境改成合适的DNS。ssl_stapling_verify验证的是OCSP响应是否由CA签发，建议打开。
HSTS（HTTP Strict Transport Security）则是告诉浏览器：这个域名在未来一段时间内只能使用HTTPS访问，任何HTTP请求都在客户端层面直接跳转，不再走网络。配置上需要谨慎处理的是max-age的值，如果站点还没完全切到HTTPS，设置很大的max-age会把用户锁死在HTTPS上，一旦证书或配置出现问题，修复窗口会很尴尬。
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;一个细节是：HSTS头只在HTTPS响应里生效，通过HTTP访问时浏览器会忽略它，所以HTTP server块里不需要设置这个头。另外，如果业务涉及多个子域名，includeSubDomains会让所有子域名都继承HSTS策略，需要确认每个子域名都能支持HTTPS后再开，否则某个子域名的HTTP服务将直接无法访问。
6. 从日志中发现攻击：三次真实排查记录
6.1 识别特征：异常UA、高频IP、畸形请求
配置做得再好，如果没有有效的日志监控，安全状态就是黑盒。我维护的服务器上都开着标准访问日志，但默认格式不足以支撑攻击分析，必改的字段包括：$request_uri（原始URI）、$status、$body_bytes_sent、$http_user_agent、$http_referer、$upstream_response_time、$request_time。其中$request_time在排查慢请求攻击时非常关键。
日志格式里的$request_time尤其重要。我曾经在日志里看到一个异常现象：某个IP的请求全部是POST，且request_time全部在接近超时阈值的位置，说明这个请求一直挂着不释放。配合错误日志里的upstream timed out，基本可以断定是慢速攻击或上游处理异常的典型模式。
高频IP的判断最好用现成的工具做聚合。我不会直接给出某种具体工具名字，但会用一条组合命令来处理这类行为。例如把相同IP的请求数、状态码分布和UA特征聚合起来：
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20这个命令在日志量不大的时候足够用了。日志量大了之后需要引入日志分析平台，将Nginx日志接入到集群里做实时聚合，再配置阈值告警。阈值设计上要有告警降噪的概念，比如同一个IP在5分钟内出现500次4xx且UA里带扫描器特征，才触发通知；单次500错误不告警，连续出现20次才告警。否则深夜被误报吵醒的经历会让你对监控系统失去信心。
6.2 从error log追到一条漏网规则
有次排查线上5xx问题，翻error.log时看到了一条反复出现的记录：upstream prematurely closed connection while reading response header from upstream。一般情况下这是上游PHP进程异常退出导致的，但频率太高且集中在某个接口上，不像偶发故障。
于是把对应时间段的access log按接口聚合，发现这个接口的请求量本身没有异常增长，但upstream_response_time出现了大量极短值，比如0.001秒，对应上游直接断开连接。查上游应用日志后发现是参数解析时抛出了大量异常，再追溯参数内容，发现是请求参数里带了一长串构造过的JSON，应用层解析失败后触发了异常退出。
问题虽然出在应用层，但Nginx层有个规则本可以拦截这类明显畸形的请求——相关的正则我早就写好了，但那次在配置新location时没有继承server块里的过滤规则，导致整个location变成了过滤盲区。这就是之前提到的"add_header在location里会覆盖"的同类问题，值得引以为戒：引入新location时要把父层级的全部安全配置重新核对一遍。
6.3 封禁与解封的操作复盘
遇到恶意IP扫描或高频攻击时，直接在Nginx配置里加deny是最快的办法，但操作时有两个细节影响很大。
第一，直接改配置文件然后reload，在连接数很高时可能造成瞬断。因此我一般使用防火墙规则或专门的动态封锁模块，避免频繁改动Nginx配置。如果必须改Nginx，我倾向于用独立的分片配置文件，便于快速增删、追溯和回滚。
第二，封禁IP要区分类型。如果是扫描器IP，封24小时就够了，因为扫描器的来源IP通常很多，封了也是大海捞针。如果是针对特定业务接口的CC攻击，封禁IP的同时必须配合limit_req缩小阈值，否则攻击者换一批IP很快就回来了。封禁不是目的，把攻击者拖入可持续对抗的节奏才是目的，此时限流策略比单纯地封锁更实在。
有次处理一个持续了三天的CC攻击，对方IP池非常大，手动的封禁整理不过来，后来把限流阈值下调到正常业务峰值的1.5倍，并开启limit_conn的单IP连接数限制，服务立刻稳定下来。日志显示大量连接在Nginx层被直接503，业务方反馈虽然部分用户看到错误页，但整体可用性恢复，攻击也因为没有耗尽任何资源而慢慢转向其他目标。这就是Nginx层限流策略的真正价值。
7. 安全配置上线后的自我检查清单
这部分是我每次动完配置都会走一遍的流程，收益一直是正的。
nginx -t配置语法检查，这个是基础，但我见过有人reload后发现问题却因为没做检查而找不到原因。curl -I查看响应头，确认Server头、安全头是否完整。- 用在线SSL检测工具扫一遍443端口，确认协议版本和证书链没问题。
- 用构造的恶意请求亲手验证拦截规则。例如请求
/files/..%2f..%2fetc/passwd，看是否返回403。 - 观察access.log的请求量曲线，确认新配置没有引入异常多的4xx。
- 如果改了限流参数，找业务方确认正常峰值流量，压测验证不会误杀。
有一次我上线新规则后忘了执行安全头检查，第二天用户反馈页面样式错乱——原来新加的X-Content-Type-Options: nosniff配合静态资源的错误Content-Type导致浏览器拒绝渲染CSS。头部的设置直接影响浏览器行为，这类问题排查起来比较隐蔽，所以在改动响应头配置之后，务必在多种浏览器下跑一遍核心页面。
另一个容易丢的是gzip和ssl的耦合问题。开启了gzip on之后，如果同时设置了gzip_types没包含application/json，部分接口的响应实际是明文传输而不是压缩传输，虽然不影响功能，但安全检查时如果用工具验证压缩配置会给出警告。这是一个小坑，但确实存在。
配置是逐步加固出来的，不是一次性写出来的。每次新增location、每个上游改动、每轮证书更新，顺手过一遍上面的检查清单，不需要额外花费多少时间，但安全水位能稳定维持在高位。
最后想分享一个实际的经验：给Nginx配置做改动时，要有版本管理意识。我习惯把配置目录做成一个仓库，每次修改都留有diff记录。某次回滚配置时，diff记录直接帮我定位到三个小时前引入的一个proxy_set_header错误，否则要靠记忆找出问题点一定会花上很久。Nginx安全这件事，本质上就是：不要把自己放在一个"我相信配置没问题"的位置，而是假设自己会犯错，然后用严格的流程和日志把错误尽早暴露出来，把影响控制在最小范围。
