Django部署AWS Elastic Beanstalk报web服务未运行故障求助

Following services are not running: web和nginx的connect() failed (111: Connection refused)是同一个问题的两种表现：EB上托管Django应用的WSGI服务根本没成功启动，nginx转发请求时找不到监听的后端进程才报连接拒绝。你日志里列的healthd、xray、httpd相关警告都是平台通用提示，不是故障根因，不用在这上面耗时间。

1. 修正WSGI启动配置，避免EB自动识别失败 #

EB部署Python应用默认用Gunicorn启动WSGI服务，和本地用manage.py runserver的启动逻辑完全不一样，绝大多数这类报错都是Gunicorn找不到应用入口导致的：

• 先在项目根目录（和manage.py同级的路径）新建名为Procfile的文件，手动指定web进程启动命令，跳过EB的自动识别逻辑，内容如下：

web: gunicorn --bind :8000 你的Django项目包名.wsgi:application --log-level debug

注意把你的Django项目包名替换为存放settings.py、wsgi.py的那个文件夹的名称，比如你的wsgi.py路径是myapp/myapp/wsgi.py，这里就写myapp.wsgi:application；监听端口必须用8000，EB的nginx默认只会把请求转发到8000端口，改成其他端口会直接连不上。

• 如果你已经配置过.ebextensions下的服务启动配置，先把自定义启动配置删掉，先用上面的Procfile最小配置验证启动。

2. 排查依赖缺失问题 #

本地运行正常不代表EB环境装全了运行依赖：

• 确认项目根目录的requirements.txt里列全了所有运行必需的包，必须包含两个关键依赖：gunicorn（WSGI服务本身）、psycopg2-binary（PostgreSQL连接驱动，别写psycopg2，EB环境编译psycopg2经常缺系统依赖报错，直接用预编译的binary版本即可）。
• 部署后直接在EB控制台拉取全量实例日志，优先看/var/log/web.stdout.log文件，这是Gunicorn的启动标准输出日志，不管是依赖缺失、wsgi路径错误、代码报错还是数据库连接失败，这里都会打印完整的错误栈，比你之前看的nginx、daemon日志定位效率高很多。

3. 排查RDS连通性问题 #

你怀疑的数据库连接问题确实可能导致服务启动崩溃，尤其是项目启动时就执行了数据库查询、migrate之类的操作的场景：

• 先检查RDS的安全组入站规则，必须放开EB实例所属安全组的5432端口访问权限，很多人配置RDS时只加了本地办公IP的白名单，EB实例根本连不上RDS，启动时直接超时退出。
• 如果RDS没有配置公网访问，要确认EB实例和RDS在同一个VPC下，且路由规则打通。
• 排查时可以临时注释掉settings.py里启动阶段的数据库相关逻辑，先把web服务拉起来，再通过EB的SSH连接进实例，手动用psql命令测试RDS连通性，逐步缩小问题范围。

无关警告说明 #

你日志里的几个警告完全不影响web服务运行，不用花时间处理：

• log file "/var/log/nginx/healthd/application.log.xxx" does not exist：web服务没启动，healthd没有日志写入目标才报的错，web服务正常运行后会自动生成对应日志文件。
• process xray is not registered/process httpd is not registered：你用的是Python+Nginx平台，不是Apache平台，也没开启X-Ray链路追踪，这是EB初始化脚本的通用输出，属于正常提示。
• process healthd is already registered：健康检查进程重复注册的提示，是EB平台自身的逻辑输出，和应用故障无关。

先做3个简单改动再重新部署，基本能覆盖绝大多数同类问题：

• 写对Procfile里的gunicorn启动命令，确认WSGI入口路径正确、监听8000端口
• 确认requirements.txt包含gunicorn和psycopg2-binary两个核心依赖
• 部署后拉取web.stdout.log查看Gunicorn启动的具体报错，针对性修复即可。

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