2026-10-09 12:06:16

刚才刷L论坛和A论坛时赫然得知 Microsoft 存储配额官方支持页面悄无声息地更新了一条足以让所有“家庭版车队”虎躯一震的规则：

从 2026 年 10 月 7 日起的新订阅，以及 2027 年 4 月 1 日起续订的 Microsoft 365 家庭版，存储空间规则正式变更——从过去的每人独立 1 TB（6 人最高 6 TB），“优化升级”为全员共享 2 TB（详见微软支持的Microsoft 存储配额页）。

地主家终究也是没有余粮了啊。

一场教科书级别的存储“反向增效”

之前的 Microsoft 365 家庭版，堪称消费级云存储服务里的性价比天花板：一年几百块钱，拉上 5 个朋友组个车队，人均几十块就能拥有 1 TB 属于自己的独立 OneDrive 空间，外加全套正版 Office。彼此互不干扰、互不越界（这对合租的车队用户非常重要）。

而这次的新规则，都不能说他是“明升暗降”了，这是“明降暗坑”：

1. 容量腰斩：之前 6 个人有 6 TB 配额，现在直接缩水成 2 TB。他喵的，人均算下来只有可怜的 333 GB，缩水了整整三分之二。
2. 变共享了：原本每人独立的 1 TB 配额没了，变成了共享 2 TB，直接阻断了合租的路子。毕竟如果车队里某位朋友抢先塞了 2 TB 进去，剩下的 5 个人可能当场连一份 Word 文档都自动保存不了。更绝的是，按照微软的铁律，OneDrive 爆仓，可不仅仅是文件只读，是会连关联的 Outlook.com 都会直接拒收邮件的啊。
3. 温水煮青蛙：新订阅立刻执行新规，现有订阅则延期到 2027 年 4 月续订时生效。呵呵，微软很懂缓冲期的艺术嘛，但说白了就是“钝刀子割肉”。

微软 OneDrive 存储“大缩水”编年史：从无限到抠搜

说起来，微软在云存储上出尔反尔、逐步收紧，也不是第一次了。整个就是一部活生生的“正版背刺史”：

• 曾经的“无限空间”画饼：早年 Office 365 为了与 Dropbox、Google Drive 抢夺市场，曾轰轰烈烈地宣传过“无限量云存储”。结果没多久，因为有少数极客用户真把几十 TB 的冷备份往里塞，微软连夜反悔，以“防止滥用”为由一刀切回 1 TB，免费空间也从 15 GB 怒砍到 5 GB。
• 重拳出击 E5 开发者白嫖：曾经大家人手一个、自动续期的 Office 365 E5 开发者订阅，E3 MSDN 订阅，可以说是无数折腾党的快乐老家。后来微软逐步收紧 API 调用验证、收紧审核门槛、大面积清理非活跃账号，把“白嫖”的漏洞堵得严严实实。
• 教育版（A1/A3）全线整顿：全球高校曾经拥有的免费的海量甚至无限 OneDrive 存储，近两年也遭遇了全机构配额上限的“血洗”，不掏钱就全校共享 100 GB 空间去吧。
• 邮件和网盘捆绑：把 Outlook 邮箱里的附件体积强行计入 OneDrive 免费云存储空间，让许多根本不怎么用网盘的用户天天收到“空间已满、即将停止服务”的红标消息。（不过这个貌似是业内常态，烦，但也不是只有微软的问题）

从封杀白嫖开发者，到整顿高校教育版，再到如今对按年付费的正规家庭版订阅者动刀——微软的刀法愈发娴熟。羊毛党薅不到羊毛也就罢了，作为羊毛党要有薅不到羊毛的觉悟，问题是现在是连真金白银买正版的羊，身上的毛都要被多剃两遍。真·正版软件受害者。

地主家的余粮，都去喂了 AI 吞金兽？

不过嘛，也正常，全球顶级云服务巨头反而越来越抠门的答案其实并不复杂：经济下行降本增效 + 资源全力转向 AI。

在当下的算力军备竞赛里，微软在数据中心、英伟达 GPU 集群、以及 Copilot 基础设施上砸下了天文数字的资本支出。每一度电、每一个机架、每一条骨干网带宽，都被疯狂消耗在训练与推理上。对财报来说，AI 基础设施才是投资人眼中那个看得见的“未来增长点”，而为几百万家庭版用户提供数以百计 PB 的廉价存储，则是不折不扣的重资产成本包袱。

AI 时代的微软、谷歌这些厂商，眼见自己的地位正在被 OpenAI、Anthropic、Meta、DeepSeek、GLM、Kimi 这些厂商威胁。所以也难怪微软，一边在 Windows、Office、Edge 甚至任务栏里无孔不入地强推 Copilot，一边在背后把老老实实存照片、存文档的云盘空间砍掉三分之二了。

这不就是“地主家为了养自己的 AI 吞金兽，转头扣下了长工兜里的干粮”嘛。

“合租车队”的散场与 NAS 自建的归宿

这一刀砍下去，真·家庭用户还能忍忍，毕竟都是一家人，空间共享也不是不能接受，但是那些在网络论坛、拼车群里自发组建的“合租车队”算是基本要散伙咯。

以前大家互不相识，全凭信任上车，反正数据各归各管，各用各的 1 TB，大家互不干扰。但现在 2 TB 共享了，陌生人拼车基本上宣告事实性死亡了——谁敢把自己的日常工作文档、邮箱收发权限，赌在另外 5 个陌生人“不会上传大文件把盘挤爆”的自觉性上？就算车队里每人都可信任，那也很难避免“某个人无意同步了大文件进来撑爆空间”的可能性。

