2026-05-15 16:24:29
最近这半个月刷 RSS 订阅的时候，又看到几篇讨论独立博客“纯粹性”的文章，也和这些博主交流了一番（如果对方有评论区的话）。有的博主觉得，个人博客就应该是绝对的净土，一旦想要通过博客索求什么回报，那股“灵气”就散了；有的博主则是在纠结，万一放个推广链接结果商家坑了人，是不是自己博客的信誉就破产了？
这类讨论在博客圈简直是“年经话题”了，每隔一段时间就得翻出来炒一遍。作为一个折腾十多年，曾多次把友链站点全“熬死”，并见证过无数博友“起朱楼、宴宾客、楼塌了”的过来人，今年就由我，站在现实的角度，为这个年经话题再贡献一篇文章。
不知道大家有没有发现，友情链接里，或者 RSS 订阅列表里，总有一些站点的最后更新日期停留在两三年前。点开看，可能是个 404，也可能是个布满灰尘的页面。24年初我曾经做过中文博客圈开往数据分析 ，当时在923个成员站点中，正常站点只有509个，占比55.15%。
很多人觉得，这些博主消失是因为“没话说了”，“没精力维护”。但作为写了11年博客，从整个站点一个月的访客都到不了三位数，到最单篇文章日访客过万的博主，我很清楚：大多数人的离开，纯粹是因为“入不敷出”。
这里的“出”，不仅是每年几百块的服务器和域名账单这种硬性开支，更是高昂的时间成本。你看，为了写一篇质量过关的教程，我得查资料吧，我需要测试代码吧、截图码字排版吧、设置那一堆 SEO 参数化信息吧，最后还要回复别人的评论，需要消耗很多时间和精力。
这种琐碎的、技术性的持续损耗，在缺乏“正向反馈”的情况下，会迅速磨平一个人的表达欲。经营个人博客，就像是在互联网的荒野里开荒一块“赛博自留地”。如果你只负责埋头干活，既不让自己爽（精神反馈），也不让自己回血（物质反馈），这地儿迟早得长满荒草，就算是陶渊明，他折腾半天没收获也会写 “种豆南山下，草盛豆苗稀。 晨兴理荒秽，带月荷锄归。 道狭草木长，夕露沾我衣。 衣沾不足惜，但使愿无违。”这种自嘲+自我鼓励的诗句。
有些博主特别喜欢说一句话：“我手写我心，我只是为了记录给未来的自己看，不在乎有没有人看，更不在乎能不能赚钱，所以我没有负担。”
这话听起来很高级，但说实话多少带点自我欺骗了。陶渊明写上边的《归园田居·其三》时，没想着流传后世吧。如果你真的只是为了写给自己看，那大家就不应该能看到你的文章了，毕竟本地的 Obsidian、Notion 甚至是现在的 Windows 记事本都比个人博客好用一万倍。既然花钱买了域名、租了服务器（白嫖也要耗费精力去学习如何白嫖）、配置了公网环境，甚至还装了统计代码监控阅读量，那你的潜意识里就在渴望“正向反馈”。 这种反馈有两种：
承认对反馈的渴望并不丢人。真正的独立是“写作权”和“编辑权”的自主，而不是洁癖般的自我折磨。 只要你的文章还是你遵循你自己意志敲出来的，没变成纯粹的 SEO 机器和 AI 搬运工，还是想什么时候写就什么时候写，想写什么就写什么，那么渴望物质反馈就不是什么“原罪”，它只是激励你继续稳定输出的“外部肥料”。想变现挣点钱补贴一下每年的账单，心安理得地多续费一年服务器，这事儿再正常不过了。
说起变现的动机，其实挺微妙的。除开真的有财政压力需要物质反馈补贴运营的，以及把“博客变成营销自媒体”以站养站的，还有相当一部分本来不追求物质反馈的博主也会在某天萌生出变现的心思。
大家肯定会发现有时候，“明明某个博主写的内容还没我硬核，折腾的技术还没我深，但他靠着挂广告、接商单、搞付费咨询，已经把服务器费用赚回来了，甚至还过得挺滋润。”
这时候，原本“佛系”的心态就容易起波澜：“我写得比他好，折腾得比他深，凭什么我每年在这里白砸几百块上千的真金白银，还要搭上这么多精力，而他却能躺着赚钱？
这种“眼气”或者说“心理不平衡”，是人性使然。本质上也是一种对正向反馈的诉求——我希望我的价值能够被量化，被市场认可。 但尴尬的地方在于，一些博主一方面产生了这种变现的欲望，另一方面又有着极强的自尊心和信誉洁癖，于是就陷入了“既想要、又怕丢面子、更怕背责任”的深度纠结。
我最开始写博客时，那是真没人看，全站1个月的流量都没现在1天的多，所以当时我基本都在混迹微博，知乎，B站，豆瓣等平台，几个月才写一点东西发到博客里，而且基本是因为其他平台不适合发这些内容才往自己博客里发。你们知道通辽耗子小约翰不，倒退10年（2017年），我知乎数据比他还好😂，关注者比他多，获赞数比他多，但是我当时1年能从知乎赚多少钱呢？不到一百块。但当时小约翰已经可以每月在知乎赚到过万了，这收入差距那可是真的赤裸裸的。再比如目前这个博客，我自己的水平我很清楚，比我写好的博主大把，博客日访客就是几百人的水平，也看不到站内有软文，有AFF的文章也很少，Ads也关了，你们应该不认为我是个盈利目的的博主吧，但我可以告诉你，这个博客现在每年能给我带来的额外收入是接近5位数的，与此同时很多比我写得好的博主却在发文抱怨服务器和域名的续费是单纯的支出项，在思考是否还要坚持运营自己的博客。这种同等付出下收入的巨大差距让人一点想法都没有那是很难的。
当我们好不容易在心里跨过了“渴望变现”这道坎，现实中却往往又会遇到新的阻力。既然变现的念头动了，为什么很多博主依然对此忌讳莫深？
感觉更多人是下意识地在害怕随之而来的“道德绑架”。很多人一旦在博客里涉及了利益（哪怕只是挂个自愿打赏的赞赏码），博主与读者的关系与心态就产生了一种微妙且畸形的变化。
这种变化在生活中非常常见：
朋友问你：“周末想去吃法餐，有推荐吗？”
你随口分享了上周去过的一家店，说：“那家店的鹅肝我觉得挺好吃的，你可以试试。”
结果朋友去了，刚好那天主厨休息，服务员态度一般，或者他点的其他菜不合胃口，甚至他那天肠胃敏感拉了肚子。
于是他跑回来抱怨：“都是你推荐的那家烂店，害我浪费了钱还坏了心情。”
这其实是典型的“责任归因偏差”。 他在做决策时，为了省去自己调研、试错的麻烦，偷偷把决策压力和风险全额“外包”给了你。当你作为一个博主，分享一个工具、一个方案、或者一个云服务商的链接时，有些读者会自动把你当成他的“终身售后”或者“无限连带责任人”。
如果你最近更新慢了，写的短了，他们就觉得你拿了钱就“飘了”；如果你推荐的厂商两年后经营不善跑路了，他们会觉得你“收了黑钱作恶”。这就让很多博主陷入了“良心的监狱”——为了不背这种莫名的锅，干脆什么都不推，甚至什么钱都不赚。
要走出这种心理困境，我觉得可以从“对外”和“对内”两个方面来解决问题：
咱们只是普通人，不是千古完人。博主是内容的提供者，不是读者的全职管家。 法律上，博主对所接洽的商业合作或推荐，仅负有最基础的“形式审查”义务（比如看这公司是不是正规经营、自己用的时候是不是真的好用）。而在良心层面，也需要学会“责任解耦”。我们要对自己的文字诚实，但我们无法、也不应该为读者的判断力和认知水平负责。
在写教程、发脚本、推荐服务时，只要基于你当下的真实体验，并且如实告知了风险，比如写过的：“他家过于新（意味着有提桶跑路的可能）”（对YT.NET），“不要对持续服务做太大期待，理性氪金充值”（对PikPak），就已经履行了全部的社交契约了。
只要不是有钱能使鬼推磨，为了点推广费去安利自己根本不赞同、或者明知道有坑的东西，你就依然是那个独立的博主。 至于商家未来的变故，或者读者自己操作失误搞出的烂摊子，那属于他们自己的人生课题。我话都说到这份上了，如此直白的风险提示了。大家都是成年人，理应拥有对自己判断力的主权，也理应承担自己做选择的风险。至于还有人非要让我为他的决策负全责，那对不起，我不背这个锅。
很多博主不敢变现，是因为潜意识里觉得自己一旦收了读者的打赏或商家的推广费，未来的表现就必须“对得起这份钱”。于是开始在更新频率、文章长度上自我折磨，最后让“反馈倒逼了产出”，把兴趣爱好变成了痛苦的工作任务。
这时候，博主就需要一种近乎“傲慢”的心态：
我做我想做的事，写我想写的文章，首先是为了满足我的情怀。我只是顺便把这个过程呈现出来，而由此产生的正向反馈（无论是读者的点赞评论还是几块钱的收益），我收着；如果没有，我也没亏——因为即便一分钱没有，我本来也要折腾这件事，也要写这篇文章。
兴趣应该是写作的唯一驱动力，需要把「记录自己」放在「谋求肯定」之前，当然这也不意味着博主要拒绝在「记录自己」的过程中，顺便去追求一下「精神肯定」与「物质回报」。
搞清楚自己的良心真的需要对谁负责，这很重要。
独立博客不应该是理想国中的精神圣殿，它更像是你的一块“赛博自留地”或者一个“路边小铺”。为了让这片自留地长期存活下去，收点门票、卖两杯咖啡、赚点电费，这事儿一点都不丢人。博客说破天也是自媒体的一种，自然会遵循自媒体的客观规律。
只要文章里的观点还是自己产生的，只要你文章的编辑权还在你自己手里，只要还是兴趣主导产出，这就不是对现实妥协。比起为了追求那种极端的、洁癖式的纯粹而导致站点最终消失，我更愿意看到大家能坦然地达成一种对反馈的可持续的自洽，让自己的赛博自留地可以长期存活下去。
PS：其实我本周的计划是打算周三发本篇文章的，结果先是遇到《免费CDN与数据统计的投毒攻击》又是遇到《NGINX “上古漏洞”》，于是本来打算周三发的文章就硬生生拖到到周五快结束了才发出来……
本文 为什么独立博客越用心越容易放弃？如何在“纯粹记录”与“理直气壮恰饭”间找到平衡 最初发表于 秋风于渭水。
2026-05-14 17:06:22
NGINX中一个存在了13年的漏洞（CVE-2026-42945），攻击者只需要向暴露的 NGINX 服务器发送特定的 HTTP 请求就有可能远程拿下服务器，受影响版本从0.6.27到1.30.0（基本上去全覆盖了）
This vulnerability exists when the rewrite directive is followed by a rewrite, if, or set directive and an unnamed Perl-Compatible Regular Expression (PCRE) capture (for example, $1) with a replacement string that includes a question mark (?). An unauthenticated attacker along with conditions beyond its control can exploit this vulnerability by sending crafted HTTP requests.
NGINX Plus和NGINX开源版本的
ngx_http_rewrite_module模块存在安全漏洞。当rewrite指令后接另一条rewrite、if或set指令，且使用包含问号（?）的未命名Perl兼容正则表达式（PCRE）捕获组（例如$1）作为替换字符串时，可能触发此漏洞。未经身份验证的攻击者可通过发送特制HTTP请求，在满足特定外部条件时利用该漏洞，导致NGINX工作进程发生堆缓冲区溢出并引发服务重启。此外，在禁用地址空间布局随机化（ASLR）的系统中，攻击者可能实现代码执行。
nginx -v 如果返回的版本号低于1.30.1那基本就是带漏洞的版本了。cat /proc/sys/kernel/randomize_va_space 如果结果是 2 就是开了内存空间随机化，这样遇到攻击 Nginx 会崩溃，而不是触发任意命令执行。? 的 rewrite 指令，看看它们是否引用了 $1, $2。grep -rInP 'rewrite\s+.*\$[0-9].*\?|if\s+\(|set\s+\$' /etc/nginx/ /www/server/panel/vhost/nginx/ /usr/local/nginx/conf/ 2>/dev/null）
官方的漏洞说明有点绕口，说人话就是
当你的NGINX（以及基于NGINX的软件，比如NGINX WAF、F5 WAF）版本号在0.6.27~1.30.0之间。
满足以下条件时可能被触发：
rewrite ，且其后跟随另一个 rewrite、if或 set
PCRE 捕获组（如 $1、$2）?）攻击者可利用此漏洞通过特制 HTTP 请求触发堆缓冲区溢出，导致 NGINX 工作进程重启,如果没有 启用 ASLR 时则可能执行任意代码）。
# 会触发 CVE-2026-42945 的高危配置
server {
listen 80;
server_name test.local;
location /vulnerable {
# 条件1: rewrite 指令，正则捕获路径部分，替换字符串包含 "?" 和 $1
rewrite ^/(\w+)/old$ /$1?new=1 break;
# 条件2: 紧跟另一个指令（这里用 if 示例，也可用 rewrite 或 set）
if ($arg_new = "1") {
set $flag "triggered";
}
return 200 "Config may be vulnerable";
}
}
^/(\w+)/old$捕获了 \w+作为 $1。/$1?new=1中同时包含 $1和问号（?）。攻击者可能发送如下请求，通过精心构造的 $1值（如超长字符串）触发溢出：
GET /aaaaaaaa...（大量字符）...aaa/old HTTP/1.1
Host: test.local
如果系统关闭了 ASLR（地址空间布局随机化），攻击者只需要精心构造的 $1 内容，将恶意代码写入溢出的堆内存空间，就能实现执行任意命令。
升级自然是最有效的解决方法。将 NGINX 升级到 1.31.0、1.30.1 或更高版本 （一般咱们用双数版本号的稳定版，当然单数的主线版也还行）
如果你因为这样那样的原因无法升级，比如你的系统版本很老了，新版Nginx无法安装等情况
那就想办法破坏漏洞触发的必要条件。修改一下逻辑（以上边的配置文件为例子）：
因为漏洞仅针对 $1, $2 这种未命名变量。如果给捕获组起个名字，就规避溢出逻辑。
location /vulnerable {
# 将 (\w+) 改为 (?<my_path>\w+)
rewrite ^/(?<my_path>\w+)/old$ /$my_path?new=1 break;
if ($arg_new = "1") {
set $flag "triggered";
}
return 200 "Config is now safer";
}
也可以先通过 set 指令将捕获到的内容转存到一个自定义变量中。这样的话 rewrite 指令执行时，引用的就是一个命名后的普通的变量了。（不推荐啊，这样改工作量太大）
location /vulnerable {
# 1. 先用 if 或另一个 rewrite 捕获并存入自定义变量
if ($uri ~* "^/(?<temp_var>\w+)/old$") {
}
# 2. 引用的捕获组是 $temp_var，不是未命名的 $1 了
rewrite ^ /${temp_var}?new=1 break;
if ($arg_new = "1") {
set $flag "triggered";
}
return 200 "Config is now safer";
}
最后是个吐槽：其实最近本来是打算写一个关于个人博客运营的文章的，结果写的太久，在各种摸鱼中，反倒是写了两篇关于漏洞的资讯:joy:
本文 藏了 13 年的 NGINX “上古漏洞” 一个问号就能远程拿下你的服务器 最初发表于 秋风于渭水。
2026-05-13 10:55:19
如果使用了某 CDN 加速 CSS 和 JS 加载，使用了某数字统计站的站点。
最近这段时间，别人每次访问你的站点时，有大概5%的几率，原来的正常JS和CSS里会被额外加入一段混淆后的JS代码。这个混淆后的代码会在特定时间在特定移动设备上，将用户跳转到风险网站，比如赌球博彩网站（马上世界杯了嘛）
其实这种供应链攻击在圈内早已屡见不鲜，比如之前我就提过的 《LNMP 一键安装包投毒事件》 《针对网站运维的供应链攻击投毒事件》《JS 加速服务投毒事件》，其手法如出一辙。
混淆后的代码会检测运行环境和访问来源，如果发现有anaiytics分析代码，比如谷歌分析，百度站长，matomo，Umami，恶意代码会延迟跳转，以免被在统计数据中看出端倪，如果发现是登录的管理员，则完全不会运行。如果发现是电脑也不会跳转，如果发现启动了分析工具也不会跳转。
如何排查自己是否使用了有问题的CDN和统计：请自己谷歌统计 投毒 跳转菠菜，CSSCDN 投毒 跳转菠菜
我就不细说了，上次写太多，对方直接开盒找过来，先冒充某大厂，提出付费删帖，不成则开始各种威胁我
不要感觉自己没感觉就轻视，因为谷歌、必应对使用了这些JS和统计代码的站点都会做降权处理的，你的站点可能会直接在搜索结果里消失。有些站长发现自己站点莫名奇妙，谷歌，必应就不收录了，谷歌Ads审核也会不通过的原因就这这里。在谷歌和必应的眼中，是你站长故意引入了恶意代码，像我之前部署的那个‘香饽饽’外链页 一样沦为黑产割韭菜的工具。（幸亏当年谷歌自己拦截了索引，也没给我降权）
黑产之所以平时装好人免费给你提供服务，无非是盯上个人站长的流量，是为了在世纪杯欧洲杯期间做恶意跳转，让你白嫖2、3年，就是为了能在球赛期间赚个大的。
如果你是用 CDN 加载 JS 代码，无论是美化用 CSS 还是统计 JS ，都要记得添加 integrity 属性，写死资源的哈希值，这样浏览器会校验文件哈希值，一旦内容被篡改，浏览器将拒绝加载。
如果你只有几个固定的 JS 脚本，可以直接使用：
操作：将你的 JS/CSS 的 URL 粘贴进去，点击生成。它会自动给你一段带 integrity 属性的代码。
使用原始的 .js 或 .css 文件，用 openssl 生成，这是最安全的方式，防止在线工具本身被劫持。直接在你的终端控制台里敲
# 生成 SHA-384 哈希值（384是目前推荐的算法）
cat your-file.js | openssl dgst -sha384 -binary | openssl base64 -A
生成哈希值后，你的 HTML 标签必须按以下格式书写。注意啊，crossorigin="anonymous" 是必不可少，否则跨域加载会失败。
<script src="https://cdn.example.com/js/main.js"
integrity="sha384-这里填入生成的Base64哈希值"
crossorigin="anonymous"></script>
<link rel="stylesheet" href="https://cdn.example.com/css/style.css"
integrity="sha384-这里填入生成的Base64哈希值"
crossorigin="anonymous">
integrity 字符串参数，否则你的网站样式就全乱了（浏览器会拦截不匹配的文件）。统计 投毒 跳转菠菜，CSS CDN 投毒 跳转菠菜本文 还在白嫖 CDN 和 数据统计？你的网站可能正在帮黑产“引流”赌球菠菜站 最初发表于 秋风于渭水。
2026-04-28 21:42:18
今天照例用手机登录服务器日常维护一下，顺手敲下大家倒背如流的 sudo apt update && sudo apt upgrade，准备给系统更个新。结果直接被兜头浇了一盆冷水：
tjsky@vm1234:~# sudo apt update && sudo apt upgrade
Reading package lists... Done
E: Could not get lock /var/lib/apt/lists/lock. It is held by process 31896 (apt-get)
N: Be aware that removing the lock file is not a solution and may break your system.
E: Unable to lock directory /var/lib/apt/lists/
我还是头一次遇到这种 Ubuntu apt update 报错的事情。于是只好起身打开电脑，在网上一搜，中文教程里都让我简单粗暴地执行 sudo rm -rf /var/lib/apt/lists/lock直接把带锁文件给删了，作为一个曾经干出《一行 rm -rf 删光了我的博客》，3年多的博客被炸到什么都不剩的人，对rm命令那是相当慎重的，果断找 AI 学习了一番相关知识。
果然，又是一如既往的：垃圾教程污染中文互联网！
而且其实系统提示里已经苦口婆心地警告过我了：removing the lock file is not a solution。强删锁文件和不弹出就直接热拔插 U 盘有啥区别。虽然确实能强行解决报错，但鬼知道文件系统里会变成什么样。
那既然系统说锁现在是被 PID=31896 进程占用了，那我就来看看它到底在干嘛：
tjsky@vm1234:~# ps -f -p 31896
UID PID PPID C STIME TTY TIME CMD
root 31896 31868 0 Apr18 ? 00:00:50 apt-get -qq -y update
好家伙， STIME（启动时间）赫然写着 Apr18！。今天可是Apr28！ 已经在后台默默“挂机”了一个多星期了！（估计可能碰上了网络波动或者镜像源超时，然后就卡死了？）
看眼这进程是什么东西启动的，能不能干掉（虽然已经大致猜到是什么了）
tjsky@vm1234:~# pstree -aps 31896
systemd,1
└─systemd,1055
└─apt.systemd.dai,31868 /usr/lib/apt/apt.systemd.daily update
└─apt-get,31896 -qq -y update
额，这不是系统默认的每天自动刷新软件源的定时任务嘛，那就简单了，既然应该不是在下载安装中卡死，那直接干死就行：
tjsky@vm1234:~# sudo kill -9 31896
# 把它的父进程也送走
tjsky@vm1234:~# sudo kill -9 31868
# 虽然按说应该是卡在刷新软件列表了，不过以防万一，还是修复一下可能存在的安装状态
tjsky@vm1234:~# sudo dpkg --configure -a
没有任何输出直接回到命令提示符，不错，毕竟在 Linux 的世界里，有一条著名的“Unix 哲学”：没有消息就是好消息。
作为一个好奇心满满的折腾党，只是把僵尸进程干死了可不行，我要去看看这 10 天到底发生了什么。
首先，去翻 apt 自己的记录 /var/log/apt/history.log，结果发现 4 月 18 日这天没有任何记录。
诶，我去，不可能啊，没记录？那4月18号那天是什么东西启动的更新，见鬼了？
又往前翻了几天的日志，转念一想，哦，卡死的命令是 update，它只是去远程拉取最新的软件清单索引，并没有实际 install 或 upgrade 任何具体的软件包，搞不好这时候确实不写入history.log的，毕竟之前也没有看到过update的记录。
那既然 apt 的日志里没记录，那就去问问系统大管家 systemd呗。
tjsky@vm1234:~# sudo journalctl --since "2026-04-18" --until "2026-04-19" | grep -i apt
果然
Apr 18 06:29:39 vm1234 systemd[1]: Starting Daily apt upgrade and clean activities...
Apr 18 06:29:42 vm1234 systemd[1]: Finished Daily apt upgrade and clean activities.
# 上面是早上的正常升级检查，几秒钟就顺利跑完了。重点在下面：
Apr 18 14:43:39 vm1234 systemd[1]: Starting Daily apt download activities...
下午 14:43 分触发的 apt-daily.service（后台更新软件源），只有 Starting，没有 Finished。进程一直拿着 apt 的进程锁占着茅坑不拉屎，导致这 10 天内所有的后续更新都被堵在了门外。
查明真相并清理完后，我信心满满地再次执行了手动更新命令。结果，屏幕上又开始疯狂刷屏：
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 47902 (unattended-upgr)
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 47902 (unattended-upgr)
...
不是，这难道又卡死了？我不是刚干死卡死的每日更新嘛，这又是啥东西在为难我。
仔细了一眼，看占用锁的进程变成了 unattended-upgr。于是就去查了一下这是个啥玩意，AI告诉我：“这是 Ubuntu 系统自带的后台自动安全更新服务。”
合着我手动更新的时候，恰好撞上了系统正在后台默默打安全补丁，用了快10年的Ubuntu，还是头一次碰到系统自动安全更新的😂。
那就只能等了，不过幸好也就等了1分钟不到，日志画风一转：
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 59297 (apt-get)
Reading package lists... Done
Building dependency tree... Done
...
锁被释放了，熟悉的 Do you want to continue? [Y/n] 终于弹了出来。按Y，回车，收工！
要是你们碰到 /var/lib/apt/lists/lock 被占用，或者 apt 进程死锁，记住啊：
rm 搞怕了，直接把自己3年多的博客全删了的惨状还历历在目，当时吓的血都凉了。kill进程了，应该先journalctl 看看系统最后在干啥，判断一下到底是真死锁了还是在跑大任务，然后再决定是否直接杀进程。Waiting for cache lock，不慌，系统会帮着把队列排得明明白白的。毕竟Ubuntu 24.04 的代号是 Noble Numbat （高贵的食蚁兽）体现了系统的成熟与可靠（吗？）。本文 Ubuntu 更新“卡死”惊魂记：揪出占用 apt 锁的“隐形罪魁祸首”！ 最初发表于 秋风于渭水。
2026-04-10 08:53:35
1月份的时候，我实在受够了罗技驱动的臃肿，写了篇《告别 Logitech Options+ 臃肿！罗技驱动精简瘦身与替代全攻略》，提供了一个可以按需开启功能的安装脚本「tjsky/logi-options-plus-mini」。没想到大家苦罗技久矣，这项目发布后不仅大家很是捧场，还被某知名科技自媒体翻牌子引用，成了我 GitHub 上 Stars 数量最高的项目😂
不过开心归开心，这方法只能说是治标不治本。虽然利用该项目可以阻止多余功能被启用，但所需的依赖文件依然稳如泰山地躺在硬盘里。再配合罗技 Options+ 那每周雷打不动、重新下载小几百 MB 文件的“特性”（Bug），而且还从！不！删！除！旧副本（拿用户硬盘当自家的垃圾场是不）。实测下来，即使精简到了极致，用了三个月后，这玩意儿的文件体积依然原地爆炸，膨胀到了 2GB！
为了彻底干掉这个“毒瘤”，3 个月后我给大家搞来了两套终极解法：官方“妥协版” 和 非官方的“真香魔法”。
对于电竞比赛电脑、隔离网络的商业电脑，是需要一个绝对不联网的驱动来保证竞技公平和商业机密的。所以罗技其实偷偷藏了一手：Logitech Options+ 离线版。
所以，这个方法只适合那些要官方背书、追求“原厂服务质量”的用户（虽然罗技最近的信用值，怕是连共享单车都扫不开了吧）。
相比官方的臃肿。Mouser 是一个极其轻量、开源、完全本地运行的 Options+ 替代品，专门用来对罗技 HID++ 鼠标进行按键和手势的重映射。目前对 MX Master 系列的体验最为丝滑，同时对其他罗技型号也提供了早期识别和通用 UI。
划重点：无需云端、无需罗技账号、纯本地运行！ 安装包体积只有 50 MB 的小工具，把官方那个 1.1GB 的庞大驱动按在地上摩擦。
| 鼠标型号 | 自动 HID++ 检测 | UI 界面 |
|---|---|---|
| MX Master 4 / 3S / 3 / 2S / MX Master | 支持 |
MX Master 系列专用界面 |
| MX Anywhere 3S / 3 / 2S | 支持 | 通用界面，实验性支持界面（需手动切换） |
| MX Vertical | 支持 | 通用界面，实验性支持页面（需手动切换） |
| 其他罗技 HID++ 鼠标 | 部分支持（基于PID/名称） | 通用界面 |
Mouser.exe（Windows） / Mouser.app（macOS） / 终端运行 ./Mouser（Linux）。(注：macOS 会管你要两个隐私权限，用来获取鼠标状态；Linux 需要给 /dev/input/event* 的读取权限和 /dev/uinput 的写入权限。)
不过话说回来，macOS 用户其实不如直接去用 SteerMouse 或者 BesterMouse 虽然需要掏钱，但好用的多，而且鼠标的平滑滚动更接近苹果原生体验。至于 Linux 用户，LogiOps 才是你最好的选择。
%APPDATA%\Mouser（Windows）、~/Library/Application Support/Mouser（macOS）、~/.config/Mouser（Linux）。免责声明：Mouser 是个第三方开发的开源项目，跟罗技（Logitech）官方没有半毛钱关系，“Logitech”、“MX Master”和“Options+” 都是 Logitech International S.A. 的注册商标。（求生欲拉满的博主）
本文 彻底告别 Options+ 臃肿！开源驱动 Mouser 实测：这才是罗技鼠标该用的驱动 最初发表于 秋风于渭水。
2026-03-16 15:25:47
免责声明： 本文仅作为网络安全技术探讨与供应链安全案例分析。文中所引用的测试数据及文件路径均来自公开网络渠道及官方公开发布的软件安装包，不涉及任何非法逆向工程、破解或入侵行为。文章旨在提醒广大开发者重视密钥管理规范，并建议相关用户注意潜在的网络通信风险。若涉及厂商已发布官方修复公告，请以官方信息为准。
近日，某安全社区内有研究人员指出，在 某数字 公司近期发布的 AI Agent 产品 “安全龙虾”（基于 OpenClaw）的公开安装包中，疑似意外包含了其官方泛域名证书的私钥文件。
这一发现引发了技术圈对于客户端打包规范以及 WebPKI 证书吊销机制的广泛讨论。本文将从技术角度对该事件进行客观验证与风险分析。
根据网络社区公开的信息，在官方提供的软件目录树中，存在一个名为 credentials 的明文文件夹，具体路径如下：/path/to/namiclaw/components/Openclaw/openclaw.7z/credentials
该目录内包含了 *.myc***.36X.cn 的 Wildcard DV（泛域名）证书及其对应的私钥。
为了验证该私钥与证书的匹配性，我们可以通过标准的 OpenSSL 工具分别提取私钥和证书的 Modulus（模数）进行 MD5 哈希比对：
> openssl rsa -modulus -noout -in myc***.36X.cn.key | openssl md5
MD5(stdin)= 446097b7674080186a469ecb0945f5af
> openssl x509 -modulus -noout -in myc***.36X.cn.crt | openssl md5
MD5(stdin)= 446097b7674080186a469ecb0945f5af
输出结果显示，两者的 MD5 指纹完全一致，在技术上证实了该 .key 文件确为对应官方泛域名证书的有效私钥。
将泛域名私钥直接打包进公开发布的客户端，在安全工程实践中属于较高风险的配置失误。其实际影响主要体现在以下几个维度：
*.my****.36X.cn 旗下的任何服务端节点。由于客户端和系统会信任该合法证书，HTTPS 的加密隧道形同虚设，流量可被实时解密。
敏感凭据暴露： 考虑到 OpenClaw 是一款 AI Agent 工具，用户通常会在其中配置各类大语言模型（如 OpenAI, Claude 等）的 API Key。若发生上述中间人劫持，这些高价值的通信凭据存在被明文截获的理论风险。
供应链劫持可能： 若该客户端的某些更新或指令下发机制依赖于该子域名的 HTTPS 验证，恶意攻击者可能利用伪造的服务器向客户端下发未经授权的指令或恶意代码。
除了开发环节的打包疏漏，本次事件在证书管理（PKI）层面的响应时间也值得关注。
根据公开的证书透明度（CT）日志（如 crt.sh ID: 24937759962），该证书由 WoTrus（沃通）于 2026年3月12日签发。截至本文撰写之时（距离私钥被公开讨论已接近1天），该证书状态依然为 Valid（有效）。
参照 CA/Browser Forum Baseline Requirements 的行业通行规定（4.9.1.1 章节），当 CA 机构意识到证书私钥可能已遭泄露（Compromised）时，应当在 24 小时内执行吊销（Revoke）操作。此次事件中响应的延迟，暴露出相关主体在漏洞响应（IR）流程上可能存在一定的滞后，这也给 WoTrus 带来了潜在的合规审查压力。
更新 2026-03-16 08:07:16 UTC 时刻，证书 OCSP 显示 Revoked （吊销）
不过鉴于大部分浏览器对无法访问 OCSP 验证服务器时会采取“软失败”配置，仅靠 OCSP 证书吊销验证并不能有效防御中间人攻击（能做中间人攻击的人，顺手拦截掉 OCSP 流量也很容易）
对于安全开发生命周期（SDL）而言，高等级的泛域名私钥应当严格存放在硬件安全模块（HSM）或专用的密钥管理系统（KMS）中，开发人员本应无法接触到私钥本体。即使出于这样那样的原因，允许开发人员直接接触私钥，也应配合 CI/CD 流水线的 Secret 扫描机制，防止重要凭据硬编码或被意外打包进公开发布版本。
出于谨慎起见，建议在官方发布包含新证书的修复版本并吊销旧证书之前，暂时避免在存在不可信网络环境的设备上使用该特定版本的客户端。同时，若曾在其中输入过高价值的 API 密钥，建议前往对应的服务商后台进行重置（Regenerate）操作，以确保资产安全。
其实谁都有写出 Bug 的时候，但这波操作实在有点过于草台班子了，不要为了快的抢先发布，而跳过开发流程的安全检查。这次幸亏只是一个*.myc***.36X.cn，要是不小心泄露了更核心的*.36X.cn的私钥，整个公司所有软件的安全信任体系可就全炸了。
业务因失误将内部域名证书打包到安装包里，证书对应域名是
*.myclaw.360.cn，实际解析地址是127.0.0.1本地回环地址，该证书仅在本地使用，不会对外提供任何服务。
发现问题后 360 安全团队立即申请吊销这份证书，目前证书已经失效，无法再用于任何合法的 HTTPS 加密通信，普通用户也不会受到任何影响。
公司已启动内部排查流程，将进一步优化安全管理机制，防范类似疏漏再次发生。
本文 【资讯】离谱！某数字安全大厂 AI 客户端竟“附赠”自己泛域名的私钥？ 最初发表于 秋风于渭水。
