桶装幺蛾子

最近 Cloudflare 宣布 Workers Static Assets 进入“普遍可用”阶段，并在博客里建议新应用都使用 Workers 而非传统的 Pages1。 词元的博客一直都是托管在 Pages 上的，之前就想实现 UA 分流，例如 cURL 访问就返回纯文字版本，浏览器访问就返回网页版，但是在纯静态的情况下基本不可能实现2。既然 Cloudflare 把 Workers 吹上天了，那就来试试到底有多神奇吧 🔥 🤔 等等！ Pages 是静态资源托管，访问次数和流量都是无限的；Workers 则需要执行用户脚本，免费版本每天限制调用 100,000 次。虽然看着很多，实际上也用不完，但是考虑每一个请求都需要计入，是不是有点浪费？ 确实 😭 词元还有很多其他的 Workers，共享十万次请求，着实有点害怕（serverless 都能被 DDoS 到下线 😅）。但是考虑到 Workers 广阔的开发空间，以及 Cloudflare 的承诺“新功能都给 Workers”，词元决定玩一下，把博客转移到 Workers。 就算哪天发现不好用或者出事儿了，迁移回来也很方便嘛 😇 ⛅ Wrangler Wrangler 是 Cloudflare 提供的 Workers 开发工具，可以快速构建项目初始设置，还能在本地模拟运行一个 Workers 实例；总之就是我们必须要用。 Wrangler 基于（万恶的）Node.js 开发，所以您得先装个 Node.js 和 npm。然后，找一个风水宝地，执行： 1 npm create cloudflare@latest -- bug-barrel 嗯，词元决定将博客的名字还是改回原来的“桶装幺蛾子”，因为谷歌上“词元计数器”就算全文匹配都搜不到自己的博客 🤣 在接下来的几个选择中，我们分别选中“Hello World Example”“Worker only”和“JavaScript”，当然语言您可以选择自己的喜欢的，不过注意 Python 只支持 PSL 里的库。 ...

两三年前，词元买了一部二手的 Kindle 8。选择如此陈旧（2016 年发布）的型号的原因，除了因为便宜（小黄鱼上全新未拆封只要 ¥300），还有个原因就是 Kindle 8 当时已经停止 OTA，词元可以放心大胆地越狱 Kindle，然后使用最新款 Kindle 仍然缺失的 EPUB 支持、自定义手势、文本编辑器等等（KOReader 提供）。 买回来之后，词元立刻尝试了越狱，用的是当时最常见、恰好支持 Kindle 8 最后一个 OTA（5.16.2.1.1 版本）的 LanguageBreak。然而，这个方法操作很复杂，词元经过四五次尝试，最终认命并注册了个美亚账号，老老实实使用内置功能 😮‍💨 然而，在词元不再关注 Kindle 越狱方法的这段时间中，今年元旦，MobileRead 论坛的 HackerDude 发布了一种新的越狱方法，号称是全版本通用，且越狱操作简单至极。 🎄 WinterBreak WinterBreak 利用了 Kindle 商店缓存的漏洞。简单概括一下越狱的原理： Kindle 在访问商店的时候，会产生缓存，存储在根目录下 .active_content_sandbox 目录下；下一次访问时，会更新过期的缓存。 这个目录中有可执行的文件，Kindle 商店会以设备权限执行。 开启飞行模式，Kindle 商店仍然会尝试读取这些文件，但是不会替换。 这样，如果我们把 .active_content_sandbox 储存的缓存中可执行文件，替换为越狱的脚本，让 Kindle 商店以设备（也就是 root）权限执行，就能实现越狱了。 Kindle 设备固件是一个精简版 Linux 内核。 本文的重点不是教您如何越狱；上文的 WinterBreak 链接里有英文教程，书伴有中文翻译和视频，都非常详细，词元不再赘述。 词元在操作过程中，有以下几个小小的坑： 🫥 如果您使用 Linux 或 macOS，请一定要提前启用“显示隐藏文件”，否则复制的时候，最重要的 .active_content_sandbox 很容易被漏掉。 🤬 不要用 WinZip 解压 .tar.gz 压缩文件，很容易损坏，导致越狱失败。 🛜 除非教程里明确说明，不要提前关闭飞行模式。 🤔 然后呢？ 词元跟着上述教程，也成功地完成了越狱。如果您看的是英文教程且做完了 Post Jailbreak 这一节的步骤，那您应该已经获得了越狱的 Kindle 的最大好处——KOReader。待会儿说说 KOReader 的一些使用技巧。 ...

