“CV工程师”的小白迷之自信

时光倒流回好几年前，那时我的 PHP 和 JS 水平还停留在相当小白的阶段（虽然现在也还是业余），用现在流行的话说，就是一名标准的 “CV 程序员”（Ctrl+C / Ctrl+V）。

当时看到一些 SEO 教程说，不要直接引用外链，不然网站权重会丢失，不利于SEO优化云云，虽然那时候博客一个月的访问量加起来都没现在一天多，我还是决定搞一个外链跳转页，实现外链SEO优化。那时候的我，写代码基本靠搜。我当时在网上东拼西凑，这里复制一段 PHP 代码，那里又找来一段 JS 脚本，缝缝补补一通 Ctrl+C / Ctrl+V 算是把功能跑通了。

那时候的我觉得自己做得挺周全：

• 既有「关键词过滤」：在后端的 PHP 里加了正则，拦截类似 eval、base64 这种敏感词，防止有人注入代码。
• 还有「来源页检查」：在前端的 JS 里写了判断，判断访问来源是不是我的博客域名，如果不是就跳回首页。

看着这套“组合拳”，我心想：“这下稳了，既防注入又防盗链，妥妥的。” 这一用，就是好几年。

我变成了黑产眼中的“香饽饽”:遭遇 Open Redirect 漏洞扫描

部署后的头几年，一切风平浪静，看起来跳转页在忠实的工作着。直到大前年开始，因为《本地部署AI文生图工具 SD-webui 生成NSFW图》部署教程被广泛引用，博客的流量和热度突然上去了。那小半年的时间里，每日新访客（仅仅是新访客就）能稳定在 4位数，高质量反链好几个。在 Google 和 Bing 眼中，我的博客权重逐渐变高。

于是乎，树大招风，我的外链跳转页被盯上了。

最开始的端倪，是 Google Search Console 发来的“提示”。网域出现了大量“未编入索引”的提示，我点进去一看，全是 /goto/?url=… 后面跟一长串乱七八糟的垃圾网站链接（赌博、色情、灰产，应有尽有）。

紧接着，防火墙（WAF）开始频繁报警。日志显示，有大量的请求携带着奇怪的参数试图经过我的跳转页做XSS或者SQL注入。这是典型的 Open Redirect（开放重定向）漏洞利用尝试。

佛系站长的机械抵抗

面对这些攻击，当时的我虽然觉得烦，但并没有意识到问题的严重性。毕竟博客前台看着没啥异常，服务器也没崩，搜索引擎也没收录这些奇奇怪怪的跳转。

于是，一向 “佛系” 的我采用了最机械的应对方式：

• WAF 堵截：我在防火墙里加了几条规则，只要 URL 参数里包含某些特征，就直接拦截。
• GSC 移除：对于 Google 收录的那些垃圾跳转链接，我直接使用 Google 的移除工具申请删除。

“反正也没造成什么实质性的破坏，能拦就拦，拦不住貌似也没啥。” 就这样，我拖着这个隐患，得过且过地又混了两年多。

形同虚设的“来源检查”：一段被覆盖的 JS 逻辑

直到最近，那种久违的“折腾之魂”突然死灰复燃。趁着手里有干劲，我决定把这个陈年老页面彻底重构一下。

当我打开那个尘封已久的 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 后代码其实会继续执行下去的，实际执行时是下边这样的过程

1. 一个非法的来源，进入 if 了。浏览器接到指令：“准备跳转回首页”。
2. 毫秒级的时间内，代码会继续往下跑，执行到了下一行。浏览器接到新指令：“准备去目标外链”。
3. 后一条指令覆盖了前一条指令,浏览器会听从最后一句代码的指挥。
4. 结果：无论来源是否合法，浏览器都会乖乖跳转到 $url（目标网站）。
5. 纯纯拦截了个寂寞

当年的我犯了初学者最常见的认知错觉，是把 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;?>";
}

顺带一提，这个错误的代码至今仍在谷歌搜索结果的前五位，而且被多个外链跳转页所使用。😂

拒绝漏洞：使用 PHP filter_var 重构安全跳转页

痛定思痛，我彻底抛弃了原来的代码，基于 PHP 服务端重写了整个逻辑。

为什么抛弃使用 JS 的检查逻辑

原因很简单，正确的 JS 代码当然可以在跳转被恶意利用时拉回用户，但这无法阻拦黑产的自动化漏洞扫描。
扫描漏洞用的爬虫、脚本（Python、Curl 、Go 等）根本就不执行 JS 的！它们只看 HTTP 响应头和 HTML 里的链接。 在扫描器眼里，我的旧代码压根没有那个 if 判断，他直接看到了最后的跳转链接。扫描器只会给我的各种路径去发?url=http://www.baidu.com之类的命令遍历尝试，看会不会触发跳转，只要触发跳转到百度的首页，就标记为“存在 Open Redirect 漏洞”，自动存入“可用资产库”。于是就会被拿来做跳转了，至于实际环境访问时能不能完成跳转，不讲究的黑产并不会去核实。只是因为有 JS 的存在，实际用户访问时会被拦截罢了。

从 JS 到 PHP：真正的来源检查

现在来源检查在服务器端完成，不依赖客户端。直接在 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('非法请求：禁止直接访问或盗链。');
}

1. 直接 403：即使被利用了，正经的爬虫也能发现报了“403 拒绝请求”
2. 不依赖 JS ：彻底杜绝了扫描器把这里“误判”为开放重定向漏洞的可能。

放弃手搓正则，拥抱 filter_var：不再自己造轮子

当年真是的小白菜的常见状态，又菜又感觉自己强，当年的 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。这在安全领域叫“黑名单防御”，但其实：

1. 这本来不应该是跳转页该做的事，这种事情应该交给更前边的更专业的WAF去做。
2. 这种方式就像玩“打地鼠”，只要稍微换个姿势（比如利用 URL 编码或者空格绕过），我的之前正则就成了摆设。
3. 而且逻辑本来就有bug，我为了不让部分跳转目标直接能看出来，加了可以将跳转目标 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('目标链接格式错误。');

• 防止跳转内网和本地主机，作为一个外链跳转服务，没有任何正当理由需要指向一个内网或本地的 IP 地址。（这里只堵了IP，毕竟使用域名指向内网IP需要DNS配合，这利用难度就高了）
• 防止包含了空格、非法字符，错误的协议头：仅这一条就能这直接过滤掉了 90% 的低级扫描和恶意注入。
• 防止 XSS 脚本注入：以前构造 ?url=javascript:alert(1)的话。在老代码里，这会被当作合法 URL 运行。而 filter_var 会识别出这不符合 Web 协议规范，直接在入口处将其掐死。
• 防止畸形参数：恶意利用时，很喜欢在参数里混入换行符或特殊的二进制字符来试图截断逻辑。这些东西在filter_var的眼里都是不合法的它只认符合 RFC 标准的纯净 URL。

当然filter_var本质上是一个“格式校验器”，挡不住顶尖高手的定向渗透，比如传入一个格式完全标准，但指向内网某个邻居的数据库的域名。filter_var 会因为它符合 URL 规范而放行。这就是所谓的 SSRF（服务端请求伪造） 风险，这类深层次的逻辑漏洞，单靠一个函数是无法完全杜绝的。但面对互联网上每天成千上万次的自动化扫描和脚本攻击，它表现得比我那些个漏洞百出的正则要好太多了。放弃对“手搓代码”的执念，承认现成工具套件，尤其是安全、密码方向的现成轮子专业能力。现在的外链跳转页代码已经是一份真正的PHP安全跳转代码了。

更多细节修改：交互和 SEO 的多重升级

把原来的“静默X秒后跳转”改成了“倒计时卡片”：

• 使用 10秒倒计时：给访客足够的时间看清“您即将离开博客”的提示。
• 在页面内显示目标网址，看清到底要去哪里，确认目标网址安全。
• 加一个立即跳转的按钮，让不想等自动跳转的人可以立刻去要去的地方。

增加 htmlspecialchars 防止 XSS 攻击

因为现在的跳转页有一个跳转URL“预览框”。如果万一黑产绕过了前面的检查，把一段代码伪装成 URL 传了进来，直接打印在 HTML 里是非常危险的，搞不好就引发 XSS 攻击了。 htmlspecialchars会把所有的 <、>、"等特殊字符全部转义成 HTML 实体，让前端可以安全展示URL。

