摘要：本文记录了作者在个人博客使用Handsome主题过程中遭遇的一次严重服务器性能故障。作者发现服务器CPU和负载异常飙升，经排查排除了外部攻击的可能，定位问题根源在于Handsome主题的CoreInterface.php文件。该文件采用商业加密混淆方案DyEncrypt，通过多层eval()动态执行加密代码，其授权验证机制因服务器网络连通性或防篡改校验问题陷入死循环，导致单次请求执行成本畸高，4核CPU瞬间满载。作者尝试更换多个PHP版本、确认扩展安装、联系主题作者均未获解决，最终改用第三方修改版本后恢复正常。文章指出该主题已近一年半未更新，作者疑似失联，并对正版授权机制的稳定性和安全性提出质疑。
众所周知，我的博客已经用了四年多的handsome主题，主要是懒得换新主题。毕竟博客的主要功能就是为了记录。
前几天发现自己的服务器CPU和负载都很高，显然是不对劲的，第一反应是有靓仔开始攻击我的博客，但是查看了CDN的日志以及服务器的日志，并没有什么激增的访问。
好在有AI指导我一步步排查，可以确认的异常点是www.52txr.cn.log 的体积达到了惊人的 1.20 GB。但是1 万条请求跨越了 15:32 到 17:02，大约 1.5 小时。这意味着平均并发只有 不到 2 QPS (每秒请求数)。这种级别的流量属于非常普通的访问，绝对算不上 CC 攻击。
这就暴露出一个更深层且核心的问题：不是请求数量太多，而是单次请求的执行成本极其畸形。
结合之前 top 截图中大量 php-fpm 进程处于 R（运行）状态，且累计 CPU 时间（TIME+）高达十几分钟甚至二十分钟，可以断定 PHP 代码在解析层面陷入了“死胡同”。仅靠几个低频的外部请求，就能让进程持续空转死循环，迅速占满 4 个核心。这就只剩下两个情况：
- 代码级死循环或严重 Bug
- 恶意后门或挖矿木马
继续往后排查，也就是检查 PHP 慢执行日志，导致服务器 4 核 CPU 持续满载的根本原因，在 Typecho 站点 www.52txr.cn 所使用的 handsome 主题上。
观察慢日志的堆栈跟踪（Stack Trace）信息，暴露出以下几个极其严重的异常特征：
- 集中卡死在单一文件：所有的超时和卡顿，最终都指向了
/www/wwwroot/www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php这个文件。 - 高频出现
eval()'d code：eval()函数在 PHP 中用于将任意字符串当作 PHP 代码来动态执行。正常的 Web 业务代码极少会高频嵌套使用eval()。它的运行效率极低，且是黑客隐藏恶意代码最常用的手段。 - 乱码函数调用：日志中反复出现诸如
()这种无法识别的乱码函数名，以及大量的闭包{closure}()调用。
我看了看CoreInterface.php 这个文件，这段代码使用了极其复杂的商业 PHP 加密/混淆方案（内部异常处理中暴露了其名称为 DyEncrypt）。代码顶部带有严厉的版权与防破解警告（“未经授权破解、传播破解行为将承担民事责任...”），且类名、函数名、变量名被全部替换为不可读的乱码符号（例如 class ÏàÎ∂œ∑πı≠ƒÆÒÚflÛ）。
代码主体几乎完全由 eval(gzinflate('...')) 构成。它的工作原理是：将真实的业务代码进行高强度压缩和加密，当网页被访问时，由 PHP 引擎在内存中现场解密并使用 eval() 强行执行。这种机制本身就非常榨干 CPU 算力。
根据AI的解释，一开始我以为是PHP版本的语法不兼容，但是我换了PHP7.4、PHP8.0、PHP8.2都不行。显然不是PHP的问题了。更大的可能是正版的加密主题在运行时会频繁连接官方的授权接口。如果服务器网络无法连通授权节点，或者防盗版机制被触发，这段混淆代码可能会故意阻断进程或陷入无限等待的死锁状态。
既然降级到 PHP 7.4 且按要求开启了扩展后，问题依然如故（image_5933f3.png显示双百满载，image_593415.jpg显示慢日志依然卡在CoreInterface.php的eval()循环中），你的推测非常合理：这极大概率是主题的授权验证机制（或本地防篡改校验）被触发，导致加密引擎进入了死锁或死循环状态。
目前联系了作者，提供的内容如下：
问题标题：正版 Handsome 主题在访问时导致 PHP 陷入死循环、CPU 4核瞬间 100% 满载
环境信息：
系统环境：Debian / 宝塔面板
博客程序：Typecho1.2.1
PHP 版本：已测试 PHP 7.4、8.0、8.2（目前稳定在 PHP 7.4）
已开启扩展：curl, mbstring（Opcache 未安装）
故障现象：
只要启用 Handsome 主题并访问网站（www.52txr.cn），服务器 CPU 就会瞬间飙升至 100%，系统负载（Load Average）极高。通过重命名主题目录可以立刻恢复正常，确定是主题代码引发的死循环。
PHP 慢日志（Slow Log）关键堆栈信息：
Plaintext
script_filename = /www/wwwroot/www.52txr.cn/index.php
[0x00007f01a4e37b50] [INCLUDE_OR_EVAL]() /www/wwwroot/www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php:19
[0x00007f01a3d60020] [INCLUDE_OR_EVAL]() /www/wwwroot/www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php(1197) : eval()'d code:1
...
[0x00007f01a4e4f450] [INCLUDE_OR_EVAL]() /www/wwwroot/www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php(1029) : eval()'d code:1029
...
[0x00007f01a3d37b30] () /www/wwwroot/www.52txr.cn/usr/themes/handsome/libs/interface/CoreInterface.php:18
已尝试的排查步骤：测试服务器外网及 curl 连通性（curl -I https://www.baidu.com 返回 200 OK，外网请求正常）。
将 PHP 版本从 8.2 / 8.0 降级至 7.4，并重新确认安装了 curl 和 mbstring 扩展，但问题依旧。
重新打包上传了解密/加密核心文件覆盖，但只要访问前台就会触发 CoreInterface.php 中的高频 eval() 循环卡死。诉求：怀疑是授权验证机制或解密引擎在当前环境下陷入了死锁，请问是否有针对此现象的排查建议或修复补丁？
但是作者一直没有回复我，我也被迫使用了其他版本。
说句题外话，我个人觉得是不是handsome主题已经有跑路的趋势。距离上次更新已经过去了一年半，而且我给作者发的QQ信息几乎没有回复过了。也许是工作太忙了吧。
现在看起来应该是正常了（使用了特别学习版本之后），希望正版能尽快修复吧。说句玩笑话，正版才是有后门的。
赞赏作者
如果觉得我的文章对你有用，请随意赞赏!