服务器 CPU 占用异常排查实录：从误杀 Wordfence 到抓出 FreshRSS 死循环
迷雾重重：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
屏幕定格的一瞬间，整场事故的逻辑开始变得清晰了：
- 事件源头：我在 FreshRSS 里启用了名为
TranslateTitlesCN的标题翻译扩展，而对推特的订阅源中恰好抓取到了一条日语标题推送。 - 网络断流：因为我用的 DeepLX 接口出现 429 限流了，插件自动降级使用 Google 免费翻译接口（
translate.googleapis.com），但是谷歌估计改了翻译的接口，导致也调用失败了。（自动降级是我自己改的，原版插件没这功能） - 缺乏回退机制：代码内部对 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 工作目录
知道问题的本质后就非常好解决了：
- 干掉罪魁祸首：
执行kill -9 763014强杀进程，在 FreshRSS 扩展管理中将TranslateTitlesCN插件禁用（其实早该禁用了，其他非中文源都是用另一个 AI 翻译插件的，当年还没有便宜的 AI 翻译 API，为了省钱，就让这几个更新过于频繁的推特源挂在这个能白嫖免费翻译的插件上）。服务器 CPU 瞬间跌回熟悉的个位数占用。 - 修改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 抓出正在执行的系统调用，那些看似诡异的故障，答案往往就清晰地写在终端显示出的日志里。
不凡
2026-10-06 09:17
你是弄了个RSS阅读器吗？
去年夏天
2026-10-07 11:21
是的，这样对源的抓取更及时一点
不凡
2026-10-07 11:27
你把频率控制一下，你的RSS阅读器几乎是每分钟请求一次，两天总请求次数2800多次了
去年夏天
2026-10-07 12:13
啊这，不好意思，我已经把插件关了。我大概知道发生什么了，设计是4小时检查一次的😂。可能是触发了某种错误的重试机制，导致它进入了每分钟重试一次。
smtcl
2026-10-04 17:23
感觉很实用，很认真的看了一遍，似乎看懂了，但是一点也不懂。用python会不会没有这些问题，毕竟现在php在圈内都没有一点存在感了
去年夏天
2026-10-05 19:19
本质上是FreshRSS的插件写出了死循环，什么语言都能遇到这种情况。
PHP怎么说呢，很大程度上是因为Wordpress和PHP的关系很拧巴，WP 作为占据了全球网站高达 43% 左右份额的绝对霸主，在 PHP 生态中本该像 Chrome 引领 Web 标准那样呼风风雨的，反倒整天希望 PHP 永不改变的更现代为好。
花非花
2026-09-28 14:49
我才突然反应过来，我有段时间没收到Linux.DO的邮件了；这么久不访问，不知道帐号啥状态了
去年夏天
2026-09-28 15:08
L站貌似没长期不登录删号的机制，账号应该还活着。
老狼
2026-09-28 12:56
非常的详细，还写了5-6小时，佩服佩服。尽管用了AI辅助，但写这么多内容，已经很不容易了
去年夏天
2026-09-28 15:06
AI该用还是要用的，能省点事是一点。主要是别直接让AI全写了或者瞎改。
Hary
2026-09-27 21:57
人手一套RSS订阅器，维护起来是挺麻烦的
彬红茶
2026-09-27 11:54
神了，我服务器的PHP有时也莫名其妙占用很高，都赶得上java了
网友小宋
2026-09-23 12:30
昨天被一些国内IP地址池请求的图床php拉满，然后给CPU拉爆了。
去年夏天
2026-09-23 14:52
快到月底了，PCDN们又有拉平上行流量的需求了。
网友小宋
2026-09-23 16:58
并没有拉流量，存疯狂请求，拉我PHP
去年夏天
2026-09-23 17:56
直接搞成拒绝服务/CC攻击了……
不凡
2026-09-22 15:56
打开页面服务器响应时间没变化，就是网页标签页的图标一直在转，打开控制台看到是https://cdn.jsdelivr.net的js文件请求超时了，还有一个图片URL加载50s（https://img.tjsky.net/2026/09/f0f3abd3e166524dd47f433f1cd070d2.webp）
去年夏天
2026-09-22 16:08
哎，没备案的网站就是麻烦啊，图片和JS有空琢磨下，目前图床用的cloudflare的CDN，国内有些地区在某个时候就会巨慢（我现在的广州联通图片的冷加载用时是1.86秒，北京联通是4.57秒）晚上偶尔30多秒的情况也有……
老张博客
2026-09-22 15:21
我现在遇到这样的问题，都是交给AI，省事！
去年夏天
2026-09-22 16:18
可不，定位插件bug位置时也是找gemini问的，自己翻插件代码太痛苦了
林羽凡
2026-09-22 10:02
我弱弱地问下，这篇博文的内容是你写的，还是Ai写的。
去年夏天
2026-09-22 10:50
我写的底稿，AI存在辅助，底下说了：「本文在创作过程中存在的 AI 辅助为：文章经过GLM-5.3-Flash的错字修改，定位插件bug位置时美国豆包 3.8 Flash 提供了一些帮助，插件死循环四重成因示意图是gpt-image-2.5-flare画的」是文章的哪里存在奇怪的感觉吗？😂
林羽凡
2026-09-22 11:07
倒不是有奇怪的地方，就是我觉得这年头写这么详细的教程，如果完全手写，真的太猛的，我是万万做不到的。
去年夏天
2026-09-22 16:16
还好还好，我以为又是AI改错字时，写出奇怪的句式了，要是感觉句子怪怪的欢迎反馈。
其实还好吧，大概写了5、6个小时，从下午写到半夜😂有AI已经好不少了，毕竟之前查改错字还需要好久，排版也需要好久。
织梦岁月
2026-09-21 08:23
深奥啊，我想学习但是似乎没有动力去学。。。
我的FreshRSS前一段时间不行了，打不开了，后来直接用了FOLO了。
去年夏天
2026-09-21 14:44
我是一直没法跑TinyTinyRSS，所以才用了FreshRSS。Folo免费版不够我用啊，要是需要掏钱就需要面对一个很现实的问题：「我为什么不用Inoreader」
织梦岁月
2026-09-21 15:42
嗯嗯，我如果也不够了就去用In
大飞
2026-09-20 21:46
所以，我用hugo等静态博客，serverless架构的，动态的维护起来有点复杂
去年夏天
2026-09-21 14:36
接受动态的好处，就要接受动态的坑点。能玩的花活更多，但也更复杂了。
依云
2026-09-20 15:45
PHP好坑哦～
开头那种网站缓存的问题，我都是开devtools然后勾选上「禁用缓存」再刷新的。或者去「存储」里把网站的cookies、localStorage、sessionStorage之类的都删掉。一般都能清干净。删整个浏览器的cookie威力太巨大了，我会尽量避免的。
去年夏天
2026-09-20 15:58
PHP为了兼容也是一堆技术债。
Discourse 架构论坛一般都是 Service Worker 的问题，清理这个就行了，但有时候清了也解决不了，他可能还会被其他东西的缓存卡住，干脆全清了。
obaby
2026-09-20 14:01
话说评论提交感觉有些慢，需要好几秒才反应，后面有很多同步的请求吗？
去年夏天
2026-09-20 15:55
有空研究一下，确实比较慢，现在是前后端动静分离的，访客提交评论后，前端机扔给后端机，后端机动态生成新的页面，然后通知香港的前端机去后端机拉新的页面缓存，前端机拉到新的缓存后，再刷新访客的浏览器，让评论者看到评论。整个链条还是比较长的
fengc's Blog
2026-09-20 11:25
运维日常有时也需要和各种巧合斗智斗勇。
去年夏天
2026-09-20 15:53
这次太巧了，正好刚登录就占用报警，正好刷新后台PHP就开始报错……
acevs
2026-09-20 10:02
学习了，遇到了先查看所有运行进程。
去年夏天
2026-09-20 10:33
这次实在太巧合……凭直觉瞎猜果然不是好的运维习惯，这次我就连续误判了2次。
obaby
2026-09-20 09:02
专业，话说装翻译插件干嘛用？
去年夏天
2026-09-20 09:47
翻译一下订阅源的标题，方便扫视时快速找到感兴趣的条目。
obaby
2026-09-20 14:00
酱紫，我的订阅都是中文的