排查 WordPress 更新后一直显示维护提示的问题，确认真实根目录和 .maintenance 文件，安全恢复访问并检查中断更新、权限与缓存。
先恢复入口，再判断更新有没有完成：WordPress 更新后如果整站一直显示“正在执行例行维护，请一分钟后回来”或 Briefly unavailable for scheduled maintenance，先进入宝塔面板的“网站”，找到目标站点并打开“根目录”；确认该目录同时包含 wp-config.php、wp-admin 和 wp-content。如果没有更新任务仍在运行，可先备份根目录中的隐藏文件 .maintenance，再把它改名移出触发路径。删除或改名这个文件只能退出维护页，不能自动补齐中断的 WordPress、插件或主题更新。
查看文件、日志和站点状态通常不收费；备份空间、商业插件续费、托管运维或服务器升配可能收费。改名 .maintenance 本身不会删除文章和数据库，但如果更新只完成了一半，恢复访问后可能出现致命错误、后台升级提示或前后台版本不一致。不要连续点击更新、清缓存和重启服务。先保存文件与数据库备份、当前版本和错误日志，再操作。
先确认真的是 WordPress 核心维护模式
WordPress 在更新核心、插件或主题时，会在安装根目录创建 .maintenance。正常结束后它会被删除；网络中断、PHP 超时、文件权限错误或更新进程被终止时，这个文件可能留下。WordPress 官方说明中的典型现象是全站显示短暂维护提示。
先在浏览器无痕窗口访问首页和 /wp-admin/，并从服务器查看响应。把域名换成真实站点，下面命令只读取响应头：
curl -sS -D - -o /dev/null https://你的域名/
curl -sS -D - -o /dev/null https://你的域名/wp-admin/如果源站返回 503，并带有维护提示或 Retry-After，再检查 .maintenance。如果源站已是 200，只有某个地区或浏览器仍看到旧维护页，优先检查 CDN、页面缓存和浏览器缓存。若页面是插件设计的倒计时、登录用户可见而访客不可见，或宝塔/主机面板有独立“维护模式”开关，则不一定是 WordPress 核心文件造成的。
在宝塔面板哪里找 .maintenance 文件
- 进入宝塔面板的“网站”，找到出现故障的域名，打开该站点的根目录。
- 在文件管理器中开启“显示隐藏文件”。以点开头的
.maintenance默认可能不显示。 - 核对同一目录是否存在
wp-config.php、wp-admin和wp-content。没有这些项目，说明当前目录可能只是反向代理目录、静态目录或上一级目录。 - 查看
.maintenance的修改时间。它应与刚才失败的更新时段接近。
一台服务器可能有多个 WordPress 站点，子目录安装和多站点也可能共用不同根目录。不能看到任意一个 .maintenance 就删除。应先用站点配置确认真实运行目录，再核对文件时间和故障域名。
用 SSH 怎样做只读确认
如果可以登录服务器，先把示例路径替换为宝塔中显示的真实站点根目录。以下命令只读取目录、文件属性和前几行内容：
cd /www/wwwroot/你的站点目录
pwd
test -f wp-config.php && echo "找到 WordPress 根目录"
ls -la .maintenance
stat .maintenance
sed -n '1,5p' .maintenance找不到文件时不要扩大为全盘删除命令。先确认站点 Nginx 配置中的根目录或反向代理目标。如果服务器部署了容器，文件可能在容器卷内；应从 Compose 的卷映射确认宿主机路径，不能只检查容器外的同名目录。
怎样安全退出卡住的维护模式
先确认没有后台更新页面仍在执行，也没有部署任务正在覆盖文件。保留当前 SSH 或宝塔会话，不要同时从多个入口重复操作。相比直接删除，先改名更容易回退：
cd /www/wwwroot/你的站点目录
mv .maintenance .maintenance.stuck-backup-请填写日期时间日期时间必须由操作者填写，例如当前维护窗口的年月日时分。命令成功后，立即从无痕窗口访问首页和后台。若服务器已安装 WP-CLI，并且明确知道正确站点路径与运行用户，也可以先查看状态，再由 WP-CLI 退出维护模式：
sudo -u 网站运行用户 wp --path=/www/wwwroot/你的站点目录 maintenance-mode status
sudo -u 网站运行用户 wp --path=/www/wwwroot/你的站点目录 maintenance-mode deactivate不要把“网站运行用户”原样复制。它通常由 PHP-FPM、容器或主机配置决定，使用 root 运行 WP-CLI 可能制造新的文件属主问题。WP-CLI 无法加载 WordPress 时，先保留报错，它可能正好说明更新后的代码、插件或数据库不完整。
退出后出现不同结果，下一步怎么走
| 结果 | 可能含义 | 下一步 |
|---|---|---|
| 首页和后台恢复正常 | 维护文件遗留，代码大概率可运行 | 仍要核对更新状态、日志和版本，不能直接结束 |
| 出现“需要升级数据库” | 代码已更新，数据库步骤尚未完成 | 先核对备份和目标版本，再按后台明确提示完成升级 |
| 出现致命错误或白屏 | 插件、主题或核心文件可能只更新一部分 | 保存错误日志，停用刚更新的组件或恢复备份，不要反复删文件 |
.maintenance 很快重新出现 | 仍有更新、定时任务或外部面板在控制维护状态 | 停止重复更新，查后台任务、部署日志、Cron 与面板维护开关 |
| 根目录没有该文件但仍显示维护页 | 可能是缓存、维护插件、托管面板或 Nginx 自定义 503 | 先直接验证源站，再逐层清查缓存和入口配置 |
如果退出维护模式后出现 WordPress 致命错误，可按WordPress 致命错误恢复模式排查读取恢复邮件和 PHP 日志。若错误指向内存耗尽，可继续参考PHP Allowed memory size exhausted 排查。不要把所有更新失败都归因于 .maintenance。
为什么删了文件仍看到维护页
先绕开 CDN 或缓存验证源站。源站恢复而公网仍显示旧页面时，再清理 WordPress 页面缓存、Nginx 缓存和 CDN 中对应 URL；不要一开始就清空所有缓存，因为缓存可能暂时保护源站，也会抹掉定位差异的证据。清理后重新查看响应状态、Age 等缓存相关头部和页面内容。
如果源站本身仍返回 503，检查宝塔网站配置、Nginx 错误日志、PHP-FPM 日志以及维护插件。某些插件或托管工具使用自己的开关，不依赖 WordPress 根目录的 .maintenance。这时继续新建或删除同名文件没有意义，应从返回页面的样式、响应头和最近变更确定控制层。
更新中断后怎样核对文件和权限
WordPress 官方资料指出，一键更新失败可能与文件系统权限或所有权有关。恢复访问后，先在后台“更新”页面核对 WordPress 核心、插件和主题的目标版本；再检查失败时段的 PHP、Web 服务器和宝塔任务日志。不要为了让更新通过而把整站目录设为 777，这会扩大写入范围并掩盖真实属主问题。
更新提示某个插件失败时，先确认插件目录是否完整、当前版本是否与 PHP 和 WordPress 兼容。生产站不要立刻把全部插件再次批量更新。先用备份或暂存环境验证故障组件，再一次只处理一个变更。文件权限的通用判断可参考Linux 文件权限与属主检查。
恢复后怎样验收
- 从无痕窗口访问首页、后台登录页、文章页和一项低风险动态操作，确认不再返回 503。
- 检查
.maintenance没有重新生成；如果使用 WP-CLI，确认状态为未启用。 - 在后台核对 WordPress、插件和主题版本，确认没有“更新失败”或数据库升级待办。
- 查看故障时间后的 PHP、Nginx 与 WordPress 日志，不再出现同一权限、超时或致命错误。
- 确认前台布局、登录、表单、缓存和定时任务正常，再结束维护窗口。
如果前台恢复但后台或写入仍异常，不能把本次处理标记为完成。更新可能只复制了部分文件。应停止继续更新，根据备份恢复原版本，或按 WordPress 官方手动更新流程补齐核心文件，并在隔离环境先验证。回退时使用故障前的文件和数据库配套备份，避免只回文件不回数据库造成版本错配。
怎样减少再次卡住
- 更新前完成文件与数据库备份，并实际确认备份可读取。
- 先在暂存站检查 PHP、WordPress、主题和关键插件兼容性。
- 选择低流量窗口，一次只做一组可归因的更新，保留当前版本清单。
- 确保站点目录的属主、写权限、磁盘容量和 PHP 执行时间满足更新需要。
- 更新完成后主动检查首页、后台、日志、Cron 与缓存，不以“进度条消失”作为唯一成功标准。
如果 WordPress 的计划任务本身长期不执行，可结合WP-Cron 错过计划排查检查循环请求和系统任务，但它与一次更新遗留的 .maintenance 是两个独立问题。
官方资料
以上资料于 2026 年 9 月 5 日核验。WordPress、宝塔、插件、托管面板和缓存服务的界面可能变化，操作时以当前站点根目录、运行用户和官方文档为准。
联系 Telegram 客服 