CLOUDFLARE

自动密钥交换把算法优先顺序与允许算法范围分开管理。旧接口仍可见，不代表旧脚本仍握有原来的控制权。

Cloudflare称，8月23日01:06至01:54 UTC，部分客户在北美源站与其新加坡数据中心之间的流量出现更多5xx错误和超时。事件已经解决，但公开说明中的具体影响范围是在这段窗口结束后才出现的。

Cloudflare在发布亚太地区网络性能事件8分36秒后称已实施修复，但截至事实截止点仍未解决。公开记录没有城市、产品、症状或客户分母，运营方只能把供应商的UTC时间线与自身路径证据对齐，不能用“亚太”替代影响范围。

Cloudflare在8月4日关闭了两起彼此独立的Workers事件。第一起让本不该出现的`Temporal`全局对象进入运行时，而且它把当前时间报告为1970年；第二起则在部署入口拒绝了带有`nodejs_compat`且兼容日期不早于8月4日的配置。Cloudflare没有说明两者同源。它们共同暴露的是一条更长的控制链：平台既决定代码能“看见”什么，也决定代码能否进入生产。

Cloudflare在8月3日用约1小时51分钟处置了一次Workers Builds事件。最值得关注的不是最终“已解决”，而是15:38 UTC的中间状态：构建已经不再失败，用户却仍可能遇到延迟。它把两种经常被混为一谈的可用性分开了——上一版本能否继续运行，以及团队能否把下一次修复可靠地送上生产。状态页没有披露根因、客户数量和生产运行影响，因此这是一场范围明确的构建链路事件，不应被扩写成全球Workers全面中断。

Cloudflare用2小时17分50秒处理完一宗Gateway事件：使用归属伦敦的专用IPv4出口地址的客户，可能无法访问公共互联网。固定出口IP常被当成安全白名单里的静态标识，但它并非脱离网络路径而独立存在。地址要通过提供商的网关、路由和区域服务才能发挥作用。本次公开记录没有给出原因和影响分母，却清楚展示了“稳定身份”如何同时形成一个狭窄而真实的故障域。

2024 年 6 月 27 日，Cloudflare 的公共 DNS 解析器地址 1.1.1.1 受到两起相互独立的 BGP 路由事件影响：一项针对 1.1.1.1/32 的异常起源通告，以及一项针对 1.1.1.0/24 的路径泄漏。事件表明，地址分配记录、ROA、路由过滤、客户出口策略、RTBH 授权、传播监测和撤回验证分别解决不同的风险；任何单一机制都不足以独自保证可达性。

一次看似局部的配置清理，如何在语法仍然有效的情况下扩大路由出口权限，并把源代码、运行状态、邻居关系、外部观测与回滚责任变成一条必须闭合的证据链。

一次自动化变更撤回了约 1,100 个客户自有 IP 前缀。事件表明，资源登记、路由授权、服务绑定、路由器实际状态和互联网可达性是相互关联却不能彼此替代的证据层；真正可问责的网络控制，必须持续证明这些状态保持一致。

2013 年 3 月的攻击表明，暴露在公网的递归 DNS、可伪造的源地址与共享互联路径，会把分散而看似轻微的配置疏漏汇聚成巨大的外部成本。责任认定不能停留在机构标签或流量峰值上，而应查明谁控制了每一个实际运行的环节，以及修复是否经过独立验证。

Cloudflare在7月31日11:51:07 UTC记录了一起轻微事件，最初涉及Analytics、Dashboard及相关API，随后扩展到Pages和Worker构建。修复在12:43:57进入监控，13:01:59宣告解决。Cloudflare明确表示，CDN缓存文件交付和其他边缘安全功能未受影响。这次事件揭示的是“站点仍可访问，但管理、观测和发布变更受阻”的分层故障，而非整个Cloudflare网络中断。