2026-01-27 16:49:53
时光倒流回好几年前，那时我的 PHP 和 JS 水平还停留在相当小白的阶段（虽然现在也还是业余），用现在流行的话说，就是一名标准的 “CV 程序员”（Ctrl+C / Ctrl+V）。
当时看到一些 SEO 教程说，不要直接引用外链，不然网站权重会丢失，不利于SEO优化云云，虽然那时候博客一个月的访问量加起来都没现在一天多，我还是决定搞一个外链跳转页，实现外链SEO优化。那时候的我，写代码基本靠搜。我当时在网上东拼西凑，这里复制一段 PHP 代码，那里又找来一段 JS 脚本，缝缝补补一通 Ctrl+C / Ctrl+V 算是把功能跑通了。
那时候的我觉得自己做得挺周全：
eval、base64 这种敏感词，防止有人注入代码。看着这套“组合拳”，我心想：“这下稳了，既防注入又防盗链，妥妥的。” 这一用，就是好几年。
部署后的头几年，一切风平浪静，看起来跳转页在忠实的工作着。直到大前年开始，因为《本地部署AI文生图工具 SD-webui 生成NSFW图》部署教程被广泛引用，博客的流量和热度突然上去了。那小半年的时间里，每日新访客（仅仅是新访客就）能稳定在 4位数，高质量反链好几个。在 Google 和 Bing 眼中，我的博客权重逐渐变高。
于是乎，树大招风，我的外链跳转页被盯上了。
最开始的端倪，是 Google Search Console 发来的“提示”。网域出现了大量“未编入索引”的提示，我点进去一看，全是 /goto/?url=… 后面跟一长串乱七八糟的垃圾网站链接（赌博、色情、灰产，应有尽有）。
紧接着，防火墙（WAF）开始频繁报警。日志显示，有大量的请求携带着奇怪的参数试图经过我的跳转页做XSS或者SQL注入。这是典型的 Open Redirect（开放重定向）漏洞利用尝试。
面对这些攻击，当时的我虽然觉得烦，但并没有意识到问题的严重性。毕竟博客前台看着没啥异常，服务器也没崩，搜索引擎也没收录这些奇奇怪怪的跳转。
于是，一向 “佛系” 的我采用了最机械的应对方式：
“反正也没造成什么实质性的破坏，能拦就拦，拦不住貌似也没啥。” 就这样，我拖着这个隐患，得过且过地又混了两年多。
直到最近，那种久违的“折腾之魂”突然死灰复燃。趁着手里有干劲，我决定把这个陈年老页面彻底重构一下。
当我打开那个尘封已久的 index.php，仔细审视当年的代码时，冷汗下来了。不看不知道，一看吓一跳——当年我所谓的“安全措施”，简直就是“千疮百孔”，甚至是在对黑灰产说着“欢迎光临”，代码幼稚的简直想穿回去抽自己的嘴巴子。
当年写下（复制来）的防止非本站使用跳转页的代码是这样的
{
//禁止其他网站使用我们的跳转页面
// 第一步：获取我们自己的域名
var MyHOST = new RegExp("<?php echo $_SERVER['HTTP_HOST']; ?>");
// 第二步：判断来源
if (!MyHOST.test(document.referrer)) {
// 第三步：如果来源不对，准备跳转回首页
location.href="https://" + MyHOST;
}
// 第四步：正常执行跳转
location.href="<?php echo $url;?>";
}
看出问题来没？我感觉稍微有点开发经验的朋友都看出来了，因为跳转逻辑被覆盖了！！
我当年知道 JavaScript 是按顺序向下执行的，所以我想当然的认为当代码执行了location.href="https://" + MyHOST;之后，非法访问就会被跳转到我的首页了，后面的location.href="<?php echo $url;?>";不会被执行。
但实际上，修改（赋值） location.href 后代码其实会继续执行下去的，实际执行时是下边这样的过程
当年的我犯了初学者最常见的认知错觉，是把 JavaScript 的 location.href 当成了 PHP 里的 header('Location: ...');了，殊不知在浏览器眼里，这只是一次变量赋值。（PS：其实PHP里这样写也是错的，后面需要写exit;,不然可能用户浏览器已经跳走了，但服务器还在空跑）
浏览器是单线程执行 JS 的。当它读到我的第一次赋值时，它在心里记下：“哦，待会儿脚本跑完了我要去首页”。但是！脚本还没跑完呢，它必须继续往下跑。 紧接着它读到了第二次赋值：“哦，不对，他改主意了，待会儿脚本跑完了，让我去外链”。 后面的赋值覆盖了前面的赋值。
就像我告诉网约车司机‘去机场’，结果还没等司机踩油门，我又补了一句‘去火车站’。那司机肯定听最后一句啊！缺少一个 else，让我的防御代码变成了一句废话。
也就是说，这里正确的写法应该写成
var MyHOST = new RegExp("<?php echo $_SERVER['HTTP_HOST']; ?>");
if (!MyHOST.test(document.referrer)) {
location.href = "https://" + MyHOST;
} else {
location.href = "<?php echo $url;?>";
}
亦或者封装成一个函数用return打断函数继续执行也可以
var MyHOST = new RegExp("<?php echo $_SERVER['HTTP_HOST']; ?>");
function CheckHOST() {
if (!MyHOST.test(document.referrer)) {
location.href = "https://" + MyHOST;
return; // <--- 让函数立即停止
}
location.href = "<?php echo $url;?>";
}
顺带一提，这个错误的代码至今仍在谷歌搜索结果的前五位，而且被多个外链跳转页所使用。😂
filter_var 重构安全跳转页痛定思痛，我彻底抛弃了原来的代码，基于 PHP 服务端重写了整个逻辑。
原因很简单，正确的 JS 代码当然可以在跳转被恶意利用时拉回用户，但这无法阻拦黑产的自动化漏洞扫描。
扫描漏洞用的爬虫、脚本（Python、Curl 、Go 等）根本就不执行 JS 的！它们只看 HTTP 响应头和 HTML 里的链接。 在扫描器眼里，我的旧代码压根没有那个 if 判断，他直接看到了最后的跳转链接。扫描器只会给我的各种路径去发?url=http://www.baidu.com之类的命令遍历尝试，看会不会触发跳转，只要触发跳转到百度的首页，就标记为“存在 Open Redirect 漏洞”，自动存入“可用资产库”。于是就会被拿来做跳转了，至于实际环境访问时能不能完成跳转，不讲究的黑产并不会去核实。只是因为有 JS 的存在，实际用户访问时会被拦截罢了。
现在来源检查在服务器端完成，不依赖客户端。直接在 PHP 顶部加入了核心校验：
// 获取来源
$referer = isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : '';
$host = parse_url($referer, PHP_URL_HOST);
// 只有从我自己域名点出来的链接，才放行
if (!in_array($host, ['tjsky.net', 'www.tjsky.net'])) {
header('HTTP/1.1 403 Forbidden');
die('非法请求：禁止直接访问或盗链。');
}
当年真是的小白菜的常见状态，又菜又感觉自己强，当年的 URL 合法性检查是自己手搓的
strpos($_SERVER['REQUEST_URI'], "eval(") ||
strpos($_SERVER['REQUEST_URI'], "base64")||
strpos($_SERVER['REQUEST_URI'], "127.0.0.1")||
……
//省略其他过滤语句
$t_url = preg_replace('/^url=(.*)$/i','$1',$_SERVER["QUERY_STRING"]);
//判断非空
if(!empty($t_url)) {
//判断取值是否是base64
if ($t_url == base64_encode(base64_decode($t_url))) {
$t_url = base64_decode($t_url);
}
我当时防御漏洞的逻辑很直观：黑客可能想干嘛，我就拦什么。黑客想传 eval，我就在代码里搜 eval；黑客想传 base64，我就搜 base64。这在安全领域叫“黑名单防御”，但其实：
这次重构，因为使用了PHP跳转而不是前端跳转，所以改用 PHP 内置的filter_var来检查跳转 URL 的合法性，并且先解码，再检查。再配合FILTER_FLAG_NO_PRIV_RANGE之类的参数去防止对内网和私有 IP 做跳转。
//base64解码部分代码就不写了，只看filter_var部分的。
$url_host = parse_url($final_url, PHP_URL_HOST);
//过滤本地主机
if (strtolower($url_host) === 'localhost') {
die('非法目标：你访问本地主机干啥。');
}
if (filter_var($url_host, FILTER_VALIDATE_IP)) {
//_PRIV_RANGE: 过滤 192.168.x.x, 10.x.x.x, 172.16.x.x 之类的大内网
//_RES_RANGE: 过滤 0.0.0.0, 127.0.0.1 等保留地址
if (!filter_var($url_host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
header('HTTP/1.1 403 Forbidden');
die('非法目标：你访问内网地址干啥。');
}
}
//确保链接格式符合 RFC 标准
if (!filter_var($final_url, FILTER_VALIDATE_URL)) die('目标链接格式错误。');
?url=javascript:alert(1)的话。在老代码里，这会被当作合法 URL 运行。而 filter_var 会识别出这不符合 Web 协议规范，直接在入口处将其掐死。filter_var的眼里都是不合法的它只认符合 RFC 标准的纯净 URL。当然filter_var本质上是一个“格式校验器”，挡不住顶尖高手的定向渗透，比如传入一个格式完全标准，但指向内网某个邻居的数据库的域名。filter_var 会因为它符合 URL 规范而放行。这就是所谓的 SSRF（服务端请求伪造） 风险，这类深层次的逻辑漏洞，单靠一个函数是无法完全杜绝的。但面对互联网上每天成千上万次的自动化扫描和脚本攻击，它表现得比我那些个漏洞百出的正则要好太多了。放弃对“手搓代码”的执念，承认现成工具套件，尤其是安全、密码方向的现成轮子专业能力。现在的外链跳转页代码已经是一份真正的PHP安全跳转代码了。
htmlspecialchars 防止 XSS 攻击因为现在的跳转页有一个跳转URL“预览框”。如果万一黑产绕过了前面的检查，把一段代码伪装成 URL 传了进来，直接打印在 HTML 里是非常危险的，搞不好就引发 XSS 攻击了。 htmlspecialchars会把所有的 <、>、"等特殊字符全部转义成 HTML 实体，让前端可以安全展示URL。
$display_url = htmlspecialchars($final_url, ENT_QUOTES, 'UTF-8');
额外增加 X-Robots-Tag：直接在 HTTP 标头中加入 noindex, nofollow，直接告诉搜索引擎爬虫：“这个页面通通都别收录，权重别传递”。这比在 <head> 里写 <meta name="robots" content="noindex, nofollow" /> 更优先，爬虫不需要解析 HTML 就能看到，从而更有效保护博客的 SEO 资产。（当然meta也要加，毕竟某搜索引擎的爬虫不认这个响应头）
<?php
header('X-Robots-Tag: noindex, nofollow');
本来这次对外链跳转页的重构也就止步于上一步了，有些熟悉本站的人，估计已经发现新版跳转页已经上线运行了一段时间了。
我最近在爬取一个图片资源站时，发现对方有个很有意思的设计，这个图片站为了防止遍历本地路径实现快速抓取图片资源，他把站内的图片链接都AES加密了。我只能看到他图片都是类似主域名/img/?url=OVA2Q……HBIdz09-d这样的地址。如果不知道加密密钥，就无法生成正确的资源地址。
我一琢磨，虽然我的跳转页有个来源域名检测，防止非本站访问。但 HTTP Referer 伪造起来难度也不高。要是真有人拿我的跳转页去搞伪装钓鱼的话，他自然能伪造请求头的。
于是我决定做个“二次进化”：使用 AES 加密跳转地址。
不过这个图片站的 AES 加密方案还是不太完善，因为很容易就能发现，他所有图片的开头和结尾字符串都是固定的。很明显是个使用 ECB 模式(固定使用同一个密钥)做对称加密的结果。
我打算更进一步使用 CBC 模式 （随机初始化向量）做加密，逻辑是：[ 随机生成的 16 字节 IV ] + [ AES 加密后的实际网址 ] 打包在一起再 Base64 编码。
这样服务器只要收到密文后，只需要先解码base64，截取前16个字节作为IV，用密钥和刚才拿到的IV，去解密后面的密文，就可以得到实际跳转地址。（从防止变成开放重定向跳板这个角度， ECB 模式已经能挡住黑产了，用 CBC 纯属为了“既然做了就做到极致”）
$final_url = '';
// 尝试 AES 解密
$binary_data = base64_decode($input_code);
if ($binary_data && strlen($binary_data) > 16) {
$iv = substr($binary_data, 0, 16);
$ciphertext = substr($binary_data, 16);
// 使用预设的密钥解密
$decrypted = openssl_decrypt($ciphertext, AES_METHOD, AES_KEY, OPENSSL_RAW_DATA, $iv);
if ($decrypted && strpos($decrypted, '://') !== false) {
$final_url = $decrypted;
}
}
这样带来的好处是巨大的：
1. 动态密文：因为 IV 是随机的，同一个网址每次加密出来的字符串都不一样，无法通过简单的特征分析来破解。
2. 杜绝搬运：那些喜欢“采集”我文章的爬虫（说的就是你，CSDN），搬运过去后跳转链接会直接失效，倒逼他们必须手动处理。
3. 无数据库：不需要像短链外链方案那样需要数据库来存链接白名单，我只需要保存好密钥就可以，只要解密失败，就说明这不是我自己生成的链接。
4. 防伪造：取消明文跳转和基础base64链接跳转后，可以彻底堵死跳转页可被第三方利用的可能性。只要解密失败直接不跳了。
其实从防止变成开放重定向跳板这个角度， ECB 模式已经能挡住黑产了，用 CBC 模式纯属“既然做了就做到极致”罢了。而且其实有了这个加密机制后，前边的什么来源验证啥的都可以不要了，毕竟未来只支持使用加密后的密文做跳转，只要没有密钥，第三方不可能构造出实际可用的跳转密文，也就无法利用我的跳转页。以 AES 加密的强度来看，想要根据已知「明文，密文」来反推密钥需要的算力资源过于庞大了。
咋说呢，当年作为“CV 工程师”省下的脑子，最后都变成了日志里的红字报警。
现在的跳转页，虽然功能没变，但它不再是一个过于容易被攻破的漏洞，而是一个安全、可控的流量出口。如果你也在维护类似的跳转功能，不妨也检查一下：你的跳转页的“安全检查”，是真的在检查，还是在自欺欺人？
跳转页的代码已经在Github开源啦（含详细注释，适用于 WordPress / Typecho / Z-Blog 等一切 PHP 站点）：
👉 点击查看：安全的外链跳转页源码
前边这个外链的跳转就是使用AES加密后的跳转链接，只有到执行跳转时才会显示出真正的跳转目标。
AI辅助创作声明：跳转页源码经过 AI 增加详细注释（他还顺手优化了一行代码），流程图、头图是 AI 画的。
因为既然开源了需要提供一个生成加密链接的demo工具，但问题是我自己不用单独页方案，我也懒得自己新写一个，所以这个项目中的加密PHP也是让AI写的，我仅测试了可运行。
The post 少写一个 else，我的外链跳转页成了黑产眼中的“香饽饽”？重构一个安全的外链跳转页（附 PHP 源码） appeared first on 秋风于渭水.
2026-01-11 00:01:06
你以为买个罗技键盘鼠标，插上就能用？太天真了。罗技的驱动历史就是一部“分裂史”。如果你像我一样，手里既有老款经典，又有新款旗舰，那你的电脑托盘区简直就是罗技图标的“连连看”。
罗技最老的管理软件叫 SetPoint、然后有了 Logitech Options，然后又变出来个 Logitech Options+ ？？厂商更新软属于正常操作，但问题是：罗技的新软件它不！兼！容！旧！硬！件！ 诶，这就逆天了好不。
SetPoint 下才能良好工作。在 Logitech Options 下虽能发现设备，但大部分高阶功能的配置项全不在。
Logitech Options 在才能良好工作，在 Logitech Options+ 下会缺少配置项了。
Logitech Options+ 不然看都看不到鼠标。
LGS (Logitech Gaming Software)，因为新的 G Hub 不能正确支持它，依然是老问题：缺配置项。
G HUB。
以前的驱动 LGS、SetPoint 都只有几十兆，清爽无比。现在的 G HUB 和 Options+，动不动就几百兆，启动慢得像是在加载 3A 大作。
看看这界面截图，里面塞了多少不好用又很臃肿的功能。
吐槽完罗技的糟心驱动，那我们要怎么解决这个问题呢？以下是我尝试过的 3 种不同层级的解决方案。
如果你想彻底抛弃官方驱动，以下神器是你的首选。
Mac 上有个牛逼的软件叫 「SteerMouse」，也就是大家口中的“万能鼠标驱动”。它的平滑滚动算法比罗技官方还要丝滑，甚至能调整滚轮加速度曲线，让鼠标拥有匹配 Macbook 触摸板的体验。绝对值得付费购买的一款软件。
Linux 社区的反向工程做得最好。「LogiOps」 是一个运行在命令行的非官方驱动，可以使用cfg文件完美配置键盘与鼠标的所有参数。
Windows 下没有单一的完美替代品，但可以通过组合软件实现官方驱动的部分功能：
调节灯光效果：如果你只是想调你的光污染键盘，可以用 “OpenRGB”。这玩意比 G Hub 好用太多，如果只为灯效，强烈建议卸载 G Hub 只装这个。
也许是罗技仅存的良心，目前还有一些官方工具可以帮你减少垃圾驱动的影响。
如果你的需求只是配对键盘鼠标，其他什么都不需要：
* Unifying 接收器（优联）：使用 「Logitech Unifying Software」，只有几兆，配对完即可卸载或关闭。
* Bolt 接收器：使用网页版工具 「logi web connect 」，连软件都不用装；如果你前边的web版不能用，可以使用 「Logi Bolt App」 独立安装包，同样配对完即可卸载或关闭。
这是罗技官方极少宣传的神器 —— Onboard Memory Manager。
对于有板载储存的键鼠，OMM 能直接读写板载内存。你可以用它设置 DPI、回报率、按键映射、灯光开关。设置完成后，即便卸载软件，配置依然保存在鼠标里。
对于像 MX Master 3/3S 这种号称“没有板载内存”的设备，其实 SmartShift 阈值、DPI 等参数会写入鼠标的临时寄存器。
* 操作方法：先安装 Logi Options+，把参数调好，然后禁止 Options+ 自启。只要不彻底断电（关掉底部开关）或者把鼠标键盘彻底用没电，大概率还能保持配置。
如果你必须使用 Options+ 的某些特定功能，但又讨厌它的臃肿，这里有一个终极解决方案。
罗技为了方便商用部署，Options+ 安装程序支持命令行禁用功能。我们可以利用这一点，只安装纯净的驱动，剔除 AI、分析、广告等垃圾组件。看下图，和文章前边那个“完整版”的Options+对比，是不是很清爽的界面。
原版项目主要针对Mac用户，而且脚本使用起来对国内用户不友好，所以我 Fork 并优化了项目 「tjsky/logi-options-plus-mini」，加入了中文界面和权限自动获取。
Windows 用户安装步骤：
1. 下载脚本压缩包并解压。
2. 双击运行 Run_Install.bat。
3. 脚本会自动检测网络环境并设置界面语言（支持从罗技中国服务器下载）。
4. 功能选择：脚本会询问你需要安装哪些组件。
* 建议输入：0 5 6 （仅基础驱动和键鼠固件更新功能）。
* 最多加个：10。（如果你需要简单的按键宏的话）
5. 输入 y 确认，脚本将自动备份配置、卸载旧驱动、并安装全新的精简版 Logi Options+ 再恢复你的配置。
6. PS“如果你运行脚本时看到的是英文界面，说明你开了全局代理让脚本误判你的地区了
无论是选择 SteerMouse 这样的第三方神器，还是使用 罗技板载内存管理器 (OMM) 实现“配置后即焚”，亦或是通过脚本 精简安装 Logi Options+，我们都能在享受罗技优秀硬件手感的同时，摆脱其糟糕的软件体验。至于那个微动计划报废问题嘛，我的建议是：除非你动手能力极强并且有足够的焊电路板的经验或者你会先练练焊电路板，否则咸鱼和淘宝有很多寄修服务或同城维修服务，找个靠谱的比自己折腾省心省力的多。
最后，希望这篇 罗技驱动优化指南 能帮你的电脑“减负”！如果你有其他更好的罗技优化技巧，欢迎在评论区分享。
The post 告别 Logitech Options+ 臃肿！罗技驱动精简瘦身与替代全攻略 appeared first on 秋风于渭水.
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，还让不让人用了？
Kdump 对于像咱们这样的个人站长，服务器主要运行 Web 服务的人，是完全没有用的，咱们并不需要在系统崩溃后查看 Kdump 保留内存转储存文件，来分析为什么系统会崩溃，面对系统崩溃我们能做到只有重启，快照，重装三板斧和报告软件作者。
所以，这 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 跳转请求，并提供了一份修改注册表彻底修复链接失效的终极解决方案。
[toc]
大概从（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%降至正常水平。一起来学习这次完整的技术复盘与防御实战。
[toc]
故事的开始非常偶然。昨天早上我本来只是看到一篇博文在介绍现代搜索引擎对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 和打脸的时刻~ 估计长期看本博客的基本是技术向居多，那我们就用数据说话。
[toc]
因为我的 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 秋风于渭水.
