现场是这样的。服务端在事件流开头写了 retry: 30000，前端断线后仍每秒重连一次，服务端日志显示重连间隔远小于 30 秒，Nginx 上瞬时连接数被打到上限。
中间走过弯路，把「中间层把这一行当成未知字段过滤掉了」当成主因，改完现象没变。
原因不止一个，得分开看。retry 必须单独占一行放在事件块里，写在 data 里无效；前端自己实现了重连，覆盖了浏览器默认行为；首个事件块还没发出连接就断了，浏览器没读到。
第一件事是抓原始流确认该行的位置
curl -N http://127.0.0.1:8000/stream | head -5再往下把 retry 放进首个事件块内
print('retry: 30000\n\ndata: ready\n\n', flush=True)前端删掉自定义重连逻辑后复测
python patch_frontend.py --remove-manual-reconnect剩下的就是在网关侧确认该行没被改写
curl -sN http://gw/stream | head -3怎么算真的好了，看的是同一批现象。断线后重连间隔接近 30 秒，瞬时连接数下降，服务端不再出现重连风暴。
提醒一点。retry 只影响浏览器原生的重连，自定义重连逻辑一旦接管，这个字段就完全无效。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。