这也是我在过去文章中说过好几次的话：不要对任何网络服务商的服务可持续做任何期待

服务商先用便宜的订阅圈占了你的数据和使用习惯，一旦促销期结束、战略重心转移了，什么削减配额、限制速度、甚至强行涨价不过是一纸公告的事情（前一段时间的 123 网盘事件大家应该也都略有耳闻吧）。今天它能从 6 人 1 TB 独享，砍到 6 人共享 2 TB，明天就能给共享池再加各种单日上传下载流量限制。

与其天天跟着大厂的配额政策提心吊胆，或许是时候把那些躺在 OneDrive 里的陈年照片和冷备份拷出来，重新把目光投向自家角落里的 NAS 或者自建私有存储了。毕竟，机箱里那几块实打实的机械硬盘，至少不会在某天清晨发来一封邮件，通知你明年的容量只剩三分之一吧。不过最近这个硬盘价格，也确实让人呵呵呵，虽然这年月硬盘要是突然炸一块儿，也挺肉疼的，但起码数据的主动权还在自己的手里是不。

本文 微软大刀部又来啦：Microsoft 365 家庭版”反向升级”变 6 人共享 2TB，合租车队连夜散伙咯 最初发表于 秋风于渭水。

2026-10-08 11:50:27

#吐槽 #日常 为什么最近总遇到神人，刚才天猫超市的快递员给我打电话对话过程是这样的：

• 快递：你有个快递到了，需要我送上门吗？
• 我：哦，你送上来吧，具体地址能看到吗？（有些面单上会隐藏最后的门牌号）
• 快递：你说一下
• 我：X号楼X单元X楼XXX
• 快递：我进不去单元门！
• 我：那你放快递柜吧（“进不去单元门”是什么破理由，你又不是第一次给我送了，这次不送上门就直说嘛，我报完具体门牌了你才说不能送，浪费咱俩的时间？）
• 快递：我没快递柜的权限！
• 我：那你放门卫（站点故意不给他们快递柜的卡）
• 快递：我们不让放门口！
• 我：那你说怎么办？送上来，你说不行；放快递柜，你也不行；放门卫，你还说不行？（绝了好不，一共就三个可选项，全拒绝了，他本来想打算怎么送？）
• 快递：不是，那个……我进不去你们单元门
• 我：你咋会进不了单元门的？你按一下门禁对讲，XXXX，家里人给你开不就好了，你又不是第一次送了（他起码已经送过5、6次快递了，都是送上门的）
• 快递：啊啊啊啊，好的好的（不耐烦中）早说。
• 然后我听到电话那头门禁等待接通的提示音几乎马上就响了，我这才知道，他给我打电话时其实就在单元门前站着呢，所以他给我打这个电话，并依次拒绝三种配送方案的意义是什么……我仔细琢磨了一下，总不能他说的“我进不去单元门！”其实想要传达的意思是：“我进不去单元门，因为我需要按门禁，但我不确定现在这个时间点家里有人没，所以我给你打个电话问问？”的意思吧？合着其实我不应该给他其他选择，而是应该直接说：“家里有人，按门禁对讲就行”？？？？这是含义可真有点难理解😂。直接问家里有人没不就好了……😅

2026-09-27 17:55:48

#吐槽 #日常 今天遇到个特别神奇的外卖小哥，中午我下单外卖，地址不小心设置成同小区的父母家了，下单后我马上发现了问题，就在APP里更新了订单的地址，结果等快到了，外卖小哥给我打电话：

• 外卖小哥：“只能送到原来的地址”。
• 我：“啊？我之前也改过地址，都给送了啊”。
• 外卖小哥：“我接单的时候就是那个地址，你改地址我这边系统不给我补偿”。
• 我（当时就火了）：“系统给不给你补偿，管我啥事？系统有这个功能，我就能用吧”
• 外卖小哥“你去那个地址拿吧”
• 我（得得，毕竟吃到饭比较重要，耐心点跟他说试试）：“首先，我改地址是平台提供的功能，至于你说的补偿什么的那是平台的问题，你别找我的矛盾。其次，也是最重要的一点，你说没补偿，你自己看看定位，改后的地址，离小区门口更近，楼层也更低吧，你送起来不应该更快吗？”
• 外卖小哥：“反正我只能送原始地址”
• 我：“我那个地址就没人，你送过去干啥？”
• 外卖小哥：“那我给你退回了”
• 我（直接一个大无语）：“蛤？行，你退回吧，我申请退款”

我申请退款后，过了大概2分钟，有个电话打过来，我接了：

• 电话那头：“您是申请退款吗？“
• 我：”您是？“
• 电话那头：”我是XXX炒饭的，我看您申请退款了，原因是未收到？“
• 我：”哦，骑手不给我送啊”（随后我给店家说了整个来龙去脉）
• 电话那头：”……他……图什么？“
• 我：“我也不知道啊，我改地址其实对他有利的，起码节约了他3、4分钟的时间，他为什么这么硬气我也搞不懂，还连累到你了”
• 电话那头：“我要是让他再给你送的话，你还要不”
• 我：“倒是可以，这么近，应该不至于凉了”

