2026-01-07 12:11:08
刚买了一台 4GB 内存的 VPS，兴冲冲地安装面板后一看，却显示只有 3.2GB？ 面对这凭空蒸发的 800MB，我第一反应是遇到了黑心商家“缺斤短两”，甚至一度怀疑自己是不是犯了低级错误，给机器 装了个 32 位系统。但经过一番排查，我发现这消失的内存并非硬件缩水，而是被系统默认开启的 Kdump 机制悄悄“私吞”了。面对VPS内存无故减少的问题，本文详解了从硬件验证到系统配置的完整排查流程，并最终通过禁用Kdump释放内存。本文将记录我从发现内存不足，到修改 Grub 参数成功找回内存的全过程。
熟悉我的朋友都知道，我一向是比较“佛系”的。
其实早在云服务器刚部署好，装好各种东西后，我就发现了这个奇怪的现象：明明我买的是 4GB 的规格，系统里怎么看都只有 3.2GB 左右。
当时看到这个数字，我心里的第一个念头是：“我去，服务商该不会是在给我搞‘缩水机’吧？” 难道这所谓的 4G 实例其实是 3.2G 的残次品？但紧接着，作为一名折腾多年的业余 DIY 玩家，这“3.2G”的诡异数字让我脑海里瞬间闪过一丝不祥的预感——这数值也太像 32 位系统的寻址上限了！
那一瞬间我甚至有点自我怀疑：“难道我手滑，给这台机器装了个 32 位的 Ubuntu？如果不小心把古董级的 32 位系统装在了现代 VPS 上，那可真是运维生涯的黑历史了……”
我赶紧敲了一行 uname -a 压压惊。看到屏幕上明明白白显示着 x86_64，我这才松了一口气：还好，系统没装错，脑子也还正常。
既然排除了“因为蠢装错系统”和“服务商虚假发货”的可能性（凉心云不至于的，况且一般哪有 3.5G 的机器），因为当时老机器上的原有服务已经全部完成迁移到这台新机器并上线运行了有几天了，我想着反正跑个 WordPress 加上几个 Docker 小容器，3GB 也绰绰有余，再加上那时候还是个 linux 萌新，面对折腾系统总有种恐惧感，也就懒得去深究那消失的 800MB 到底去了哪。这一拖，就是4年多过去了（这到底算佛系还是算拖延症呢）。
直到前几天，我遭遇了一次恶意的刷流攻击。虽然通过各种手段挡住了攻击，但那当时看着服务器内存水位线一直处于报警阈值边缘，我的心态终于崩了。
资源寸土寸金，在关键时刻，这“莫名失踪”的 内存可能就是压死骆驼的最后一根稻草。于是，我决定不再佛系，彻底查清这笔“内存烂账”。
虽然早就排除了 32 位系统的嫌疑，但我还是得确认一下底层的硬件规格。使用 dmidecode 命令查看底层硬件信息：
sudo dmidecode -t memory
输出结果非常明确，物理插槽上确实是实打实的 4096 MB：
Physical Memory Array
Location: Other
Use: System Memory
Maximum Capacity: 4 GB
...
Memory Device
Size: 4096 MB
Type: RAM
...
然而，当我切换回系统视角，使用 top 命令或者在面板一看，画风就变了：
MiB Mem : 3419.1 total
4096 – 3419 ≈ 677 MB。 既然物理内存没少，系统也是 64 位的，那只能说明一件事：这部分内存被操作系统内核在启动阶段就已经“私吞”了，导致用操作系统实际可支配的内存减少。
系统可用内存比机器规格小不少，在虚拟化环境（云服务器，VPS）中是非常常见的。一般无非是3个地方
现在云服务器，都有一些魔改虚拟化机制，可能会在客户机底层埋一些小玩意，这些“小玩意”会占用一点点客户机内存作为通信缓冲区，不过一般都非常克制，不至于直接砍下去 800 MB 吧
毕竟虚拟的主板 BIOS 和硬件设备也需要占用地址空间嘛，比如我还开了VNC，几十MB的虚拟显存占用总要有。但是这玩意一般最多也就吃个200M，不应该啊。
我不放心可以执行一下命令，看了下内存映射日志。
dmesg | grep "Memory:"
输出： Memory: 3319136K/4194304K available (14336K kernel code, ...)，嗯……这，被吃的内存可真多。
kdump-config show
显示 current state: ready to kdump，说明它正在占用内存。
cat /proc/cmdline
返回的配置最后赫然写着：crashkernel=2G-16G:512M,16G-:768M
破案了！元凶就是它——Kdump。
什么是 Kdump？
Ubuntu 默认会启用 kdump 。目的是在为了实现当系统内核崩溃时记录错误日志的功能。为了保证系统内存被用户打满后再崩溃时，还有地方存放数据，所以会在系统启动时预先强行划走一部分内存。这部分内存对普通应用是不可用，也不可见的，因此 top 、php、Nginx 统统都统计不到。
不得不说，这也太狠了吧，2G-16G:512M，合着，物理内存在 2G 到 16G 之间，强制保留 512MB？？？我4G砍512MB还不太明显，2G的机器，你给人家砍 512MB，还让不让人用了？
对于像咱们这样的个人站长，服务器主要运行 Web 服务，要这玩意干啥，我又不需要去调试内核崩溃这种底层代码级错误。（主要完全不会……）如果系统内核真崩了，我不应该直接重启或者回滚快照吗。
所以，这 512MB 的“昂贵的买路钱”，我不交了。
sudo vim /etc/default/grub
# 当然，你要是习惯用 nano 的话 用sudo nano /etc/default/grub
找到 GRUB_CMDLINE_LINUX 这一行。
# 原配置：
GRUB_CMDLINE_LINUX="... crashkernel=2G-16G:512M,16G-:768M ..."
# 修改为（直接禁用）
GRUB_CMDLINE_LINUX="... crashkernel=0M ..."
注意：
1. 保留该行内原有的其他参数，只修改 crashkernel 部分
2. 如果你的参数是写在GRUB_CMDLINE_LINUX_DEFAULT里的话，那就改这里的参数。
这一步至关重要，不更新引导文件，改了配置也没用。
注意：执行后，服务器（系统）会被重启
sudo update-grub
sudo reboot
重启服务器后，第一时间打开终端输入 free -m.可用总内存从 3.2GB 瞬间跃升到了 3.9G。舒坦，这么多年拖延的问题终于解决了。虽然平时看着不起眼，但在流量高峰期或者 Docker 容器跑得比较多的时候，它就是从卡顿到流畅运行之间的那道分界线。如果你也发现你的 VPS 内存“缩水”严重，不妨检查一下 /etc/default/grub，说不定也能找回这笔“私房钱”。
3419Mib/1024/1024X1000X1000=3.26G内存可用，然后面板还隐藏了百分位，变成了3.2G，然后我（4G-3.2G）X1000=800MB，得出了“我擦，怎么少了快800MB”的结论。正确算法应该是 4096-3419=677MB 不过琢磨了下，我决定还是按照当时的实际心路历程去如实写吧。The post VPS内存缩水排查：消失的 800MB 内存去哪了？ appeared first on 秋风于渭水.
2026-01-04 16:53:40
最近你是否遇到了这种诡异情况：在 Telegram 等软件中点击 Google 搜索链接时，系统毫无反应，仿佛鼠标点击被”吃”掉了一样？你可能已经尝试过重置默认浏览器、清理 DNS、检查 Hosts 文件、痛骂网络运营商、怀疑你的魔法上网工具，但问题依旧。
别急，这很可能不是网络故障，而是你的 Windows 安卓子系统 (WSA)在作祟！本文记录了一次深度排错过程：揭秘崩溃的 ‘WsaClient.exe’ 进程如何通过 URL Scheme 劫持（App Links）”绑架”了系统的 http/https 跳转请求，并提供了一份修改注册表彻底修复链接失效的终极解决方案。
大概从（2025年的）年初开始，我的电脑出现了一个非常诡异的“玄学”故障。
起初是在 Telegram 上，朋友发来的消息如果带有 google.com链接（比如搜索结果分享 www.google.com/search?q=...），我点击链接后什么都不会发生。
注意，是真正的“什么都没发生”：浏览器没有弹出，没有报错，仿佛我的点击被黑洞吞噬了一样。
但奇怪的是，点击其他任何链接（比如 github.com，baidu.com，youtube.com）都能正常唤起浏览器。
但极其偶尔的时候（也就2次），如果我关机关一半又取消了，这时候是可以点击 Telegram 中的 google 链接，自动调用浏览器打开的，只不过这时候因为魔法工具没启动，得到的只是一个无法连接的网页。
当时这个问题对我的影响不算大，毕竟只是 Google 的链接嘛，大不了我手动复制链接扔进浏览器里打开。我甚至一度以为是 Telegram 的 Bug （毕竟用的不是官方客户端）也就没当回事，就这样“带病生存”了大半年。
直到前几天，我的 Antigravity 登录掉了。
当我点击登录界面的「Sign in with Google」按钮时，熟悉的死寂再次降临 —— 按钮按下去，浏览器没有弹出，没有任何反应。我没法登录了。
这问题就严重了。我开始意识到，这不是 Telegram 单个软件的问题。经过一番简单的测试，我发现事情比我想象的要严重得多：
https://google.com，回车，无反应。start https://google.com，回车，无反应，也不报错，只有鼠标光标会变成繁忙状态1秒左右，然后恢复原样。这就不仅是“玄学”了，这是系统级的 URL Scheme 劫持。作为一个爱折腾的人，我决定彻底揪出这个“幽灵”。
既然是 Google 打不开，我首先想到的自然是网络或浏览器问题，毕竟国内嘛。
https://google.com.jp，秒开。.com是Windows 可执行文件后缀。我试着输入 https://google.com/（加了尾部斜杠强制识别为 URL），依然打不开。那就可以排除系统将其误判为本地文件的可能。https://ww.google.com、https://myaccount.google.com，秒开。输入 https://www.google.com、https://google.com、https://accounts.google.com，故障出现。ww.google.com和myaccount.google.com的。google.com、accounts.google.com等个别域名，非常精确。这就非常有意思了。既然浏览器没问题，网络没问题，那问题一定出在 “我发出打开URL指令” 到 “浏览器收到指令” 的中间环节。
既然 CMD 运行 start https://google.com 没有任何报错信息，并且有进入繁忙状态，说明那个拦截请求的进程要么是在“沉默中灭亡崩溃”了，要么“处理了不告诉我偷偷的”。我打开了 Windows 事件查看器 (Event Viewer)，先试图寻找系统崩溃的蛛丝马迹。
果不其然，在 Windows 日志 -> 应用程序 中，我抓住了一个刚刚发生的“应用程序错误”：
任务类型：应用程序奔溃事件
出错应用程序名称： WsaClient.exe
出错模块名称： ucrtbase.dll
异常代码： 0xc0000409 (堆栈缓冲区溢出)
将日志清空后再次执行打开 google 链接的操作，可以再次复现。
WsaClient.exe？这踏马不是 Windows Subsystem for Android (WSA) 吗？
看到 WSA 我反应过来了。
我安装的是 GitHub 上修改过的 MagiskOnWSA 版本 WSA，里面集成了 GApps（谷歌全家桶）。
安卓系统有一种机制叫 App Links，应用可以向系统注册它支持的域名。显然，WSA 里的 Google App 极其霸道地向 Windows 宣示了主权：“所有 google.com 等域名都归我管，别给浏览器。”
这个图已经是我修复后的了，之前 Google App 足足关联了 17 种链接。
故障流程还原：
google.com。而 Office 里的链接之所以能打开，估计是微软自家的 Office 内部有更高级的超链接处理逻辑，绕过了系统的这一层默认关联，链接直接发给了浏览器。
既然找到了真凶，卸载 WSA 当然能解决，但我还想留着它用。我需要的是切断关联。
但这比我想象的难得多：
pm disable-user 把安卓端的 Google App 冻结了。结果 Windows 居然还是固执地调用 WSA，然后继续崩溃，甚至我都把 WSA 给关闭了，Windows 还是锲而不舍的去呼叫 WSA ，就像对着一具尸体喊话。这就很绝望了。说明 Windows 系统内部有一份独立的、不受 UI 控制的注册表清单，记录着这个错误的关联。
没办法，只能动用注册表编辑器 (regedit) 进行物理切除。
经过反复按 F3 地毯式搜索 google.com ，我终于在深层的 AppModel 路径下找到了这几个“僵尸”条目：
计算机\HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppModel\SystemAppData\MicrosoftCorporationII.WindowsSubsystemForAndroid_8wekyb3d8bbwe\AppUriHandlers\www.google.com
这里明明白白地写着 AppUriHandlers\www.google.com。就是这几行注册表项，像幽灵一样死死抓着我的google.com链接不放，导致我无法在电脑中点击链接打开谷歌的网页。
解决方法：
https://google.com
https://google.com
困扰我一年的“玄学”故障，竟是因我在 WSA 里装了个谷歌全家桶的需求。
这个故事告诉我们：
gmail.app.goo.gl、m.instagram.com
如果你也遇到点击某个特定网站毫无反应 Windows 链接跳转失效的情况，不妨查查是不是有什么奇怪的 应用 产生了 URL Scheme劫持 。希望这篇排错记录能帮到有同样困扰的朋友。
The post 记一次“闹鬼”的故障：Windows 点击 Google 链接毫无反应，竟是安卓子系统 (WSA) 惹的祸？ appeared first on 秋风于渭水.
2025-12-31 10:04:27
服务器负载异常？出站流量居高不下？本文记录了我如何发现并防御一种伪装巧妙的低频分布式“刷流”攻击。通过分析Nginx日志、识别异常UA和参数，最终使用Nginx 444 状态码成功对抗刷流攻击，将服务器负载从70%降至正常水平。一起来学习这次完整的技术复盘与防御实战。
故事的开始非常偶然。昨天早上我本来只是看到一篇博文在介绍现代搜索引擎对robots.txt文件格式的适配，里边提到对于WordPress博客已经不再推荐屏蔽/wp-includes/，我核实了一下确实是这样的，于是计划修改一下博客的 robots.txt 文件，优化一下 SEO 策略。
然而，当我登录面板准备操作时，首页的负载引起了我的警觉。在这个本该平静的时间点，服务器的状态却显得异常亢奋，负载持续在70左右。
我果断先去一眼到底是什么进程在吃我的资源，结果：
这个数据绝对有问题，而且是有大问题！先不说umami里在线访客只有2个人的情况，也不说PHP占用也不低的事情。就算是有大量真实用户访问，PHP 的负载应该会很高（毕竟 WordPress 是动态博客，缓存做的再好也不对劲）。但现在 Nginx 居然比 PHP 还忙，这种诡异的情况，一般意味着：
直觉告诉我： 恶意爬虫或 CC 攻击的可能性最高，于是先从这个方向查。
常规起手，先看 Nginx 的 access.log
# 我这里打的默认路径，如果你想参考，请根据你的实际情况调整
tail -f /var/log/nginx/access.log
这屏幕日志刷的哗哗的，滚动的飞快，1秒怕不是有10条以上了，我还没看清就刷上去了，额，算了，还是统计一下吧，直接看日志超过我的目力限制了。
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 20
粗看一切正常，并没有哪个IP在疯狂请求我的站点。
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10
返回结果的前几条是这样的：
129007 /
60547 /?local_ga_js=f78e59fd91e18c7a2940a914030e9743
1620 /feed
246 /tutorial/971
88 /robots.txt
80 /favicon.ico
啊，这……对于我这个日均几百人的博客，8个小时内，首页 / 被访问 12.9 万次，带特定参数的 URL 被访问 6 万次，这显然是有人在疯狂刷我的首页和特定资源。
首页的日志不好分析，毕竟有正常人在，那个奇怪的local_ga_js就好分析多了，让我看看都有谁在请求这个文件
grep "local_ga_js" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 50
所有 IP 的请求次数都是8次，这也过于稳定了吧！
我追溯了本周的历史日志，他一直维持着一个大概有 400 个 IP 的 IP 池，用这些 IP 轮询，每个 IP 使用了 7~8 次后就弃用，重新拨号获取新的 IP 。既然这是正常的家宽 IP 而且攻击者释放 IP 的速度也很快，直接屏蔽整个广东电信的 IP 或者封禁 IP 一段时间就显得不合适且毫无意义了。
先干死请求local_ga_js=XXXXX的，攻击特征这么统一不干你干谁，首页的问题先放到一边。
先改一下站点的 nginx 配置
# 放在 location / 之前
if ($query_string ~* "local_ga_js=") {
return 444;
}
这里使用 Nginx 特有的 444 状态码。相比返回 403，444 会直接关闭连接且不返回任何数据包，能最大限度节省出站流量以及服务器性能。（Nginx官方关于444状态码的介绍）
前边的规则配置后效果立竿见影， 几个查询扔出去，果然看到 CPU 压力已经大幅下降了。
有效果就好，我先去喝口水，大早上这么半天连口水都没喝呢，喝水时脑内复盘了一下目前的现状：
第一阶段的防御（拦截恶意 PHP 请求）已经大获全胜！首页的 Redis 缓存被命中。Nginx 直接吐出了静态 HTML，没有调用 PHP，PHP 不再处理那些垃圾请求了。但是他一直在刷首页，还是有点烦人的，毕竟这依然会造成一个持续的 0.5MB/s 的出站流量，虽然这和整体带宽相比并不大，但一天下来也 40 GB 了。倒完水回来喝一口，和同事聊几句工作，咱们继续处理。
echo "" > /var/log/nginx/access.log
查看文件大小：
ls -lh /var/log/nginx/access.log
额，短短60秒，日志文件就有100KB了，一行请求基本是 200 B，一秒内还是有接近10次请求……
> awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr
842 444
744 200
712 301
8 304
5 414
3 302
1 404
> awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10
1941 /
1160 /?local_ga_js=f78e59fd91e18c7a2940a914030e9743
19 /feed
9 /robots.txt
5 /?local_ga_js=1
4 /music/
4 /favicon.ico
3 /tutorial/971
3 /music/fonts/element-icons.535877f5.woff
2 /wp-content/themes/JieStyle-Two-2.6.2/webfonts/fa-solid-900.woff2
看来不是自动化的脚本，因为针对JS的规则已经生效了，444这种直接断开的行为，在对方看来应该类似于对方关机了，我倒水喝水都过去10分钟了，他还在请求那个JS。
grep "local_ga_js" /var/log/nginx/access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -nr | head -n 10
1292 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
1290 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36
1289 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
78 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36
64 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
18 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0
7 Mozilla/5.0 (Macintosh; Intel Mac OS X 12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 YaBrowser/22.7.0 Yowser/2.5 Safari/537.36
7 Bun/1.3.0
额，这Chrome版本号是不是有点过于统一了。现在的最新 Chrome 版本已经是 140+ 了。就算为了MV2扩展，也不应该停留在 113、110、129这种版本上吧。
至于最后那个Bun/1.3.0，也非常眼熟嘛，明显是个脚本。
# 屏蔽特定的虚假 Chrome 版本
if ($http_user_agent ~* "Chrome/(110|113|129)\.0\.0\.0") {
return 444;
}
配置重载后，重新看一下系统占用
这才正常嘛，搞定收工。
战局已定，服务器恢复了往日的宁静。但作为一个技术人，好奇心驱使我必须把这件事琢磨透：这到底是个啥？
回顾整个事件，它和传统意义上的DDoS或CC攻击截然不同
1. 目的非致死：攻击者精准地将负载和流量控制在报警阈值之下，显然不想让我立刻发现并全力封堵。他的目的不是“打死”我的网站或者一次性薅干我的流量包，而是“持续地、悄悄地偷走”我的出站带宽。
2. 技术特征诡异：固定且无意义的 local_ga_js 参数、集中且陈旧的 Chrome User-Agent（110，113，129）、完全由广东家宽IP构成的庞大且轮换的IP池……这不像黑客工具，更像某种为了模拟“真实用户浏览行为”而设计的工具。
3. 流量流向：我的服务器 RX（接收）: TX（发送） 比例严重失衡，高达1:10以上。这意味着攻击者在用极小的请求成本（入站），换取我服务器返回的大量网页数据（出站）。
把这些线索拼起来，一个合理的推测浮出水面：这很可能是一种新的 “PCDN流量平衡” 又名 “刷下行” 行为。
攻击者（或其背后的平台）控制着一个庞大的家庭宽带设备网络（就是那些“广东电信”IP）。这些设备在使用 PCDN 设备赚钱或 获取 PT 站的积分的时候，为了防止因为上行带宽的比例过高而被运营商发现。于是设备被指令去“访问”一些目标网站（比如我的博客），通过持续请求首页和本地谷歌统计代码这类缓存良好的资源，产生大量的下行流量数据。这些流量数据被记录为“他的正常访问”，而我的服务器则成了默默奉献带宽的“奶牛”。
所以，这不是一场充满恶意的破坏，更像是一次精打细算的“白嫖”。我的服务器，不幸成为了别人赚取小钱钱的一个高质量、稳定的下行带宽资源。这种新型刷下行的手段，抛弃了之前单(几个) IP 直接拉满线程，一晚薅干流量包的行为，不再竭泽而渔，而是改为使用大量 IP 轮换，请求的也是体积不太大的资源，请求频率也控制在适当的范围。
对此我只想说：
对我来说，分享行为在于有效传递信息，即使对方是个伸手怪，白嫖党（虽然我不赞同这种白嫖行为），但只要他真的使用了我的数据。无论是看了一个教程解决了问题，还是看到了我的碎碎谈有了一些启发，还是发现了一个有趣的程序，哪怕他不同意我的看法和我激情对线。我的付出兑现了价值就行！数据发挥了作用，成为了他人的养料。这是一种基础但实实在在的价值实现，我可以接受数据服务于个体价值。
而刷流者呢，他们伪装成一个正常的用户，欺骗我宝贵的上行带宽和服务器资源。他们根本没有对数据的实际需求，其唯一目的就是制造虚假流量来应对 ISP 的监控，给他自己获取利益。这是一种彻头彻尾的欺诈性索取。本质上是将个人利益（无论合理与否）粗暴地建立在牺牲、欺骗、并摧毁其他真正分享者的有限资源之上。它非但不是对抗 ISP 强权的“侠客行为”，反而是对同行者的“背后捅刀”，是数字世界的公敌与污点。对于这类披着 P2P 外衣的流量刷子、电子垃圾虫、损人不利己的赛博脑残，必须予以最强烈的鄙视、唾弃和防范！
/?local_ga_js=XXXX其实是本地化 Google Analytics 统计代码，这样谷歌分析才能对中国用户生效（虽然谷歌分析的域名没被墙，但访问并不稳定）所以实际上最后用的 Nginx 配置文件是# 放在 location / 之前
if ($arg_local_ga_js = "f78e59fd91e18c7a2940a914030e9743") {
return 444;
}
要放过正常用户嘛。
5. 不过鉴于这位刷量的说不好也是订阅了我的博客，所以我又做了一些监控措施，以防他变招。
The post 对抗刷流攻击：我是如何通过Nginx防御“绅士刷流”并拯救服务器性能的 appeared first on 秋风于渭水.
2025-12-25 15:03:00
如果把长期写个人博客比作一场马拉松，那 2025 年对我来说，大概是——跑到半路鞋掉了，光着脚跑完，结果回头一看，成绩居然还凑合？
又到了一年一度立 Flag 和打脸的时刻~ 估计长期看本博客的基本是技术向居多，那我们就用数据说话。
因为我的 Umani 在年中时炸了一次（倒霉爪云，云服务太烂了），所以就以 Google Analytics的数据吧
也就是说，今年有起码十多万人曾光顾过我这个小站。如果把这些人都塞进鸟巢体育馆，差不多能坐满 2 个鸟巢。总的来说，今年这个小破站的访问量还算稳健，感谢每一位路过、停留、甚至不小心点进来的朋友。
每年总会有一两篇文章，因为恰好踩中了大众的痛点，数据会格外好看。今年也不例外，而且冠军毫无悬念。大家最关心的，永远是“如何在资本家的围墙上打个洞”。不过仔细一看数据也挺尴尬，爆款都不是今年写的，也许说明蹭热点并不能带来流量，写对大家有用的好东西才不会被埋没，终究会被别人发现的？
《Chrome 如何继续使用 uBlock Origin 等 Manifest V2 扩展》 ：以 2.7W 次浏览的绝对优势夺得桂冠。
这篇文章能火，纯粹是因为谷歌“作妖”。当 Chrome 开始强推限制更多的 Manifest V3，并试图让uBlock Origin 等老牌去广告扩展 “提前退休” 时，广大用户怨声载道。我这篇教程，说白了就是教大家如何“曲线救国”，利用企业策略、隐藏的实验性参数等手段，让旧版好用的扩展再战几年。
我还真要谢谢谷歌的作妖，在 Chrome 上搞“计划报废”，整个系列的 3 篇文章直接拿走了本站 15% 的流量，当时我写下这篇文章时还是2024年的夏天，文章的阅读量基本稳定在每个月200左右，直到今年7月12号，当天站内PV直接超过了5位数……，果然“反抗资本强权（和广告）”是全人类的刚需。
《让 WIN11 / WIN10 下蓝牙耳机也支持使用 AAC LDAC aptX HD LE3等更好的音频编码器》 2.2W+ 浏览。
看来大家都受够了 Windows 那个听个响的蓝牙音质，手机上动不动就有什么LDAC、aptX HD等先进编码器，最不济也有个ACC。结果到了电脑上，windows 10 到现在也只支持个SBC，真听个响。windows 11倒是好点了，AAC 支持了，LC3 也支持了。可惜微软对AAC的支持是部分支持，只支持固定采样频率，LC3倒是一个很美好的编码器，可惜现在支持的耳机实在太少了。
《PikPak第三方网页版/PikPak第三方客户端汇总》 等一系列相关文章
当年纯粹是为了下番剧快一点而接触到了这个当时才刚发布不到一周的小众网盘，为了领免费会员加了交流群，然后就一发不可收拾，顺手写了几篇介绍和教程，没想到因为写的太早，全网都没啥介绍和教程，一度在 “pikpak”、“pikpak网盘”这两个关键词上，比他们官网的排名还靠前（哭笑不得）。
翻了翻 Archives ，算上本文的话，今年大概又水了……啊不，是认真输出了 30 篇文章。文章的主题依旧杂乱无章，像极了我的知识树。
1. 工具与服务的运维：折腾 PikPak 与 FreshRSS ，解决 中国特色网络与 Docker 的局坑，追求免费自建稳定。
2. 浏览器与扩展的攻防战：对抗 Chrome 自动更新，争夺浏览器控制权。
3. AI浪潮下的平民玩法：白嫖Sora、DeepSeek R1等AI工具，部署本地搜索，吐槽AI爬虫影响。
4. 网络与运维的日常踩坑：应对TLS证书失败，创意搭建Cloudflare Worker图床，解决Git大项目与GitHub访问问题。
5. 生活与社会的吐槽记录：记录飞机轮椅申请等实用指南，关注 Win10 停支持、春运抢票及爱奇艺DMCA等。
这30篇文章，写下了 31285 字，算下来姑且我也算个双周更博主了。这些文章目前一共收获到 733 次评论。
数量虽然不说高产似母猪把，但主打一个“写有用的东西”。从数据反馈来看，那种纯碎碎念的内容越来越少人看，反而是那种 “遇到问题 -> 解决问题 -> 记录方案” 的实战派文章，生命力最强。
今年在博客最大的动作，就是试图更换博客主题。
理想很丰满：这套主题都停更好久了，完全是依靠着各种补丁跑起来的，于是打算换个更现代、更清爽的皮肤，给各位更好的阅读体验。顺带把谷歌自动广告停了，实在太烦人了。
现实很骨感：操作过程堪比在飞机飞行中更换发动机。
具体表现为：更换后，页面第一次访问较大几率出现乱码，刷新一下又好了。这种“薛定谔的显示错误”最为致命，因为它让你无法稳定复现问题。
于是，我开始了漫长的排错之旅：
1. 自行修复：检查文件编码、数据库字符集、HTTP头、缓存……一顿操作猛如虎，问题依旧二百五。
2. 询问AI：喂给Claude、ChatGPT、Gemini等一堆日志。AI们给出了从修改配置到重装软件的十几种方案，逐一尝试，收效甚微。
3. 咨询大牛：在技术群里卑微提问，收获了“你是不是动数据库了？”“缓存清了吗？”等灵魂拷问，以及一些高深莫测的、我试了也没用的建议。
4. 求助网友：发帖描述问题，回复多是“我用的也是这个主题，没问题啊”。遇到问题时最绝望的莫过于此。
在经历了长达一周多的、精神与肉体的双重折磨后，我望着被我改的七零八碎的代码和依旧随机乱码的页面。我终于做出了一个违背“折腾精神”，但顺应“心理健康”的决定：恢复服务器的快照，回档到更换主题之前的那一刻。鼠标点击确认的那一刻，世界清净了。博客恢复了正常，除了浪费的时间，什么都没发生。
今年对博客本身有效的折腾，唯二：
给文章末尾和 RSS 源加了一句提示词，试图教化那些来抓取内容的AI，让它们总结时别忘了是从我这里“学习”的。（具体效果未知，但求个心理安慰）
看看大家都从哪儿来到我的小破站的：
直接访问：占比比谷歌还高，看来还是有人把本站放到自己的收藏夹里的，很欣慰。
社区与友链：知乎、GitHub、Linux.do、CSDN、豆瓣、贴吧等社区带来了不少流量。“开往”、“博友圈”、“十年之约”、“BlogFinder”、“blogsclub”等博客联盟的友链跳转也是稳定的来源。感谢各位友链小伙伴和社区里的分享。
一些神奇来源：来源数据里还混入了一些 127.0.0.1:XXXX （本地）、 172.20.x.x\10.x.x.x （大内网），甚至还有 mi.feishu.cn （小米内部的云文档）的引用。看来我的文章偶尔也会出现在一些内部技术文档或本地测试环境里，这感觉有点奇妙。
这部分我只能大呼看不懂了。
从城市排名来看，来自台北的朋友以微弱优势战胜了香港成为了访客最多的城市，至于到底是本站很受台湾网友欢迎还是很多人的魔法上网节点是台湾的我就不知道了（估计是应该是真人居多吧，毕竟大部分魔法上网的更倾向于用香港）。上海、深圳、郑州、大连、广州、北京的朋友也贡献了可观的流量。
每当看到这些地理位置，就会觉得这个小小的博客，像是一个连接了世界各地某个角落的、微弱的数字信号塔。虽然我们素未谋面，但通过一篇解决具体问题的小教程，产生了奇妙的连接。
回看 2025，虽然技术折腾是个闭环，折腾一圈又回到了原点。2025年的地球上发生了很多大事，在我敲下这篇文章的当下，窗外的北风在呼叫着穿过大楼之间的空隙，阳光洒在我桌前的植物上，2025 这个世界没有变得更好，但也没有变的更坏吧。博客的折腾是个螺旋上升的过程，虽然去年并不是数据最好的一年（最好的是2022年，因为写了一篇教用SD画色图的文章）不过比起去年，也没变得更差。
最后，用今年一篇不起眼的小文章《碎碎谈》里的一句话作为结尾吧
“对我来说，分享行为在于有效传递信息。”
感谢你看到这里。我们，明年再见。
The post 2025 年终总结：流量、爆款与一场主题更换引发的“血案” appeared first on 秋风于渭水.
2025-12-06 22:50:46
最近我的 FreshRSS 阅读器出了一个怪现象：用来实现智能刷新订阅源的 AutoTTL 扩展在这个月初突然“罢工”了。具体表现为，我手动点击刷新后，它能按调整后的 TTL 时间更一次，之后就彻底“躺平”。所有订阅源的「下次更新时间」都卡在 pending，关掉 AutoTTL 反而能恢复正常自动刷新。
这问题有点意思，像是某个环节的状态机卡住了。作为一个喜欢刨根问底的人，我花了点时间深入排查，最终发现问题的根源竟是一个看似不相关的数据库警告。记录一下这次排查的全过程，给遇到类似问题的博友一个排故参考。
问题的核心矛盾点很明确：
actualize_script.php 和网络连接本身没问题。最讨厌这种“时灵时不灵”的问题，因为手动刷新后，AutoTTL 扩展居然还能正常工作一次（其实并不是正常工作，只是当时我没发现而已。其实这次会在更新到一半时卡住，但因为会更新一部分订阅源所以我当时一直以为订源被全部更新了）
首先重新拉取一次镜像，并检查AutoTTL 扩展的实际版本，确保他们都是最新版，以防这个 bug 其实早就被修复了，只是我没更新，或者是两者某一方更新后，另一方没更新导致的兼容性问题。
经过检查，确认目前，FreshRSS、PostgreSQL、AutoTTL都是他们各自的最新版本了。
看眼日志里都有点啥问题，是不是某个订阅源有问题，导致卡死在它上边了
虽然日志中有很多类似报错
cURL error 28: Operation timed out
HTTP 503 Service Unavailable!
HTML+XPath Web scraping failed for
Error fetching content: HTTP code 0: Could not resolve host:
但这基本都是订阅源本身的问题，比如触发了源的抓取频率限制，源站服务器卡了。并没有发现会引起订阅源无法更新的故障。于是这时我感觉肯定是扩展的锅，于是就跑去 github 给 AutoTTL 发了个 issues。
扩展作者mgnsk的回复提醒了我“How often does your cron run? A pending status means that the time for updating the feed has arrived but cron has not run yet.（cron 每隔多久运行一次？挂起状态意味着更新 feed 的时间已到，但 cron 尚未运行。）”
FreshRSS 的自动更新依赖于容器内的 Cron 服务定时执行任务，既然自动更新卡住，那就先检查 cron 是不是正常工作。
FreshRSS本体容器名：freshrss-app
PostgreSQL数据库容器名：freshrss-db
PostgreSQL数据库用户名：freshrss
PostgreSQL数据库密码：freshrss
docker exec -it freshrss-app /bin/bash
service cron status，结果显示 cron is running.。嗯，系统级的 cron 在正常走，没问题。
查看定时任务：看看具体定时任务是什么
执行 crontab -l，看到了关键配置：
*/21 * * * * . /var/www/FreshRSS/Docker/env.txt; su www-data -s /bin/sh -c 'php /var/www/FreshRSS/app/actualize_script.php' 2>> /proc/1/fd/2 > /tmp/FreshRSS.log
这个配置设计得很周到：先加载环境变量文件，然后切换到 www-data 用户执行更新脚本，还把日志重定向了。
php /var/www/FreshRSS/app/actualize_script.php ：结果直接罢工了，好吧看来环境变量是必须的。. /var/www/FreshRSS/Docker/env.txt; su www-data -s /bin/sh -c 'php /var/www/FreshRSS/app/actualize_script.php' 结果订阅源正确刷新了！ 这说明Docker内，cron设置的更新命令本身和权限设置都是正确的，所以如果不使用 AutoTTL 时能正常更新是理所应当的。AutoTTL 的工作原理，其实就是
1. 先根据每个订阅源历史上的平均更新间隔，最短更新间隔，计算出每个不同的订阅源，最合适的刷新间隔。
2. 拦截系统的cron，让他不是刷新所有订阅源，而是改为触发 AutoTTL，由 AutoTTL 去判断本次 cron 应该去刷新哪些订阅源。
3. 就在这时，我注意到了一个事情：AutoTTL 会往数据库里写数据并计算排序他们 既然刚才手动执行系统级 Cron 任务能成功，为什么自动运行时 AutoTTL 就不行呢？差别就在于“手动”和“自动”之间的环境差异。我意识到，刚才的输出信息我还没仔细看。
再次手动执行 Cron 任务，但这次我紧紧盯着终端输出。果然，在一堆刷新成功的提示信息之间，发现了一条 WARNING：
WARNING: database "freshrss" has a collation version mismatch
DETAIL: The database was created using collation version 2.36, but the operating system provides version 2.41.
HINT: Rebuild all objects in this database that use the default collation and run ALTER DATABASE freshrss REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.
这个警告来自于 PostgreSQL 数据库。大意是：数据库的排序规则版本和操作系统提供的版本不匹配。通常是因为系统底层库升级了，但数据库对象还用的是旧规则。
我想起来，月初时服务器宕机了一次，被我顺势维护了一番，当属将所有能更新的 docker 都手动更新了一次，而日常docker 的自动更新是由 Watchtower 做的，为了稳定性，我并不允许 Watchtower 去更新 docker 中的数据库版本，这次我看 PostgreSQL 只是一个小版本升级（ 15.14 → 15.15 ）更新日志中没改啥东西，就顺手也给升级了。
根据警告信息的提示，我们需要对 PostgreSQL 数据库进行操作。
# 进入 PostgreSQL 的容器，使用 psql 客户端连接
docker exec -it freshrss-db psql -U freshrss -d freshrss
REINDEX DATABASE freshrss;
这个过程可能会花费一些时间，取决于你数据库大小。
刷新数据库的排序规则版本：
重建完成后，重建完成后，执行 WARNING 提示中的命令，更新数据库的系统目录版本：
ALTER DATABASE freshrss REFRESH COLLATION VERSION;
我推测是这样的机制
pending。希望这篇记录能帮到遇到类似问题的朋友。如果你的 FreshRSS 或者其他使用了 PostgreSQL 的Docker 也出现了什么灵异现象，不妨先去检查一下数据库日志，说不定会有惊喜（或者说惊吓）。
具体这次 Docker 官方在 PostgreSQL 升级时做了什么，可以参考这篇文章《原地报废：不要在生产环境用Docker跑PostgreSQL！》
The post FreshRSS 自动更新订阅源失效排查：AutoTTL 扩展失效竟是 Docker 官方埋下的坑 appeared first on 秋风于渭水.
2025-11-29 10:45:11
你是否遇到过 PikPak 网盘从国内直接访问不稳定甚至无法访问的问题，除了部分地区是因为被墙外，还有一些地区是因为DNS默认解析的 IP 响应速度不理想，之前 Shimily 大佬写过一个小程序，可用来检测目前PikPak接口的最快的IP地址，然后绑定对应的Hosts即可提升访问速度，但是这个2年前的程序有点年久失修了，并且实际测试中有个小bug，不过好在大佬开源了代码，所以我简单修了一下，重新打包了exe文件。
一般来说全国这个 IP 都是最快的，直接 hosts 设置这个 IP 就行。
打开本地hosts文件，添加以下到hosts中进行保存即可
8.210.96.68 api-drive.mypikpak.com
8.210.96.68 user.mypikpak.com
注意：该 hosts 只会加速你网页/客户端内的浏览响应速度，并不会对下载生效，如果想加速下载请对下载工具设置代理工具解决，或尝试白嫖方案。
如果你遇到的是 pikpak 网页或 APP 显示「对不起，pikpak 在当前地区不可用」，说明你的区域没被墙，只是你 IP 是国内的，被 pikpak 官方限制了，这个可以通过 hosts 屏蔽检测域名解决
打开本地hosts文件，添加以下到hosts中进行保存即可
0.0.0.0 access.mypikpak.com
0.0.0.0 access.mypikpak.net
0.0.0.0 access.pikpak.me
0.0.0.0 access.pikpakdrive.com
就只写windows系统方案了
notepad，按回车，就会出现记事本的界面。C:WindowsSystem32driversetc，点击右下角「文本文档」，选择「所有文件」，点击出现的hosts文件，然后点右下角的「打开」，就会弹出hosts文件的编辑页面。8.210.96.68 api-drive.mypikpak.com
8.210.96.68 user.mypikpak.com
步骤1和2其实是为了打开一个管理员权限的记事本程序，也可以替换为：
基于 shimily 的程序修改而来，程序没处理好 IP 无效后的报错，现在在部分地区已经无法正常使用了。我主要是改了一下这部分的逻辑，并加了几个新的可用 IP 重新打包
软件下载：https://tjsky.lanzouq.com/irpcw3bqpbxa 密码:2var
软件截图：
软件代码：
import typer
import platform
import subprocess
import statistics
pikpak_hosts = [
"8.222.208.40",
"8.210.96.68",
"8.209.208.12",
"8.209.248.151",
"149.129.129.1",
"149.129.132.58",
"198.11.172.147",
"47.88.28.176",
"43.160.170.231",
"43.156.21.88",
"43.160.168.77",
"43.159.52.123"
]
def main():
confirm = typer.confirm("请确认是否开始检测pikpak域名延迟?", abort=True)
if confirm:
host_pings = []
for host in pikpak_hosts:
typer.echo(f"正在检测IP {host} 延迟...")
try:
if platform.system() == "Windows":
output = subprocess.check_output(
["ping", "-n", "5", host],
stderr=subprocess.STDOUT,
universal_newlines=True
)
else:
output = subprocess.check_output(
["ping", "-c", "5", host],
stderr=subprocess.STDOUT,
universal_newlines=True
)
except subprocess.CalledProcessError as e:
typer.echo(f"IP：{host} 无法连接!n")
continue
pings = []
for line in output.splitlines():
if platform.system() == "Windows":
if "时间=" in line:
ping = float(line.split("时间=")[1].split("ms")[0])
pings.append(ping)
else:
if "time=" in line:
ping = float(line.split("time=")[1].split("ms")[0].strip())
pings.append(ping)
if len(pings) == 0:
typer.echo(f"IP：{host} 无法连接!n")
continue
else:
avg_ping = statistics.mean(pings)
#取avg_ping小数点后两位
avg_ping = round(avg_ping, 2)
typer.echo(f"IP：{host} 平均延迟为：{avg_ping}msn")
host_pings.append((host, avg_ping))
fastest = min(host_pings, key=lambda x: x[1])
typer.echo(f"检测完成：nIP：{fastest[0]} 延迟最低, 平均值：{fastest[1]}ms")
typer.echo("n按回车键退出程序...")
input()
if __name__ == "__main__":
typer.run(main)
The post PikPak 无法访问或访问卡顿问题解决–自动检测 PikPak 延迟最低 IP 工具 appeared first on 秋风于渭水.
