嘿，你的思路完全没错，反向代理正是解决这个问题的标准方案！

咱们先理清楚核心矛盾：两台物理服务器如果都直接对外暴露80/443端口，公网IP的端口只能绑定到一个服务上，自然会冲突。反向代理就相当于一个统一的「入口网关」，所有用户请求先打到这台代理服务器，再由它根据规则把请求转发到对应的后端服务器上，完美解决端口冲突问题。

至于你问的要不要第三台服务器？其实有两种可行方案：

• 方案一：使用第三台独立的Nginx反向代理服务器（首推）
  这台服务器作为唯一的对外入口，绑定你的公网IP，专门监听80/443端口。后端的两台服务器则只用内网IP通信，它们的Nginx可以继续监听80/443（只对内网开放），或者改成8080、8081这类不冲突的端口。
  你只需要在代理服务器的Nginx配置里，根据不同域名（毕竟你是WordPress站点，每个站应该对应独立域名吧？）做转发规则就行。举个简单的配置片段：

  # 转发到第一台后端服务器的站点
  server {
      listen 80;
      server_name site1.com site2.com;
  
      location / {
          proxy_pass http://192.168.1.100; # 第一台服务器的内网IP
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
      }
  }
  
  # 转发到第二台后端服务器的站点
  server {
      listen 80;
      server_name site3.com site4.com;
  
      location / {
          proxy_pass http://192.168.1.101; # 第二台服务器的内网IP
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
      }
  }
  

  这个方案的优势是架构清晰，后期新增服务器或者站点时，只需要在代理服务器上添加配置即可，而且后端服务器的负载压力也更均衡，单点故障风险更低。

• 方案二：用现有其中一台服务器兼任反向代理
  如果不想额外加服务器，也可以把其中一台现有服务器的Nginx改成「代理+自身服务」的模式：保留它的公网IP，监听80/443，把属于另一台服务器的域名请求转发过去，自己的域名则直接处理。不过这种方式会让这台服务器的负载更高，一旦它出问题，所有站点都会受影响，适合预算有限、站点规模较小的场景。

另外补充下HTTPS的情况：如果你的站点要启用HTTPS，SSL证书只需要部署在反向代理服务器上就行（可以用Let's Encrypt免费证书），代理服务器解密HTTPS请求后，再转发给后端的HTTP服务，能减少后端服务器的SSL解密负载。

总的来说，第三台独立反向代理服务器是最稳妥的选择，对你目前10个WordPress站点的规模来说，单台代理服务器完全能胜任，后期扩展也很方便。

备注：内容来源于stack exchange，提问作者cipre