Compose 更新上游后 Nginx 报 502：检查依赖重启

后端配置改了，执行 docker compose up -d 后，后端容器被重建，Nginx 却仍显示 Running。接着请求返回 502，日志出现 connection refused。这种情况可以先核对依赖更新是否传递到了代理服务：depends_on 中的健康检查条件安排启动等待，但不会自动让所有未改变的服务重新启动。

这里处理的是 Compose 显式更新依赖服务后的重启安排。若 Nginx 从第一次启动就连错地址，先检查上游配置；容器内 localhost 指向哪里是另一条排查路径。

看重建记录，再看最终依赖配置

用启动时相同的目录、项目名和 -f 参数读取状态。以下假设服务名是 nginx、httpd，实际使用时替换：

docker compose version
docker compose config
docker compose ps -a
docker compose logs --tail=100 nginx httpd

config 可能展开凭据，分享前需脱敏。对照更新时的输出：是否只有 httpd 出现 Recreate，而 nginx 保持运行；Nginx 的报错是否发生在这次更新之后。后端已变成 healthy 只说明健康检查通过，不能证明代理当前使用的连接或地址已经更新。

如果最终模型只剩短写法，或依赖条件被覆盖文件改掉，先修正真实生效的配置。不要仅凭磁盘上一份 YAML 就认定启动命令用了它。

把 restart 写在依赖项下面

Docker Compose 2.17.0 引入了依赖长写法中的 restart: true。在已有代理服务中，可以保留原镜像、网络、端口和上游配置，只补上这项依赖设置：

services:
  nginx:
    # 保留原来的 image/build、网络和代理配置
    depends_on:
      httpd:
        condition: service_healthy
        restart: true

这是配置片段，nginx 和 httpd 仍需各自完整的服务定义，后端也必须有有效健康检查。restart: true 表达的是 Compose 更新依赖服务后，重新启动依赖它的服务。它与服务顶层的 restart: unless-stopped 作用不同：顶层策略交给容器运行时处理容器退出，依赖项中的设置用于 Compose 操作。

修改前保存原配置，并在维护窗口应用。重新创建后端、重启代理都会影响正在处理的请求；无需为补这一项执行整个项目的 down，更不需要删除数据卷。

自动重启不会沿依赖关系传播

后端进程崩溃，由 Docker 的重启策略自动拉起，并不属于上述依赖重启传播范围。只给依赖加上 restart: true，不能保证后端每次自动重启，代理或应用都随之重启。

后端运行期间的中断仍需要应用重连、代理合理解析服务地址，以及适合业务的有限重试。如果问题是应用首次启动早于数据库就绪，可继续核对数据库启动等待与连接条件，不要混成同一个问题。

用下一次受控更新确认行为

应用配置后，再读取同参数的 config，确认 restart: true 位于正确依赖项下。下一次安排好的后端更新，应同时检查 Compose 输出、代理启动时间和实际请求：依赖更新之后，消费者是否按预期重启，后端就绪后是否恢复正常响应。

若代理确实重启仍返回 502，继续检查日志中的目标地址、端口、服务网络和后端监听。上游地址缓存只是可能的分支，单凭“重启后恢复”不能确认它就是根因。需要回退时恢复原依赖配置，用原部署参数重新应用，并确认原镜像与业务入口仍可用。