AI 推理请求仍然基于 HTTP 和 TLS，但其连接持续时间、调用模式、配置变更频率和载荷敏感度与普通网页流量不同。IXCDN 与 routed.hk 的运行数据表明，按短请求设置的超时、重试和资源上限不能直接沿用到推理流量。
长时流式响应与空闲超时
流式推理响应可能持续数分钟，模型计算期间还会出现暂时无数据的空闲区间。若边缘代理沿用网页请求的统一短读超时，会把正常推理间隔判定为上游故障并中断连接。
超时策略应区分连接建立超时、首字节超时、流式空闲超时和请求总时长。四者保护的故障阶段不同，不能由单一 request_timeout 代替。
自动化调用、重试风暴与幂等控制
智能体和服务间调用通常由程序自动重试。若客户端、网关和上游同时重试，同一故障会产生倍增流量，并重复消耗推理配额。入口需要明确速率限制、并发上限、重试预算和幂等键；对非幂等请求，网关不能在缺少业务语义时自行重放。
高频配置变更与发布一致性
模型路由、租户配额、访问凭据和安全策略会持续调整，因此配置属于生产数据，而不是偶尔修改的静态文件。配置链路需要具备版本标识、发布物签名、节点应用状态、审计记录和可验证回滚，避免节点同时运行互不兼容的配置片段。
敏感载荷与数据最小化
边缘节点可能处理提示词、接口凭据、工具参数和企业上下文。缓存键、访问日志、错误响应和调试采样都必须执行数据最小化：默认不缓存带鉴权或个性化语义的响应，不在日志中记录完整凭据，对请求体采样设置明确的用途、保留期和访问权限。
安全审计范围与结果
2026 年 10 月 13 日，外部研究团队报告了两个可以串联的配置边界问题。完成直接修复后，我们继续审查请求从入口到计量的完整路径，共记录 71 项问题；截至本文发布时，69 项关闭，2 项持续跟踪。
配置分发也在这次工作中重建。每个节点使用独立配置流，发布物带有签名，节点先验证和准备，再切换到服务状态。DNS、边缘和站点发布已经迁移。具体设计和上线故障记录见《配置分发重构：从红队报告到分阶段发布》。
这 18 天包含六百余次提交，期间出现过金丝雀失败和回滚。发布按节点分批推进，使故障被限制在单个节点，完成原因确认后再继续扩大发布范围。
工程控制原则
- 鉴权正确性优先于延迟优化。 请求规范化、权属校验和凭据隔离属于必要的入口处理，不能通过省略校验降低延迟。
- 故障语义必须显式定义。 新配置验证失败时继续使用上一版；发布异常时停止推进；仅在线路故障时使用经过验证的替代路径。
- 性能指标必须分解到处理阶段。 平均延迟无法区分首字节、流式空闲、回源、重试和节点切换，需要分别记录。
这些原则同样适用于普通 API；长连接、自动重试和高成本上游只是更容易暴露不合理的默认配置。
未完成项与验证边界
按实体增量分发尚未在生产开启；每核一线程的执行模型仍处于设计阶段；代表性负载下的整链路压测仍需继续。因此，现阶段结果不能外推为所有模型、地区和连接时长下的统一性能结论。
routed.hk 与客户流量使用同一套边缘能力，因此相关改动会先在自营服务上验证，再依据观测数据调整生产默认值。
技术细节请继续阅读：《AI 推理流的超时、连接迁移与热路径优化》。