AWS Elastic Beanstalk健康转警告求助：疑似黑客请求致EB误判

问题分析 #

从你提供的日志来看，这些upstream prematurely closed connection错误是黑客扫描不存在的PHP后门文件（比如/51314.php、/fusheng.php等）导致的。当Nginx试图将这些请求转发给上游应用服务器时，应用因为找不到对应文件直接关闭了连接，Nginx会默认返回502 Bad Gateway状态码——这正是Elastic Beanstalk（EB）健康监控统计的"HTTP 5xx错误"，从而误判实例健康状态转为Warning，而你的实际应用运行完全正常。

解决方案 #

1. 拦截恶意请求，避免触发502错误

最直接的方式是让Nginx在转发给上游前就拦截这些无效请求，返回404而非502。你可以通过EB的自定义Nginx配置实现：

• 在你的应用根目录创建.ebextensions/nginx/conf.d/block_malicious_scans.conf文件，添加以下配置：

# 拦截不存在的PHP文件请求，直接返回404
location ~* \.php$ {
    try_files $uri =404;
    # 保留原有的FastCGI/上游转发配置（如果有）
    # 例如：
    # fastcgi_pass unix:/var/run/php-fpm/www.sock;
    # fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    # include fastcgi_params;
}

这个配置会先检查请求的PHP文件是否存在，不存在则直接返回404，不会转发给上游应用，也就不会触发连接关闭的错误和502状态码。

2. 封禁恶意IP

如果日志里的恶意请求来自固定IP（比如172.31.35.221），可以直接在Nginx里封禁：
在上述配置文件中添加：

deny 172.31.35.221;

或者通过EB的安全组规则，拒绝该IP的入站流量。

3. 调整EB健康检查策略

让EB只关注应用的健康状态，而非所有请求：

• 登录AWS控制台，进入你的EB环境，在配置 > 监控 > 健康检查中，将健康检查路径修改为你的应用专属健康端点（比如/health），确保这个端点只返回200状态码。这样EB只会统计这个端点的请求，忽略恶意扫描的5xx错误。

预防建议 #

• 启用AWS WAF：配置规则拦截常见的恶意请求模式，比如扫描后门文件、SQL注入、XSS攻击等，从源头阻止这类请求到达你的实例。
• 定期审计日志：通过CloudWatch监控Nginx日志，设置告警规则，当出现大量异常请求（比如频繁访问非常规PHP文件）时及时通知。
• 限制入站流量：通过安全组只开放必要的端口（比如80/443），拒绝不必要的IP访问。
• 保持组件更新：定期更新EB平台版本、Nginx、应用服务器及依赖库，修复潜在安全漏洞。

内容的提问来源于stack exchange，提问作者user4848830