一段 SSE 或 gRPC 推理响应可能持续数分钟，中间几十秒没有新字节也很常见。用户换网、缓存后台刷新和源站压缩等普通网络行为，都会在长连接里暴露不同的问题。
IXCDN 的 AI 网关 routed.hk 使用同一套边缘能力。过去两周多，我们针对实际失败用例检查了超时、HTTP/3、缓存刷新、压缩和计量路径。下面只讨论已经复现并验证的部分。
按响应类型配置流式空闲超时
旧逻辑给所有响应使用同一个读超时，默认 10 秒。这个值对普通文件可以接受，却会中断处于正常计算停顿的推理流。
现在，边缘依据源站真实返回的响应头识别长连接流。SSE 和 gRPC 响应在响应头到达之后，正文读空闲窗口不低于 300 秒，每读到一次数据就重新计时。如果配置了更长的超时，则保持不变。
慢读保护也做了同样的区分。按累计速率判断慢客户端，只对声明了长度的有限响应生效。流式响应的时间由模型决定，不能用它来衡量客户端的接收能力。限速策略则保持独立，继续生效。
QUIC 连接迁移的端口校验缺陷
HTTP/3 支持连接迁移，移动设备从 Wi-Fi 切到蜂窝网络时可以继续使用原连接。审查中，一个相关用例看似偶发失败：成功时约 0.3 秒，失败时总是耗尽完整超时窗口。重复运行后可以确认，它由特定端口区间切换稳定触发，并非随机抖动。
抓到的数据包给出了答案：NAT 换址之后，服务端完全不处理新地址的包。根因是 QUIC 库的默认校验器：如果新旧端口跨越了 User（1024–49151）和 Dynamic（49152 以上）区间，就拒绝迁移并丢弃数据包，不发出任何错误。
这个问题上游已经由 aws/s2n-quic#3040 报告，并由 #3166 修复：只拒绝 System 端口与非 System 端口之间的迁移，黑名单端口和 IP 范围检查保留。我们升级了 s2n-quic，并用真实的 HTTP/3 客户端在线上做了对比：同一条连接发 14 个请求，第 1 秒切换源端口。
| 换址方式 | 升级前 | 升级后 |
|---|---|---|
| 同区间 | 14/14 | 14/14 |
| User → Dynamic | 7/14，之后全部卡死 | 14/14 |
| Dynamic → User | 8/14，之后全部卡死 | 14/14 |
升级后全程只有一条连接，换址前后请求耗时几乎不变。
HTTP/2 和 HTTP/3 的后台刷新
缓存对象过期后，边缘可以先返回旧内容，同时在后台刷新。这是兼顾速度和新鲜度的标准做法。
审查发现，这个后台刷新由 HTTP/2 或 HTTP/3 请求触发时会失败：子请求要把原请求转成 HTTP/1 头再解析，而请求行写的是 HTTP/2，解析器不接受。HTTP/1.1 不受影响，所以原有测试一直没有发现。
修复还藏着一个陷阱。HTTP/2 的主机名在 :authority 里，请求头中没有 Host。只改版本号，解析能过，但子请求认不出域名，刷新照样失败。现在转换时会同时写入 HTTP/1.1 和 Host。
我们先写出能复现问题的端到端测试，确认修复前失败、修复后通过。上线后，HTTP/2 和 HTTP/3 触发的刷新都在几秒内完成。
回源与边缘的压缩职责
源站已经压好的内容，边缘不该解开再压一遍。
现在，开启压缩的域名回源时会声明自己支持的编码。源站返回压缩内容时，边缘原样缓存、原样交付；客户端不接受该编码时才解压；需要改写内容的功能才向源站要明文。线上验证中，MISS 和 HIT 的响应都与源站逐字节一致。
这里有一个行业惯例要提醒：CDN 回源会携带 RFC 9110 要求的 Via 头，而 nginx 的 gzip_proxied 默认是 off，请求带 Via 时不压缩。如果你的源站是 nginx，建议配置：
gzip_proxied any;在一台托管十余个站点的 nginx 源站上，我们开启这项配置后，10 个站点首页的回源字节从 220,035 降到 62,214，减少约 72%。没有配置的源站也不受影响，边缘会继续压缩后交付。
计量热路径的锁争用优化
我们把域级计量拆到工作线程分片，让超限拒绝绕过互斥锁，把日志编码移到后台，并修补了上游正文的逐帧复制。下面是隔离基准，不代表生产端到端吞吐：
| 场景 | 修改前 | 修改后 |
|---|---|---|
| 8 线程单热点域计量 | 12.44 Mops/s | 483.44 Mops/s |
| 8 线程同桶超限拒绝 | 15.25 Mops/s | 123.64 Mops/s |
| 8 线程同桶放行 | 14.74 Mops/s | 14.46 Mops/s |
| 64 MiB 输入的目标复制量 | 67,108,864 字节 | 0 |
| 64 KiB 读取耗时 | 22.57 ms | 7.80 ms |
这些是隔离基准，不是线上数据。优化也不是处处都赢：同桶放行没有改善，小块读取且长期保留数据帧时，内存分配反而增加了。
基准结果与验证边界
对 AI 应用而言，最重要的指标是首 token 延迟和流的完成率。这两个数字，我们现在还不能给你。
代表性负载下的整链路压测尚未完成，线上窗口的样本也不足以证明延迟提升。每核一线程的模型还停留在设计阶段。我们修掉的，是那些会让长流中断、变慢、变贵的具体原因。
因此，目前可以确认的是几条具体故障路径已被移除，不能据此宣称所有 AI 请求的首 token 更快。后续结果会继续区分隔离基准、线上观测和完整负载测试，避免把三者混在一起。