Nginx解析漏洞，析漏说白了就是析漏当Nginx与PHP-FPM配合时，攻击者能通过一个特殊的析漏URL让服务器执行不该执行的文件。

2019年那会儿，析漏我亲眼见过一个站点被人用`/upload/avatar.jpg/.php`打穿。析漏图片马直接变成了webshell，析漏服务器权限瞬间归了攻击者。析漏这不是析漏什么高深技巧，纯粹是析漏配置不当留下的病根。

漏洞的析漏核心在Nginx的`fastcgi_split_path_info`和`try_files`这两行配置上。很多运维图省事，析漏直接抄网上的析漏模板，结果把`cgi.fix_pathinfo`设为1，析漏PHP-FPM就会自作主张地解析路径。析漏你请求`/shell.jpg/.php`，析漏它找不到`.php`这个文件，就回头把`shell.jpg`当PHP脚本执行了。

修复方案其实特别简单——把`cgi.fix_pathinfo`改成0，或者在Nginx配置里加一行`if ($request_filename ~ \.php$) { return 403; }`。但真正的问题在于，很多开发团队压根不知道自己踩了这个坑，直到被扫描器扫出漏洞才慌慌张张去补。

有个细节值得留意：这个漏洞只在Nginx+PHP-FPM的组合里出现，换成Apache就没这毛病。为什么？因为Apache对路径的处理方式不同，它不会去猜你请求的文件到底是不是PHP。Nginx的设计初衷是高性能静态服务，动态解析交给后端，结果这个“甩锅”机制反而成了突破口。

我见过最离谱的案例是某公司把用户上传的PDF文件直接存在web根目录，文件名还是用户可控的。攻击者上传一个`evil.pdf`，然后访问`/uploads/evil.pdf/.php`，服务器就乖乖地把PDF内容当PHP代码跑。PDF里嵌入的PHP代码直接执行，这操作简直像把钥匙放在门口垫子下面。

现在的Nginx版本其实已经默认关闭了`cgi.fix_pathinfo`，但老项目、老镜像、云市场里的廉价模板，照样带着这个洞四处跑。你去GitHub搜`nginx.conf`，随便翻几个高star的仓库，八成还能看到`fastcgi_split_path_info ^(.+?\.php)(/.*)$;`这种写法。

说句实在话，这个漏洞本身没什么技术含量，但它反映了一个普遍问题——很多人用Nginx只是照葫芦画瓢，根本不清楚每行配置在干什么。安全漏洞往往不是代码写错，而是配置不当。你让一个新手去调Nginx，他能给你整出十个不同版本的坑。

最后提醒一句，如果你还在用LNMP一键包，赶紧去查一下`php.ini`里的`cgi.fix_pathinfo`。别等被黑了才想起来，这玩意儿修复成本几乎为零，但被利用的代价可能是整个服务器沦陷。