tes286

@rzbb 好像确实不一样？实际解析出来 ip 的线路不同。

这里是湖北移动，解析 alibaba-cn-pvg-00001.oss-cn-shanghai.aliyuncs.com ，从 4.2.2.1 获取的 ip 地址为 47.101.9.7 ，从 223.5.5.5,8.8.8.8 ，cloudflare doh 获取的都是 183.192.187.127 。而关闭 edns client subnet 后一律是 47.101.9.7

前者是阿里云多线地址（ AS37963 ），后者是中移上海公司的地址（ AS24400,AS9808 ）

猜测为阿里为了省钱，根据源 ip 分流到差的线路，但是差线路实在是太差了，又或者是没做好优化。而没有 edns 提供客户端信息后，fallback 回更好的线路。

解决方案是用没有 edns 的 dns ，或者有部署本地 dns 的，试一下单独给*.oss-cn-shanghai.aliyuncs.com 配置规则

https://www.cloudflare.com/zh-cn/learning/ssl/what-is-encrypted-sni/

大概是 esni 发力了。esni 需要 https 类型 dns 记录，国内的 local-dns 大概会过滤掉。只是 sni 阻断的网站当然就能联通了。

不过这个方法不太稳定，也支持有限（目前仅观察到 cloudflare 大量部署了 esni ，也就是只能连到 cloudflare 上的网站，并且网站所有者没关掉这个功能），且需客户端支持。

观察 https://<domain>/cdn-cgi/trace 中的 sni 字段，一般是 sni=plaintext 或者 sni=encrypted ，分别对应 esni 是否启用。

嗯，调用 oss 资源没有签名吗，有签名也不会被黑产引导直接访问链接吧（时效限制）。

还有一些其他的措施，可以缓解，比如加上 Referer 限制，强制将 Content-Type 设置为 application/octet-stream 和 x-content-type-options 为 nosniff ，可以部分缓解该情况。

还有一些法子，应该有用但是不太常规。比如，存图片到 oss 时，先加密，然后展示时前端解密。不用太复杂，也没必要藏密钥。总之就是让机器人识别不出这是什么东西。用 xor 就可以（虽然可能绕过，但是足够应对非针对性的攻击）。

不过最好还是别允许 svg 了吧。

先不讨论别的，就是说，以我的经验（我是自学的），有自学能力的人解决问题的能力强，不容易给人添麻烦

我遇到过有些人，习惯了老师带着，看到问题，首先去问，“这个怎么办”，“为什么现在又不行了”，“怎么打不开”

而可以自己探索的人，往往会自己尝试解决，实在没辙才会提出问题，比如在提 issue 时，附加上：

- 错误追踪
- 日志
- 版本
- 可能的原因分析
- 等等

我没有权利要求每个人都必须做到这些要求，但社区对于傻瓜式的提问明显是不太高兴的，因为大家不是淘宝客服

有一些老话，就反应了这点，比如 no code no fix ，又比如名言 read the fucking manual （ RTFM ） 和 search the fucking web （ STFW ）, 都是一个潜规则，尊重他人时间，先自助再求助。纯粹从培训班出来的人恐怕没有多少知道这些的。

久而久之，人们就倾向于让人们自学，也是在设置一个门槛，变相也是在为自己省事。没错，我们希望*宁缺毋滥*，大批的人的涌入并不总是好事。如果不信，翻一翻 GitHub 里热门仓库的 issues ，说不定还能找到亮眼的，一大堆英文中的中文，问着傻瓜式的问题（可能是我见识浅薄，GitHub 中最常见的语言一是英文，二就是中文。其他语言要么是项目本身有本地化才有，要么就没有）

反正，投入精力研究的习惯与能力是必须的，当然啦，如果你可以教给你的学生这些，那就最好了。推荐读物：《提问的智慧》

@Rehtt 嗯..应该是支持的,我的.top 站就在 cf 上

https://imgur.com/e66TBiL

确实。包括我自己自建的 doh 也被 reset 了。

第一个地址被 ban 后换了个新地址，不超过一天就又被 ban 了，adg home 上请求量才几千

最近 dns 环境好像很差，运营商在拦截一切 udp dns 数据包，返回几个奇奇怪怪的 ip （比如那个 ipv6 地址：2001:1 ，很明显是假的。。。）

服了(*￣︿￣)

> www.google.com 1.1.1.1
服务器: [1.1.1.1]
Address: 1.1.1.1

非权威应答:
名称: www.google.com
Addresses: 2001::1
31.13.88.26
> www.google.com 8.8.8.8
服务器: [8.8.8.8]
Address: 8.8.8.8