🌩️ 太长不读：用 Cloudflare Workers 搭建代理白嫖 Gemini，然后用 AstrBot 和 NapCat 接入 QQ，实现零（低）成本的 AI QQ 机器人。 🏛️ 首先要有 Gemini Google 是为数不多的开放免费大语言模型 API 的提供商，但是很可惜，与其他 Google 服务一样，在国内是无法直接访问的。考虑到低成本这个要求，我们使用 Cloudflare Workers 搭建一个代理，实现国内访问。 当然如果您有境外服务器，那更好，直接在 NGiNX 里用常规方法添加反向代理。您都有服务器了，就不需要词元教您了吧 😁 目前 Gemini 对 gemini-2.0-flash 提供了每天 1500 次免费请求，而 Cloudflare Workers 则有每天 1000 万次免费请求，对于个人用户，如果您不把机器人拉近好几个大群，肯定是绰绰有余的。 首先，您要有个 Google 账号，还有 Cloudflare 账号，都不需要绑定信用卡——相信您可以自己搞定。另外还得有个域名，在 NameSilo 上可以买个 .top，十几块一年，还能用支付宝。 然后，去 Google AI Studio，创建一个 token，复制备用。 Gemini 这边就结束了，接下来去 Cloudflare 创建一个 Worker。 然后，选择 Hello World 项目，创建一个空项目，随便起个名字。建立成功之后选择“编辑代码”，粘贴以下的 JS 代码。 ...

因为 Xray 内核面板扛把子 3X-UI 作者宣布停更、Xray 内核长期以来不支持 TUN（而 v2rayN 的双核心解决方案在词元这儿不大能用），词元最近把服务端和客户端都换成了 sing-box。 要说 sing-box 的配置文件是真的好写，主要是它对 Xray 和 Mihomo 的写法都做了兼容处理，词元写惯了 Xray，转换过去没有压力，之前使用的 VMess、WS、TLS 和 CDN 的保险方案很快就转移过去了。 💡 如果您感兴趣，可以参考这个模板：chika0801/sing-box-examples，需要自行填写 UUID 和 Path，可以参考之前词元那则脚本搭建的博客。 但是今天词元不是要讲怎么把这协议迁移过去。毕竟，只要套上 CDN 且有最基本的加密，就基本不可能被封——原因不在于协议、特征什么的，而是 GFW 不会封禁 CDN 的 IP，“代价”太大。 词元想聊的是 Hysteria2，一个其实也不算很新的协议。 🤬 Hysteria2 是啥 Hysteria2 是一个以 UDP、QUIC 和 HTTP/3 为基础的协议。说它的技术本质，词元也搞不清（您可以去看看文档），但有几个基本特点是很好说清的： 🎭 伪装成 HTTP/3 流量，理论上来说比第一代 Hysteria 特征减少。但是很可惜的是，HTTP/3 和 QUIC 本身就是特征，尤其是在某些地区，运营商会干扰、拦截这些流量（俗称“Q 死”）。 📦 使用 UDP 包，且比普通 TCP 和 BBR 算法 TCP 的丢包重发策略更激进： 普通 TCP 在丢包率高时，将其等同于“带宽小”，减速发包。 BBR 算法 TCP 在丢包率高时，以维持带宽稳定为目标，加速发包。 Hysteria2 则主动“抢占”带宽，按 Brutal 算法增加包的数量，尽力达到用户设定的带宽。 ☁️ 不能套 CDN，主流的 CDN 几乎没有支持 UDP 这种“暴力”的包，何况支持 HTTP/3 的 CDN 也很少。 第二点导致了很多争议，因为 Brutal 算法在努力达到用户设定的带宽时，有可能出现多倍发包的情况，而这在流量高峰期会导致网络更加拥挤。Hysteria2 和 Xray 开发者各执一词，前者认为这只是达到运营商和用户签订的“流量协议”的一种手段，而后者认为这会导致骨干网更加拥挤，影响其他协议的用户。 ...

