Notices by 毛茸茸生长 :trans_flag: (bgme@bgme.me)

@aquilegia
有点好奇道法是什么？

@roytam1 @kt
反向代理还是 nginx 更靠谱。
squid 我只用过正向（将 socks 代理转换为 http 代理），不太熟悉反向怎么配置。

@kt
caddy cache 真的是太差了。
caddy 2 至今没有一个稳定可用易用的 cache 方案。

@kt
最后附上我折腾 Caddy cache 的经历。

--------

Caddy 2 目前可以使用的缓存模块有两个 http.handlers.cache （ https://github.com/caddyserver/cache-handler ）、http.handlers.http_cache （ https://github.com/sillygod/cdp-cache ），但均是非官方模块，Caddy 2 自身并不支持缓存。
如果你因为一些需求，比如说反代S3媒体库，需要用到缓存功能，Caddy 2 就……
一个反向代理，连缓存都不支持，多少有一点嘈点满满。

下面再说一说这两个非官方的缓存模块。

http.handlers.cache 基于 Souin cache，存储后端支持 Badger、NutsDB、Etcd、Olric、Redis，值得注意的一点是该模块并不支持像 Nginx 那样的 filesystem cache。

后三个都是 in-memory cache ，内存消耗巨大，本人只尝试使用过 Olric （因为支持 embedded olric 无需额外安装软件）。
embedded olric 不知道为什么，内存消耗特别大，测试时缓存 nitter 媒体文件，请求了大约1000个文件，传输流量140MB，Caddy的内存占用就已经达到了1.5GB。继续测试，发现Caddy的内存占用基本上是按请求流量十倍大小来算的。

前面两个 Badger 与 NutsDB 都是KV数据库，算是 filesystem+memory 的 hybrid cache 。
但实际使用下来，问题多多。
Badger 存在缓存污染问题，模块开发者自己都建议不要使用 Badger （ https://github.com/caddyserver/cache-handler/issues/27 ）。
NutsDB 倒确实没有缓存污染问题，但却存在内存占用的问题。将 EntryIdxMode 设为 HintBPTSparseIdxMode，按 NutsDB 官方的说法『HintBPTSparseIdxMode 是专门节约内存的设计方案，单机10亿条数据，只要80几M内存』。但实际使用中却存在内存占用持续增长的问题。反代 img.bgme.me ，大约8个小时后，便 OOM Kill 了，OOM kill 时 total-vm:26129016kB, anon-rss:9457364kB。

此外 http.handlers.cache 配置相当的复杂，一点都和简单易用沾不上边。

再说一说 http.handlers.http_cache 模块。
http.handlers.http_cache 倒确实是简单易用，也完全是基于文件的 filesystem cache。
在实际使用中发现存在部分请求超时的问题。这是一个老问题，之前也有人提过 issue https://github.com/sillygod/cdp-cache/issues/24 ，按理来说应该也修复了，但在实际使用中我确实是又遇到了这个问题（caddy v2.7.0-beta.1 、cdp-cache v0.5.0）。感觉可能与请求并发有关，本地环境测试时并没有那么容易出问题，但放到生产环境中，便经常出现请求超时。
另外，重启服务后该插件会令之前缓存的Key丢失，遇到相同请求时会再次请求上流。 https://github.com/sillygod/cdp-cache/issues/38
此外，该插件并不支持 Nginx 那样设置最大存储大小。

总之，目前 Caddy 并不存在靠谱的 Cache 方案。如果你因为一些需求，比如说反代S3媒体库，需要用到缓存功能，并不非常推荐使用 Caddy。

@kt
主要还是用的 Caddy。
部分需要 Cache 的站点，比如说 img.bgme.me ，中间套了一层 nginx。

还用 Caddy 有好几个原因：

需要多节点间证书共享与管理时，Caddy 要方便很多。
certbot+nginx 单节点的话还好。但如果我想四五个VPS，共用一张证书，certbot+nginx 就比较麻烦了。还要搭配一套独立的证书管理与分发系统。
Caddy由于模块化的设计（多种存储后端），以及自动证书管理功能，多节点共用证书就方便多了。
只需要多节点配置为同一个存储后端（如 redis、dynamodb），就OK了。

