Cloudflare 亚太方向是不是出问题了？

关于 9 月 22 日 香港、新加坡、日本节点部分网络中断的情况说明

一、事件概述
2026 年 9 月 22 日 18:15 （ HKT ）起，我们监测到香港、新加坡、日本节点的国际方向陆续出现丢包、连接中断及访问缓慢，主要影响经 HE 、Cogent 、Arelion 等国际骨干进入的流量；各地本地及直连方向不受影响。

二、原因说明
经排查，故障源于第三方运营商 HGC （ AS9304 ）的 BGP 路由泄漏：
• 我们与多家网络存在对等互联（ peering ），对等路由只应在双方之间使用，不应再向外转发；
• HGC 将通过对等方（如 TWGate AS9505 ）学到的我们的路由，错误地重新宣告给了它的上游 FLAG/GCX （ AS15412 ）；
• 这些路由随后扩散到 HE （ AS6939 ）、Cogent （ AS174 ）、Arelion （ AS1299 ）等国际骨干网。按行业惯例，骨干网优先选用来自其客户方向的路由，因此这条错误路径覆盖了我们正常的优选路径；
• 大量国际流量被牵引到 HGC—FLAG 这条不具备相应容量的路径上，链路拥塞，造成丢包与中断。

为什么三地同时受影响：泄漏针对的是路由而非某个机房。我们各节点的前缀经上游运营商和交换点正常宣告后，凡被 HGC 学到的都会被一并泄漏，因此香港、新加坡、日本的国际方向同时受到影响。我们的机房设备、线路及自身网络在此期间均运行正常。此次故障的根因在第三方网络内部，公开 BGP 数据（ bgp.tools / RIPE RIS ）可查证。国际骨干当前看到的错误路径示例：AS15412 → AS9304 → AS9505 → AS983 → AS38136 。

三、处理过程
• 18:20 监控告警，NOC 开始排查；
• 18:25 确认为 HGC 路由泄漏，影响范围扩大至新加坡、日本节点；
• 18:30 撤回/收紧向相关交换点及对等方的宣告，调整路径优先级；
• 18:45 联系 HGC 、FLAG/GCX 及各上游 NOC ，要求在源头过滤，并申请上游对 HGC 方向限制宣告。
• 19:00 观察到 HGC 仍通过我们上游运营商的正常宣告学到路由并继续泄漏；


四、当前状态与下一步
需要坦率说明的是：我们能单方面控制的宣告已全部调整，但 HGC 仍可通过上游运营商的正常宣告学到我们的路由，这一环节不由我们控制，也不能简单切断。彻底恢复取决于 HGC 或 FLAG/GCX 在其网络内完成过滤，在此之前仍可能反复出现间歇性抖动。我们将：
• 持续监测各节点、各方向路径，发现新的泄漏路径立即处置；
• 持续催促 HGC 、FLAG/GCX 及各上游的处理进度

歪个楼，中国的三大运营商移电联，普通家庭宽带客户，命中的 Cloudflare CDN 边缘节点都是美国（虽然延迟高，但运营商节省费用），所以这次很偶然的，绝大多数中国用户都不受影响……

反而是极少数精品网，联通 AS9929 ，移动 AS58807 ，会命中 Cloudflare CDN 的香港和日本节点……会受到影响。

原来如此 我说突然的网络超时

@Cert 我这边主要是长期挂的香港出口（有自己的落地 IP ），正好命中 HKG 机房，基本就是写博客的时候发现图片加载不出来了，才排查到这个问题

我们的服务器在新加坡，昨天发现 Cloudflare 回源特别慢，且间歇性出现 520 522 525 。同时除了生产服务外，承载基础设施的开发用服务器也同样表现。

关闭 Cloudflare 加速，直接请求反倒是非常稳定，推测不是 Cloudflare 的问题，而是回源的时候恰好走了被 AS9304 霍霍过的路由。

前天晚上開始就發現有問題了 jp kr - hk ，昨天擴大到 sg 等等

@suiyun39 我怀疑也是如此，不过奇怪的点在于，如果回源连不上源站，理论上 CF 会报告 522 之类的，但我这边完全没有观察到类似情况，一点响应没有就断开了

@MFWT 两种情况都有可能，一是 Cloudflare 无法回源，一是 Client 到 Cloudflare 的东南亚节点也有可能过被牵扯到 HGC—FLAG 这条线里直接丢弃。

另外一提，HGC 这逼公司是老演员了，21 年曾一脚干翻 60 多个国家的主干网络，25 年也干过一次 BGP 路由泄漏的操作。(╯°□°）╯︵ ┻━┻

@suiyun39

牛逼....

感觉我这边更像是回源的锅，因为可以正常收到 CF 的 HTTP 响应头，至少去边缘的链路是没事的