准备停机时先拒绝新请求还是先断旧连接：网关排空怎样验收

准备停机时立即断掉所有连接，会中断原本快完成的请求；继续接新请求又可能永远排不空。本文先定义ready、draining和stopped，再用明确截止的合成事件表核对完成、拒绝和清理集合。当前只验证应用状态参考器，没有启动真实服务或负载均衡。

排空从停止新准入开始

附件在一千毫秒进入draining，五千毫秒达到最终截止。状态转为draining时，readiness应不再表示可接新流量；入口也必须立即拒绝新准入，不能只等外层负载均衡慢慢摘流。因为摘流传播有延迟，这段时间仍可能有连接到达，应用本身需要明确处理。

旧短请求在零毫秒开始，三千结束，应正常完成；旧长请求五百开始，七千结束，超过排空截止，因此列为取消；新请求一千一百到达，直接拒绝。参考结果分别是完成old-short、取消old-long、拒绝new。只统计退出码无法看见三个集合是否符合预期。

等待在途不等于无期限等待

截止点需要覆盖正常收尾，又不能无限拖住升级或宿主关闭。可记录当前在途数、最早截止和剩余清理预算；等待期间若新请求仍增加在途集合，就说明准入门没有关好。取消旧长请求后，还要释放响应、队列许可和连接，不是给它贴一个cancelled标签就算结束。

立即关闭作为对照，会连旧短请求也打断；它可能符合紧急退出策略，但与有期限排空不是同一行为。本文选择保护能在截止前完成的在途请求，具体业务若有事务或后台作业，还需明确哪些工作受这次HTTP排空管理，哪些由另一套持久任务生命周期负责。

将应用顺序与部署传播分别验收

容器先收到停机信号，是进程启动与信号转发层的问题；本篇关注应用已经决定停机后怎样处理请求，两者不能互相代替。Docker启动顺序资料提供依赖与关闭关系背景，但不会自动实现网关业务的readiness、拒绝新请求或等待在途逻辑。

本批离线结果不证明负载均衡已摘流，也不证明真实TCP连接在五千毫秒按时关闭。若补做安全集成，可用假长短请求服务，在排空期间持续投递新请求，保存实际拒绝起点和旧请求结果，同时观察外层仍有多少迟到流量。最终报告应把应用拒绝、负载均衡传播、在途完成与强制清理分别列出，才能判断停机时丢失的请求发生在哪一步。

配套样本与复核入口

下载本篇独立合成输入和实验运行器。上述文件放在同一目录后运行 python run_lab.py C036。完整运行需要全部四十四份输入及相关配置。结果中的method区分离线计算、静态参考检查与回环实测，不能把前两者当成真实网关已通过。

资料核对日期：2026-10-24。官方依据1；官方依据2。

与本站相关基础教程的区别：旧文是部署总指南；本文验证ready摘除、停止新准入、等待在途与最终退出的顺序，不讲备份恢复或渠道回退。