这个问题发现得挺早了，本来以为官方会修，升到4.4就好了。结果还是需要自己动手。
其实说大不大，说小也不小。别人用的r2，可能也没那么容易被DDOS个几千块的。但我这个b2的政策可谓是越改越坏，直接让人看见我的存储桶名称。

发现经过

之前有个小朋友来注册我实例，后来要走了，她发嘟文说备份不了账号。我就试了一下。我这大号肯定不行，11个G呢😅。用小号测试，结果发现也卡在那边。我用systemctl status mastodon-sidekiq查看日志（好在规模小），再分析了一下代码，发现.env.production需要加个环境变量，就能下载存档了。可这个存档一下载，好家伙，直接显示我存储桶的名字，而且去掉后面的参数也可以下载。

BUG复现

随便找个我注册过的站点，查看是否使用存储桶。本地存储没有问题，小森林的v3.5改也没问题。如果是v4.x使用了s3存储，生成存档

手机下载存档直接新标签页打开；电脑直接单击下载存档，找到下载任务，右键复制下载地址，再粘贴出来，就会得到这个url
https://g2p1.tx12.idrivee2-3.com/media/backups/dumps/000/000/044/original/archive-20250901134144-489b8264d31db513d71906da83a57cc7.zip?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=6hoK4q54tJB9R3oeLs4Z%2F20250901%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20250901T134148Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=535d9427a6f30462311df071b446b1ea2d4eff971ab2fd6a3b993c6c33d69ac2
其中，这个主机名就是该站的S3_ENDPOINT。
这个存储桶还算安全，我也看了这个供应商，e2存储桶确实比b2要良心，但我最近也懒得再迁移了，关键是每个月差价小于10美分，也不清楚每次下载操作要多少钱。留着备选吧，等哪天我存储桶也被DDOS小鬼盯上了，那我就试试迁移过去。看上去完美适配了长毛象。

这种情况下，即使url有期限，也可能被用户DDOS。

踩坑历程

鄙人能力有限，没法摸清这个临时链接是如何生成的，动用了哪些依赖。而且刚才还发现，如果使用了b2存储桶以外的供应商，反而可能会导致更多的bug。
最后的解决思路就是用这段代码

1
2

url = attachment.expiring_url(expires_in.to_i)
ENV.key?('S3_ALIAS_HOST')? url.sub(ENV.fetch('S3_ENDPOINT') + "/" + ENV.fetch('S3_BUCKET'), "https://" + ENV.fetch('S3_ALIAS_HOST')) : url

取代原来的

1

attachment.expiring_url(expires_in.to_i)

结果就是，目前仅在我实例上（不论是新地址还是旧地址）运行良好。

这属于是b2存储的坑吧