好的实现不会依赖用户反复刷新碰运气，而会让每个阶段有明确输入、输出、超时和终态。 WebSocket 建立后是长时间双向字节流，默认 HTTP 请求超时和响应缓冲不再合适。代理、LB 与应用的 idle timeout 必须与心跳预算一致。
发布方案必须可复现、可观察并可回退，且回退要包含配置和数据兼容性。健康检查只证明进程存活，核心路由、依赖和后台任务还需单独验收。
先定义系统契约
这项能力横跨客户端、网络与服务端，局部最优很容易制造全局故障。工程决策需要同时约束两端行为、持久化事实和运维预算。
- 只在 Upgrade 头存在时设置 Connection upgrade，关闭 WebSocket 缓冲，timeout 大于数个心跳周期；只信任已知代理写入的 Forwarded。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 重试必须带幂等键、退避和截止时间；超过截止时间后建立新任务，而不是继续复活旧回调。
“反向代理 WebSocket 配置：升级头、超时、缓冲和真实地址”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
哪些情况会破坏契约
边界条件会把隐藏假设变成真实事故。弱网、刷新、并发和容量上限必须组合测试，因为单独出现时它们往往都能被重试掩盖。
- 无条件信任 X-Forwarded-For 允许客户端绕过 IP 风控；代理 timeout 比心跳稍短会周期性切断所有空闲连接。
- 旧响应在新任务建立后迟到，如果没有版本隔离，会把健康状态覆盖成失败或再次启动已取消工作。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
如何逐条验证契约
发布闸门应包含确定性回归、随机时序探索和真实浏览器组合。发现一次失败后保存 seed 与状态轨迹，让它永久成为可重放用例。
- 通过 HTTP/1.1、HTTP/2 前端、IPv6 与两层代理建立连接，保持空闲跨越超时并发送大消息，验证地址、关闭码和内存。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
完成并不等于主路径跑通，而是每个终态都能对账、每个自动动作都受用户意图约束、每个成本都有明确上限。