一、为什么 WordPress 跑通后还要再加一层 LB¶

当前阶段里，WordPress 已经分别在 web01 和 web02 上跑起来了，但如果用户仍然直接访问某一台 Web 节点，就还没有真正用上集群能力。

原笔记接下来的目标就是：

• 给两台 Web 站点前面加一个统一入口
• 通过 Nginx 的 upstream 做请求分发
• 让 blog.oldboylinux.cn 由负载均衡主机统一接入

这样做之后，用户不再直接感知后端到底是哪一台 Web。

二、LB 主机上需要准备什么¶

原笔记依旧使用 Nginx 作为前端负载均衡，并在 oldboy02 上完成安装。

这部分和之前基础负载均衡实验类似：

yum install -y nginx
rpm -qa nginx

真正关键的是站点配置文件。

三、blog.oldboylinux.cn 的负载均衡配置怎么写¶

原笔记给出的 LB 配置如下：

upstream blog_pools {
 server 192.168.1.20:80;
 server 192.168.1.22:80;
}

server {
  listen 80;
  server_name blog.oldboylinux.cn;

  error_log /var/log/nginx/blog-error.log notice;
  access_log /var/log/nginx/blog-access.log main;

  location / {
    proxy_pass http://blog_pools;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

这份配置里，几个关键点分别对应不同作用：

• upstream blog_pools：定义 WordPress 后端池
• proxy_pass http://blog_pools;：把请求交给后端池
• proxy_set_header Host $http_host;：保留原始域名
• X-Real-IP 与 X-Forwarded-For：透传真实客户端来源

四、为什么这里的请求头透传仍然很重要¶

即便已经进入负载均衡阶段，原笔记仍然保留了：

proxy_set_header Host $http_host;

这是因为后端 Web 仍然是按：

• server_name blog.oldboylinux.cn

来匹配站点的。
如果前端 LB 不把原始域名传过去，后端仍然有可能命中错误的虚拟主机。

同理，真实 IP 透传也依然必要，因为：

• 后端日志分析仍要看真实客户端地址
• 后续排查问题时不能只看到 LB 主机 IP

五、配置完成后如何验证¶

原笔记的验证流程很标准：

先检查语法并重启：

nginx -t
systemctl restart nginx

然后在 Windows 本地 hosts 中加入：

192.168.1.21 blog.oldboylinux.cn

之后浏览器访问：

http://blog.oldboylinux.cn/

与此同时，在 web01 和 web02 上同时查看访问日志：

tailf /var/log/nginx/blog-access.log

原笔记指出，默认情况下可以观察到请求轮流落到两台 Web 上，这说明：

• LB 已经正常分发请求
• 两台 Web 都在处理同一个域名站点

六、为什么 WordPress 能被这样接入集群¶

这个案例之所以能跑通，不只是因为 upstream 写对了，还因为前面几步准备已经到位：

• 两台 Web 拥有相同的站点代码
• 上传目录通过 NFS 统一
• 数据库统一连向同一个 MariaDB

也就是说，LB 本身只是“入口调度层”，真正让 WordPress 可以多节点工作的，是前面完成的数据与文件共享基础设施。

七、把这个案例抽象成生产思路¶

从原笔记的配置可以抽象出一个非常典型的 Web 集群入口模式：

1、应用站点先在多个 Web 节点跑通
2、静态共享和数据库统一准备好
3、前端 Nginx 用 upstream 统一代理
4、保留域名和真实客户端头部
5、通过日志观察请求是否已经均匀分发

这也是很多中小型 LNMP 架构演进到集群阶段的自然路径。

八、小结¶

把 WordPress 接入 Nginx 负载均衡，配置本身并不复杂，核心仍然是：

• 用 upstream 组织后端节点
• 用 proxy_pass 转发请求
• 用请求头透传维持站点匹配和日志准确性

当前端入口统一、后端数据共享到位后，一个可轮询访问的 WordPress 集群就算真正搭好了。