WordPress 部署与运维实战：从部署认知到故障排查

这组记录来自几次不同阶段的 WordPress 实践：从宝塔迁到 1Panel，重新认识 Docker 部署，给多站环境接入缓存，再到小规格 VPS 的资源收敛和后台 524 排查。

一次请求经过哪些组件

在 1Panel 环境里，浏览器发出的请求通常先到 OpenResty。传统部署由 OpenResty 把 PHP 请求交给 PHP-FPM，PHP 再读取 WordPress 文件、查询数据库并生成页面；一键部署的容器化 WordPress 则多了一层反向代理，OpenResty 把请求转给 WordPress 容器，由容器内的 Web 与 PHP 环境继续处理。

Redis 不负责接收网页请求。启用对象缓存后，WordPress 在生成页面的过程中会先从 Redis 读取部分数据库查询结果，未命中时再访问 MySQL 或 MariaDB。页面缓存处在更靠外的位置，它保存已经生成的 HTML，让部分匿名访问不用再次运行 PHP。

浏览器
  ↓
OpenResty
  ↓
PHP-FPM 或 WordPress 容器
  ├─ WordPress 文件、主题与插件
  ├─ MySQL / MariaDB
  └─ Redis 对象缓存

实际部署未必与这张简图完全一致，但排查问题时可以沿请求方向逐层确认：域名和证书是否正常，OpenResty 是否把请求交给了正确的后端，PHP 是否可用，数据库和 Redis 是否能从当前运行环境访问。

传统部署和容器部署

传统部署的网站文件直接放在主机目录中，OpenResty、PHP 和数据库之间的关系比较直观。容器部署把应用及其运行环境隔离起来，网站数据通过挂载目录持久保存，组件之间通过端口映射或 Docker 网络通信。

这一区别会影响文件位置、配置生效方式、组件使用的主机名和故障排查路径。主机上的 localhost 与容器里的 localhost 指向不同环境，容器访问宿主机或其他容器时，也不能直接照搬传统部署里的连接地址。

延伸阅读

主线之外还有几篇独立记录：

• 1C1G 服务器搭建 WordPress 插件开发环境，手动 LEMP 路线的完整搭建过程
• 宝塔面板 WordPress 优化与 Nginx 规则调整，早期宝塔环境下的调整清单
• WordPress 小问题记录，插件导致 CPU 爆满、发布无限加载、双 H1 与段落插广告
• MySQL 进程被杀记录，2019 年的一次数据库故障