深夜 GFW 疑似大规模干扰 443 端口连接

[mxdyeah]

目前消息（非官方）： 中国大陆网络故障 自 2025 年 8 月 19 日 16:36 （ UTC 时间） 开始，中国大陆网海外方向的 443 端口流量被完全阻断

群友反馈： IPv4 TCP 443 ，SYN 的首包就插 RST 。和域名是否备案、后缀没关系。

特斯拉官网，Apple ，Microsoft 服务，都没留白名单，我的 API 全挂。

这反映了什么？是不是又有临时工要被开除了哈哈哈

目前 bing 、python.org 的访问正常，github 显示拒绝连接(dns 解析正常)

[hpj]

牛啊！太牛了！

[ENIAC]

https://imgur.com/a/wAkWjb0

玩个鸡儿嘛

[ZztGqk]

确实，同受到影响

[darksword21]

好像恢复了

[ZztGqk]

刚想上 Apple 官网发现被阻断了，还以为是自己网络问题，刚评论完就恢复了

[johnnyR]

HK 全部挂

[darrenfang]

突然 GitHub 打不开了，刚刚恢复

[HADB]

我的香港阿里云也访问不了，不过 cloudflare 能用。现在好像恢复了

[wxf1259059284]

我一小时前突然连不上所有国内网站，除了百度

[xinhaih]

现在恢复了

[Fanly]

刚刚发现许多网站访问不了，我还以为是 Cloudflare 崩了，现在刚恢复

[WizardLeo]

已经恢复了，临时工误操作

[BeiChuanAlex]

大家不要紧张：呐，我是一个汽车修理工，随身带个扳手，很正常吧，正好扳手掉到机房里面了，很正常吧，正好导致断网了，很正常吧

[xqzr]

IPv4 TCP 443 ，SYN （首包）就插 RST 。和域名没关系

[skiy]

刚好相反。今天（昨天）移动直连 GitHub 不需要扶梯。但另一个省的朋友也是移动，但访问不了。

[ZRS]

@skiy IPv6

[obeykarma]

应该是采集行为
为了提升他们的学习模型的精准度吧

[billccn]

@obeykarma 他们本来就是旁路监听，根本不需要中断链接来采集，反而保持畅通更利于他们采集链接建立以后的行为。

我猜测这是某种 fallback 策略，比如分析旁路数据的集群出现问题，完全不处理的话就相当于没有墙，这是万万不可的，于是直接在链路上启用了发送 RST 的规则。

这次其实是绝好的观察墙的运作的机会，希望有人当时利用这个机会系统的 probe 一下墙。

[xiaoz]

我网站也收到了大量告警，一会儿故障，一会儿恢复。

[xctcc]

我的腾讯广州机子 git 拉不下来了。。。。

[totoro52]

应该是在采集数据

[NewYear]

哈哈哈，这个为虎作伥的工程师这个月绩效保不住了。

说不定他也上 V2

[someonesnone]

昨天 hk 全红

[jackOff]

不是，应该是在做流量阈值截断测试，昨晚挂了一个常用的，另外两个备用的没事

[wegbjwjm]

@NewYear 都不是一个阶层的，不过站里多了很多阴兵倒是真的

[ZeekChatCom]

中国人太难了，外部和内部敌人都要围剿我们。

[linhongjun]

这几天 GitHub 都可以直连了

[caiqichang]

临近节日是这样的

[deepbytes]

基操基操，勿要 666

[strobber16]

没受影响，我这里监控数据一切正常。什么鬼

[xdeng]

搬瓦工的受影响了

[elevioux]

凌晨 0 点到 1 点，kuma 监控的几台公司的香港服务器疯狂报警

[latifrons]

半夜 443 端口的梯子都挂了

[xixiv5]

难怪我说昨天晚上怎么回事

[linkbank]

网站联通访问正常，移动和电信无法访问，还没恢复，英国 IP ，正常吗？

要怎么处理？

[crc8]

跨越长城，走向世界。

[thereone]

