最近在服务器上整理 WordPress 网站时，我发现网站根目录中存在一些非常奇怪的文件名，例如：
insert_id
post_tag,
ids
name
--max-time
-D
-o
tail
0
0,
false,
,
甚至还有一条明显来自日志过滤命令的正则表达式，被直接变成了文件名。
这些文件大多只有 0 字节。结合之前在 SSH 终端中执行和粘贴较长命令的经历，基本可以判断，其中一部分文件很可能是在某次命令粘贴或执行过程中意外创建的。
不过，WordPress 目录里本身也存在不少正常的 0 字节文件。如果看到空文件就全部删除，很容易误伤 WordPress 核心、插件缓存保护文件或历史工具。
因此，这次没有直接批量删除，而是按“先扫描、再确认、优先隔离、最后才删除”的方式，对整个网站目录进行了一次比较完整的清理。
网站目录为：
/data/wwwroot/www.shuijingwanwq.com
一、首先发现一批明显异常的 0 字节文件
最开始通过 ls -la 查看网站根目录时，可以看到不少完全不像正常 WordPress 文件的项目。
例如：
,
0
0,
ids
insert_id
name
post_tag,
--max-time
-D
-o
还有这样一个几乎可以确定来自 Shell 命令的文件名：
^\[13-Jul-2026 21:(20|21|22|23|24|25|26):.*(execution timed out|terminating|SIGTERM|too slow)
这些文件的共同特点非常明显：
- 大量文件大小为 0；
- 文件名像命令、参数、变量值或 SQL 字段；
- 有些甚至以
-开头； - 与 WordPress 正常目录结构完全无关。
第一次统计时，整个站点共有 63 个 0 字节普通文件。
但这里不能简单执行：
find . -type f -size 0 -delete
因为后续检查证明，WordPress 核心、W3 Total Cache、WPCode、SyntaxHighlighter、Organize Series 等组件中，本身就存在正常的空文件。
所以我只挑出了其中 16 个高置信度异常文件，先移动到隔离目录，而不是直接删除。
隔离完成后：
moved=16
skipped=0
网站中的 0 字节文件数量也从：
63
下降到了：
47
二、为什么剩下的 0 字节文件不能继续批量删除
接下来逐项检查剩余空文件后，发现其中很多都有正常来源。
例如 WordPress 核心中就包括：
wp-includes/js/swfupload/license.txt
wp-includes/js/swfupload/swfupload.js
wp-includes/js/swfupload/handlers.js
wp-includes/js/swfupload/handlers.min.js
wp-includes/js/swfobject.js
这些文件虽然是 0 字节，但运行 WordPress 核心校验后：
wp --allow-root core verify-checksums
结果为：
Success: WordPress installation verifies against checksums.
说明它们就是当前 WordPress 官方发行包的一部分，不能因为大小是 0 就删除。
另外还有：
- W3 Total Cache 的缓存目录保护
index.html； - WPCode 等插件中的占位文件；
logreport/no_delete；logreport/show/no_delete；- SyntaxHighlighter 自带的
clipboard.swf； - Organize Series、Microsoft Clarity 等插件自己的文件。
因此，“0 字节”只能作为排查线索，不能作为删除依据。
三、又发现一个 2019 年遗留的 temp-write-test 文件
剩余文件中还有：
wp-content/temp-write-test-1565457605
继续追查源码后发现，WordPress 自己的：
wp-admin/includes/file.php
会创建类似：
temp-write-test-*
的临时文件，用于判断目录写入权限和文件所有权。
正常情况下，测试结束后文件应该被删除。
而这个文件的修改时间可以追溯到 2019 年。我后来又在自己 2021 年 2 月 19 日的一篇旧博客中找到了它：
也就是说，它至少在 2021 年就已经存在，并不是最近终端误操作产生的文件。
最终判断是：
这是一个历史 WordPress 写权限检测临时文件，由于某种原因当时没有正常清理。
因此同样没有直接删除，而是将其移入隔离目录。
处理以后，全站 0 字节文件数量进一步从：
47
下降到：
46
这个数字一直保留到了最终检查。
四、顺手清理已经不用的 Hueman 主题和 Hueman Addons
检查历史文件时，还发现服务器中仍然保留着已经不用的 Hueman：
hueman inactive
hueman-addons inactive
目前网站已经使用 Twenty Twenty-Five，因此 Hueman 主题先通过 WP-CLI 删除：
wp --allow-root theme delete hueman
删除成功。
但是删除 Hueman Addons 时却遇到了：
Error: Cannot do 'launch': The PHP functions proc_open() and/or proc_close() are disabled.
进一步检查发现，当前 PHP 8.5 的全局 disable_functions 中禁用了：
proc_open
proc_get_status
考虑到网站生产环境还在使用 PHP-FPM，我没有为了 WP-CLI 去修改全局 PHP 安全配置。
最后采用的办法是：
只在执行 WP-CLI 时临时放开 WP-CLI 所需要的几个 PHP 函数，PHP-FPM 和普通 PHP CLI 的全局安全限制保持不变。
通过这种方式，Hueman Addons 也成功删除：
Deleted 'hueman-addons' plugin.
Success: Deleted 1 of 1 plugins.
随后又在 root 用户的 .bashrc 中增加了一个 wp() Bash 函数，让以后执行 WP-CLI 时自动使用这套临时配置。
这样以后再清理插件或主题，就不需要每次重新输入一长串 PHP 参数，同时也不会为了 WP-CLI 降低整个 PHP-FPM 环境的限制。
五、继续检查：异常文件是否还有“非 0 字节版本”
把 0 字节异常文件处理完以后，我又想到一个问题：
如果以前的终端误粘贴不仅创建过空文件，还创建过有内容的异常文件怎么办？
因此又扫描了所有文件大小，重点寻找：
- 以
-开头的文件； - 包含 Shell 元字符的文件名；
- 根目录中的命令式文件名；
- 文件名前后包含异常空白；
- 换行符、Tab 等异常字符。
结果为：
suspicious_count=0
这意味着，前面隔离掉那 16 个文件以后，已经没有发现同类型的高置信度 Shell 命令碎片文件。
六、第二轮扫描一度产生几千行结果
后来我进一步扩大规则，检查：
- 网站根目录非常规文件；
- 文件名中的异常字符；
uploads、cache中的 PHP 等脚本。
结果输出一下变得非常大。
原因不是发现了几千个木马，而是：
wp-content/cache/object/
下面存在大量 W3 Total Cache 对象缓存文件，例如：
wp-content/cache/object/term_language_relationships/.../*.php
这类文件本身就是缓存数据。
因此重新调整扫描规则：
整个
wp-content/cache/不参与这一轮异常文件判断。
毕竟 W3 Total Cache 的缓存旧文件、垃圾回收以及 _old 文件问题，本来就准备以后单独审计，没有必要和这次网站根目录清理混在一起。
调整以后，只剩 23 个值得人工复核的项目。
七、23 个非常规文件中，真正需要清理的并不多
这一轮扫描发现了一些非常有年代感的文件：
Adobe AIR_3.6.exe
nginx-1.10.1.zip
hosts
make_sql.php
wp-config.php.bak-slytranslate-debug-2026-07-14-100437
此外还有：
fix-en-chinese-tags.php
polylang-batch-zh-to-en-tags.php
merge-tags.php
nginx.conf
cdn-test.html
ads.txt
以及 Google、百度、搜狗、IndexNow 等验证文件。
这时候再次证明：
文件看起来奇怪，并不代表它应该删除。
所以后面没有批量处理，而是一个一个确认用途。
八、三个 PHP 文件原来是我每天还在使用的标签维护工具
下面三个文件最开始看起来很像一次性维护脚本：
fix-en-chinese-tags.php
polylang-batch-zh-to-en-tags.php
merge-tags.php
但实际上它们是我现在仍在使用的 WordPress / Polylang 标签处理工具。
继续查看入口代码后，三个文件开头都有：
if (php_sapi_name() !== 'cli') {
die("❌ 请在命令行运行\n");
}
后面才加载：
require __DIR__ . '/wp-config.php';
其中部分脚本还支持：
--dry-run
--all
等命令行参数。
因此它们明确属于 PHP CLI 专用维护脚本。
即使浏览器直接访问，也会在加载 WordPress 和执行数据库逻辑之前终止。
所以最终决定：
fix-en-chinese-tags.php
polylang-batch-zh-to-en-tags.php
merge-tags.php
全部保留。
这也是这次清理过程中非常重要的一点：不能仅凭文件名和位置判断一个文件已经废弃。
九、make_sql.php 通过旧博客找回了来历
对于：
make_sql.php
我直接在自己的博客中搜索文件名，找到了 2026 年 4 月 30 日的旧记录：
这个脚本当时用于根据 Nginx 历史访问日志生成浏览量导入 SQL，再将历史浏览量导入 WordPress。
当时它本来就是一次性数据处理流程。
现在相关任务已经完成，也不需要继续通过公网访问：
https://www.shuijingwanwq.com/make_sql.php
因此将其移出了网站根目录，但没有永久删除，而是保存在：
/root/swq-webroot-cleanup-quarantine-20260808/
以后如果还要参考当时的处理逻辑，仍然可以找回来。
十、wp-config.php 备份文件优先移出公网目录
本次发现的文件中，我认为最应该优先处理的是：
wp-config.php.bak-slytranslate-debug-2026-07-14-100437
它虽然只是调试期间留下的备份，但 wp-config.php 中可能包含：
- 数据库连接信息；
- WordPress 密钥；
- 其他敏感配置。
而备份文件的扩展名已经不是正常的 .php。
这类文件没有任何理由继续放在 Web 根目录。
所以第一时间将它移动到：
/root/swq-webroot-cleanup-quarantine-20260808/
而不是继续留在：
/data/wwwroot/www.shuijingwanwq.com/
十一、2013 年的 Adobe AIR 和 2016 年的 Nginx ZIP 也找了出来
另外两个非常典型的历史遗留文件：
Adobe AIR_3.6.exe
nginx-1.10.1.zip
修改时间分别可以追溯到：
2013
2016
nginx-1.10.1.zip 与我过去在 Windows 本地开发环境中使用的 Nginx 1.10.1 时间线也完全吻合。
这些文件显然不是当前 WordPress、Linux、PHP-FPM 或 Nginx 生产环境所需文件。
但考虑到它们毕竟是多年以前留下的资料，我依然采用隔离而不是立即永久删除。
十二、hosts 原来也是 2017 年本地开发留下来的
网站根目录还有一个：
hosts
只有 110 字节。
内容为：
127.0.0.1 localhost
::1 ip6-localhost
172.28.28.18 default.interact.shenzhen.localhost
结合过去的博客记录，可以确认这是以前 Windows / Android / Genymotion 本地开发过程中留下来的 hosts 文件，而不是现在服务器真正使用的：
/etc/hosts
因此它也被移入隔离目录。
十三、根目录中的 nginx.conf 反而不能删
比较容易误判的还有：
nginx.conf
它并不是当前实际运行的：
/usr/local/nginx/conf/nginx.conf
两者 SHA256 不同：
929e8a834bd2494c42f12a8f7cb12795409c6aa7e23e5576b7b9e63ec0d6390b nginx.conf
6bd4e466bbcc629ee076386b54949a35ead6e22213faaa614191b878de751d7e /usr/local/nginx/conf/nginx.conf
通过 nginx -T 检查，也没有发现当前 Nginx 配置显式引用网站根目录中的这个文件。
但查看内容以后马上发现：
# BEGIN W3TC Page Cache cache
...
# END W3TC Page Cache cache
# BEGIN W3TC Browser Cache
...
# END W3TC Browser Cache
# BEGIN W3TC Page Cache core
也就是说，这是 W3 Total Cache 生成的 Nginx 规则文件。
所以虽然当前没有直接发现它被 Nginx 主配置加载，也不应该趁这次目录清理随便删除。
W3TC 后续会单独审计，本次先保留。
十四、验证文件也不能看到旧就直接删
根目录还存在不少验证文件，例如：
google6ef993c34e9a65a9.html
baidu_verify_U5mywj2jTv.html
baidu_verify_codeva-LyBgT68D0O.html
baidu_verify_codeva-0D6Gn3P4Mk.html
sogousiteverification.txt
1311aeca4e764c48afb3665fb02f3537.html
ed840343aa968ef81a2d8c6d432b7abc.txt
这些文件大多只有几十到一百多字节。
我还专门检查了当前 Nginx 日志中的访问次数，结果全部为 0。
但这不能直接说明它们已经无用。
原因很简单：
- 搜索引擎的网站验证可能多年都不会重新请求一次；
- 现在网站前面还有 CDN，请求也未必一定进入当前源站日志；
- 删除验证文件可能导致以后重新验证站点所有权时出现问题。
因此，目前仍在使用的 Google、百度搜索资源平台、搜狗以及 IndexNow 等相关文件继续保留。
十五、百度联盟、阿里妈妈和 360 WebScan 已停用，因此对应验证文件直接删除
不过有三个文件已经可以明确确认没有继续保留的意义。
百度联盟
bdunion.txt
现在已经明确不再使用百度联盟，因此直接删除。
阿里妈妈 / 淘宝联盟
root.txt
对应的平台也已经不再使用，因此同样删除。
360 网站安全检测
webscan_360_cn.html
这是以前 360 网站安全检测 / WebScan 使用的网站验证文件。
目前已经明确不再使用这项服务，因此也直接删除。
最终确认：
CLEAN: bdunion.txt
CLEAN: root.txt
CLEAN: webscan_360_cn.html
十六、ads.txt 只有 Google AdSense，继续保留
根目录还有：
ads.txt
检查内容：
google.com, pub-8392190980622725, DIRECT, f08c47fec0942fa0
当前只有 Google AdSense 授权记录，没有 Adsterra 或其他已经停用广告平台的记录。
因此 ads.txt 继续保留。
十七、最终清理结果
最后再次检查已经处理过的文件：
CLEAN: bdunion.txt
CLEAN: root.txt
CLEAN: webscan_360_cn.html
CLEAN: hosts
CLEAN: make_sql.php
CLEAN: Adobe AIR_3.6.exe
CLEAN: nginx-1.10.1.zip
CLEAN: wp-config.php.bak-slytranslate-debug-2026-07-14-100437
当前隔离目录：
/root/swq-webroot-cleanup-quarantine-20260808
里面保留：
Adobe AIR_3.6.exe
hosts
make_sql.php
nginx-1.10.1.zip
wp-config.php.bak-slytranslate-debug-2026-07-14-100437
总大小大约：
2.0 MB
另外，最开始发现的 16 个 Shell 命令碎片文件，则保存在：
/root/swq-zero-byte-quarantine-20260808
两个隔离目录暂时都不会马上删除，先保留一段时间。
十八、清理完成后的最终基线
最后统计：
网站根目录普通文件：32
全站 0 字节文件：46
最重要的是：
高置信度命令碎片异常文件：0
同时 WordPress Core checksum 已经通过。
因此，目前剩余的 46 个 0 字节文件不能再理解成“46 个垃圾文件”。
它们中的绝大部分已经确认属于：
- WordPress 官方核心文件；
- 插件自带空文件；
- W3 Total Cache / WPCode 的目录保护文件；
- 历史日志目录标记文件；
- 其他具有明确用途的占位文件。
继续为了把数字降到 0 而清理，反而可能开始误删正常文件。
十九、这次清理最大的体会
这次排查最开始只是想处理几个因为 Shell 命令误粘贴而产生的空文件，最后却顺着这条线发现了：
- 16 个明显的命令碎片文件；
- 一个多年遗留的 WordPress
temp-write-test； - 已经不用的 Hueman 主题；
- 已经不用的 Hueman Addons；
- 一个暴露在 Web 根目录的
wp-config.php调试备份； - 一个完成历史使命的
make_sql.php； - 2013 年的 Adobe AIR 安装程序；
- 2016 年的 Nginx Windows 压缩包；
- 2017 年的本地开发
hosts； - 已经停用的百度联盟、阿里妈妈和 360 WebScan 验证文件。
但同时也避免误删了：
- 仍在日常使用的三个标签维护脚本；
- W3 Total Cache 生成的
nginx.conf； - W3TC 预加载 Sitemap；
- Google AdSense 的
ads.txt； - 搜索引擎与 IndexNow 验证文件；
- WordPress 和插件自带的正常 0 字节文件。
所以对于一个已经运行十多年、经历过多次迁移、主题更换、插件调整以及服务器环境变化的 WordPress 网站来说，目录清理真正困难的并不是：
“怎么批量删除文件？”
而是：
怎么证明一个文件确实已经没有用了。
我的做法最终变成了：
发现异常 → 查看文件属性 → 查源码 → 查旧博客 → 查当前配置 → 判断是否仍在使用 → 优先隔离 → 最后才删除。
虽然比直接执行一条 find ... -delete 麻烦很多，但对于生产站点来说，这种方式明显更稳妥。
这次清理到这里可以暂时结束。
接下来如果还要继续整理，我会把 W3 Total Cache 的历史页面缓存、_old 文件和垃圾回收机制 单独作为一个问题处理，而不会再和网站根目录清理混在一起。
Linux 服务器运维、部署与线上故障排查
如果你的网站或后端服务部署在 Linux 服务器上，遇到访问异常、Nginx 配置问题、MySQL / Redis 异常、Docker 服务不可用、磁盘占满、CPU / 内存过高等问题，可以联系我做一次远程排查。
适合以下场景：
✅ 网站打不开或访问不稳定
✅ Nginx / PHP-FPM 配置异常
✅ MySQL / Redis 性能或连接问题
✅ Docker 服务部署与维护
✅ 服务器迁移与环境配置
✅ CPU / 内存 / 磁盘异常排查
服务内容：
✅ Linux 环境检查
✅ 网站部署与迁移
✅ Nginx / PHP-FPM / MySQL / Redis 排查
✅ Docker 配置与维护
✅ 服务器性能分析
✅ 长期远程运维支持
如需咨询，请联系我，并注明：Linux 运维咨询。
联系方式：
Telegram：@shuijingwan
微信：13980074657
邮箱：shuijingwanwq@gmail.com
发表回复