$display_url = htmlspecialchars($final_url, ENT_QUOTES, 'UTF-8');

增加 noindex, nofollo 标头

额外增加 X-Robots-Tag：直接在 HTTP 标头中加入 noindex, nofollow，直接告诉搜索引擎爬虫：“这个页面通通都别收录，权重别传递”。这比在 <head> 里写 <meta name="robots" content="noindex, nofollow" /> 更优先，爬虫不需要解析 HTML 就能看到，从而更有效保护博客的 SEO 资产。（当然meta也要加，毕竟某搜索引擎的爬虫不认这个响应头）

<?php
header('X-Robots-Tag: noindex, nofollow');

进阶玩法：使用 AES 加密隐藏真实链接

本来这次对外链跳转页的重构也就止步于上一步了，有些熟悉本站的人，估计已经发现新版跳转页已经上线运行了一段时间了。

我最近在爬取一个图片资源站时，发现对方有个很有意思的设计，这个图片站为了防止遍历本地路径实现快速抓取图片资源，他把站内的图片链接都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加密后的跳转链接，只有到执行跳转时才会显示出真正的跳转目标。

The post 少写一个 else，我的外链跳转页成了黑产眼中的“香饽饽”？重构一个安全的外链跳转页（附 PHP 源码） appeared first on 秋风于渭水.

苗姐这几天感冒了，也不知是不是因为前几天我给她洗澡没关门导致的，周二凌晨发烧到39.5℃，周三一早我们就带着她去了医院，抽血化验，结果是病毒性感冒，让回家吃奥司他韦。小家伙抽血哭了十几分钟，最后被我硬生生抱出的门诊楼，她的脾气特古怪，越是人多越是哭个不停，反而一看没人了，立马就不哭了。

昨天开始她的情况不太好起来，下午嚷嚷着「爸爸我要吃草莓」，于是x出去给她买了草莓和电解质补充剂，她吃了四五颗，剩下一颗一直拿在手里边玩边吃，还剩半颗时，趁我不注意塞我嘴里了…那草莓一点甜味都没有，我能感觉也到粘着一层她的鼻涕，我立马吐出来扔垃圾桶里，她看我一阵恶心的样子，反而笑得合不拢嘴，于是今天一早我也重感冒了…

今天上午她咳嗽更厉害了，又给她买了雾化机和布地奈德，用了一下似乎好多了。

唉，我讨厌感冒。

下午更新下，中午吃饭，苗姐亲了她姑姑一口，下午她姑也感冒了…啊哈哈哈

痛点深扒：罗技驱动软件的三宗罪（G Hub/Options+）

罗技第一宗罪：驱动分裂与版本混乱

你以为买个罗技键盘鼠标，插上就能用？太天真了。罗技的驱动历史就是一部“分裂史”。如果你像我一样，手里既有老款经典，又有新款旗舰，那你的电脑托盘区简直就是罗技图标的“连连看”。

罗技最老的管理软件叫 SetPoint、然后有了 Logitech Options，然后又变出来个 Logitech Options+ ？？厂商更新软属于正常操作，但问题是：罗技的新软件它不！兼！容！旧！硬！件！ 诶，这就逆天了好不。

• 在鼠标范畴：
  • 我有一只经典的 Logitech M570 轨迹球，这玩意只能在 SetPoint 下才能良好工作。在 Logitech Options 下虽能发现设备，但大部分高阶功能的配置项全不在。
    • 现状：我必须装「SetPoint」。
  • 我还有一个 MX Master （第一代） 鼠标，这次则是只能在 Logitech Options 在才能良好工作，在 Logitech Options+ 下会缺少配置项了。
    • 现状：我又必须装「Logitech Options」。
  • 我还有个 MX Master 3S （第三代） 鼠标，必须用最新的 Logitech Options+ 不然看都看不到鼠标。
    • 现状：我又双必须装「Logitech Options+」。
  • 结果： 为了用鼠标，我电脑里必须同时装 SetPoint + Options + Options+ 三个软件，加一起快 1GB了。除了都叫罗技，这三个软件界面、逻辑完全不同，简直像三家公司的产品。
• 在键盘范畴：
  • 我柜子有一把 G610 机械键盘，如果要用，需装上古的 LGS (Logitech Gaming Software)，因为新的 G Hub 不能正确支持它，依然是老问题：缺配置项。
    • 现状：我又双叒必须装「Logitech Gaming Software」。
  • 我家里目前正在用的是年会抽奖中的 G512 机械键盘，这个则 LGS 不认，需要用最新 G HUB。
    • 现状：我又双叒叕必须装「G Hub」。
  • 结果： 你猜我为什么把G610收起来不用呢，因为 G HUB 经常在自动更新后会把 LGS 的驱动干坏掉，或者两个软件在系统中抢占资源，导致键盘卡的妈都不认识了。

罗技第二宗罪：软件臃肿与广告植入

以前的驱动 LGS、SetPoint 都只有几十兆，清爽无比。现在的 G HUB 和 Options+，动不动就几百兆，启动慢得像是在加载 3A 大作。

• 驱动里塞个浏览器：最近的 Logi Options+ 更新搞了个“AI Prompt Builder”（AI一键启动），甚至在驱动里塞了一个完整的浏览器环境！这功能还默认开启，这种在驱动里塞完整浏览器环境的行为我就不点名还有什么软件了，个顶个都是知名流氓。
• 推销广告：打开驱动，还没看到电量，先糊一脸新品广告：“来看看我们新出的 MX Master 4 吧！”。我买你家那么贵的外设，不是买了个广告位好不！（所以我现在用《Bluetooth Battery Monitor》在任务栏看电量，尽量不打开罗技软件）。
• 罗技语音（Logitech Voice）：为了个游戏语音功能，强行整合进 Options+，不仅占用后台，还经常弹窗。问题是，谁家好人玩游戏用罗技语音啊。

罗技第三宗罪：功能冗余与逻辑混乱

• 驱动必须常驻后台：现在很多新功能（如 RGB 灯光、应用切换配置）依赖驱动常驻。一旦驱动崩溃（罗技驱动日常），鼠标键盘立马变回“智障”模式，DPI 乱跳。
• “智能”并不智能：那个 Smart Actions（宏命令） 逻辑极其死板，还不如我自己写个 AutoHotKey 脚本好用。
• 强制推行账号登录：G HUB 强制登录云同步，但大概率同步失败，或者被云端旧存档覆盖新配置。
• 功能设计鸡肋：比如那个 Actions Ring 鼠标手势，和开源工具（如 Quicker、WGestures）相比，简直是小灵通和 iPhone 16 的区别。罗技的设计下，默认你要用拇指按住那个手势按钮，然后以一个极其费手腕的姿势移动鼠标，并享受那微妙的延迟感，然后选中一些并没啥卵用的功能。

看看这界面截图，里面塞了多少不好用又很臃肿的功能。

实战教学：如何优化罗技驱动体验？三大解决方案

吐槽完罗技的糟心驱动，那我们要怎么解决这个问题呢？以下是我尝试过的 3 种不同层级的解决方案。

方案一：使用第三方工具替代罗技驱动（Mac/Linux/Windows）

如果你想彻底抛弃官方驱动，以下神器是你的首选。

1. Mac 用户：SteerMouse

Mac 上有个牛逼的软件叫 「SteerMouse」，也就是大家口中的“万能鼠标驱动”。它的平滑滚动算法比罗技官方还要丝滑，甚至能调整滚轮加速度曲线，让鼠标拥有匹配 Macbook 触摸板的体验。绝对值得付费购买的一款软件。

2. Linux 用户：LogiOps

Linux 社区的反向工程做得最好。「LogiOps」 是一个运行在命令行的非官方驱动，可以使用cfg文件完美配置键盘与鼠标的所有参数。

3. Windows 用户：组合拳

Windows 下没有单一的完美替代品，但可以通过组合软件实现官方驱动的部分功能：

• 实现按键映射和宏：使用 「X-Mouse Button Control」。
  

• 调节灯光效果：如果你只是想调你的光污染键盘，可以用 “OpenRGB”。这玩意比 G Hub 好用太多，如果只为灯效，强烈建议卸载 G Hub 只装这个。
  

方案二：利用“罗技板载内存管理器”实现免驱运行

也许是罗技仅存的良心，目前还有一些官方工具可以帮你减少垃圾驱动的影响。

1. 极简配对工具（无需安装庞大的驱动）

