2026 年 10 月 13 日，一支外部安全研究团队向 IXCDN 报告了两个可以串联的配置边界问题。我们当天开始隔离、核查和修复，并确认待验证记录没有进入有效配置。
直接修复完成后，三个产品入口分别维护域名权属的现状仍表明底层设计存在重复实现。审查范围因此扩展到请求处理和配置发布的完整链路，并最终触发配置分发重构。
端到端请求路径审计
团队选了一条普通请求，逐段检查入口解析、权限判断、缓存、回源、交付、日志和计量。这样比按模块翻漏洞清单更容易发现同一种错误在不同路径里的重复实现。
审查共记录 71 项问题，主要集中在六类：
- 自定义交付路径绕过公共处理阶段，导致限速等策略覆盖不完整；
- Host 大小写、路径编码和重复请求头等原始输入过早参与决策；
- 同一凭据承担多种职责；
- 部分异常路径默认放行；
- 队列和任务表缺少明确上限；
- 热路径存在深拷贝和同步阻塞。
对应修复也尽量落在公共边界上：请求只在入口规范化一次；回源地址在 DNS 解析后校验并检查自环；中继改用专用凭据；无法确认的安全判断默认拒绝。
截至本文发布时，69 项已经关闭，另外 2 项仍在跟踪：存量节点的回源地址校验核对，以及计量热路径的进一步降本。没有未分配或无人处理的项目。
可验证的配置发布状态机
审查中风险最高的部分是配置分发。域名、证书、访问控制和安全策略都通过它到达边缘；routed.hk 的 AI 网关配置也走同一条链路。我们没有继续在旧流程上增加条件，而是重新定义了发布单位和节点状态。
- 节点级配置流：每个节点只接收自己的配置，故障范围可以限定到具体节点。
- 签名发布：发布物使用 Ed25519 签名，节点用本地固定的公钥验证；仅控制传输链路不足以伪造有效配置。
- 先准备后切换：配置完成验证和准备后进入
prepared，再切换到serving。任一步失败都保留上一版有效配置。 - 两阶段回滚：回滚先生成并暂存，由运维再次确认后才发布。发布后配置流仍保持暂停，避免旧问题尚未修复就继续推进。
DNS、边缘和站点发布目前已经使用这套流程。管理边缘暂时保留在旧路径，因为它承载配置控制通道本身；在新路径充分验证前，不把控制入口和被控对象同时迁移。
分阶段发布发现的故障
发布按节点逐台进行，每次都与站点基线比较，发现异常立即回滚。这个决定限制了三次实际故障的影响范围：
- 首次金丝雀激活早于监听端口就绪，授权探测因此失败。修复后，激活必须等待监听器完成启动。
- 一台节点磁盘上的配置已经过期，新二进制拒绝启动并进入重启循环。现在替换二进制前会先验证磁盘配置，而不再用“旧进程仍在运行”推断文件有效。
- 割接后仍有少量路径引用旧地址。发布流程因此加入固定的端到端验收，不再只检查进程和健康端点。
节点无法验证新配置时继续使用上一版，这项设计在上线期间多次生效。它并不能消除错误，但能让错误停留在发布阶段，而不是直接进入客户流量。
未完成项
- 按实体增量发布已经实现，生产节点目前仍下载完整工件；
- 写入侧分片和迁移门控要等陈旧进程记录清理完再开启；
- 跨境弱网场景还需要更多持续验证。
感谢研究团队负责任地披露问题。该报告除促成两个入口的直接修复外，也帮助我们定位了多条路径共用的设计缺口；本文列出的未完成项将继续跟踪。