又过来了大概8、9分钟，店家又打给我：
店家：“我问他，这单退回的要罚你款吧，这一来一回耽误你手上的其他单子，也要被罚款吧，人家新地址距离更近了，平台不给你改送达时间的话，对你更有利吧。他支支吾吾的只说退了算了，我让他转单（给其他骑手）他也不转。哎，这单我给你退了吧，你重新下一单吧”
我：“哎，行吧……咱们都倒霉，这啥事啊”

我到现在都没想清楚他是个什么思路，居然把我的餐退回店家了。
我又不是先下一个很近的地址，然后改到远的地址，这种恶意利用修改地址功能，会导致他低价送远距离订单，我改完的地址反而比原地址更近了一点好不，这也不给送的？？
而且他要是直接不给送，认罚，不退回商家，我还能理解成他直接把餐扣下，当成自己的午饭吃了。他居然顶着手上其他订单超时的debuff，特意浪费时间把餐退回商家了？？这不是损失扩大化了吗？他图什么呢？

2026-09-21 11:49:03

#吐槽 不是，现在视频网站的吃相都这么难看了吗？迪士尼宣布 Disney+ 从英国开始，未来无论你是否有会员，开的是什么等级会员，视频的开头结尾将统统一视同仁的插入“广告”，当然迪士尼自己的说法是订阅会员依然享有“无广告”体验，视频播放前后强迫用户看的那个插片，只是“推广信息”，是“猜你喜欢、热门内容”之类的内容，并非广告内容。不是大哥，你本来就一直在涨价，还玩这一出，搞毛啊……目前我用的合租新加坡账号还没被插广告，看红R上的讨论，应该是从英国开始逐步推广至全球，目前只是插一些迪士尼自己的预告片啥的，如果不同意新的用户协议（接受这个推广内容）就无法观看，并且用户协议里强调，如果使用反广告措施屏蔽广告的话，被检测到就会停止播放视频，就像YouTube那样，加入打击用户使用广告拦截插件的队伍。（PS：最后的好消息：根据英国网友的实测儿童模式下，依然是真 · 没有广告的，这个应该和欧盟法规有关，但不知道未来新加坡订阅也能这样不，反正我主要是给家里小朋友订阅的，只要儿童模式依然能没广告就行，不然就只能回归BT/PT模式，我辛苦点给他下资源看了）

2026-09-20 00:19:50

迷雾重重：php-fpm 岁月静好，CPU 却突然暴走

一切的开始非常平平无奇。

前天晚上Linux.do论坛抽风，登录状态访问就白屏，这也算是 Discourse 架构论坛的常态了，我就直接把整个浏览器的全部缓存和 Cookie 清空来解决问题。访问白屏的问题解决了，但这么搞的代价懂得都懂：我所有网站的登录状态全掉了。

昨天早上起来，因为要回复文章下的几条新评论，我便重新登录了 WordPress 后台。敲完回复点击提交，起身去倒杯水的功夫，口袋里的手机突然一震——监控服务发来告警：

「主机 CPU 占用超过 80% 且持续超过 5 分钟」

我的第一反应：又特么是哪位闲得蛋疼的在拿小脚本刷我的站了？我这种前后端动静分离的架构还能让后端机 CPU 打满的攻击可不一般。

赶紧坐到电脑前登录服务器排查核心指标，先敲个 top 看看占用，按 P 排序一看，前排俩 PHP：

php 65%
php-fpm 10%

诶，这php-fpm占用不太对劲，因为这套前后端动静分离的架构，平时能让后端 PHP 介入处理的基本也就只剩：1、访客评论；2、访客搜索。

先看下php-fpm的情况，结果诡异的是php-fpm 状态页一片岁月静好：

请求数(accepted conn) 7
活跃进程数量(active processes) 1
空闲进程数量(idle processes) 10
慢请求数量(slow requests) 0
到达进程上限次数(max children reached)0

PHP-FPM 负载低得可怜，根本没有什么从前端机发来的 PHP 动态请求，那个唯一活跃的 1，估计还是我自己没关闭的管理后台页，但现实是，现在系统的整体 CPU 居高不下。这说明消耗 CPU 的大概率不是前端进来的常规 Web 访问，而是脱离了 FPM 进程管理的对 PHP 的直接调用。

不放心的我还是看了一下 Nginx 访问日志，虽然 Nginx 日志里确实夹杂着不少对 /goto/ 链接的恶意访问，以 1 秒 5~10 次的频率访问着，但这都是预期内的情况。

这个/goto/外链跳转页的恶意利用问题持续很多年了，害得我还重构了一个安全的外链跳转页（具体经过详见之前这篇文章《少写一个 else，我的外链跳转页成了黑产眼中的“香饽饽”？重构一个安全的外链跳转页》）并且我直接在 Nginx 层面做了拦截，但是也不知道是不是因为之前问题持续太久，黑产圈估计有个流行的《1000个外链跳转接口.xlsx》之类的热门数据，我的跳转页一直在上边，导致有脚本小子持之以恒的使用着我的外链跳转页。1 秒 5~10 次的频率虽然不低了，但是对 Nginx 来说，对他们返回 403 根本用不了多少性能。

既然大概率不是 web 侧的问题，那我就去看下 PHP 的错误日志，然后鬼使神差地刷新了一下博客后台网页，浏览器给我报了一个 500 错误，PHP 日志里也瞬间开始被同一条致命报错刷屏：

PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 67108864 bytes) in .../plugins/wordfence/vendor/wordfence/wf-waf/src/lib/waf.php on line 336

单次请求直接撑爆了整整 512MB 内存限制，并且路径指向 Wordfence 的 WAF 核心文件。