默认情况下，Arch Linux 开机会展示 Linux 内核和 systemd 的日志。尽管出现问题时用这些日志排查很有用，但是每次开机，都看到一堆文字滚动，夹杂着几个报错（没有内核签名啊，无法更新钥匙环啊），还是不大舒服。 Fedora 的开发者照着 Windows 和 macOS，搞了个 Plymouth：它可以像这几个操作系统一样，显示开机画面。正好词元之前换到了 systemd-boot，可以默认禁用菜单，开机过程更加简洁了；现在再关掉日志，看起来也更舒服些。 那今天，就来装个 Plymouth 玩玩。 👄 安装 Plymouth 由于 Plymouth 已经进入 freedesktop.org 的官方资源，安装非常简单： 1 sudo pacman -S plymouth 然后，为了让内核和 systemd 在启动时不要显示日志，需要修改一下内核参数。您如果使用 systemd-boot，可以修改启动条目 /boot/loader/entries/*.conf，在内核参数末尾添加： options ... splash quiet 若您还是会看见一些日志，那是因为 dmesg 显示了一些它认为“重要”的日志。添加或修改日志等级即可： options ... loglevel=3 0 是最严重的错误，而 7 是调试信息，3 基本上就是只显示报错。 您当然也可以复制一份条目，然后删除 splash 和 quiet 并填写 loglevel=7，添加参数 plymouth.enable=0 disablehooks=plymouth 禁用 Plymouth，作为调试启动参数。 您还需要将 Plymouth 添加到 mkinitcpio 的生成参数里，以便生成包含 Plymouth 的 initramfs。编辑 /etc/mkinitcpio.conf，找到以下行： ...

systemd-boot 是一个易于配置的 UEFI 启动引导管理器。相比于更加常见的 GNU GRUB，它有以下优缺点： 轻量灵活，功能和界面都很精简，配置文件很好写（GRUB 的配置文件甚至需要 grub-mkconfig 转译）。 是一个原生的 EFI 应用程序，只使用固件功能。这导致了下一条的功能缺失。 缺乏 GRUB 的一些功能，例如不支持主题、不支持文件系统读写（FAT 等 EFI 固件支持的除外）；对于 BTRFS 用户来说，还不支持直接从 BTRFS 子卷启动（只能写内核参数）。 似乎有些同学认为 systemd-boot 界面比 GRUB 好看。 对词元来说，由于不需要 Windows 双启动，也不怎么使用 BTRFS 子卷启动的功能，systemd-boot 的功能足矣。因此，今天就来删掉 GRUB，安装 systemd-boot。 📦 安装 systemd-boot 在 Arch Linux 上，systemd-boot 是 systemd 的依赖，而后者又是 base 包组的依赖，因此您应当已经安装了 systemd-boot，可以通过 bootctl 配置。 首先，将 systemd-boot 安装到 /boot： 1 sudo bootctl install systemd-boot 默认您的 ESP 分区是 /boot、/boot/efi 或 /efi。 如果您的输出中包括以下警告： ...

Caddy 虽好，但是要让它使用 Cloudflare API 处理 DNS 验证，还非得重新编译一次。而且，词元发现 Caddy 直到目前都没有充足的第三方文档（尽管其官方文档很好），对于一些特殊需求到底该怎么写配置还是不甚清楚。因此，词元决定换用另一个可以自动续期的 SSL 申请工具，综合一下 Caddy 的功能和 NGiNX 的性能和资料优势。 很明显，这个工具就是 acme.sh。 😁 这个长得很像网址的名称确实是一个网址，直接重定向到 GitHub 仓库。 📦 安装 为了不要污染用来日常操作的账号，也防止 sudo 权限被滥用，我们新建一个普通用户： 1 2 sudo useradd -m certbot sudo passwd certbot 🤖 Certbot：你礼貌吗？ 然后，使用 acme.sh 的安装脚本安装。注意这里不需要 Root 权限，安装位置也在主目录下： 1 curl https://get.acme.sh | sh -s email=you@example.com # 改为您的邮件 目前 acme.sh 已默认从 Let’s Encrypt 转为使用 ZeroSSL，后者需要邮箱地址进行注册，所以如果您打算使用默认设置，您需要添加 email=you@example.com 这一部分。如果您打算使用 Let’s Encrypt，可以忽略这个设置。 🏅 申请证书 首先要激活一下在 .bashrc 中添加的 $PATH 位置： 1 . .bashrc 如果您打算使用 Let’s Encrypt，请执行： ...

词元身边有几位大佬，对于科学上网安全基本是躺平状态——在国产手机上开 v2rayNG、不分流用 360 和 QQ、微信、用 +86 手机号注册电报。词元虽然无法完全保证自己的信息是安全的，但是还是想尽量分离国内外账号，最起码让帽子叔叔难查一点儿 😁 英国有家神奇的运营商 giffgaff，隶属于三大运营商之一的 O2，他们的运营方式绝无仅有——“办理 SIM 卡”这个环节压根儿不存在，甚至不需要登录，直接填写地址，全球范围内就给您免费邮寄一张。然后，您拿到卡再激活，充值获得一个号码。 这个运营方式在国外也就是比较新奇，但是对于国内的词元，可太棒了： giffgaff 毕竟是正经运营商，可以在国内漫游，那就可以接受验证码。 不像 Google Voice 和 Talkatone 那样风控过度严格。 最关键的是，它甚至还有“Pay as You Go”套餐，即预充值，然后用多少扣多少费，0 月租（收短信不要钱，发短信每条 0.3 英镑，半年保活一次即可）。 这似乎是目前解决“分离”问题的最优解了。 📱 获得 SIM 卡 第一个问题，虽然“全球”当然是包括中国的，SIM 卡也确实可以跨洋邮寄到中国（甚至还是免费的？！），但是由于是平信，不光时间会很长（据说 15 到 20 天），而且“最后 100 公里”还很可能丢信件。 于是，词元选择到拼夕夕上随便找了一家最便宜的（反正东西都是一样的），然后快递到家，2 天，9 块 9 搞定 ✌️ 😁 如果您决定要从官网上直接获取，网上教程很多，可以自己搜一搜。 商家很明显就是个人，很幸运可以收到那些粉红色的邮件，甚至还有邀请链接充 10 送 5。 拿到 SIM 卡，还需要激活才能使用。激活链接就在 giffgaff 网站上，需要充套餐，最低的是 10 英镑。您当然可以使用支持 VISA 的信用卡支付，但是如果您没有，也可以到淘宝上搜搜，有很多旅行代充，会给您一个折扣码，按照商家指导直接输入即可。 按照目前汇率，10 英镑是 89 人民币，代充是 98 元。整个过程多花了 20 块，但是少了很多麻烦，还是挺值得的 😊 ...

三个月之前，词元发布了一则非常详细的 VLESS、WebSocket、TLS 加上 CDN 的代理搭建指南（搭建自己的代理服务器），给出了词元当时认为最安全的方案。 事实证明，这个方案确实很安全，元旦期间词元用的 Cloudflare Anycast IP 被封了，但词元的服务器 IP 依然坚挺，可以正常访问（改 hosts 可以继续使用 CDN）。而这个安全性，主要就来自于 CDN 的加持，这样可以最大限度地防止 IP 泄露，将自己的流量隐藏在 CDN 边缘服务器的巨量吞吐中，被封也就无从谈起了。 上个月，词元又在 XTLS/Xray-core 的讨论中看到维护者 RPRX 提供了一种他十分自豪的方案：XHTTP。光是从他宣传 XHTTP 的力度（超长“简”介、写进个人主页）上来看，这个协议很牛。 之前词元嫌麻烦，原本的“三驾马车”协议也很够用，而且词元也不能确定这个协议抗封锁的有效性。（词元并不是科学上网领域的专家！）但是最近看到不良林也发布了搭建这种协议节点的视频，说实话有点心动了。借着 L 站上白嫖的节点，词元删掉了原本搭建使用的脚本，来试试这个金光闪闪的新协议！ “……这下又开启了一个崭新的时代……”——RPRX ✨ 这是什么 词元与上一篇文章相反，先来讲讲 XHTTP 的原理。因为，来这儿看先进技术的您估计已经有了能用的代理节点，看这则博客的目的大概是改进一下安全性，肯定要先知道凭什么做出改变嘛。 🫣 永不被封的 meek 协议 故事的开端是一个叫作 meek 的协议。这个协议原本是 TOR 的一种混淆处理方式，在 TOR 的实现中模仿了 Azure 的流量，用以防止封禁。 TOR 浏览器中也提到，这种方法虽然能在“重度”审查地区使用，但是会非常缓慢。 半年之前，Xray 的维护者在内核中实现了 meek 协议。其关键，就在于将 VLESS 节点信息伪装成普通 HTTP 流量，采用标准格式。正常的 HTTP 流量中，服务端在没有客户端的请求的情况下，不能向其主动发送数据包。为了克服这一问题，meek 在发送请求之后，不能从服务端得到数据，而是会再次发送请求，获得服务端已经从客户端请求的地址中获取的数据。 绕晕了？列个表： 浏览器：访问 hi.bug-barrel.top。 客户端代理：拦截请求，先用 VLESS 加密，然后包进正常 HTTP 数据包中，发送给服务端代理。 过墙（内到外），检测到正常 HTTP 数据包。 服务端代理：收到 HTTP 数据包，解包；里面是 VLESS 数据包，解包；哦，原来是 hi.bug-barrel.top，发送给目标服务器。 目标服务器：对服务端代理慢慢发包，正在传输。 客户端代理：过一段时间，发包问服务端代理“好没好啊”，包装方式相同。 过墙（内到外），检测到正常 HTTP 数据包。 服务端代理：还没有收到目标服务器发的包，回复一个空数据包，包装方式相同。 重复以上三步，直到服务端代理收到目标服务器的数据包，服务端代理回复有内容的数据包。 就这样，客户端反复发包，服务端反复回复（还得严格按照顺序），直到数据传输完成。 ...

我国智慧勤劳的劳动人民前段时间搞出来一个很新的科学上网方式——伪造 SNI。实现方法十分令人震惊：只需要给浏览器启动时加上一段参数，就可以免服务器访问谷歌、X、维基百科等等站点。例如： 1 google-chrome-stable --host-rules="MAP *google* google.cn,MAP *youtube.com google.cn,MAP *.ggpht.com google.cn,MAP i.ytimg.com google.cn," --host-resolver-rules="MAP google.cn 82.118.16.109," --test-type --ignore-certificate-errors 用这段命令行启动 Chrome，就可以直接访问 google.com 和 youtube.com，速度还挺快（虽然 YouTube 不能播放视频）。 要知道，上一次我们能做到这一点，大概是 10 年前；GFW 还只使用 DNS 污染的时候，可以通过设置一个加密 DNS，实现自由访问。大规模的 IP 封禁现在已经成了 GFW 封禁手段的主流，特别是 HTTPS 普及、无法过滤页面上的内容之后，无需一部境外服务器的方法就基本绝种了。 当然，部分站点（例如 GitHub、LINUX DO）依然可以通过 DNS 设置解决访问问题，因为它们都没有被完全封禁，仅仅使用了 DNS 污染和封禁部分 Anycast IP 的方式阻碍连接。 那这到底是怎么回事？和 1 月 1 日发生的小规模“漏风”事件是否有关？词元也来看看。 🙅‍♂️ 免责申明 本文采用了一些来自网络的资料，因为范围实在太广，词元又没有记录来源的好习惯，无法一一列出，若您感觉某一段内容很熟悉，不必怀疑，大概就是您读或写过它。如果您比较介意词元的行为，敬请邮件告知，词元将添加对您的内容的引用。 本文所有内容与突破中华人民共和国国家防火长城无关，只适用于突破类似 OpenGFW 等第三方防火长城实现，也请读者承担自己的责任，勿以 GFW 作为实验对象，谢谢。 🔧 实现方法 首先我们先来试一试效果。如果您是 Linux 用户，可以直接使用上文所述的那个命令启动 Chrome，然后看看是不是可以正常访问 Google 了；如果您是 Windows 用户，请修改 Chrome 快捷方式，将那段参数添加在原本的命令之后。 ...