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

9 月 22 日
 MFWT

源站在 US ,访问同一张图片,US 秒开,HK 无法加载,表现为 HTTP 响应头都传完了,能看到缓存状态为 HIT 了,但响应体不返回任何内容,连接也不断开。

写这段的时候 screen 挂了 curl ,请求发出后等了很久,还是一个字节都没有输出,但计时器还在跳,最后在 22 分 30 秒的时候 curl 报错 HTTP2 INTERNAL_ERROR ,连接断开。

下午好像听人说 HGC 漏路由了,导致部分 IP 段断连,自己也观察到香港机器 ping 美国机器完全丢包,不知道是否与此有关系?

5094 次点击
所在节点    宽带症候群
25 条回复
anarkh35
9 月 22 日
关于 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 及各上游的处理进度
Cert
9 月 23 日
歪个楼,中国的三大运营商移电联,普通家庭宽带客户,命中的 Cloudflare CDN 边缘节点都是美国(虽然延迟高,但运营商节省费用),所以这次很偶然的,绝大多数中国用户都不受影响……

反而是极少数精品网,联通 AS9929 ,移动 AS58807 ,会命中 Cloudflare CDN 的香港和日本节点……会受到影响。
isbase
9 月 23 日
原来如此 我说突然的网络超时
MFWT
9 月 23 日
@Cert 我这边主要是长期挂的香港出口(有自己的落地 IP ),正好命中 HKG 机房,基本就是写博客的时候发现图片加载不出来了,才排查到这个问题
suiyun39
9 月 23 日
我们的服务器在新加坡,昨天发现 Cloudflare 回源特别慢,且间歇性出现 520 522 525 。同时除了生产服务外,承载基础设施的开发用服务器也同样表现。

关闭 Cloudflare 加速,直接请求反倒是非常稳定,推测不是 Cloudflare 的问题,而是回源的时候恰好走了被 AS9304 霍霍过的路由。
zagfai
9 月 23 日
前天晚上開始就發現有問題了 jp kr - hk ,昨天擴大到 sg 等等
MFWT
9 月 23 日
@suiyun39 我怀疑也是如此,不过奇怪的点在于,如果回源连不上源站,理论上 CF 会报告 522 之类的,但我这边完全没有观察到类似情况,一点响应没有就断开了
suiyun39
9 月 23 日
@MFWT 两种情况都有可能,一是 Cloudflare 无法回源,一是 Client 到 Cloudflare 的东南亚节点也有可能过被牵扯到 HGC—FLAG 这条线里直接丢弃。

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

牛逼....

感觉我这边更像是回源的锅,因为可以正常收到 CF 的 HTTP 响应头,至少去边缘的链路是没事的
BeautifulSoup
9 月 24 日
@Cert 并不是,电信大部分家宽访问 CF 命中的是荷兰阿姆斯特丹 PoP ,移动是西雅图,联通是洛杉矶
AssassinYe
9 月 24 日
难怪最近收到的反馈很多
hzh1990
9 月 24 日
哎 反正 5xx 暴涨~ 然后竞价广告下架
yyzh
9 月 25 日
@BeautifulSoup 看地区吧?我这电信大内网家宽连 cf dns 去新加坡.延迟非常棒.
BeautifulSoup
9 月 25 日
@yyzh 1.1.1.1 和 1.0.0.1 是特例
YunXuyun
9 月 27 日
@yyzh 电信到 cf 的路由是今年才改的吗?我记得以前都是只有去西美的,而且速度很感人,到了晚上根本不能用。现在除了新加坡的节点之外,还有什么好推荐的吗( ipv6 节点也可)?
yyzh
9 月 28 日
@YunXuyun @BeautifulSoup 应该给了钱就能用的吧.例如下面这些给了钱的.用电信开就是走的 CF 新加坡.
www.wto.org
www.udacity.com
www.shopify.com
www.glassdoor.com
BeautifulSoup
9 月 29 日
@yyzh 是,花钱了电信可以走优化路由去新加坡,不花钱享受不到。但即便花钱了,联通也是去美西
yyzh
9 月 29 日
@BeautifulSoup 不花钱可以偷 ip 用嘛。那一堆 cf 优化不都这样来的。
联通的话应该是 cf 那边有问题。其实联通自己到 cf 是走 hkix 直连到香港的。但问题是 cf 自己回来绕路了
ip.skk.moe
crc8
9 月 29 日
@yyzh 深圳电信可以用 CF DNS ?我看国内不通 1111 啊
BeautifulSoup
9 月 29 日
@yyzh 优选 IP 本来就违反 ToS ,8 月已经封过一波了,现在已经不是个好选择;至于联通,我目前没测试到可以接入 HKIX 的,上面列的几个站点电信去新加坡、移动去香港,只有联通去程直接到美西。

@crc8 大部分地方的电信通 1.1.1.1 ,确实是去新加坡。电信的 DNS 解析托管到 CF 的域名也是递归到新加坡的 PoP 查询

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://v2ex.ih06.com/t/1244076

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX