旧版本容器滚动升级“迟迟不退出”的根本原因是应用未优雅终止或连接未释放，而非单纯网络解绑慢；docker compose 仅等待进程退出或健康检查失败，若应用未处理 sigterm、连接池未关闭或反向代理未摘流，旧容器将卡在 running/removing 状态阻塞上线。
旧版本容器在滚动升级中“迟迟不退出”，表面是网络解绑慢，实质是服务未优雅终止或连接未及时释放。Docker Compose 本身不主动等待应用层连接关闭，只按配置等待容器进程退出或健康检查失败——若应用未响应 SIGTERM、连接池未关闭、反向代理未切断长连接，旧容器就会卡在网络就绪状态，阻塞新实例上线。
确认是否真被网络解绑拖慢
先排除误判：执行 docker compose ps 查看旧容器状态，若长期停留在 Running 或 Removing，再用 docker inspect State.Status 和 NetworkSettings.Networks 字段。真正卡在网络解绑时，NetworkSettings 可能残留旧网络端点，但更常见的是容器进程仍在运行（如 PHP-FPM 子进程未退出、Node.js 未监听 SIGTERM）。
强制优雅终止应用进程
关键不是让 Docker 快点解绑网络，而是让应用自己干净收尾：
- 在服务启动脚本或入口文件中注册 SIGTERM 处理：PHP 项目加
pcntl_signal(SIGTERM, fn() => { $server->shutdown(); exit(0); });；Node.js 加process.on('SIGTERM', () => { server.close(); }); - 设置合理的 stop_grace_period（默认 10s），给应用留足清理时间：
deploy:<br> stop_grace_period: 30s
- 避免在容器内用
sleep infinity或后台守护进程掩盖主进程退出逻辑
切断外部连接依赖
旧容器常因反向代理（Nginx、Traefik）或负载均衡器仍转发流量而持续收包，导致连接无法自然断开：
- 在更新前主动从 LB 摘除旧实例：如 Traefik 中通过 label
traefik.enable=false动态下线 - 使用健康检查配合前置探针：在
deploy.healthcheck中设start_period和retries，确保新容器就绪后，旧容器因健康失败被标记为不可用 - 对 HTTP 服务，在应用层返回
503 Service Unavailable并设置Connection: close响应头，加速客户端重连
调整 Compose 网络行为参数
若确认是 Docker 层面网络解绑延迟（较少见），可微调底层行为：
- 禁用网络热插拔：在
docker-compose.yml的 service 级别添加network_mode: "bridge"，避免 overlay 网络中跨节点解绑的额外协商开销 - 缩短网络清理超时（需 Docker 24.0+）：在
daemon.json中加"default-ulimits": {"net_core_rmem_max": {"Hard": 262144, "Soft": 262144}}，减少 TCP 连接 TIME_WAIT 占用 - 避免在
depends_on中滥用service_started——它不保证网络可达，仅控制启动顺序