没有感觉到，自建的节点 tls+vless 采用高位端口。昨天从你说的“自 2025 年 8 月 19 日 16:36 （ UTC 时间） 开始”我是一点感觉都没有。下班回去后还做了一个速度测试都没有什么问题到凌晨 1 点没有任何感觉不能上的。

[uncat]

我这边的实际情况：

- 个人的所有海外服务器都触发了 HTTPS 不可达的告警
- 服务器遍布多个地区（香港、新加坡）
- 触发告警的时间是：08-20 00:39
- 告警消除的时间是：08-20 01:49

给大家参考。

[P945]

@uncat #38 时间是差不多，Https 都被切了。

[uncat]

@P945 是的。

我刚开始还以为只是我的云平台供应商不稳定。看到大家提供的消息才知道范围比我预计的要大。

[unb]

可以啊，大家都有 https 监控，我却没有

[cm2gseh]

#38 那段时间 US 的 IP 小机全挂了，但是 cloudflare 正常，还自个定位礼了一段时间，还以为证书过期了什么的。原来大家都一样。

[LnTrx]

还记得过去改屏蔽一般是在上班时间，这次在午夜有点不同寻常

[LnTrx]

@billccn 有人在当时做过测量和分析了，容易搜到

[mxT52CRuqR6o5]

开除？加薪！

[docx]

@thereone #36 你把标题再读一遍

[Bantes]

新加坡的机子，昨晚监控一直推 down 警告

[mwuxlcanrh]

443 不行，太容易被这样干了。需要用一个随机的端口。

[zzbd]

大内网成为现实？

[felilong123]

是只有家宽受影响吗？我 上海腾讯云上的 blackbox 探针，去港、日、美方向好像都没有受到干扰？
dns/connect/tls/transfer 看起来都正常

[uncat]

@felilong123

> 是只有家宽受影响吗？

不是的。

我有两个探测发起点。一个是家宽下的虚拟机，一个是阿里云云服务器。其中阿里云云服务器上的 black exporter 也触发告警了。FYI

[felilong123]

@uncat #51 阿里云哪个区域呀？出海走的哪条线路？ black 具体表现是后面 tls/transfer 都没了嘛？
我看了下是 tx 广州，
AS4134->AS132203 （ tx 香港）
AS4134->AS45102 （阿里香港）
AS4134->AS2914 （ NTT 东京）
AS4134->AS4134 （ CHINANET-US ）
我这边这四条线 443 好像都没问题

[chjerry2008]

借着这个机会，说一个题外观察：我发现很多使用 vless 协议的人（另一个相关帖子也是），会在跟帖中贴出自己使用的协议，使用其他协议则是相对较少。是使用这个协议的过程中，的确很少遇到断联问题呢？还是该协议的 owner 的心理外延呢？个人旗帜鲜明的不喜欢 owner 。更讨厌近期以日期作为版本号的行为。

[yvescheung]

过几天要阅兵了，网络武器自然也要提前演练一下

[uncat]

@felilong123

> 阿里云哪个区域呀？

阿里云深圳

> blackbox exporter 具体表现

看了 blackbox exporter 的 failed log 。DNS 通了，但在“准备连接/建连”这一步就失败了。

> 出海走的哪条线路

阿里云：AS37963 -> AS45102 联通 169 线路
家宽：AS9808 -> AS45102 CMNET → CMI 线路

PS：阿里云轻量应用服务器，无论在新加坡还是香港，都是 AS45102 。

[Mihari]

01:44
澳门特区政府自家人都没被放过 那我也不能说啥了🤣

[spacezip]

@uncat 家宽我重新拨号 好了一部分线路 单位几十万一个月的政企 瘫了一个多小时，流量全跑 iepl 了

[uncat]

@spacezip

> 流量全跑 IEPL 了

有 IEPL （ International Ethernet Private Line 国际以太网专线）后备，不错不错。

[HFX3389]

@thereone #37 内容不看就算了，标题得看呀，你用“高位端口”当然没事，这次阻断的是 443 ，标准的 HTTPS 端口

[dosmlp]

梯子走的专线，不过墙，不影响

[kyor0]