如果你的需求只是配对键盘鼠标，其他什么都不需要：
* Unifying 接收器（优联）：使用 「Logitech Unifying Software」，只有几兆，配对完即可卸载或关闭。

* Bolt 接收器：使用网页版工具 「logi web connect 」，连软件都不用装；如果你前边的web版不能用，可以使用 「Logi Bolt App」 独立安装包，同样配对完即可卸载或关闭。

2. 罗技板载内存管理器 (OMM)

这是罗技官方极少宣传的神器 —— Onboard Memory Manager。
对于有板载储存的键鼠，OMM 能直接读写板载内存。你可以用它设置 DPI、回报率、按键映射、灯光开关。设置完成后，即便卸载软件，配置依然保存在鼠标里。

3. 无板载内存设备的“偷鸡”技巧

对于像 MX Master 3/3S 这种号称“没有板载内存”的设备，其实 SmartShift 阈值、DPI 等参数会写入鼠标的临时寄存器。
* 操作方法：先安装 Logi Options+，把参数调好，然后禁止 Options+ 自启。只要不彻底断电（关掉底部开关）或者把鼠标键盘彻底用没电，大概率还能保持配置。

方案三：硬核瘦身！安装精简版 Logi Options+ 驱动

如果你必须使用 Options+ 的某些特定功能，但又讨厌它的臃肿，这里有一个终极解决方案。

罗技为了方便商用部署，Options+ 安装程序支持命令行禁用功能。我们可以利用这一点，只安装纯净的驱动，剔除 AI、分析、广告等垃圾组件。看下图，和文章前边那个“完整版”的Options+对比，是不是很清爽的界面。

使用 logi-options-plus-mini 脚本

原版项目主要针对Mac用户，而且脚本使用起来对国内用户不友好，所以我 Fork 并优化了项目 「tjsky/logi-options-plus-mini」，加入了中文界面和权限自动获取。

• 下载地址：GitHub | 蓝奏云

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 秋风于渭水.

缘起：从“佛系”到“崩心态”

熟悉我的朋友都知道，我一向是比较“佛系”的。

其实早在云服务器刚部署好，装好各种东西后，我就发现了这个奇怪的现象：明明我买的是 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 保留内存

毕竟虚拟的主板 BIOS 和硬件设备也需要占用地址空间嘛，比如我还开了VNC，几十MB的虚拟显存占用总要有。但是这玩意一般最多也就吃个200M，不应该啊。
我不放心执行一下命令，看了下内存映射日志。

dmesg | grep "Memory:"

输出： Memory: 3319136K/4194304K available (14336K kernel code, ...)，嗯……这，被吃的内存可真多。

可能吃内存的元凶三：Kdump (崩溃转储机制)

1. 先检查当前状态：

kdump-config show

显示 current state: ready to kdump，说明它正在占用内存。

2. 看一眼 Grub 默认配置：

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）

Kdump 对于像咱们这样的个人站长，服务器主要运行 Web 服务的人，是完全没有用的，咱们并不需要在系统崩溃后查看 Kdump 保留内存转储存文件，来分析为什么系统会崩溃，面对系统崩溃我们能做到只有重启，快照，重装三板斧和报告软件作者。

所以，这 512MB 的“昂贵的买路钱”，我不交了。

第一步：编辑 Grub 配置文件

 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里的话，那就改这里的参数。

第三步：更新 Grub 并重启

这一步至关重要，你不更新引导文件，改了配置也没用。
注意：执行后，服务器（系统）会被重启

sudo update-grub
sudo reboot

优化结果：瞬间回血

重启服务器后，第一时间打开终端输入 free -m.可用总内存从 3.2GB 瞬间跃升到了 3.9G。舒坦，这么多年拖延的问题终于解决了。虽然平时看着不起眼，但在流量高峰期或者 Docker 容器跑得比较多的时候，它就是从卡顿到流畅运行之间的那道分界线。如果你也发现你的 VPS 内存“缩水”严重，不妨检查一下 /etc/default/grub，说不定也能找回这笔“私房钱”。

总结

1. 感觉最近怎么总是在折腾一些陈年旧故障（笑哭）
2. 这次排故过程其实并不复杂，但它提醒了我：系统的默认配置（尤其是云服务商提供的系统镜像内的配置）未必就是最优配置。
3. 系统默认开启 Kdump 是为了生产环境的稳定性调试考虑的，但对于小内存（尤其是 2G/4G 档位）的 VPS 来说，这却是一种极大的资源浪费。
4. 毕竟操作了系统配置，切记操作前做好快照备份。 如果未来服务器经常莫名其妙死机且无日志可查，那时候才需要重新开启 Kdump 来抓取崩溃现场。但对于绝大多数像我一样只是跑跑博客、Docker 的用户，关了它吧，真香！
5. 熟悉运维的读者应该早已经看出来了，标题说是缺失了800MB内存，这只是我那时候不太熟悉换算得出的错误数字，实际应该是677 MB。那为什么我当时算出了800MB呢，是因为实际情况是物理内存4096MiB，其中3419Mib可用，但面板里不是这样算的，面板是用10进制算的，所以变成了3419Mib/1024/1024X1000X1000=3.26G内存可用，然后面板还隐藏了百分位，变成了3.2G，然后我（4G-3.2G）X1000=800MB，得出了“我擦，怎么少了快800MB”的结论。正确算法应该是 4096-3419=677MB 不过琢磨了下，我决定还是按照当时的实际心路历程去如实写吧。

The post VPS内存缩水排查：消失的 800MB 内存去哪了？ appeared first on 秋风于渭水.

故障初发：Telegram 中的 google 链接无法打开

大概从（2025年的）年初开始，我的电脑出现了一个非常诡异的“玄学”故障。绝对算得上是我遇到过最离谱的 Windows 点击链接无反应 故障

起初是在 Telegram 上，朋友发来的消息如果带有 google.com链接（比如搜索结果分享 www.google.com/search?q=...），我点击链接后什么都不会发生。

注意，是真正的“什么都没发生”：浏览器没有弹出，没有报错，仿佛我的点击被黑洞吞噬了一样。

但奇怪的是，点击其他任何链接（比如 github.com，baidu.com，youtube.com）都能正常唤起浏览器。

但极其偶尔的时候（也就2次），如果我关机关一半又取消了，这时候是可以点击 Telegram 中的 google 链接，自动调用浏览器打开的，只不过这时候因为魔法工具没启动，得到的只是一个无法连接的网页。

当时这个问题对我的影响不算大，毕竟只是 Google 的链接嘛，大不了我手动复制链接扔进浏览器里打开。我甚至一度以为是 Telegram 的 Bug （毕竟用的不是官方客户端）也就没当回事，就这样“带病生存”了大半年。

故障现象升级：从 Telegram 到系统级 URL 跳转失效

直到前几天，我的 Antigravity 登录掉了。

当我点击登录界面的「Sign in with Google」按钮时，熟悉的死寂再次降临 —— 按钮按下去，浏览器没有弹出，没有任何反应。我没法登录了。

这问题就严重了。我开始意识到，这不是 Telegram 单个软件的问题。经过一番简单的测试，我发现事情比我想象的要严重得多：

• Win+R 运行：输入 https://google.com，回车，无反应。
• CMD/终端：输入 start https://google.com，回车，无反应，也不报错，只有鼠标光标会变成繁忙状态1秒左右，然后恢复原样。
• Team/PDF阅读器/其他软件：点击文内的 Google 链接，统统无效。
• 唯一的幸存者：神奇的是，Office 全家桶（Word/Excel）里的 Google 链接竟然能正常打开。（忒忒忒，微软自家兄弟的待遇果然不一样）

这就不仅是“玄学”了，这是系统级的 URL Scheme 劫持。作为一个爱折腾的人，我决定彻底揪出这个“幽灵”。

常规排查：排除浏览器、Hosts 与网络问题

既然是 Google 打不开，我首先想到的自然是网络或浏览器问题，毕竟国内嘛。

1. 排除协议与浏览器：
   我在运行框输入 https://google.com.jp，秒开。
   这说明：
   • https 协议关联没问题（系统知道找浏览器）。
   • 浏览器本身没挂。
   • 故障只针对 .com 后缀的 Google 域名。
2. 排除文件混淆：
   早年间.com是Windows 可执行文件后缀。我试着输入 https://google.com/（加了尾部斜杠强制识别为 URL），依然打不开。那就可以排除系统将其误判为本地文件的可能。