非权威应答:
名称: www.google.com
Addresses: 2001::1
199.16.158.8
> www.google.com 223.5.5.5
服务器: [223.5.5.5]
Address: 223.5.5.5

非权威应答:
名称: www.google.com
Addresses: 2001::1
31.13.88.26
> www.google.com 2001:4860:4860::8888
服务器: [2001:4860:4860::8888]
Address: 2001:4860:4860::8888

非权威应答:
名称: www.google.com
Addresses: 2001::1
31.13.68.169
> www.google.com 216.239.32.10
服务器: [216.239.32.10] -> ns1.google.com
Address: 216.239.32.10

非权威应答: -> 这里本来应该是权威解析的
名称: www.google.com
Addresses: 2001::1
199.16.158.9
tes286@TESDpc:~$ dig www.google.com +trace @192.168.0.200 -4

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> www.google.com +trace @192.168.0.200 -4
;; global options: +cmd
. 517895 IN NS a.root-servers.net.
. 517895 IN NS b.root-servers.net.
. 517895 IN NS c.root-servers.net.
. 517895 IN NS d.root-servers.net.
. 517895 IN NS e.root-servers.net.
. 517895 IN NS f.root-servers.net.
. 517895 IN NS g.root-servers.net.
. 517895 IN NS h.root-servers.net.
. 517895 IN NS i.root-servers.net.
. 517895 IN NS j.root-servers.net.
. 517895 IN NS k.root-servers.net.
. 517895 IN NS l.root-servers.net.
. 517895 IN NS m.root-servers.net.
;; Received 525 bytes from 192.168.0.200#53(192.168.0.200) in 0 ms

com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
;; Received 1174 bytes from 199.7.83.42#53(l.root-servers.net) in 32 ms

www.google.com. 203 IN A 157.240.17.35
;; Received 59 bytes from 192.26.92.30#53(c.gtld-servers.net) in 43 ms -> 甚至截胡根 dns

正常解析:
tes286@TESDpc:~$ dig dns.google +trace @192.168.0.200 -4

; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> dns.google +trace @192.168.0.200 -4
;; global options: +cmd
. 517679 IN NS a.root-servers.net.
. 517679 IN NS b.root-servers.net.
. 517679 IN NS c.root-servers.net.
. 517679 IN NS d.root-servers.net.
. 517679 IN NS e.root-servers.net.
. 517679 IN NS f.root-servers.net.
. 517679 IN NS g.root-servers.net.
. 517679 IN NS h.root-servers.net.
. 517679 IN NS i.root-servers.net.
. 517679 IN NS j.root-servers.net.
. 517679 IN NS k.root-servers.net.
. 517679 IN NS l.root-servers.net.
. 517679 IN NS m.root-servers.net.
;; Received 525 bytes from 192.168.0.200#53(192.168.0.200) in 0 ms

google. 172800 IN NS ns-tld4.charlestonroadregistry.com.
google. 172800 IN NS ns-tld5.charlestonroadregistry.com.
google. 172800 IN NS ns-tld1.charlestonroadregistry.com.
google. 172800 IN NS ns-tld2.charlestonroadregistry.com.
google. 172800 IN NS ns-tld3.charlestonroadregistry.com.
;; Received 730 bytes from 193.0.14.129#53(k.root-servers.net) in 335 ms

dns.google. 10800 IN NS ns2.zdns.google.
dns.google. 10800 IN NS ns1.zdns.google.
dns.google. 10800 IN NS ns3.zdns.google.
dns.google. 10800 IN NS ns4.zdns.google.
;; Received 539 bytes from 216.239.36.105#53(ns-tld3.charlestonroadregistry.com) in 86 ms

dns.google. 900 IN A 8.8.8.8
dns.google. 900 IN A 8.8.4.4
;; Received 274 bytes from 216.239.38.114#53(ns4.zdns.google) in 249 ms

@allenforrest 现在好了，确实已经解决了。aws 控制台还真有点坑

原本在 lambda 哪里部署到 cloudfront ，我以为全部都配置上了，哪知道只配置了默认路径，像 *.png *.js 之类默认添加的规则还没加上。。。页面上也不说明一下（流汗

@xenme 能改的，用 lambda@edge 改，具体可以看 https://assets.cdn.tes286.site/cdn-cgi/trace （这个是 cloudflare 提供的）

@allenforrest 都不太行。 我这（移动）晚上 10 点左右其实都不咋样，不仅是 cdn ，所有出国流量都极慢，包括我的梯子。不过对比起来，cloudfront 略好一点，虽然都不够 1 MBytes/s
参考： https://storage.tes286.site/%E5%B1%8F%E5%B9%95%E6%88%AA%E5%9B%BE%202024-09-18%20224800.png

不过白天 cloudfront 上限高一些，多线程甚至能满宽带