docker stop本身不实现平滑连接重置，它仅发送SIGTERM并默认等待10秒后发SIGKILL；真正实现需反向代理（如Nginx配置worker_shutdown_timeout）、后端应用（响应SIGTERM并关闭就绪探针）、网络层（禁用DNS缓存、使用自定义网络）及编排工具（如Compose的stop_grace_period或K8s的preStop）四层协同。
“docker stop”本身不直接实现平滑连接重置，它只是向容器主进程发送 sigterm 信号并等待（默认10秒）后强制 sigkill。真正支撑高性能反向代理中**平滑连接重置**（即旧连接处理完、新连接无缝接入）的，是反向代理容器自身如何响应停止信号 + 后端应用容器如何配合优雅退出 + 网络层如何避免连接中断。关键不在 docker stop 命令，而在于整个链路的设计协同。
反向代理容器必须支持优雅终止
Nginx、Traefik 或 Envoy 这类代理必须配置为：收到 SIGTERM 后暂停接受新连接，但继续处理已建立的长连接（如 WebSocket、HTTP/1.1 keep-alive、HTTP/2 stream），直到超时或自然结束。例如：
- Nginx 需启用
worker_shutdown_timeout（如worker_shutdown_timeout 30s;），确保 worker 进程在关闭前完成正在处理的请求； - 启动时使用
--sigterm-exit（某些定制镜像）或通过 entrypoint 脚本捕获 SIGTERM 并调用nginx -s quit； - 避免直接用
kill -9或过短的 stop-timeout（如docker stop --time=2），否则会打断活跃连接。
后端应用容器需实现健康检查与就绪探针联动
反向代理（如 nginx-proxy 或 Traefik）依赖容器标签（如 VIRTUAL_HOST）或 Docker API 事件自动更新 upstream。但若后端容器在 docker stop 前仍被代理转发流量，就会导致 502/503。解决方式是：
- 在应用容器内提供
/healthz或/readyz接口，并返回 200 仅当服务真正可服务； - 反向代理配置健康检查（如 Nginx Plus 的
health_check，或 Traefik 的healthCheck），自动将失联/未就绪实例从 upstream 移除； - 应用在收到 SIGTERM 后立即关闭就绪探针（返回 503），同时继续处理已有请求 —— 这样代理会在几秒内停止发新请求，但不中断进行中的连接。
利用 Docker 用户自定义网络与 DNS 缓存控制
Docker 内置 DNS 解析默认有缓存（TTL 1 秒），但上游变更后若代理仍缓存旧容器 IP，可能把请求发到已停止容器。要保障平滑：
- 反向代理配置中禁用 upstream 域名的 DNS 缓存（如 Nginx 使用
resolver ... valid=1s;并配合set $backend "myapp:3000"; proxy_pass http://$backend;动态解析）； - 所有容器部署在同一个 user-defined bridge 网络，依赖 Docker DNS 实现服务发现，避免硬编码 IP；
- 避免使用
host.docker.internal或宿主机网络模式，它们绕过 Docker DNS 和健康机制。
stop 流程应嵌入编排层而非手动执行
单用 docker stop 无法保证上下游协同。生产环境应交由编排工具驱动：
- Docker Compose：定义
stop_grace_period: 30s，并在应用侧监听 SIGTERM 执行清理； - Kubernetes：依靠
preStophook（如 sleep 10 && curl -X POST /shutdown）+ readinessProbe + terminationGracePeriodSeconds； - CI/CD 流水线中，先触发反向代理重载（如
docker exec nginx nginx -s reload）再停后端，或使用滚动更新策略。
平滑不是靠一个命令完成的，而是代理、应用、网络、编排四层共同响应 SIGTERM 的结果。docker stop 只是那个“开始倒计时”的触发器。
