Nginx的间件配置错误比代码漏洞更致命。我见过太多团队把精力花在追CVE上，易出却忽略了`alias`拼接、漏洞`try_files`逻辑这类日常配置埋下的间件雷。真正被攻击者利用的易出，往往不是漏洞0day，而是间件那些写错的路径和放得太宽的权限。

拿`alias`来说，易出官方文档写得很清楚，漏洞但实际使用中翻车率极高。间件假设你写了`location /files { alias /var/www/html/; }`，易出访问`/files../secret.conf`时，漏洞某些旧版本Nginx会直接解析成`/var/www/html/../secret.conf`。间件路径穿越就这么发生了。易出别笑，漏洞2019年某大厂就因为这个泄露了整份数据库备份文件。修复方式倒简单——alias路径末尾不加斜杠，location用精确匹配，但多少人会主动检查自己线上配置？

再说`try_files`。这指令本意是优雅处理静态文件回退，但如果你写成`try_files $uri $uri/ /index.php?$query_string;`，且PHP-FPM监听的`location`没有严格限制`fastcgi_param SCRIPT_FILENAME`，攻击者就能通过构造`/uploads/evil.jpg/x.php`触发解析漏洞。更隐蔽的是，某些CDN回源配置会把`X-Accel-Redirect`头透传出去，配合`internal`指令的误用，内网文件直接裸奔。我审计过的项目里，至少三成存在这类隐患，而且开发者完全不知情。

CRLF注入是个老生常谈但依旧活跃的问题。当Nginx作为反向代理时，如果上游服务器返回的`Location`或`Set-Cookie`头里含有未过滤的换行符，攻击者就能注入任意响应头。比如`$uri`变量被直接拼进`proxy_set_header`，而`$uri`又未做转义——这可能导致会话固定攻击。有个电商平台因此被批量刷优惠券，损失几百万。修复方案是用`$request_uri`替代`$uri`，但很多老配置还带着这种写法。

别忘了那类不常见的错误——`merge_slashes`参数。默认情况下Nginx会合并连续斜杠，但如果你为了兼容某些API关闭了它（`merge_slashes off`），同时配合`proxy_pass`的URI重写，就可能构造出`http://target//internal//admin`这样的路径，绕过基于前缀的访问控制。我曾在渗透测试中用这个方法打进过某政务系统的管理后台，全程没有触发任何WAF规则。

最后提个容易被忽略的细节：Nginx的`limit_req`模块在分布式环境下形同虚设。单机限流每秒10次，但攻击者用几百个IP轮询，照样能把后端打挂。更别提`limit_conn`对HTTP/2多路复用的失效——每个流都能独立计数，配置稍有不慎就绕过限制。

说到底，Nginx的漏洞大多不是引擎本身的锅，而是使用姿势的问题。与其天天盯着CVE公告，不如花时间梳理自己的location优先级、变量使用场景和代理转发头。生产环境里，一个等号和一个波浪号的区别，往往就是安全与沦陷的分界线。