好了，现在问题的因果链看起来无比严密且闭环：
浏览器掉登录 -> 我重新登录后台的行为唤醒了 WP 的某个后台维护任务与预加载进程 -> 部分穿过前端 Nginx 防御规则的异常访问触发 Wordfence 防火墙的高频比对 -> Wordfence 解析大量规则与日志导致内存溢出、CPU 飙升。

我当即进入终端清空了 wflogs/ 缓存并暂时移除了 Wordfence 插件，博客后台果然秒速恢复访问，随后 CPU 也回落了。我当时甚至在心里暗骂：艹，Wordfence 又给我惹麻烦（至于为什么是“又”，请见2026-09-10的碎碎谈：《绝了，被自己站点的安全插件拦到外边了》）

因为一会儿马上就要出差，我也没功夫细琢磨了，简单把 Wordfence 的扫描调到低占用模式后，我就关电脑收拾收拾出发了。

提醒一下，我这里「进入终端清空了 wflogs/ 缓存」 的行为会导致很多次生灾害：
1. Wordfence 的防火墙会被置于「学习模式」（约等于关闭了防火墙）。
2. Wordfence 的白名单设置也会被一起清空。（你可能会被拦到外边）
当时是比较着急，所以直接删了所有的缓存，如果你也遇到类似的情况时，最好别学我，应该去目录下排查文件体积，只删有问题的缓存文件。

然而，问题没有这么简单就放过我。

那幽灵般的 CPU 高占用，在 1 小时 15 分钟（75 分钟）后分秒不差地再度浮现。

而且占用报警过于规律，是教科书级的：高占用时 CPU 的总体占用死死卡在 90% 左右，在持续整整 5 分钟后，异常负载消失，CPU占用瞬间回落；接着在沉寂 1 小时 15 分钟后，分秒不差地卷土重来。但问题是当我第二次收到报警提示时，我已经在去隔壁市的车上了，手上就有个手机，这还怎么搞。不过好在因为前后端动静分离，后端机哪怕挂了，也不影响访客访问和爬虫爬取（前端机发现后端机无法访问后会锁死静态缓存不再更新），无非是无法评论，无法搜索罢了。而且高占用的时候，后端机器也并没有完全失去响应，只是稍慢罢了。先凑合着呗，还能咋滴。

峰回路转：打满 CPU 的居然是 FreshRSS

直到今天下午我终于有空了，重新打开电脑，做一次正式的 CPU 占用异常排查。

根据昨天和今天上午的观察，高占用时博客访问还是正常的，且每次高占用都极其规律地持续整整 5 分钟，5 min = 300 s，恰好是 PHP 侧 300 秒的超时配置，说明异常进程不是自己退出了，只是因为超时被系统干掉了，既然不是瞬时偶发问题，我就有极其充裕的时间去现场“抓现行”。

等到快到高占用的点儿，我就守着 top，一出现 PHP 线程高占用立刻执行进程占用排序：

ps -eo pid,user,%cpu,%mem,command --sort=-%cpu | grep -i php | head -n 5

终端打印出的第一行结果让我当场愣住：

763014 www-data  92.3  1.0 php /var/www/FreshRSS/app/actualize_script.php

啥情况，吃满 CPU 的不是 WordPress，也不是 Wordfence，而是跑在 Docker 容器里的自建 RSS 阅读器——FreshRSS！（因为 Linux 容器本质上共享宿主机内核，宿主机的 ps 也能将容器内的进程看得一清二楚。）

合着昨天早上我以为的所谓“我登录后台所以触发了 CPU 高占用”，纯粹只是碰巧撞上了它的执行周期？而 Wordfence 内存耗尽让我进不去博客，也只是系统算力被占满、请求积压时引发的次生灾害？这可真有点难猜到——昨天我不是没怀疑过别的程序，但除了 WP 出过异常，其他东西都正常得不能再正常，包括 FreshRSS！

底层现形：用 strace 抓出导致 CPU 暴走的死循环

虽然知道是谁出了问题，但是问题的关键还没解决：为什么一个拉取 RSS 的脚本，突然从昨天开始每次执行时都会把 CPU 占用吃满整整 300 秒？

抄起 Linux 诊断神器 strace 直接盯住这个进程排查 CPU 占用：

strace -p 763014 -s 200

终端瞬间开始以抽风一样的速度疯狂滚屏，满屏都是几乎一模一样的系统调用失败，我赶紧按了 ctrl+c 停住刷屏：

newfstatat(AT_FDCWD, "/root/[https://translate.googleapis.com/translate_a/single?client=gtx&sl=auto&tl=zh&dt=t&q=%E3%81%8A%E3%81%AF%E3%81%AE%E3%82%93%EF%BD%9E%E3%81%8A%E3%81%8D%E3%81%9F%EF%BC%9F%E2%99%A1](https://translate.googleapis.com/translate_a/single?client=gtx&sl=auto&tl=zh&dt=t&q=%E3%81%8A%E3%81%AF%E3%81%AE%E3%82%93%EF%BD%9E%E3%81%8A%E3%81%8D%E3%81%9F%EF%BC%9F%E2%99%A1)", 0x7ffd6c94ce30, AT_SYMLINK_NOFOLLOW) = -1 EACCES (Permission denied)
write(2, "Error in translation: Failed to get content from Google Translate API.\n", 71) = 71
write(2, "TranslateTitlesCN: Empty translation result on attempt 1\n", 57) = 57
getcwd("/root", 4096) = 6

屏幕定格的一瞬间，整场事故的逻辑开始变得清晰了：

