GCP 发了 initial incident report 了。简单粗暴总结就是，GCP 在自动定期更新/重置 某个 API 调用次数阈值 时，错误的数据扩散到了全球然后 Google 所有 API（Google 所有 API 都是 GCP 控制的、这也是为什么你申请 Google 产品的 API 的 Key 要去 GCP 控制台）都 503 了；其中 美中可用区的 数据库 过载了导致恢复特别慢。

https://t.iss.one/ObservingHumanActivity/17654

因为 sing-box 没有 Fake IP，所以使用 lvh.me 作为 iperf3 服务器 测试 是不经过 sing-box 的 TUN 直接使用 lo0 loopback 的，这样测试的 macOS/Linux 操作系统的回环性能、而非 sing-box TUN 的回环性能。

测试 sing-box TUN 回环性能 的正确方式是，使用 ip a 或者 ifconfig 查看 sing-box 创建的 utun 的 网卡/广播 IP，将其作为 iperf3 的服务器 IP 进行测试。

恭喜 TailScale 拿到了 192.200.0.0/24 和 2606:B740:49::/48 。TailScale 的 API、控制平面从 2025 年 7 月 15 日（UTC+0）起将开始使用来自该 IP 段内的静态 IP。

[慢报] 南京信风旗下 114DNS（114.114.112.0/21）自 2025 年 6 月起，国际改由 Zenlayer 代播 Anycast，114DNS 国际新增 新加坡、德国法兰克福、美国洛杉矶 三个节点，原 美国芝加哥节点 被去除，114DNS 官网 亦进行了相应的新闻更新。

相关资料：

bgp.tools ： https://bgp.tools/prefix/114.114.112.0/21
114DNS 新闻： https://www.114dns.com/news.html
Globalping 探针部分 MTR 结果： https://globalping.io?measurement=7GhSox5O8SSQfji9

#TIR （Today I Read，今天我读了什么）

《（SQLite，在部分指标中）比文件系统快 35%》- SQLite

https://www.sqlite.org/fasterthanfs.html

#TIR （Today I Read，今天我读了什么）

《Fluid: How we built serverless servers》from Vercel, Inc.

https://vercel.com/blog/fluid-how-we-built-serverless-servers

#TIR （Today I Read，今天我读了什么）

《Introducing UniFi OS Server for MSPs》

https://blog.ui.com/article/introducing-unifi-os-server

TL;DR: UniFi 正在内测 在任意 x86 硬件上 安装 UniFi OS 和 UniFi Application Suite，并且正式推出后 不收取任何 授权、订阅 费用。


原文引用：

> If you can rack it you can run UniFi OS.

补充，自建的 UniFi OS（网关）和 UniFi Application Suite（即 UniFi OS Server）届时同样可以接入 UniFi 官方的 Site Manager，也可以接入 自建/自托管 的 Site Manager。

如何在 Google Chrome M139 恢复 MV2 扩展：在 chrome://flags 中 启用 Temporarily unexpire M137 flags 和 Temporarily unexpire M138 flags`。重启 Chrome，在 chrome://flags 中重新禁用 Extension Manifest V2 Deprecation Warning Stage 、 Extension Manifest V2 Deprecation Disabled Stage 、 Extension Manifest V2 Deprecation Unsupported Stage 、重新启用 Allow legacy extension manifest versions ，重启 Chrome。

或者使用启动参数 --args --disable-features=ExtensionManifestV2Unsupported,ExtensionManifestV2Disabled （其中 --agrs 参数的作用是指定启动参数），该参数在 M139 和 M140 版本中都有效。

如何真正有效的禁用 Google Chrome 在 macOS 上的自动更新（非搜索引擎和 AI 提供的过时方案）：

sudo chown root:wheel "$HOME/Library/Application Support/Google/GoogleUpdater"
sudo chmod 000 "$HOME/Library/Application Support/Google/GoogleUpdater"

sudo chown root:wheel "$HOME/Library/Google/GoogleSoftwareUpdate"
sudo chmod 000 "$HOME/Library/Google/GoogleSoftwareUpdate"

上述命令 不会 影响浏览器扩展的更新、只影响 Google Chrome 本体的更新。执行上述命令后，可以通过访问 chrome://settings/help 验证 更新失败。

SukkaW/Surge 的 ip/telegram 配置现已包括 Telegram 备用服务器 IP 地址，随 CI 自动构建和定时构建时自动获取，不依赖写死硬编码。

UniFi Network Applications 9.4.11（Early Access）的更新日志提到了一个新 Feature「WAN Magic」，可以真正叠加多 ISP 的带宽，目前暂时只开放给美国、并且需要订阅 UniFi 的 WAN Magic 服务。

