非 PHP 站点如何应对高频 PHP 扫描：用 Nginx 444 让扫描器“碰壁”

如果站点不使用 PHP，那么所有 .php 请求都是恶意扫描，让 Nginx 直接返回 444 断开连接即可。

问题

访问日志里常见这样的记录：同一个 IP 几秒内请求上百个不存在的 .php 文件，全部返回 404。

52.187.x.x - - [16/Oct/2026:04:46:07 +0800] "GET /3PJcpMFsD8B.php HTTP/1.1" 404 146 "-" "-"
52.187.x.x - - [16/Oct/2026:04:46:08 +0800] "GET /radio.php HTTP/1.1" 404 146 "-" "-"
52.187.x.x - - [16/Oct/2026:04:46:14 +0800] "GET /wp-login.php HTTP/1.1" 404 146 "-" "-"

这是自动化扫描器在用字典探测后门和漏洞。404 是正常响应，扫描器会认为服务器在正常工作，于是把整本字典跑完，既浪费服务器资源，也暴露了服务器信息。

为什么用 444

444 是 Nginx 的特殊状态码：不返回任何内容，直接关闭连接。扫描器拿不到响应，通常会判定目标异常而放弃，转去扫下一个 IP。

配置

在站点的 server 块中加入：

server {
    # ...原有配置

    # 请求 php 的全都不响应
    if ($uri ~* \.php$) {
        return 444;
    }
}

~* 表示不区分大小写；$uri 不含查询参数，所以 /1.php?p= 这类请求同样会被拦截。

验证

nginx -t && nginx -s reload
curl -i http://example.com/test.php
# 输出 curl: (52) Empty reply from server 即表示生效

注意事项

• 确认站点真的没有 PHP：有些“非 PHP 站点”其实挂着 PHP 写的子系统，比如 /blog 是 WordPress、/admin 用了 phpMyAdmin、某个统计脚本是 xxx.php。先 grep -i "\.php" /var/log/nginx/access.log | grep -v " 404 " 看看历史上有没有返回 200 的 PHP 请求，有就要给这些路径单独放行。
• 用了 CDN / 反向代理时：如果站点在 Cloudflare 等 CDN 后面，Nginx 返回 444 后，访客看到的是 CDN 的 520 错误页，扫描器拿到的仍是一个完整的 HTTP 响应，444 的效果会打折扣。这种情况更推荐在 CDN 的 WAF 规则里直接拦截 .php。
• 444 不等于安全：它只是让扫描器少扫、少拿信息。真正的安全仍然依赖于及时更新软件、不在 Web 目录放敏感文件、关闭不需要的端口。