1. 事件源头：我在 FreshRSS 里启用了名为 TranslateTitlesCN 的标题翻译扩展，而对推特的订阅源中恰好抓取到了一条日语标题推送。
2. 网络断流：因为我用的 DeepLX 接口出现 429 限流了，插件自动降级使用 Google 免费翻译接口（translate.googleapis.com），但是谷歌估计改了翻译的接口，导致也调用失败了。（自动降级是我自己改的，原版插件没这功能）
3. 缺乏回退机制：代码内部对 Google 免费翻译接口报错时，完全没有指数退避、错误跳过之类的机制，只会在 PHP 执行超时前的 300 秒内不知疲倦地高频重试，把 CPU 死死压在 90% （Docker 们整体有个 90% 的限制线），直至超时被系统强制杀死。（我后来换了原版插件测试，一样会出现这个问题，看来不是我自己魔改出的问题）

灵魂拷问：容器里的进程，怎么会去访问 /root 还权限越界？

看着日志里满屏的 /root/https://... 和 EACCES (Permission denied)，我一度怀疑自己的眼睛：FreshRSS 明明关在 Docker 容器里，很严谨地用着 www-data，怎么会扯上 /root 目录？凭什么啊，不过甭管凭什么，我都要进容器看到底 FreshRSS 是怎么调用的。

先进入容器内部

docker exec -it freshrss-app /bin/bash

执行 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

看起来很贴心，很严谨是吧，先用默认的 root 去加载环境变量文件，以防没有获取环境变量文件的权限，然后再切换到 www-data 用户执行更新脚本，还把日志重定向了，避免使用 root 执行脚本，导致可能的漏洞利用点。

可惜这一行看似很贴心，很严谨的命令，却直接踩中了 Linux 与 PHP 的三个机制暗坑：

1. su 不带横杠，工作目录被原样继承

容器内的 Cron 守护进程是以 root 身份启动的，因此 Cron 触发命令时的初始工作目录默认会是 /root。 随后关键来了——脚本切换权限时使用的是 su www-data，而不是 su - www-data（带横杠的），这俩命令有什么区别：

• su - www-data：先完整登录，然后环境重新初始化，并自动 cd 到用户的home目录（通常为 /var/www）。

• su www-data：仅切换执行进程的UID/GID，但当前工作目录会被原封不动地保留了下来！

在日常使用终端时，使用 su www-data 是非常好的，因为我们确实需要让当前工作目录以及大部分父环境变量被原封不动地继承下来，这样后续敲sudo XXXXX命令时比较方便。但是对于 FreshRSS 的定时任务，这就导致了一个极度分裂的执行状态：进程表面上用着低权限的 www-data 用户权限，但它的当前工作目录依然停留在 /root，如果每次都写绝对路径，只调用www-data有读写权限的目录，倒是不会出现什么问题，结果又遇到了下一个机制。

2. PHP 底层的祖传相对路径回退机制

翻译插件在网络请求失败后，PHP 内部的 Stream 流处理出现中断，触发了 PHP 底层文件系统的祖传回退机制，PHP 会认为：“这个网络请求既然失败了，那会不会其实它不是一个远程 URL，而是开发者在当前目录下写的一个相对路径文件呢？”于是 PHP 会非常“机智”地把当前的工作目录和要访问的 URL，直接拼接到一起，调用 newfstatat 去相对文件路径找一下（/root/https://translate.googleapis.com/...）是否在硬盘上存在。

3. Linux 700 权限的当头一棒

问题在于 /root 目录权限是极其严格的 700，归 root 所有。 哪怕仅仅是判断一个文件是否存在，操作系统也要求进程对父级目录具备 x（搜索/遍历）权限。 此时在系统眼里，以 www-data 身份运行的 PHP 进程正在试图访问属于 root 的 700 权限目录，Linux 内核二话不说，直接返回一个 EACCES (Permission denied)。但插件并没有指数退避、错误跳过之类的机制，只会报错后马上继续再重试一次。

这下好了，访问超时 + 路径回退 + 权限越界 + 无回退重试，四重 Buff 叠满，PHP 硬生生把死循环逻辑塞进了 CPU，以每秒上万次的频率抽打 CPU，造就了这场持续 5 分钟的 CPU 暴走。

修复与收尾：禁用扩展 + 修正 Cron 工作目录

知道问题的本质后就非常好解决了：

1. 干掉罪魁祸首：
   执行 kill -9 763014 强杀进程，在 FreshRSS 扩展管理中将 TranslateTitlesCN 插件禁用（其实早该禁用了，其他非中文源都是用另一个 AI 翻译插件的，当年还没有便宜的 AI 翻译 API，为了省钱，就让这几个更新过于频繁的推特源挂在这个能白嫖免费翻译的插件上）。服务器 CPU 瞬间跌回熟悉的个位数占用。
2. 修改Cron：
   修改 Crontab 计划任务，显式将执行路径切到 FreshRSS 根目录，避免子进程继承 root 的工作路径：

*/21 * * * * cd /var/www/FreshRSS && . ./Docker/env.txt; su www-data -s /bin/sh -c 'php ./app/actualize_script.php' 2>> /proc/1/fd/2 > /tmp/FreshRSS.log

手动触发了一次更新，CPU 纹丝不动，收工。

运维最大的陷阱往往就在这儿：直觉和巧合会编织出一张具有高度欺骗性的网。“刚登录后台就报警”的巧合，差点让我把精力全耗在调试 WordPress 和怨恨安全插件上。