3. 排除 Hosts 与 DNS：
   检查 C:\Windows\System32\drivers\etc\hosts，干干净净。
   尝试将默认浏览器从 Chrome 切换为 Edge，故障依旧。
4. 难道是莫名其妙的撞墙了？
   我在运行框输入 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指令” 到 “浏览器收到指令” 的中间环节。

定位故障：利用 Windows 事件查看器锁定崩溃的 WsaClient.exe

既然 CMD 运行 start https://google.com 没有任何报错信息，并且有进入繁忙状态，说明那个拦截请求的进程要么是在“沉默中灭亡崩溃”了，要么“处理了不告诉我偷偷的”。我打开了 Windows 事件查看器 (Event Viewer)，先试图寻找系统崩溃的蛛丝马迹。

果不其然，在 Windows 日志 -> 应用程序 中，我抓住了一个刚刚发生的“应用程序错误”：

任务类型：应用程序奔溃事件
出错应用程序名称： WsaClient.exe
出错模块名称： ucrtbase.dll
异常代码： 0xc0000409 (堆栈缓冲区溢出)

将日志清空后再次执行打开 google 链接的操作，可以再次复现。

WsaClient.exe？这踏马不是 Windows Subsystem for Android (WSA) 吗？

真相大白：WSA 安卓子系统的 App Links 霸道劫持

看到 WSA 我反应过来了

我安装的是 GitHub 上修改过的 MagiskOnWSA 版本 WSA，里面集成了 GApps（谷歌全家桶）。
虽然这个版本的 WSA 很香，但安卓系统有一种机制叫 App Links，应用可以向系统注册它支持的域名。显然，WSA 里的 Google App 极其霸道地向 Windows 宣示了主权：“所有 google.com 等域名都归我管，别给浏览器。”

这个图已经是我修复后的了，之前 Google App 足足关联了 17 种链接。

故障流程还原：

1. 我在 Windows 点击 google.com。
2. Windows 发现这域名归 WSA 管，于是唤起 WsaClient.exe。
3. WSA 客户端（由于是魔改版或环境问题）在处理这个调用请求时，触发了 ucrtbase.dll 的溢出，瞬间崩溃。
4. 因为崩溃的太快且 WSA 并无 UI 来显示报错，我看到的现场就是“点完链接什么都没发生”。

而 Office 里的链接之所以能打开，估计是微软自家的 Office 内部有更高级的超链接处理逻辑，绕过了系统的这一层默认关联，链接直接发给了浏览器。

艰难排雷：常规设置与 ADB 冻结统统无效

既然找到了真凶，卸载 WSA 当然能解决，但我还想留着它用。我需要的是切断关联。

但这比我想象的难得多：

1. 系统设置无效：我去 Windows 设置 -> 应用 -> 可打开网站的应用，把 WSA 关联的 google.com 关掉。结果毫无作用，事件查看器里依然报错。
2. 安卓设置无效：进 WSA 内部把 Google App 的“打开支持的链接”关掉，直接导致 WSA 崩溃。重启WSA后再次查看，倒是显示支持的链接都关掉了
3. ADB 冻结无效：我一怒之下用 ADB 命令 pm disable-user 把安卓端的 Google App 冻结了。结果 Windows 居然还是固执地调用 WSA，然后继续崩溃，甚至我都把 WSA 给关闭了，Windows 还是锲而不舍的去呼叫 WSA ，就像对着一具尸体喊话。

这就很绝望了。说明 Windows 系统内部有一份独立的、不受 UI 控制的注册表清单，记录着这个错误的关联。

解决方案：修改注册表，根除 WSA 的 URL Scheme 链接劫持