nginx 不支持对请求头、响应头进行文本替换。
举个例子，我现在建立了 bgme.bid 这个 bgme.me 的镜像入口，由于 mastodon 响应中设置了 content-security-policy ，而且还都是基于 bgme.me 域名设置的，因此我需要将 content-security-policy 响应头中的 bgme.me 替换为 bgme.bid 。
这样的需求 nginx 如果不使用第三方模块就是做不到。

Caddy 支持通过 HTTP API 统一管理也是继续使用 Caddy 的原因之一。
当然主要是上面的两点。

shell-startup-actual.png

《家人的 Apple ID 开了双重认证，仍然被钓鱼，求大佬解惑，也顺便给大家提个醒》
https://v2ex.com/t/959041?p=1
https://web.archive.org/web/20230724133122/https://v2ex.com/t/959041?p=1

https://v2ex.com/t/959041?p=2
https://web.archive.org/web/20230724132050/https://v2ex.com/t/959041?p=2

强烈建议时间线上的各位绒友（尤其是苹果用户）仔细阅读一下这个贴子（包括回复）。
在这个贴子中，楼主讲述了自己家人被骗取 Apple ID ，随后通过免密支付盗刷20多笔订单，共计1.6万的经历。

其中的要点是骗子如何通过伪造页面骗取 Apple ID 密码，以及如何绕过 2FA 认证添加信任号码的流程。

bae.st 被1000+实例屏蔽
detroitriotcity.com 被 900+ 实例屏蔽

能做到这一步，也算是某种意义上的很厉害了。

一个观察，不一定对。
Fediverse 上那些标榜 Free speech 、言论自由的用户，不知道为什么，都特别特别喜欢骚扰别人。

https://bgme.me/@admin/110738268058818367

不知道这条公告嘟文，还能诱捕出多少骚扰帐户？

https://chat.mozilla.org/
其实如果要用 Matrix 的话，使用 mozilla 这个实例也挻不错的。
Firefox 直接 SSO 登录就OK了。
而且更关键的是少数国内没有墙的大Matrix实例。

【基于GeoIP的代理分流模式的安全隐患】

基于GeoIP的代理分流模式存在极大的安全隐患。
国内直连，国外走代理，听起来好像不错，但代价就是：任何一个国内网站，只要想做，都可以知道你有没有挂梯子，你国内IP、梯子IP是什么。

下面是对该问题详细讲解。
据我所知，现在很多的代理软件都采取默认全走代理，绕过中国IP、中国域名、局域网IP这样的分流策略。但这种白名单式的分流模式是存在极大的安全隐患的。

如图一所示，如果一个国内网站想知道访问者有没有使用代理，那它可以采取这样的探测策略。在大量正常的第三方请求中，夹杂一些非中国IP、非中国域名的请求。
如果访问者使用的是采取上面所说的白名单分流模式的代理，那么这些非中国IP、非中国域名的探测请求就会被分流至国外代理服务器进行访问。
这样一来，网站便可以知道该访问者是否使用了代理，该访问者国内IP是什么，该访问者墙外的代理IP是什么。

感兴趣的读者可以手动模拟一下上述的过程。
一切开始之前，先访问一下 http://myip.ipip.net/ ，获得自己当前IP。
然后在国内网站，比如说 https://www.baidu.com/ 、https://www.bilibili.com/ ，运行下面的 javascript 代码。
确认一下，控制台输出的IP地址是否与上一步获得的IP一致。

```
(async ()=>{console.log((await (await fetch("https://www.cloudflare.com/cdn-cgi/trace", {"mode":"cors"})).text()).split('\n').filter((x)=>x.startsWith('ip=')).map((x)=>x.replace('ip=','')).join(''));})()
```

再进一步讲，黑名单分流模式也存在同样的问题，通过精心选择的探测域名同样可以达到探测的目的。