幸好系统的底层调用永远诚实——以后运维还是少看表象猜谜，多用 ps 找准 PID，拿 strace 抓出正在执行的系统调用，那些看似诡异的故障，答案往往就清晰地写在终端显示出的日志里。

本文 服务器 CPU 占用异常排查实录：从误杀 Wordfence 到抓出 FreshRSS 死循环 最初发表于 秋风于渭水。

2026-09-14 11:42:01

升级 VMware Workstation 的九九八十一难：幽灵虚拟机、1603 报错和手工装 Tools

一切的开始非常简单：VMware Workstation 曝出了两个虚拟机逃逸与穿透漏洞 CVE-2026-59346 与 CVE-2026-59347。因为使用中涉及在虚拟机里对陌生软件做测试的情况，虚拟机逃逸与穿透这种级别的安全漏洞是注定无法接受的，只得老老实实从 VMware® Workstation 17 Pro 升级到最新的 VMware® Workstation Pro 26H1u1。

然而，在通往新版本的路上，全是坑啊。

PS：如果你是被 VMware Tools 安装失败回滚卡住的，可以直接跳到第七难的VMware Tools 手动安装流程。

第一难：博通 VMware 下载的迷宫漫游

众所周知，VMware 被博通收购了，所以整个支持与下载体系全部搬迁进了博通的统一门户，下个安装包必须要登录博通统一账户。

我打开登录页面，密码管理器自动填充了账号密码，点击登录——“用户名或密码错误”。

扯淡吧，密码管理器还能把密码记错的？那就尝试找回密码，博通告诉我：“你压根就没注册过”，切，离谱他妈给离谱开门——离谱到家了，我TM没注册过，那我上次怎么登录下载的安装包，你给我删了就删了呗，瞎说什么。淡定淡定，重新注册一下。

好不容易重新注册进去了，不得不说，博通的网站妥妥一个现代反人类 UI 的集大成者。你必须在支持门户、软件分发、产品授权树状图里一层层翻找，经过数个形似企业级采购合同的确认页面，最终在某个隐蔽的二级子目录里才找到 Workstation Pro 26H1u1 的下载按钮。这破玩意有多隐蔽呢，隐蔽到我写文时想去截个图，我居然就找不到地方了。

第二难：Session 0 里的“幽灵虚拟机”

再次众所周知，升级安装前必须关闭所有运行中的虚拟机。打开 Workstation 界面，所有机器都显示为“已关闭”，列表里一片祥和。但当我安装时，不出意外地提示仍有虚拟机正在运行。

调出终端，敲下查询命令：

cd "C:\Program Files (x86)\VMware\VMware Workstation"
.\vmrun.exe -T ws list

注意这里是因为我这时候用的是16 pro，新版后路径应该用cd "C:\Program Files\VMware\VMware Workstation"了

控制台返回：Total running VMs: 0。

就瞎扯吧，那台本地用来跑 agent 的 Ubuntu 服务器绝对还活着呢，直接强杀进程容易导致磁盘损坏或残留死锁文件。不过这个倒是好解决，直接通过 SSH 关机就好了：

sudo poweroff

这是 Windows 的服务隔离机制导致的：Workstation 的虚拟机开机自启是通过系统服务 VMware Autostart Service 实现的，它是以 SYSTEM 身份驻留在 Session 0（后台系统会话）层级，而桌面客户端是运行在Session 1（用户会话）层级。导致当前登录用户下的 vmrun 根本“看”不到启动的虚拟机。

这个机制槽点实在是太多，虽然我明白这样设计的原因，这样设计下，重启宿主机后，不需要登录宿主机，虚拟机也会实现自启，但这样设计，也意味着用户如果让他的虚拟机开机自启了，那就无法使用客户端控制他的虚拟机了，必须要手动关机才行。你问要是用户无法手动关机时咋办？那就只能直接杀进程强关了。

第三难：VMware Workstation 中文界面消失，汉化补丁还挑 Build 版本

安装倒是没啥新状况，顺利安装完成了，但 VMware Workstation 的中文界面没了，一启动就是全英文。倒不是说英文界面看不懂、没法用，只是母语界面更符合直觉，日常扫一眼配置参数时中文界面用起来更舒服一点。

本以为和以前一样改改配置即可，于是开始常规操作：

1. 在快捷方式目标末尾追加 --locale zh_CN；
2. 在 %APPDATA%\VMware\preferences.ini 和全局 config.ini 中硬编码 pref.locale = "zh_CN"。

重启软件，哎，毫无反应，依旧是纯英文。

简单搜了一下找到了一个 26.0.0.1810 版本的 messages\zh_CN 语言文件夹，看起来版本差距不大，直接复制进新版的安装目录试试，再次尝试启动——依旧无效啊。

去检索了一番：合着博通从 17.6 起彻底剥离了外部文本字典加载的多语言机制，官方表示以后“English only”。新版本的多语言不再读取外部 .vmsg 语言文件，而是直接二进制主程序写死。这意味着针对上一个 26.0.0.1810 的汉化资源，面对版本号为 26.0.1.25688693 的新版本，虽然版本号就只差了0.0.1也会完全无效。

既然官方不做人，那只能转向大家的智慧了。去 52pojie（吾爱破解）论坛翻找了一下，果然有大佬针对制作了新版的内存劫持补丁与资源文件。按照说明做了文件替换之后，熟悉的中文界面终于回归了。

第四难：VMware Tools 安装失败回滚，旧版本怎么也卸不掉

