遇到这种前后状态不一致的问题确实闹心，我结合你给出的所有配置细节，给你梳理一步步的排查方向，咱们先从最直接的本地curl失败入手：

第一步：先搞定EC2实例上localhost:8000连不通的问题 #

这是核心根源，目标组不健康本质也是因为访问不到服务，先把本地连通性解决：

• 先看容器是不是真在运行：登录EC2实例，执行 docker ps，看看你的Shop-Sphere-Container是不是处于Up状态。如果容器已经退出，立刻看日志找原因：docker logs <容器ID>，重点盯Gunicorn启动的报错信息——比如是不是Django的wsgi模块路径写错了？你CMD里是Shop_Sphere.wsgi:application，要确认项目根目录下的wsgi文件路径、拼写完全正确，有没有大小写错误？
• 检查EC2实例的端口监听：执行 netstat -tulpn | grep 8000 或者 ss -tulpn | grep 8000，看看有没有进程绑定8000端口。如果没结果，要么容器没启动，要么端口映射出问题了。
• 进入容器内部测试：如果容器是Up状态，执行docker exec -it <容器ID> bash进入容器，然后在容器里执行curl -v http://localhost:8000/health/，看能不能返回200状态码：
  • 如果容器内部都访问失败，先检查Django的配置：虽然你环境变量设了ALLOWED_HOSTS=*，但要确认settings.prod里是不是真的读取了这个变量？比如有没有写ALLOWED_HOSTS = os.environ.get('ALLOWED_HOSTS', '').split(',')？如果没正确读取，请求会被直接拒绝。
  • 再检查Gunicorn启动命令，你用--bind 0.0.0.0:8000是对的，但有没有可能Django的settings里有配置错误（比如数据库连接、Redis连接失败），导致Gunicorn无法加载application对象？

第二步：排查ECS与目标组的配置匹配问题 #

你任务用的是awsvpc网络模式，这里很容易踩坑：

• 目标组的注册类型必须是IP：awsvpc模式下每个任务有独立的弹性网卡（ENI），目标组不能把EC2实例作为目标，必须注册任务的私有IP。去ECS服务的负载均衡配置里确认，目标组的注册类型是不是选的IP，而不是instance。如果选了instance，ALB会去访问EC2实例的8000端口，但这个端口根本没绑定服务，自然会不健康。
• 目标组健康检查路径要完全匹配：你的Django健康检查URL是/health/（带末尾斜杠），目标组的健康检查路径必须一模一样！如果目标组填的是/health（不带斜杠），Django会返回301重定向，ALB的健康检查会把3xx当成失败。
• 核对任务定义的端口映射：你任务定义里hostPort和containerPort都是8000，这个没问题，但要确认EC2实例的安全组允许目标组的健康检查流量访问8000端口（入站规则要开HTTP 8000，来源是ALB的安全组）。

第三步：复盘Dockerfile与任务定义的细节 #

• 容器健康检查命令的小错误：你任务定义里的容器健康检查命令是curl -f http://localhost:8000/health || exit 1，同样少了末尾的斜杠！curl -f参数会把3xx重定向当成失败，所以这个健康检查其实是不生效的——虽然ECS显示任务“运行中”，但实际容器健康检查是失败的？你可以把命令改成curl -f http://localhost:8000/health/ || exit 1，或者加-L参数跟随重定向：curl -fL http://localhost:8000/health || exit 1。
• Dockerfile的依赖安装：你用了pipenv install --system --dev，开发依赖里会不会有和生产环境冲突的包？比如某些debug工具导致Gunicorn启动异常？可以试试去掉--dev参数，只安装生产依赖：pipenv install --system，重新构建镜像测试。

排查优先级建议 #

1. 先查EC2上的容器状态和日志，确定容器本身能不能正常启动服务
2. 确认目标组的注册类型和健康检查路径是否正确
3. 修正容器健康检查命令的路径问题
4. 验证Django prod配置是否正确读取环境变量

内容来源于stack exchange