Nginx反向代理场景下应对目录遍历攻击的最优方案探讨

兄弟我太懂你这种被恶意扫描烦到的感觉了——一堆乱七八糟的请求打过来，不仅浪费Nginx和后端Node.js的资源，还得手动加一堆location规则，简直是慢性折磨！咱们一步步来解决这个问题，从“快速拦”到“彻底防”，给你几个实用的方案：

1. 别给404了，直接断连接更解气 #

你说的没错，给恶意请求返回正经404反而有点“抬举”他们了。Nginx有个专属杀招：return 444，这个指令会直接关闭TCP连接，不给攻击者任何响应包——让他们的请求卡在半空中，既浪费对方的资源，又不会留下明确的“这个路径不存在”的信号。

比如把你之前的零散规则换成批量拦截：

# 匹配常见恶意路径，直接断连接
location ~* (^\.env|phpmyadmin|owa|ecp|\.git|\.vscode|info\.php|config\.json|sftp\.json) {
    return 444;
}

这里用~*做不区分大小写的正则匹配，把所有扫描高频的路径关键词都塞进去：比如开头的.env（用^\.env避免匹配到类似xxx.env的正常路径）、phpmyadmin这类常见后台、.git/.vscode这类敏感配置目录，一次性搞定大部分请求。

2. 从源头封禁恶意IP，比拦路径更彻底 #

只拦路径还是被动防御——总有新的扫描路径冒出来。配合fail2ban工具，直接从IP层面封禁频繁发送恶意请求的攻击者，一劳永逸：

• 首先在Nginx日志里标记出这些恶意请求（比如刚才的正则匹配的请求），或者直接匹配日志里的GET /.env这类条目；
• 配置fail2ban的规则，比如只要某个IP在10分钟内发起3次这类请求，就自动把它加入防火墙黑名单（比如iptables），封禁几小时甚至几天。

这样不用天天更新Nginx的路径规则，让工具帮你自动清理垃圾IP。

3. 进阶玩法：返回假响应迷惑攻击者 #

如果你想更“腹黑”一点，可以不直接断连接，而是返回一个看起来像正常站点但毫无价值的响应——比如返回和你的正常404页面一模一样的内容，但在Nginx层面直接返回，根本不碰后端Node.js：

location ~* (^\.env|phpmyadmin) {
    # 直接返回本地的假404页面，或者用root指定静态文件目录
    root /path/to/your/static/fake-pages;
    try_files /fake-404.html =404;
}

这样攻击者扫到的是和正常站点一致的404，没法判断哪些路径是真的不存在，哪些是你故意拦截的，增加他们的扫描成本。

最后总结下最优流程 #

1. 先用Nginx正则批量拦截已知的恶意路径，用return 444断连接，避免请求打到后端；
2. 部署fail2ban监控Nginx日志，自动封禁频繁扫描的IP；
3. 定期更新正则规则，把新出现的扫描路径加进去（比如看到日志里有新的奇怪请求，就补到正则里）。

这样既省心，又能最大程度减少后端的压力，还能恶心一波恶意攻击者～

备注：内容来源于stack exchange，提问作者Passiday