没办法，只能动用注册表编辑器 (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链接不放，导致我无法在电脑中点击链接打开谷歌的网页。

解决方法：

• 找到所有包含 AppUriHandlers\google.com 且路径属于 WSA 的项，直接右键删除。
• 重启资源管理器
• 再次 Win+R 输入 https://google.com
• 浏览器秒弹！
• 在telegram中点击链接 https://google.com
• 弹出选择打开方式弹窗 （注意：第一次选择后，浏览器很可能会打开一个乱码页，但只要调用浏览器打开了就行，之后再点链接时就没有问题了）

故障总结：槽点满满

困扰我一年的“玄学”故障，竟是因我在 WSA 里装了个谷歌全家桶的需求。

这个故事告诉我们：

1. 相信日志：当 CMD 都不给你报错的时候，事件查看器是最后的诚实证人。
2. 别太信 UI：Windows 设置里的开关关掉了，并不代表底层的设置真的清理干净了。
3. 技术债：折腾第三方魔改系统组件（WSA with GApps），迟早是要还债的……
4. 早有预兆：如果你注意看了最后那张注册表中的 AppUriHandlers 项，你会发现其实 WSA 不仅霸道的劫持了 google 的打开方式，还有ins、facebook、chatgpt 等等成吨的链接，只是恰好我没发现而已，我仔细想了一下，其实去年我也遇到过这些链接无法打开的情况，只是因为出现频率远小于google的链接，所以被我忽略了，毕竟“无非是复制链接去浏览器里打开嘛”😂
5. 阿三化：合着用户在 WSA 里装了谁家的 APP ，用户就无法在电脑中点链接后自动用浏览器打开谁家的链接了，微软被阿三附体名不虚传。最终我不得不手动清理了这部分注册表，只保留绝对需要用 APP 打开的链接，比如gmail.app.goo.gl、m.instagram.com

如果你也遇到点击某个特定网站毫无反应 Windows 链接跳转失效的情况，不妨查查是不是有什么奇怪的 应用 产生了 URL Scheme劫持 。希望这篇排错记录能帮到有同样困扰的朋友。

The post 记一次“闹鬼”的故障：Windows 点击 Google 链接毫无反应，竟是安卓子系统 (WSA) 惹的祸？ appeared first on 秋风于渭水.

在“反内卷”和“松弛感”的生活基调里，又是坚持阅读的一年。书籍始终是照进日常的微光，音乐与拍照则为心灵拓出另一片旷野，与我一起对抗浮躁。今年一共读了95本书，完整读完63本（不含专业书），比去年多3本。这多出的3本，是前段时间心血来潮翻开的钢笔画教程，还在夜深人静的时候尝试画了几幅。

今年坚持362天拿起了书本（更多是电子书），其中微信阅读592小时，加上纸质书保持平均每天阅读约1.9小时，阅读总时长和平均时长较去年略降低。今年增加了国内作者的阅读比重，经典文学与本土散文，比如老舍的烟火气、许地山的哲思、陈慧的市井诗、冯骥才的文化情怀、阿来的旷野叙事、史铁生的生命叩问。国外作者主要有我偏爱多年追随的黑塞，还有川端康成、克拉丽丝·李斯佩克朵等。总体依然是偏重于文学类，以及一些自然观察和生态哲思类书籍，选书比较随性。

使用电子书进行阅读的比例较去年继续上升，达到85%以上。笔记自动归类、关键词秒速检索，效率远超纸质书；旅行时带块墨水屏，比沉甸甸的书省心太多；手机同步进度，随手就能续上未读完的故事。

常听人说“书看不进去”，其实不必强求。每天利用10分钟的空当，打开阅读APP而非短视频应用，每次读10来页，一年下来也能攒下可观的阅读量。我手机上没有小红书和抖音，微信关闭朋友圈和视频入口，尽可能的关闭消息推送和红点，不安装资讯类应用。其实最终并没有因此错过了什么，反而收获了久违的专注力。

今年观影量跌至历史新低，仅24部，重刷了几部旧片。对比大学时一年百余部观影的记录，如今确实难感受到电影里的“诚意”。或许真的是年纪上去了，看看纪录片触摸真实或者听听圆桌派汲取知识，更加符合我的口味。听歌自然不用说了，以老歌和古典为主。

明年打算读历史、植物、佛学相关的书，欢迎大家给我荐书，也欢迎加入阅读的行列。抱着非功利的心态，一起享受阅读的快乐。

2025 已读书单

1. 《平面国》 [英] 埃德温·A.艾勃特 / 鲁冬旭 / 上海文化出版社 / 2020-08 / ★★★☆
2. 《世界在书店中》 [英] 亨利·希金斯 / 彭伦 / 人民文学出版社 / 2022-03 / ★★★☆
3. 《博物学家的自然观察笔记》 [美]约翰·巴勒斯 / 刘浩兵 / 浙江大学出版社 / 2018-11 / ★★★
4. 《心灵书写》 冰千里 / 北京联合出版公司 / 2021-10 / ★★★
5. 《森林之歌》 [加] 苏珊娜·西马德 / 胡小锐 / 中信出版社 / 2022-06 / ★★★★☆
6. 《大医·破晓篇》 马伯庸 / 上海文艺出版社 / 2022-09 / ★★★★
7. 《夏天的玫瑰》 史铁生 / 湖南文艺出版社 / 2016-10 / ★★★★
8. 《苦炼》 [法] 玛格丽特·尤瑟纳尔 / 段映虹 / 上海三联书店 / 2021-10 / ★★★★☆
9. 《指数基金投资指南》 银行螺丝钉 / 中信出版社 / 2017-11 / ★★★
10. 《八宝辣酱》 汪曾祺 / 文化发展出版社 / 2021-07 / ★★★★
11. 《成事之道》 姜鹏 / 红旗出版社 / 2024-05 / ★★★
12. 《务虚笔记》 史铁生 / 人民文学出版社 / 2011-04 / ★★★★
13. 《关键跃升》 刘润 / 机械工业出版社 / 2024-07 / ★★★
14. 《山谷微风》 余华 / 北京十月文艺出版社 / 2024-08 / ★★★☆
15. 《阅读是安静的自我觉醒》 [德] 赫尔曼·黑塞 / 易海舟 / 天津人民出版社 / 2025-04 / ★★★
16. 《情书》[日] 岩井俊二 / 穆晓芳 / 南海出版公司 / 2018-06 / ★★★★
17. 《哭泣的骆驼》 三毛 / 微信读书 / 2025-04 / ★★★★
18. 《晴耕雨读，得闲饮茶》 季羡林等 / 华中科技大学出版社 / 2023-04 / ★★★☆
19. 《老舍谈写作》 老舍 / 百花洲文艺出版社 / 2019-06 / ★★★★☆
20. 《老舍：有朋友的地方就是好地方》 老舍 / 浙江文艺出版社 / 2024-05 / ★★★★
21. 《茶馆》 老舍 / 人民文学出版社 / 人民文学出版社 / 2018-04 / ★★★★
22. 《去有风的旷野》 阿来 / 人民文学出版社 / 2024-09 / ★★★★
23. 《一只鸟接着一只鸟》 [美]安·拉莫特 / 朱耘 / 中信出版集团 / 2023-03 / ★★★★
24. 《思考就是我的抵抗》 [英] 弗吉尼亚·伍尔夫 / 齐彦婧 / 中信出版社 / 2022-09 / ★★★☆
25. 《月牙儿》 老舍 / 北京联合出版公司 / 2020-06 / ★★★★
26. 《人间处方》 梁晓声 / 北京联合出版公司 / 2023-10 / ★★★
27. 《去有花的地方》 陈慧 / 宁波出版社 / 2024-6 / ★★★☆
28. 《恶意》 [日] 东野圭吾 / 娄美莲 / 南海出版公司 / 2016-11 / ★★★★
29. 《大地上的事情》 苇岸 / 广西师范大学出版社 / 2020-10 / ★★★★☆
30. 《在菜场，在人间》 陈慧 / 天津人民出版社 / 2023-12 / ★★★☆
31. 《一切愁云消散》 [英] 薇塔·萨克维尔-韦斯特 / 王林园 / 浙江文艺出版社 / 2025-06 / ★★★★
32. 《空山 第一部：随风飘散》 阿来 / 微信读书 / 2025-07 / ★★★★
33. 《至少还有书》 [美] 帕梅拉·保罗 / 林晓筱 / 湖南文艺出版社 / 2022-01 / ★★★☆
34. 《遥远的公路》 舒国治 / 中国友谊出版公司 / 2024-05 / ★★★★
35. 《人间旅馆》 陈年喜 / 天津古籍出版社 / 2025-07 / ★★★☆
36. 《四时之美：丰子恺节令书》 丰子恺 / 长江出版社 / 2019-10 / ★★★★
37. 《能人》 冯骥才 / 天津人民出版社 / 2020-11 / ★★★☆
38. 《我在北京送快递》 胡安焉 / 湖南文艺出版社 / 2023-03 / ★★★
39. 《重走》 杨潇 / 上海文艺出版社 / 2021-05 / ★★★★
40. 《古都》 [日] 川端康成 / 马辛西 / 微信读书 / 2025-10 / ★★★★☆
41. 《伊豆舞女》 [日] 川端康成 / 林少华 / 青岛出版社 / 2023-01 / ★★★★
42. 《园冶》 计成 / 张则桐注解 / 三秦出版社 / 2021-07 / ★★★★☆
43. 《雪国》[日] 川端康成 / 董海燕 / 微信读书 / 2024-10 / ★★★☆
44. 《山水》 冯至 / 天津人民出版社 / 2022-03 / ★★★☆
45. 《黑塞的晚安处方》 黑塞 梭罗 加缪等 / 小迦 / 北京理工大学出版社 / 2025-09 / ★★★☆
46. 《春桃》 许地山 / 玖壹合创 / 2022-01 / ★★★★
47. 《空山灵雨》 许地山 / 江苏凤凰文艺出版社 / 2015-05 / ★★★☆
48. 《黑白绘：钢笔画完全自学教程》 涂涂猫 / 人民邮电出版社 / 2016-02 / ★★★
49. 《画笔下的城市》 Dopress Books / 人民邮电出版社 / 2017-01 / ★★★☆
50. 《万尼亚舅舅·三姊妹·樱桃园》 [俄] 契诃夫 / 焦菊隐 / 上海译文出版社 / 2014-09 / ★★★★
51. 《那一天》 [法] 维利·罗尼 / 赵朝泉 / 广西师范大学出版社 / 2014-12 / ★★★★
52. 《古村·古俗》 冯骥才 / 浙江文艺出版社 / 2021-06 / ★★★☆
53. 《生命本就纯真》 周国平 / 湖南文艺出版社 / 2020-09 / ★★★★
54. 《旷野的诗意：李元胜博物旅行笔记》 李元胜 / 重庆大学出版社 / 2020-12 / ★★★★
55. 《笔尖下的黑白世界》 白鹿猿 / 人民邮电出版社 / 2020-07 / ★★★
56. 《定投十年财务自由》 银行螺丝钉 / 中信出版社 / 2019-09 / ★★★
57. 《还是要相信》 陈鲁豫 / 花城出版社 / 2021-03 / ★★★
58. 《禅修入门》 虚云 / 汇聚文源 / 2024-07 / ★★★★☆
59. 《写作与生活》 [巴西] 克拉丽丝·李斯佩克朵 / 陈迪 / 人民文学出版社 / 2022-02 / ★★★☆
60. 《星辰时刻》 [巴西] 克拉丽丝·李斯佩克朵 / 闵雪飞 / 人民文学出版社 / 2022-03 / ★★★☆
61. 《股票作手操盘术》 [美] 杰西·利弗莫尔 / 杜浩 / 中国青年出版社 / 2012-07 / ★★★★☆
62. 《简单 丰盛 美好》 [日]枡野俊明 / 程俐 / 北京时代华文书局 / 2020-06 / ★★★
63. 《我走入宁静蔚蓝的日子》 [德]赫尔曼·黑塞 / 窦维仪 / 广东人民出版社 / 2024-03 / ★★★★☆

2025 观影清单

1. 《抓娃娃》 2024 / 中国大陆 / ★★★
2. 《哪吒2魔童脑海》 2025 / 中国大陆 / ★★★★
3. 《我们一起摇太阳》 2025 / 中国大陆 / ★★★★
4. 《遗落战境》 2013 / 美国 / ★★★
5. 《守岛人》 2021 / 中国大陆 / ★★★
6. 《影响世界的中国植物》 2019 / 中国大陆 / ★★★★
7. 《焚城》 2024 / 中国香港 / ★★★
8. 《徒步101》 2022-2024 / 中国大陆 / ★★★★
9. 《探索新境》 2022-2024 / 中国大陆 / ★★★
10. 《客从春天来》 2024 / 中国大陆 / ★★★★
11. 《一直游到海水变蓝》 2020 / 中国大陆 / ★★★★★
12. 《罗小黑战记》 2019 / 中国大陆 / ★★★★
13. 《超人》 2025 / 美国 / ★★★
14. 《失控夜班》 2025 / 瑞士 / ★★★★
15. 《异形：地球 第一季》 2025 / 美国 / ★★★
16. 《侏罗纪世界：重生》 2025 / 美国 / ★★
17. 《会计刺客2》 2025 / 美国 / ★★★
18. 《新·驯龙高手》 2025 / 美国 / ★★★
19. 《F1：狂飙飞车》 2025 / 美国 / ★★★★
20. 《碟中谍8：最终清算》 2025 / 美国 / ★★★★
21. 《埃利亚斯》 2024 / 法国 / ★★★
22. 《长安的荔枝》 2025 / 中国大陆 / ★★★
23. 《久别重逢》 2024 / 中国香港 / ★★★
24. 《罗小黑战记2》 2025 / 中国大陆 / ★★★★

附：2024年的已读书单+观影记录、2023年的已读书单、2022年的已读书单、2021年的已读书单

服务器负载异常？出站流量居高不下？本文记录了我如何发现并防御一种伪装巧妙的低频分布式“刷流”攻击。通过分析Nginx日志、识别异常UA和参数，最终使用Nginx 444 状态码成功对抗刷流攻击，将服务器负载从70%降至正常水平。一起来学习这次完整的技术复盘与防御实战。

[toc]

📉 序幕：一次普通的 robots.txt SEO 优化

故事的开始非常偶然。昨天早上我本来只是看到一篇博文在介绍现代搜索引擎对robots.txt文件格式的适配，里边提到对于WordPress博客已经不再推荐屏蔽/wp-includes/，我核实了一下确实是这样的，于是计划修改一下博客的 robots.txt 文件，优化一下 SEO 策略。
然而，当我登录面板准备操作时，首页的负载引起了我的警觉。在这个本该平静的时间点，服务器的状态却显得异常亢奋，负载持续在70左右。

🔍异象：服务器负载异常——负载的“虚假繁荣”

我果断先去一眼到底是什么进程在吃我的资源，结果：

• php-fpm 加上 nginx 一直维持在 CPU 占用 50~70 %的区间内 （绝了，刚好在报警阈值以下）
• php-fpm 的 CPU 占用大概20%左右，nginx 则是在 50%左右（1、说明大部分流量都命中缓存了，2、处理网络流量占用了大量 CPU 资源，要知道平时 Nginx 很少会超过 2% 占用）
• 网站的出站流量持续维持在 2MB/s以上 （同样也压的非常精准，正好不会触发报警）
• umami统计里今天的访客到至今（我查询的时候）才300多人。

这个数据绝对有问题，而且是有大问题！先不说umami里在线访客只有2个人的情况，也不说PHP占用也不低的事情。就算是有大量真实用户访问，PHP 的负载应该会很高（毕竟 WordPress 是动态博客，缓存做的再好也不对劲）。但现在 Nginx 居然比 PHP 还忙，这种诡异的情况，一般意味着：

1. 我被恶意抓取了？
2. 我被盗链了？
3. 我被 CC 攻击了？
4. 亦或者我的服务器被植入恶意脚本了？

直觉告诉我： 恶意爬虫或 CC 攻击的可能性最高，于是先从这个方向查。

🧐侦查：从 access.log 中寻找蛛丝马迹

常规起手，先看 Nginx 的 access.log

1. 实时查看日志（看看现在正在疯狂刷新的请求是什么）：

# 我这里打的默认路径，如果你想参考，请根据你的实际情况调整
tail -f /var/log/nginx/access.log

这屏幕日志刷的哗哗的，滚动的飞快，1秒怕不是有10条以上了，我还没看清就刷上去了，额，算了，还是统计一下吧，直接看日志超过我的目力限制了。

🤔疑点：Nginx日志分析——IP分散、参数固定、流量精准控制

1. 统计攻击 IP Top 20（找出攻击者IP）：

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 20

粗看一切正常，并没有哪个IP在疯狂请求我的站点。

2. 统计被请求最多的 URL（找出受害文件）：

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 万次，这显然是有人在疯狂刷我的首页和特定资源。

3. 针对性看一下请求来源 （都有谁在请求异常文件）

首页的日志不好分析，毕竟有正常人在，那个奇怪的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 一段时间就显得不合适且毫无意义了。

⚔️ 破局：Nginx防御配置——拦截特定查询字符串

先干死请求local_ga_js=XXXXX的，攻击特征这么统一不干你干谁，首页的问题先放到一边。

先改一下站点的 nginx 配置

# 放在 location / 之前
if ($query_string ~* "local_ga_js=") {
    return 444;
}

这里使用 Nginx 特有的 444 状态码。相比返回 403，444 会直接关闭连接且不返回任何数据包，能最大限度节省出站流量以及服务器性能。（Nginx官方关于444状态码的介绍）

😏追击：对抗刷流攻击——伪造的浏览器指纹

前边的规则配置后效果立竿见影， 几个查询扔出去，果然看到 CPU 压力已经大幅下降了。
有效果就好，我先去喝口水，大早上这么半天连口水都没喝呢，喝水时脑内复盘了一下目前的现状：

• Nginx还是保持在15%左右的占用
• php-fpm保持4%左右的CPU占用。
• RX（入站）基本维持在几十KB/s，
• TX（出站）还是持续在500KB/s到2MB/s之间。

第一阶段的防御（拦截恶意 PHP 请求）已经大获全胜！首页的 Redis 缓存被命中。Nginx 直接吐出了静态 HTML，没有调用 PHP，PHP 不再处理那些垃圾请求了。但是他一直在刷首页，还是有点烦人的，毕竟这依然会造成一个持续的 0.5MB/s 的出站流量，虽然这和整体带宽相比并不大，但一天下来也 40 GB 了。倒完水回来喝一口，和同事聊几句工作，咱们继续处理。

1. 首先清空日志，不然日志太大了不好分析

echo "" > /var/log/nginx/access.log

2. 等 60 秒

3. 查看文件大小：

ls -lh /var/log/nginx/access.log

额，短短60秒，日志文件就有100KB了，一行请求基本是 200 B，一秒内还是有接近10次请求……

4. 先看下60秒内的拦截和放行的比例（看状态码）确保前边的措施生效了。

> 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

• 拦截成功 (444): 842 次。说明前边针对 JS 的规则生效了，拦住了 36% 的攻击。
• 重定向 (301): 712 次。说明攻击者很蠢，在访问 HTTP 或者非 www 域名，被 Nginx 自动纠正到 HTTPS。
• 穿透防线 (200): 744 次。这是我唯一需要担心的。这意味着有 744 个请求被认为是“合法”的，Nginx 处理了它们（返回了网页）。

5. 再次看看它在访问什么 URL （再看一次新的日志）

> 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。

6. IP太分散，我们来看看User-Agent

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，也非常眼熟嘛，明显是个脚本。

7. 直接Nginx屏蔽这3个版本号试试，反正看了眼统计数据除了攻击者，压根就没人用。

# 屏蔽特定的虚假 Chrome 版本
if ($http_user_agent ~* "Chrome/(110|113|129)\.0\.0\.0") {
    return 444;
}

🎉 最终战果：立竿见影

配置重载后，重新看一下系统占用

• Nginx CPU： 从 25% 瞬间暴跌至 1%~2%。
• 出站流量 (TX)： 从 700KB/s 降至 20KB/s（偶尔跳动至 500KB/s，应该是真实用户的访问）。
• 应用层： PHP-FPM 继续保持 4% 的养老状态。

这才正常嘛，搞定收工。

🕵️‍♂️真相大白：这不是攻击，而是“刷流”

战局已定，服务器恢复了往日的宁静。但作为一个技术人，好奇心驱使我必须把这件事琢磨透：这到底是个啥？
回顾整个事件，它和传统意义上的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 外衣的流量刷子、电子垃圾虫、损人不利己的赛博脑残，必须予以最强烈的鄙视、唾弃和防范！

🛡️ 尾声：系统恢复与安全启示

1. 监控的阈值，也是攻击者的标尺：攻击者显然针对性研究过参数，将攻击力度精准控制在阈值之下。这提醒我，需要设置更复杂的异常检测规则（如流量同比暴增、非常规时间段的活跃度），而不能只依赖静态阈值。
2. “低频分布式”攻击成为新常态：高调、暴力的攻击容易发现也容易防御。但这种低频、IP海量轮换、模仿正常行为的“慢性消耗”更难察觉。防御思路必须从“封堵单点”转向“识别行为模式”。本次是通过固定参数和异常User-Agent进行拦截。
3. 444状态码是个好东西啊：面对明确定义的恶意请求，直接返回 444（连接关闭） 而非403或404，能最大程度节省服务器资源（尤其是出站流量），让攻击者“偷不到”任何数据包，把损失降到最低。
4. 那个/?local_ga_js=XXXX其实是本地化 Google Analytics 统计代码，这样谷歌分析才能对中国用户生效（虽然谷歌分析的域名没被墙，但访问并不稳定）所以实际上最后用的 Nginx 配置文件是

# 放在 location / 之前
if ($arg_local_ga_js = "f78e59fd91e18c7a2940a914030e9743") {
    return 444;
}

要放过正常用户嘛。
5. 不过鉴于这位刷量的说不好也是订阅了我的博客，所以我又做了一些监控措施，以防他变招。

The post 对抗刷流攻击：我是如何通过Nginx防御“绅士刷流”并拯救服务器性能的 appeared first on 秋风于渭水.

如果把长期写个人博客比作一场马拉松，那 2025 年对我来说，大概是——跑到半路鞋掉了，光着脚跑完，结果回头一看，成绩居然还凑合？
又到了一年一度立 Flag 和打脸的时刻~ 估计长期看本博客的基本是技术向居多，那我们就用数据说话。

[toc]

一、 量化 2025：这么佛系的站还能有这种流量？

因为我的 Umani 在年中时炸了一次（倒霉爪云，云服务太烂了），所以就以 Google Analytics的数据吧

• 活跃用户：12W 人 (差不多正好1个月1万人)
• 新用户：21W 人（新朋友比常客多这么多，说明咱这地儿引流能力还行，但“回头率”还有巨大提升空间……或者说大家都是看完教程就撤的？）
• 总互动事件：130W 次（平均每位活跃用户停留了 1分55秒，大概够读完一篇短文开头）
• 总浏览量：这玩意没法直接加，但看数据，几十万次浏览是有的。

也就是说，今年有起码十多万人曾光顾过我这个小站。如果把这些人都塞进鸟巢体育馆，差不多能坐满 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. 求助网友：发帖描述问题，回复多是“我用的也是这个主题，没问题啊”。遇到问题时最绝望的莫过于此。

在经历了长达一周多的、精神与肉体的双重折磨后，我望着被我改的七零八碎的代码和依旧随机乱码的页面。我终于做出了一个违背“折腾精神”，但顺应“心理健康”的决定：恢复服务器的快照，回档到更换主题之前的那一刻。鼠标点击确认的那一刻，世界清净了。博客恢复了正常，除了浪费的时间，什么都没发生。

今年对博客本身有效的折腾，唯二：

• 修复了RankMath SEO插件和WP Editor.md编辑器共存的冲突问题。（不然每次写完文章需要恢复到古腾堡编辑器才能处理SEO事务）

• 给文章末尾和 RSS 源加了一句提示词，试图教化那些来抓取内容的AI，让它们总结时别忘了是从我这里“学习”的。（具体效果未知，但求个心理安慰）

五、流量来源：搜索引擎依然是最强的

看看大家都从哪儿来到我的小破站的：

• 搜索引擎：必应和谷歌是两大巨头，合计带来了超过15万次会话。必应今年超越谷歌成为最大的流量入口，独立博客的命脉，依然牢牢握在搜索引擎手里。谷歌则明显下滑，来自谷歌的流量已经低于直接访问了。某度依然爬虫持之以恒的天天来，但就是不收录本站的任何东西。

• 直接访问：占比比谷歌还高，看来还是有人把本站放到自己的收藏夹里的，很欣慰。

• 社区与友链：知乎、GitHub、Linux.do、CSDN、豆瓣、贴吧等社区带来了不少流量。“开往”、“博友圈”、“十年之约”、“BlogFinder”、“blogsclub”等博客联盟的友链跳转也是稳定的来源。感谢各位友链小伙伴和社区里的分享。

• 一些神奇来源：来源数据里还混入了一些 127.0.0.1:XXXX （本地）、 172.20.x.x\10.x.x.x （大内网），甚至还有 mi.feishu.cn （小米内部的云文档）的引用。看来我的文章偶尔也会出现在一些内部技术文档或本地测试环境里，这感觉有点奇妙。

六、读者画像：天涯海角的数字邻居

这部分我只能大呼看不懂了。
从城市排名来看，来自台北的朋友以微弱优势战胜了香港成为了访客最多的城市，至于到底是本站很受台湾网友欢迎还是很多人的魔法上网节点是台湾的我就不知道了（估计是应该是真人居多吧，毕竟大部分魔法上网的更倾向于用香港）。上海、深圳、郑州、大连、广州、北京的朋友也贡献了可观的流量。
每当看到这些地理位置，就会觉得这个小小的博客，像是一个连接了世界各地某个角落的、微弱的数字信号塔。虽然我们素未谋面，但通过一篇解决具体问题的小教程，产生了奇妙的连接。

七、结尾：2026 继续在折腾中前行

回看 2025，虽然技术折腾是个闭环，折腾一圈又回到了原点。2025年的地球上发生了很多大事，在我敲下这篇文章的当下，窗外的北风在呼叫着穿过大楼之间的空隙，阳光洒在我桌前的植物上，2025 这个世界没有变得更好，但也没有变的更坏吧。博客的折腾是个螺旋上升的过程，虽然去年并不是数据最好的一年（最好的是2022年，因为写了一篇教用SD画色图的文章）不过比起去年，也没变得更差。
最后，用今年一篇不起眼的小文章《碎碎谈》里的一句话作为结尾吧

“对我来说，分享行为在于有效传递信息。”

感谢你看到这里。我们，明年再见。

The post 2025 年终总结：流量、爆款与一场主题更换引发的“血案” appeared first on 秋风于渭水.

发文

今年共发表文章 63 篇，与去年基本持平，略增 1 篇。内容上继续围绕“闲余”与“雅致”的核心主旨，以游山玩水、山野探索为主，专题包括“我在苏州逛园子”、“山西河北历史文化之旅”、“博物图鉴”、“日常漫步”，也浅谈了几篇关于极简、效率与断舍离的文章，技术类内容已基本淡出。年度点击量最高的文章是年初第一篇发布的《Calibre 推荐配置与插件》，共获得 18,533 次点击。全年收到评论 2,103 条，较去年增加 300 条，“S兄”成为本年度“首席评论员”。评论数最多的文章是《以阅读体验为核心的网页宽度设计策略》。

共发布 63 篇文章，浏览最多的 10 篇文章如下：

Calibre 推荐配置与插件 (18,533)
隐居假期 (8,731)
WordPress 极简主题 Dear v1.2.0 (8,644)
以阅读体验为核心的网页宽度设计策略 (7,486)
上海外滩 (7,413)
山西河北9天历史文化之旅保姆级攻略 (7,332)
我在苏州逛园子之留园 (7,183)
我在苏州逛园子之虎丘 (6,944)
途中风景 (6,573)
观“古蜀瑰宝—三星堆与金沙”文物特展 (6,537)

共收到 2103 条评论，评论最多的 10 篇文章如下：

以阅读体验为核心的网页宽度设计策略 (63)
隐居假期 (58)
桦加沙过后的凤凰山 (58)
日常漫步 Vol.19 之稻田与猫 (49)
雅余也有公众号了 (45)
上海外滩 (45)
山西河北9天历史文化之旅保姆级攻略 (45)
途中风景 (43)
macOS Tahoe 26 丑哭了 (42)
WordPress 极简主题 Dear v1.2.0 (42)

倒腾

今年对博客主题进行了 5 次调整，并完成 1 次服务器重新部署。回顾“更新日志”，仍以“移除”、“简化”和“禁用”为主线。通过持续简化，在大量更新图片的情况下，全站占用空间反而减少了 50%，其中减少生成冗余尺寸的缩略图收效显著。最新的 Lighthouse 评分中，除因文字颜色较浅导致“无障碍”项得分 95 分外，其余各项均为满分。

生命在于折腾，生命不息，折腾不止。是时候再次回答一遍“独立博客自省问卷15题”了。（今年意外还收到5份答卷）

主题

今年未发布新主题，也未对现有主题进行迭代。一方面灵感有限，另一方面网络上优秀主题已足够丰富。极简的终点究竟在何处？或许明年再尝试回答，但始终坚信：内容为王。

感谢

今年评论数增长 300 条，在此特别感谢以下“TOP 10 评论员”：S (100)、ACEVS (67)、网友小宋 (62)、夜未央 (53)、heilzz (50)、粽叶加米 (30)、1900 (29)、满心 (25)、寻鹤 (21)、全局变量 (21)。在此不一一列举，感谢所有“友圈”中的朋友们，明年继续互动起来。

2026 年，继续努力，回馈自己，成为更好的自己。

-

附：2024 年个人博客回顾

另外，请记住！75年前的今天，12月24日是长津湖战役胜利的日子。中国人民志愿军在冻饿交加、装备悬殊的极端条件下殊死搏斗拼来了这场胜利。

年前我和x不回内地了，准备过完年等车子智能驾驶推送了再回去，不想再开四五千公里，虽然现在EAP功能可以用，但感觉还是不太靠谱。

我和他最近聊了蛮多关于未来的计划，得出的结论是准备把JN的两套房子卖了，其中一套是现在住的，还有一套租期到明年6月，计划是这样，换到JS定居，那边城市配套和教育资源比我们JN好很多，并且山东省的风气我和x也一直很抵触，周围人「开智」的很少，大家都喜欢研究「鱼头朝谁」的文化，其实我是想定居到川渝地区，毕竟那是彩虹🌈之城，大家包容性很好，x不同意，他觉得太远了，也是，他的父母年纪见长，也需要人照顾，「一走了之」定居到千里之外，不合适。

没生苗姐前，大约是20年我数次征求他的意见，问他是否愿意跟我去国外定居，刚开始的确会很难，但是以后应该不会后悔，他拒绝了我很多次，也是出于考虑到家里父母养老的问题。

再后来苗姐出生了，我也没了折腾的心思，有了这个软肋和「甜蜜的负担」以后，真的心气都没了大半，让苗姐去新疆读书，我想了想也不现实，一来实在是太远了，这边城市和城市之间动辄四五个小时车程，周边全是戈壁，除了高考有加分政策，其他福利都不如内地，况且也可能要把苗姐送出去，算了，不能捡了芝麻丢了西瓜。

卖JN房子是因为这两年确实房价跌了不少，春江水暖鸭先知，我二姐是房地产从业者，她也觉得房价没有触底，三四线城市的下跌📉潮还没有到来，不如趁后知后觉大部分人还没感觉，先把不升值的资产变现，现金为王。

所以明年回JN应该就会把房子挂中介，先在那边租个三居室，买房的事，碰到愿意大出血腰斩卖我们还都喜欢的房子就入手，没有就暂时长租，手里的现金一年收益十来万足够我们开销了。

还有，博客改名了，从「三十海河」改为「我们叁」。

最近折腾公众号比较多，也发现很多人都在写公众号，当然，这可能是“孕妇效应”，自己关注公众号多了，自然看到相关的信息也多一些。而且，在现在大数据推流的情况下，你越关注什么，大数据越给你推什么信息。

不过，也有可能现在确实有更多的人在写公众号了。因为公众号似乎改变了他的传播方式，原来公众号只推荐给关注他的人，现在公众号可以推荐给没有关注的人了，也就是向公域发展了。这样的话，公众号的流量一下子就提升了很多。公众号也可以像一个个人博客一样经营了。而且相对于个人博客，还有很多优势。

比如：

个人博客一般的流量来源主要是搜索引擎、关注者，而公众号的流量来源有关注者、公众号推荐、微信搜一搜等，而且公众号的关注者的分发很好，个人博客大部分还是靠关注者主动去查看更新，而公众号可以及时把更新的文章推送给关注者，非常方便。在搜索方面也一样，个人博客一旦被百度降权，或者没有被百度收录，那搜索的流量几乎为零，而公众号只要别违规，还是能有一定的搜索来源的。所以，公众号现在流量可能更稳定一些。

另外一个，公众号变现现在也比较方便。公众号500个粉丝以上就可以开通流量主，可以在公众号文章内、文章底部、评论区等位置插入广告，有流量或点击都会有广告收益，另外还能开通打赏、跟广告主约稿等获得收益的方式。而个人博客现在想要获得收益，做广告联盟也不方便，adsense相对好一点，但单价也很低了，广告投放对于小站长来说更是没有什么机会。

第三，做公众号还有一个好处是方便将关注者转为私域流量，可以将关注者加到好友中，如果有做相关产品的，可以利用私域实现一些转化。个人博客也可以，但是不如公众号这么方便，只要文章中留个二维码，感兴趣的人直接长按识别就加上了，非常方便。

当然，公众号也有一些限制。比如必须严格遵守公众号的相关规则。一些敏感词不能发等等。

最后，老达也开通公众号了，老达的公众号是：老达观海笔记，欢迎朋友们关注一下哈！下面是公众号二维码，也可以扫码关注哈！

最近在成都参加培训，一个星期的时间。培训中心在成都市郊区，周边可以说是荒郊野岭的，刚好也不愿意出去逛，真好利用这一个星期的时间好好减减肥。最近在家里吃的太多了，老丈人最近过来跟我们一起住，帮着做饭，做的又好吃，盛饭有多，吃胖了不少。

不过，经过4天的锻炼、节食，发现减肥真的不容易。

来培训的这几天，每天跑步8公里，然后早上基本上支持鸡蛋和牛奶，中午吃一个鸡蛋或者不吃，晚上吃一点点菜和肉，不吃主食，晚上饿的睡不着，有一天下午培训的时候甚至有点低血糖，赶紧去外面的超市买了饼干和牛肉干，补充了点能量才好一点。

就这样，4天了，早上空腹称了一下体重，137.4斤，比来之前应该是瘦了2斤，真是不容易啊。来之前跟孩子说，我这次培训争取减肥3斤，看来还得继续努力啊，继续每天跑步5公里以上，控制饮食，争取后面2天的培训再减一斤！

看过很多减肥的视频和说法，一个共同的观点还是要少吃，即使不锻炼，也要少吃，控制好饮食就能瘦下来。可是昨天晚上饿的我睡不着，真的是难受啊。再坚持坚持吧！

不知不觉，手里这台华为P40 pro已经用了4年半了。。。

最近感觉手机电池不耐用了，基本上半天时间电量就只剩下20%多，不得不利用中午午休的时间给手机充电，在办公室的时候，也经常把手机连在充电器上。。。华为手机自带的电池健康检测也提示手机电池的最大容量只有81%了。（后来华为服务中心的客服说，最大容量到85%以下就该换电池了）

于是，昨天趁着休息的时间，跑了一趟华为授权服务中心，专门去换电池。之前电话咨询过，换一个原装电池也就159元，不贵。没想到去了之后，告知最近换电池有活动，只要109元就可以了。哈哈，来回打车费也省了。

今年华为又相继推出了p70和mate70手机，不过老达没钱，也没心思换手机，手里这个华为p40 pro运行流畅，也不发热，还能玩暗黑破坏神，就是空间稍微紧张一点，只有256G，偶尔要删一下照片。

这次换过电池，感觉运行起来更流畅了，还能在用2年，哈哈！

自从买了房，就感觉被房贷牢牢捆绑住了。老达买房时间是2018年，正是海南房价最高的时候，房贷利率也是最高的时候，当时贷款利率竟然高达5.88，贷款110万元，连本带息要还200多万。。。但是这也没有办法，当时感觉房价还要涨，所以就硬着头皮买了。

现在看来，确实不应该太着急，放到现在不仅能省不少利息，还能少支付不少购房款。。韭菜的命，没有办法。

存量房贷终于下调了

好在最近房贷利率可以下调了，银行也是不错，主动联系我让我申请调整存量房贷利率。上个月在手机银行上提交了申请，这个月已经执行了最新的房贷利率标准。让我没有想到的是，房贷利率调整幅度很大，从原来的5.88一下子降低到3.3，比我现在的银行信用贷的利息还要低不少。

存量房贷利率调整之后，每个月的还款金额从2986降低到2327，每个月减少了660，降幅巨大，生了不少利息。早知道上半年就不提前还房贷了。哎，涉及到钱的，总是反复决策错误。

想把这套房子也卖掉，可是现在房价下跌了很多，不算利息已经亏损30万了，基本上快把首付跌没了。。。

你们现在房贷利率是多少？