大家可能都知道,最近老马脑子一抽,学习墙内平台给X账户加上了IP属地。好家伙,这下炸出不少IP属地中国的用户。
说到无墙IP,不得不引出这两个经典的讨论:
了解技术的可以去看看这两篇讨论,我这里只是做个概括。2025年3月25日,UjuiUjuMandan在net4people论坛发了一篇帖子,解释“防外线”的概念,并扫了一些AS来发现防外线。他把扫描结果放到了karasawa/greenline - Codeberg.org 这个仓库里。
7月14日,某仰止用户(GitHub用户名rawchina)写脚本扫描了整个中文维基百科的编辑记录,筛选出所有中国IP。随后,李老师在推特转发了这个帖子 ,有更多人知道这件事。7月16日, UjuiUjuMandan扫描rawchina提供的数据,确认其中包含许多无墙的IP。
之后,rawchina的账户莫名其妙被封。我是怎么知道是被封的而不是主动删号?如果你在net4people的讨论下,鼠标悬浮在@rawchina上,可以看到这个账户的头像并不是Ghost,正常来说,GitHub主动删号头像会变成Ghost。由此推断,账户是被举报而封。
仰止这个网站在8月1日也炸了,不清楚站长是否被拿下。我更倾向于是站长自己闭站的,因为中共当局拿下网站后,通常不会留下任何信息,而仰止站长在自己的网站和本站都留下过信息。
9月17日,积至泄密的文件中包含“绿色通道”相关文档。同日,@rest-api-v2在net4people的讨论下,表示自己将要扫描英文维基百科的编辑记录。
Twitter 2019年的一篇名为nformation operations directed at Hong Kong的博文中写道:
As Twitter is blocked in PRC, many of these accounts accessed Twitter using VPNs. However, some accounts accessed Twitter from specific unblocked IP addresses originating in mainland China.
Twitter(x)显然不会公布这些账号的IP地址。维基百科是个特例,它公开展示匿名编辑者的IP,我们能知道防外线使用者在什么时间编写过什么内容。
我准备分析英文维基百科的编辑记录,看看有哪些新的发现。
9月19日,@rest-api-v2公布英文维基百科的分析结果,又发现许多中国IP。UjuiUjuMandan扫描这些IP,确认了许多IP是无墙的。
时间线回到今天,X启用IP属地功能。
5 个赞
关于X加IP属地衍生的“中国直连的外宣账号”拉清单事件也刚想发,就顺便发你这了
个人点评:
我发掘并写教程关于各种直连工具和方法,是想帮助那些没有节点的人、作为应急手段、终有一天达成实质上的无墙,没想到五毛粉红早就直连上了
拉清单补充:
ppp213
(ppp213)
2025 年11 月 25 日 01:03
7
直连ip有三种用途,一种是机器人帐号,一种是监狱人工帐号,最后一种是特权家庭。外交部这些都不可能使用直连ip,防火墙是阻碍通信,而vpn或代理则是监控通信,共匪对任何人都不信任,所以外交部访问外网也要有记录监控。监狱可以直连,是因为整个人都被监管着。极权就是要全面控制,不可能留有缝隙的,像文革后期就是极权瘫痪的时期,所以才会有黑市有自留地等等缝隙扩大成“改革”,而习时代则是极权巩固的时期,监控只会越来越严。
这还是受现金狗粮的,可以去墙内搜青年网络文明志愿者,政治利益狗粮嗯撒
编程随想的推特如果显示中国IP属地账户肯定就是被国宝控制了,不过他的Blogspot一直没被拿下。
可能表达的有歧义,原意是,编程随想现在还在上海提篮桥监狱,假如他也在列表中,比如迷人的小红就是编程随想呢,那就挺魔幻的
twitter的一张网页上的域名并不是只有 x.com ,x.com 及其子域名确实可以通过 cloudflare-ech.com 前置隐藏
但这些域名并不托管在cloudflare上
abs.twimg.com
abs-0.twimg.com
pbs.twimg.com
video.twimg.com
域名没有隐藏,风险有点大
还有个 account.google.com 的ip 是 ip封锁的
ppp213
(ppp213)
2025 年11 月 26 日 00:32
13
你讲的是偶尔出动的战狼群,那个有人潜入揭示过,是群里发临时vpn临时帐号骚扰活动,和长期工作不一样。长期工作可以直连的共匪只信任囚犯,党内严禁上外网是专门发文的,共匪谁都不信任,包括它们自己。
1 个赞
oio
2025 年11 月 26 日 00:57
14
Twitter有自己的AS13414 ,云服务用的是GCP,但用的是自己的IP段,全被GFW墙了。在马斯克统治下,X被巴西墙了,这才换上了Cloudflare。
abs.twimg.com是Twitter的静态资源分发域名,用的是Fastly,估计签的合同没到期,暂时没换Cloudflare。
abs-0.twimg.com也是分发静态资源的,用的还是Twitter自己的IP,IP已被墙。
pbs和video用的是Cloudflare。
网页版具体用了哪些外部域名可以看CSP标头,所有Google域名肯定是连接不了的。
1 个赞
oio
2025 年11 月 26 日 01:07
15
GFW把cloudflare-ech.com墙掉不就行了
https://pbs.twimg.com/cdn-cgi/trace
https://video.twimg.com/cdn-cgi/trace
对,这两个地址可以访问,确实是Cloudflare的
当时访问 https://abs.twimg.com/cdn-cgi/trace 发现并不是 Cloudflare的 ,下意识以为twimg.com 子域名全都不在Cloudflare,没想到三级域名居然还分CDN/平台托管
abs-0.twimg.com 用 https://tcp.ping.pe/abs-0.twimg.com:443 测了下端口没墙;从 https://blocky.greatfire.org/https/abs-0.twimg.com 来看是 sni阻断
enotj
2026 年1 月 3 日 07:47
17
*.x.com *.twimg.com *.twitter.com全部强制解析到Cloudflare IP即可,避免X的负载均衡,否则可能会在Twitter IP / Fastly / CF 之间跳
只有 abs-0.twimg.com完全在fastly,迟早上CF反正解析到CF也无所谓吧,都是些emoji加载不了
现在有Meta可以直连有兴趣可以试试…
opened 01:55PM - 31 Dec 25 UTC
~~总之就是1小时22分速通GFW~~
~~直连CF网站、X、Facebook、Instagram、Threads、WhatsApp,当然不直连也行,通过代理时… 也能开ECH~~
## 前言
大概三个月前发现CF可以强制开ECH
一个多月前 _@JonSnowWhite 在 [#529](https://github.com/net4people/bbs/issues/529#issuecomment-3527886471) 提到的论文_
> As discovered by Mücke et al. (https://dl.acm.org/doi/pdf/10.1145/3744969.3748401)
>
> It is also possible to discover ECH configurations of TLS servers by handshaking with them using a non-valid ECH extension (https://www.ietf.org/archive/id/draft-ietf-tls-esni-25.html#section-6.1.6).
研究提出了一种如何探测 ECH 部署情况的方法,利用TLS的HelloRetryRequest来获取ECH配置,结果发现 Meta(Facebook) 正在偷偷测试 ECH ,并且没有在 HTTPS 记录中发布 ECH 配置,仅可以通过该方法获取
当时见到 FB 的几个 SNI 应该早就被封,过了一个月再看,发现有一个没被封,而且 FB 目前的测试 ECH 并没有轮换密钥`AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAEAAWQVZWNoLXB1YmxpYy5hdG1ldGEuY29tAAA=`
那就容易了,结果一试,好家伙,Meta系也能强制ECH
既然过了一百天GFW都没封cloudflare-ech.com,~~还有白票怪的各种什么ECH workers~~,那么就有必要去利用它了
## 正片
之前尝试的方法,要么是采用MitM强制开启ECH,引入自签根证书的风险,要么是在本地路由的DNS服务上强制修改HTTPS记录,有一定的搭建成本
那么为什么不利用大善人的互联网基础设施直接搭建修改HTTPS记录的公共DoH服务呢?
等了辣么久还没人去搞,那么今天我来打个样
还是搭在Cloudflare Workers,
需求喂给LLM:
(其他Prompt略)
```
通过ip4/ip6参数传递CF优选IP
path不要用/dns-query
默认页面伪装404
Workers无法访问CF的IP段,采用Google的DoH服务
Chrome开启DoH后会并行查询A AAAA HTTPS记录,HTTPS记录仅用于获取alpn和ECH
ECH Fronting:
通过其他域名的HTTPS记录获取ECHconfig并修改
CF的ECHconfig从cloudflare-ech.com获取
Mata的ECHconfig目前固定为AEj+DQBEAQAgACAdd+scUi0IYFsXnUIU7ko2Nd9+F8M26pAGZVpz/KrWPgAEAAEAAWQVZWNoLXB1YmxpYy5hdG1ldGEuY29tAAA=
DNS记录的修改逻辑:
X会负载均衡到自有IP/fastly,且不支持IPv6访问,如果是X的域名则直接返回CF优选IP的A 记录,AAAA记录返回空,并且HTTPS记录采用CF ECH
查询 A AAAA 记录如果任意记录是 CF IP 则返回 CF 优选IP,否则直接转发
查询HTTPS记录时,向源DoH查询A和AAAA,如果有任意返回 CF IP 则转发CF ECH,如果有任意返回Meta IP,则转发固定alpn和Meta ECH
CF和Meta的IP段:
(参见geoip,略)
```
调研1小时,拷打 LLM 22分钟,部署workers,绑域名,就可以用了
打开Chrome浏览器,设置安全DNS,填写https://你绑定的域名/doh-ech-test?&ip4=104.18.10.118,104.18.11.118&ip6=2606:4700::6812:a76,2606:4700::6812:b76
可替换为优选IP,如果cloudflare-ech.com故障或CF让其不返回ECH,后面增加&ech=可以获取的域名,CF Free Plan站点都有ECH
吐槽一下Meta的IPv6都有一段face:b00c,真实写在脸上....
## 结论
就是提前体验ECH全面部署的状况,至少目前CF和Meta(一些IP)还是可以直连的,目前没有迹象表明CF会轮换outerSNI,当然压力全部给到outerSNI了
如果后续其他CDN跟进部署,也可以用上述的方法探测到ECHconfig,并自己添加HTTPS记录
因为没有用Meta系的东西,没测试是否所有Meta CDN的资源都能ECH直连,似乎是都可以
~~绕地球一圈回国测试直连太麻烦了吧~~
如果不直连也可利用ECH防止代理看到真实SNI,总之可以提升隐私保护
至于如果全面强制ECH的话,喜欢分流的同学,可能不喜欢ECH,但换个角度或许也是利好分流,规则更简单?一条ech.google就不会漏了?
~~欢迎各种ytber转载,给你们贡献收益,反正都是LLM写的~~
致敬一下[直连老英雄们](https://gfwrev.blogspot.com/2010/03/gfw.html),在赛博大善人的帮助下,现在twitter.com真的可以直连了
也多亏各种标准和协议的推动,让GFW千疮百孔,希望明年ECH转正
## 祝大家新年快乐,2026年GFW倒塌,谢谢大家!
可以使用
不过还是提两点,一、测的时候用的本地dns服务器修改记录,没用works搭建doh服务器修改记录,不确定给出的wroks doh代码可用
二、facebook的ip几乎 都是block的,要寻找可用ip,对封掉的ip进行任何技巧都是徒劳的,这个话题有时间展开来说