宿主机里的安装升级搞定，接下来就要把虚拟机里的 VMware Tools 也升到对应版本，结果撞上了经典的 VMware Tools 安装失败回滚。

挂载虚拟光盘，在 Windows 虚拟机里双击 setup.exe，进度条欢快地读到一半，突然开始“正在回滚操作”，随后弹出一个冷冰冰的错误窗口，逼逼叨叨说了一堆，大概意思就是：

VMware Tools 安装向导提前结束。由于出现了错误，所以未能完成安装。

没有错误代码，没有原因，也没给任何指引，就通知你一句：「没安装上，现在自动结束安装了。」

界面上不写原因，那就只能去日志里自己找。按 Win + R 输入 %TEMP% 回车，找到 vmmsi.log_20260908_111111_Failed.log，直接往上翻，找日志里最后出现的安装失败标识 Return value 3（Return value 3 只是标记这个没装上，真正导致出错的原因得看它上面几行的记录）。

还好日志里倒是写的挺清楚：

Action ended 10:57:15: RemoveExistingProducts. Return value 3.
Property(S): WIX_UPGRADE_DETECTED = {55F0F698-8B00-40BF-8583-A16452EC3FF9}

新版装不上，是因为旧版本的 VMware Tools 卸载不掉。

新安装程序识别到了旧版本，在执行升级前的卸载动作时，旧版的卸载进程跑一半就崩了，因为旧版卸载失败，所以整个新版安装自动回滚。

• 我先尝试通过 Win11 的设置-应用-安装的应用卸载：卸载程序的进度条跑了不到四分之一就直接自己消失了。
• 然后尝试在管理员权限的 CMD 下用 msiexec /x {55F0F698-8B00-40BF-8583-A16452EC3FF9} /qb 强行卸载：没区别，还是卸载一半就炸了。

第五难：旧版 MSI 卸不掉，去打捞微软已下架的强制卸载工具

额，行吧，这种底层 MSI 无法卸载也不是第一次见了，这时候最管用的是微软官方的强制卸载工具：Microsoft Program Install and Uninstall Troubleshooter。

打开微软支持页面准备下载，结果发现：微软大刀部又发力了，微软已经移除了该工具的下载链接，官方建议用户去 Windows 设置里使用新版 windows 疑难解答，但新版疑难解答根本没有强制卸载工具啊！！！

好在我隐约记得家里那台做 NAS 的小主机里有这个工具。立刻开远程桌面连过去，但是问题是，我忘了这个工具我给放什么地方了，而且我记得他实际的名字应该不叫 Microsoft Program Install and Uninstall Troubleshooter.exe，于是只能用 everything 在茫茫多的文件里用关键字 Uninstall 慢慢翻，好再终于找到了，原来叫 MicrosoftProgram_Install_and_Uninstall.meta.diagcab。

然后我犯了一个错误：我刚才用的是宿主机的远程桌面，因为 VMware Tools 还没有被正确安装，所以现在我无法快捷地将宿主机内的卸载工具复制到虚拟机里，于是只能重新用虚拟机里的远程桌面去家里电脑再复制一次。

运行工具，选择“卸载”，手动指定产品识别码 {55F0F698-8B00-40BF-8583-A16452EC3FF9}。工具发挥正常，在磨磨唧唧半个小时后，彻底扬了整个旧版 VMware Tools，重启虚拟机，「设置」->「应用」->「已安装的应用」，列表中不再显示旧版 VMware Tools 看来彻底卸载掉了。以防万一再顺手清理掉 ToolsInstallerCache 安装缓存。

rmdir /s /q "C:\Program Files\Common Files\VMware\ToolsInstallerCache"

第六难：VMware Tools 1603 错误，被 Win11 24H2 二次拦截

清干净旧版，我满心欢喜地再次双击新版安装包，然而在进度条接近末端时——熟悉的“正在回滚操作”再次回归，惊不惊喜，意不意外。

我……（以下省略对博通的几千字友好问候）难道刚才没卸载干净？

再次查看 %TEMP%\vmmsi.log，这次倒是没有了 RemoveExistingProducts，取而代之的是一个新的问题：

CustomAction VM_CopySupportFiles returned actual error code 1603
Action ended 11:40:15: InstallFinalize. Return value 3.
Property(S): SupportFilesDir = C:\Users\admin\AppData\Local\Temp\...
Property(S): VERSIONNTBUILD = 26200

这就是大家常说的 VMware Tools 1603 错误，最最没用的一句报错，因为相当于摊手告诉用户“装失败了，为什么失败我不知道”。

不过结合上边的日志，还是搞懂发生了什么，当前的虚拟机系统是 Windows 11 24H2。我们可爱的微软收紧了安全隔离策略：

1. MSI 在完成阶段由 SYSTEM 权限服务在后台调用文件操作；
2. 试图向当前普通用户的临时目录（AppData\Local\Temp）释放并执行临时的 DLL 文件；
3. 这种“高危”行为触发了 Windows 的跨会话隔离与“智能”防护策略，于是就被拦截并拒绝执行了。

我先尝试在系统安全中心中关闭实时保护和篡改防护，可是拦截依然存在；

再尝试在管理员 CMD 中通过 set TEMP=C:\Temp 重定向一个临时路径，避免放在用户的临时目录下，虽然系统这次允许了释放临时的 DLL 文件，但是执行还是被拦截了。

第七难：VMware Tools 手动安装——纯手工装驱动、注册服务