出于好奇，查了一下相关的新闻，发现 WAN Magic 最早出现在 UniFi World Conference 2025 上，从 KeyNote 里摘出来两句话「VPN bondage links between all the multiple ISPs and have a true aggregated session performance.」「Utilizes multiple ISPs with VPN links to ensure robust connectivity.」

所以这样看来，大抵是某种 MPTCP-like 的隧道。

重要公告

纯真 IP 库镜像 qqwry.mirror.noc.one 域名将于 2025.11.31 UTC+0 起被弃用，请尽快更换至域名 qqwry-mirror.cdn.skk.moe

迁移方法：全局替换 qqwry.mirror.noc.one 为 qqwry-mirror.cdn.skk.moe 。

Homebrew 已经支持 多文件平行下载（每个文件仍然只使用一个线程），可以通过 HOMEBREW_DOWNLOAD_CONCURRENCY={int} 环境变量启用。

https://fxtwitter.com/isukkaw/status/1956706093742325959

精华内容：难道说，GFW 通过参考了一篇 GFW Report 研究分析 GFW 识别 FET 的手段和行为的 paper、才实现了识别 FET 的功能、在代码实现过程中还 参考/借鉴/移植 了 AperNet 团队参考 GFW Report 那篇论文 实现并 开源在 GitHub 上的 OpenGFW 代码？

发一个暴论，考虑到比较暴论，所以就只丢我的 TG 频道和 Mastodon 上好了。

这次积至泄漏的疑似 GFW 相关文件 一石激起千层浪，闹得沸沸扬扬，并且可以肯定的是，积至确实开发了一个类似 GFW 的网络审查工具（在下文中，我将其称之为「积至 GFW」），可以按照一定的误伤率支持识别部分 VPN 和隧道协议、并且有主动发现 VPN 的能力（暴论：这个功能一听就像是海外一些国家的定制需求）。

从积至泄漏的源码中关于 FET（即 Fully Encrypted Traffic，Shadowsocks 流量即是 FET 的一个典型且著名的 example）识别功能的实现代码（CPP-based）、存在一段注释、包含下述两个 URL：

- GFW Report 为二作的这篇 paper： https://www.usenix.org/conference/usenixsecurity23/presentation/wu-mingshi
- AperNet 团队（ https://apernet.io ，他们也是 Hysteria 和 Hysteria2 协议背后的开发者）的 玩具 IDS/IPS/DPI 项目 OpenGFW 中基于上述 paper 而实现的 FET 识别功能 https://github.com/apernet/OpenGFW/blob/278d731b6f0df6665e00987fa9e8afa99244d5f6/analyzer/tcp/fet.go

感兴趣的观众可以在积至泄漏文件中找到 /decoders/session_flags/fet.cpp 文件，即可在文件开头看到我所说的包含两个 URL 的代码注释。

难道说，GFW 通过参考了一篇 GFW Report 研究分析 GFW 识别 FET 的手段和行为的 paper、才实现了识别 FET 的功能、在代码实现过程中还 参考/借鉴/移植 了 AperNet 团队参考 GFW Report 那篇论文 实现并 开源在 GitHub 上的 OpenGFW 代码？

先有鸡还是先有蛋的问题 听着非常匪夷所思，但是让我们做一个思维实验：如果我们把 2015 年起部署在国际出口和北京根 DNS 镜像上、并历经多年升级迭代至今的 GFW 称作「The True Original GFW（原初 GFW）」；积至根本无法获取到「The True Original GFW」的源码、不得不在开发「积至 GFW」的过程中进行 cleanroom 净室开发，在开发过程中甚至 参考/借鉴/移植 了 AperNet 在 GitHub 上的开源的 OpenGFW 的代码。进一步暴论，积志这套「积至 GFW」和「The True Original GFW」可能 除了都是网络审查工具之外，没有任何其他关系。

我们可以进一步推测：中央控制的网络审查手段可能仍只有「The True Original GFW」一个、且仍只部署在 DNS 和国际出口；地方政府、地方运营商分公司，为了满足各种 KPI（反诈、对异见人士的识别和抓捕、地方网安/网警的行政诉求），向积至和其他厂商招标、定制、采购「GFW 类似物」。这也解释了为什么江苏虽然向积至采购了「积至 GFW」产品，却只用于反诈拦截。

这个暴论完全可以自圆其说，并且也能够解释为什么「GFW 呈现去中心化和边缘计算的趋势」。「The True Original GFW」本身并没有去中心化，可能也没有在多地大量部署；真相可能是，在「中央集权+地方分权」的政治大背景下，整个网络审查制度自发地、自下而上地 实现了去中心化，「边缘计算」只不过是相应的错觉罢了。

然而，网络审查制度的去中心化，只会 让 审查对抗手段 面临更多挑战。