为了安全考量，也许根本就不应该进行分流，要么全部直连，要么全走代理。
使用两个浏览器，一个全部直连，一个全走代理，国内网站使用直连浏览器访问，国外网站使用代理浏览器访问。可以在一定程度上缓解这个问题。

另外，从这里也可以看出屏蔽第三方请求的重要性。
如果使用 uBlock Origin 插件的嘟友，可以参考wiki，将屏蔽模式设为 Hard 模式。
https://github.com/gorhill/uBlock/wiki/Blocking-mode:-hard-mode

不得不说 GFWList [1]已经严重过时了。
条目中不但有大量重复项、失效项，关键是被墙网站收录严重不全。
去重之后，按域名算只有 5681 条，而作为对比 dnsmasq-china-list 项目[2]收录的中国网站域名有64674条。

GFWList 严重不全，大概也是越来越多的翻墙软件使用白名单分流模式的原因吧。

[1] https://github.com/gfwlist/gfwlist
[2] https://github.com/felixonmars/dnsmasq-china-list

看到时间线上有嘟友发 Cloudflare 新 Fediverse 项目 Wildebeest 。
https://github.com/cloudflare/wildebeest

虽然 Wildebeest 这个项目第一眼看到就觉得是坑，研究了之后，发现不但是坑，而且是大坑，掉进去爬不出来的那种。

身为穷人一个，我最关心的就是费用了？
功能什么的之后再说，我们先说一说每个月要多少钱吧。

先说结论：每月至少$11。
Images Storage $5
Images Delivery $1
Worker $5

Images 两个看了图二，想必各位很好理解。

在此特别解释一下 Worker 那5刀是怎么来的。
Worker Free Plan 不是每日包含10万请求吗？我只是轻度使用，不用升级 Paid Plan 吧？
但是千万不要忘记 Wildebeest 项目使用 Workers KV 作为缓存。而 Cloudlfare Worker Free Plan 每日只有1千次写入额度。

使用 KVNamespace 进行全局搜索，涉及 Workers KV 写入操作的函数和API如图四所示。
可以看出 Home TimeLine 完全是基于 Workers KV 实现的。而每收到一次 /user/<id>/inbox 请求都会产生两次 Workers KV 写入操作。
免费计划每日1千次写入额度根本就不够用。

除上述费用之外，D1数据库也是一笔逃不掉的费用。
而且更为糟糕的是，D1现在还处在 Alpha 阶段，暂时免费，也没有收费标准。
但参考友商的 RDS 收费标准，想必价格是不可能便宜的。

最后，也是最为关键的是 Wildebeest 项目与 Cloudflare 基础设施深度绑定，你想逃都没法逃，想搬到别家去，no way。

收到了奇怪的关注请求，发现了奇怪的 Fediverse 服务。
https://mastinator.com/

那么问题来了，要不要封禁 mastinator.com 实例？

Explore the fediverse, but use block like it's a machine gun in a zombie apocalypse
https://boyter.org/posts/mastinator-activitypub-breaking-assumptions/

又发现了神奇的 Fediverse 工具。
https://fba.ryona.agency/

想知道你的实例被多少实例屏蔽了吗？
fedi block api 帮你实现这个愿望。
只需要输入实例域名，便可以查询到哪些实例以什么理由屏蔽了你的实例。

附图是对一些实例的查询结果。
bgme.me：14+2+3=19
mastinator.com：112+1+1+1+1+4=120
pawoo.net：516+147+66+147+60+10+11+3+12=972

虽然说吃鸡蛋不用看母鸡是谁，但人之常情难免有一些好奇。
拉到页面最底下 kiwifarms ，原来是你呀。某种意义来说，他们确实是挻需要这个工具的。

bgme.me 实例近半年后台 Sidekiq 每日执行任务数变化曲线。

Elon Musk 收购推特对中文长毛象影响可能没有想象中的那么大，或者影响的余波已经过去，现在又回归了日常。

顺便@一下其它几位站长。
@strawberry @lianghuan @salt @fghrsh @flyover @Showfom

不知道其它站是不是存在相似的变化趋势。