得得得，你系统搞一堆“安全”拦截，那我就索性彻底抛弃 MSI 的自动化安装流程，直接回到最纯粹的系统底层操作：提取驱动和程序本体，用系统命令手动安装驱动和部署程序文件。

挂载虚拟光盘（我这里的盘符是 D:），先尝试解包：

D:\setup.exe /a /p C:\VMToolsExtract

屏幕弹出一个窗口告诉我：setup.exe 支持 /a（管理模式解包），但不认 /p 这个路径参数，这倒是触及我的知识盲区了，于是跑去问了一下机智的 ChatGPT，它教我修改参数传递方式，利用 /v 将传递路径参数：

D:\setup.exe /a /v"TARGETDIR=C:\VMToolsExtract /qn"

注意：这条命令是静默执行的。需要自己去 C:\VMToolsExtract 盯着，文件不再增加就说明解包完了。终于，所有的驱动原文件（.inf / .sys）和 vmtoolsd.exe 整整齐齐地摆在我的眼前了。

接下来就是纯手工的 VMware Tools 手动安装环节：

1. 用 pnputil 强制安装所有驱动

遍历并强制安装所有解包出来的 .inf 驱动文件：

pnputil /add-driver "C:\VMToolsExtract\*.inf" /subdirs /install

意思是让系统把目录里所有 .inf 驱动全部找出来并强制装进系统驱动库——手动替代 MSI 安装程序做驱动安装。

回车后，控制台开始快速滚动，安装所有的驱动。不过这个东西没很明确的结束提示，只能多等一会儿确保全部安装上了。

PS：安装时十几秒后屏幕会瞬间黑屏并闪烁刷新了一次，不要慌，这是安装 SVGA 3D 显卡驱动时的正常情况。

2. 部署程序文件并注册 VMTools 后台服务

把程序文件手动复制到默认的安装目录，并通过服务控制器手动建一个服务来每次自动启动：

:: 把程序文件复制到默认目录
mkdir "C:\Program Files\VMware\VMware Tools"
robocopy "C:\VMToolsExtract\VMware\VMware Tools" "C:\Program Files\VMware\VMware Tools" /E /IS

:: 注册系统级后台服务并启动
sc create "VMTools" binPath= "\"C:\Program Files\VMware\VMware Tools\vmtoolsd.exe\"" start= auto DisplayName= "VMware Tools"
sc description "VMTools" "VMware Tools 核心后台管理服务"
sc start "VMTools"

sc create 这条相当于手动帮系统把 VMware Tools 的后台服务登记进服务列表，binPath 指向主程序，start= auto 表示开机自启，把 MSI 安装程序原本该做的事自己手做一遍。

最后控制台返回了明确的 [SC] StartService SUCCESS 就说明成功了。

3. 自启动 vmusr 会话进程（分辨率自适应与剪贴板）

分辨率自适应缩放与宿主机之间的剪贴板双向同步，依赖的是运行在用户桌面会话中的 vmusr 实例。需要将其写入注册表启动项：

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "VMware User Process" /t REG_SZ /d "\"C:\Program Files\VMware\VMware Tools\vmtoolsd.exe\" -n vmusr" /f

:: 立即启动
start "" "C:\Program Files\VMware\VMware Tools\vmtoolsd.exe" -n vmusr

回车执行，瞬间虚拟机屏幕自适应拉伸铺满了整个宿主机显示区域。尝试一下在主机和虚机之间拖动文件、复制文本，映射虚拟磁盘，这会儿都可操作了，完美。

现在的状态：机器能正常用，分辨率自适应、剪贴板双向同步、文件拖拽、虚拟磁盘映射全部正常，唯一的小问题是每次虚拟机开机都会弹一次“VMware Tools 不是最新版本”。这个可以点「不再提醒我」解决问题。

总结与吐槽

整个升级过程，槽点多到不知从何吐起：

1. 商业收购带来的抛弃：博通接手后的产品完全偏向企业级大型客户，号称免费对个人，但实际个人用户用起来难度极大。不仅下载页面如同天书迷宫，连沿用多年的原生多语言支持也被一刀切掉，徒增社区汉化精力与用户的使用难度。
2. 被安全机制与陈旧架构夹击的 MSI：现在的 Windows 11 在虚拟化安全、核心进程隔离和进程权限控制上越来越严(S)格(B)；而这些上古软件的 MSI 安装包却依然固守着十几年前的做法——喜欢在安装过程中跨线程调用用户 Temp 目录里的动态链接库，那一定要出事啊。
3. 最可靠的永远是底层工具：只有看日志、翻注册表，最基础的 pnputil 和 sc 不会让人失望，以及老工具就是好用（可惜大都被砍了）。
4. 问题彻底解决了吗？并不：估计是手动安装时漏了什么配置文件没改，每次虚拟机开机后就会提示 VMware Tools 不是最新版本，需要更新。但执行更新就会装一半后触发自动回滚，日志里显示已经安装了同版本，不过这个倒是好办，直接点「不再提醒我」就可以解决。
5. 哎，VMware Workstation 咋说呢，让人又爱又恨吧，底层虚拟化成熟度、3D 渲染加速能力，外设兼容性依然是Windows底层虚拟机的天花板，但博通收购后搞出的反人类的下载流程让人第一步就想摔键盘，而且成也底层败也底层，复杂的网络驱动和深层系统注入又让它卸载时宛如流氓软件般顽固，根本就卸载不干净。

本文 升级 VMware Workstation 的九九八十一难：幽灵虚拟机、1603 报错和手工装 Tools 最初发表于 秋风于渭水。