WordPress 输入用户名和密码后反复回到登录页，别只检查 Cookie 和插件。2020 年的一次故障，最终发现服务器磁盘可用空间为零，一个日志文件已占用约 15 GB。

从登录页转到主机状态

有一段时间没进后台，再次登录时页面持续返回 wp-login.php，地址中带着 redirect_to 和 reauth=1。我看过清理 Cookie、修改核心文件等建议，但它们没有解释这个原先正常的站点为什么突然失效。

于是连接服务器检查 CPU、内存和磁盘，发现可用磁盘空间已经耗尽。继续定位，占用主要来自日志。旧记录记载，清理后并重启 Nginx，后台恢复登录。

这个结果支持磁盘满影响应用的判断，但没有保存足够日志去确定到底是数据库、临时文件还是其他写入失败。重启与恢复发生在同一次操作中，也不证明重启本身是必需条件。

先只读检查空间与 inode

Linux 上可以从这些命令开始：

df -h
df -i
du -x -h --max-depth=1 /var/log

df -h 看文件系统空间，df -i 看 inode 使用情况，du 用于逐层定位目录占用。最后一条的选项以 GNU/Linux 为背景；权限不足时应按主机管理方式查看，不因读不到就直接更改整个目录权限。GNU 磁盘使用工具

日志也可能位于站点、PHP、数据库或其他服务目录，不能只查 /var/log。先确定它由谁写入，再决定如何保留和清理。

恢复空间不能变成长期“删日志”

应保留必要诊断片段，修正异常增长原因，并为对应服务设置轮转、保留期限和磁盘告警。直接删除仍被进程打开的大文件，空间还可能暂时没有释放，不能只看目录里文件消失就认为问题结束。

相关的文件占用与保留策略见Linux 日志空间排查。

登录循环还有其他可能性

磁盘恢复后，检查登录跳转、后台操作以及服务错误是否正常。如果空间并无异常，再核对 Cookie、站点地址、HTTPS 代理和插件。不能把这次经历变成“所有登录循环都要删除日志”，更不应先修改 WordPress 核心文件来碰运气。