最近有不少文章在说“Nginx 高危漏洞，18 年隐患，影响全球大量服务器”。很多人第一反应是：是不是 Nginx 又爆了一个必须立刻升级的 0day？其实这类说法里，最常被提到的是 Nginx 的 alias 配置错误导致路径穿越 问题。它不是传统意义上的“版本漏洞”，而是一个非常容易被写错的配置坑。

一、问题出在哪里？

Nginx 里经常会用 alias 把某个 URL 路径映射到服务器上的静态目录，比如：

location /static {
    alias /www/wwwroot/site/static/;
}

表面看起来没问题：访问 /static/logo.png，就去读取 /www/wwwroot/site/static/logo.png。

但危险点在于：

  • location /static 末尾没有斜杠；
  • alias /www/wwwroot/site/static/ 末尾有斜杠。

这种组合在某些情况下可能导致路径拼接边界不清，攻击者构造特殊 URL 后，有机会让 Nginx 读取到 alias 目录之外的文件。

二、它会造成什么后果？

如果网站目录结构类似这样：

/www/wwwroot/site/
├── static/
│   ├── logo.png
│   └── style.css
├── config.php
├── .env
└── database.php

本来外部只应该访问 static/ 目录里的图片、CSS、JS。
但如果 alias 配置不严谨，就可能被绕到上级目录，导致敏感文件被读取。

可能泄露的内容包括：

  1. 数据库账号密码；
  2. 网站源码；
  3. API 密钥；
  4. 后台配置文件；
  5. 备份文件和日志文件。

所以它真正危险的地方不是“能不能打崩服务器”，而是可能直接把配置和密钥暴露给外部访问者。

三、正确写法是什么？

危险写法：

location /static {
    alias /www/wwwroot/site/static/;
}

建议改成：

location /static/ {
    alias /www/wwwroot/site/static/;
}

也就是：

location 路径末尾加 /
alias 真实路径末尾也保持 /

这样边界更明确，访问 /static/logo.png 才会映射到真实的 static/logo.png。

四、怎么自查？

在服务器上可以检查 Nginx 配置里有没有 alias：

nginx -T | grep -n "alias"

重点看有没有这种结构：

location /xxx {
    alias /some/path/;
}

如果 location /xxx 没有以 / 结尾，而 alias 路径以 / 结尾，就要重点检查。

修改后先测试配置：

nginx -t

确认无误后再重载：

nginx -s reload

如果是 1Panel、宝塔、Docker 或 OpenResty 环境，要根据实际容器或面板入口重载，不要直接乱改生产配置。

五、额外防护建议

除了修正 alias，还建议加上敏感文件拦截规则：

location ~ /\. {
    deny all;
}

location ~* \.(env|ini|log|sql|bak|zip|tar|gz)$ {
    deny all;
}

同时关闭目录浏览：

autoindex off;

如果网站前面有 CDN 或 WAF，也不要完全依赖它。CDN 能挡一部分请求，但源站配置错误依然应该修。

六、总结

这类 Nginx 隐患的本质是：

配置里的 location 和 alias 边界写错，导致外部请求有机会越过静态目录，读取不该公开的文件。

重点不是盲目恐慌，也不是只看 Nginx 版本，而是马上检查自己的配置：

  1. 搜索所有 alias；
  2. 检查 location 是否以 / 正确结尾；
  3. 禁止访问隐藏文件和备份文件；
  4. 修改后执行 nginx -t；
  5. 再平滑重载 Nginx。

网站安全很多时候不是复杂漏洞，而是一个小斜杠写错了。