@Mihari 港澳是境外，谢谢

[peasant]

@felilong123 看了一下上海腾讯云连接香港服务器的日志，01:16~01:48 之间没有收到 443 的响应，后面就恢复了。

[fred649]

腾讯云北京的服务器，2025-08-20 00:38:39 起无法访问，2025-08-20 01:50:35 恢复。

[P945]

@spacezip #57 看了日志，确认同一时间段家宽（联通）也断了，罕见。

[alleluya]

@LnTrx #44 请教有啥分析结果或者结论吗? 在哪能看到

[thereone]

@docx
@HFX3389
看到了，我是说的自建梯子没有问题所以没有感觉到这点。这种大概率就是某些人调整信安平台策略一把梭没有检查仔细导致的草台班子而已。看其他人和别的平台发帖有的省可以有的省不行，基本可以确定就是统一管控平台下发策略存在延迟导致到各个运营商省级出口旁挂设备上策略的生效时间不一致。
基本路径就是 管局和工信的统一管控平台你们说的 GFW--->对接三网运营商集团信安平台---->三网运营商各个省出口旁挂的信安设备。专线（非普通互联网专线）是不过这个信安平台的所以专线的没有问题。

[echoechoin]

@xqzr 我们公司卖的设备都是收到 ack 才发 rst

[clf]

这个明显是某个运营商封禁家宽 443 的防火墙策略被人部署到主干网了。

[HelloWorld23333]

应该是阅兵前，对突发事件的预案演习。

[waye121]

@uncat 果然我说咋突然啥都不能连了，赶紧启动 3HK 的卡应急。确实在 2 点的时候恢复了。

[DAPTX4869]

@wegbjwjm #25 下面的牛马还是一样的

[Narcissu5]

可能是在为 9.3 做演练，这次的阵仗非常大

[jinxjhin]

@alleluya #65 gfw report

[cuicuiv5]

这说明他们已经有了全面切断互联网连接的能力了

[ltux]

白名单模式预演。

[huaweii]

@Narcissu5 说实在的，正经人谁看 9.3 啊，狗都不看 🙈

[lun9]

别急,只是演习而已, 话说大家都用什么 DNS.

[SunsetShimmer]

本报告记录了我们对这一短暂但广泛的封禁事件的测量与分析。主要发现如下：

1. 无条件的 `RST+ACK` 注入仅发生在 TCP 443 端口，未见于其他常见端口（如 22 、80 、8443 ）。
2. 该无条件注入同时扰乱了出入境中国双方向的连接，但触发机制**不对称**：从中国境内向境外发起的连接，客户端的 `SYN` 包与服务器的 `SYN+ACK` 包各自触发三个 `RST+ACK`包；从境外向中国境内发起的连接，只有服务器返回的 `SYN+ACK` 会触发 `RST+ACK`，客户端发送的 `SYN` 不会触发注入。
3. 负责注入的设备指纹与已知 GFW 设备不匹配，因此**此次事件要么由新的 GFW 设备造成，要么是由已知设备以一种新的或误配置的状态运行造成的**。

aHR0cHM6Ly9nZncucmVwb3J0L2Jsb2cvZ2Z3X3VuY29uZGl0aW9uYWxfcnN0XzIwMjUwODIwL3poLw==

[SURA907]

只能祈祷这不是预演了

[w3cll]

可恶！
原来是这样，难怪我在公司跑的脚本昨天凌晨 1 点左右突然中断，导致本来快跑完了的脚本今天上班了又重新跑

[liuguang]

难怪昨晚连不上，GFW 丧尽天良。

[obeykarma]

@liuguang 病魔怎么还没战胜方教授

[yangliudi123]

祖国确实强大了，强盗了

[Kirkcong]

@cuicuiv5 #74 从来都可以

[wuruxu]

.org 的服务 最好通过代理

[Mihari]

@kyor0 港澳是境外这是所有人都明白的道理 我都说是特区政府了 你觉得墙不会给这些合格合规的网站白名单吗 连这种听话的白名单都拦截了不是挺灰色幽默吗