很多人把 WordPress 装好以后，下一步就会想做这件事：给它挂一个正式域名，最好还是一个单独的二级域名。
比如主站是 godsun.pro，那内容站就挂成 ai.godsun.pro；以后文件站是 p.godsun.pro；再往后做别的服务，也继续按子域名拆。这个思路本身完全没问题，问题出在很多人一开始没把结构想清楚，于是刚接入域名、反向代理或者 Cloudflare Tunnel，WordPress 就开始各种报错，最常见的就是 301 循环、HTTPS 识别不对、后台登录反复跳转。
这篇我就不从“某一个命令怎么敲”开始，而是先把这条链讲明白：域名、入口、WordPress 本体，到底分别在干什么。 你把这个逻辑理顺了，不管你是面板装、Docker 装，还是直装，后面都会顺很多。
顺便说一句，WordPress 放在反向代理或 Tunnel 后面出现重定向循环，这不是你一个人的问题。公开社区里一直有人踩这个坑，本质都是同一类原因：外面明明是 HTTPS，WordPress 自己却以为来的是 HTTP，然后就开始反复跳转。
一、先把最核心的三层分清楚
很多新手一开始容易把好几件事混成一件事，实际上 WordPress 挂二级域名，至少有三层：
- 域名 DNS：负责让别人能找到你
- 外网入口：负责接住访问，再转给后面的服务
- WordPress 站点本体：真正负责输出网页内容
举个最直白的例子，如果你要挂的是 ai.godsun.pro，那它的链路大致就是：
ai.godsun.pro → 外网入口 → WordPress
这里的“外网入口”，可以是：
- 有公网 IP 的服务器 + Nginx / Caddy 反向代理
- 家里机器通过 Cloudflare Tunnel 对外暴露
- 面板自己带的站点入口和证书管理
而 WordPress 本体可以是：
- 面板里的一个站点
- Docker / Podman 里的 WordPress 容器
- 系统里直接安装的 WordPress
这三层不要混。尤其是 Cloudflare Tunnel，它解决的是“内网服务怎么出去”，但它不是 WordPress 本体，也不等于你已经把反向代理的逻辑完全想明白了。
二、最适合新手的理解：域名是门牌，入口是门卫，WordPress 是房间
我一直觉得新手学这些东西，最怕一开始就被术语压住。其实换成人话就很简单：
- 域名 是门牌号
- 入口 是门卫或前台
- WordPress 是真正提供内容的房间
别人访问 ai.godsun.pro，先找到这个门牌，然后请求先到前台，再由前台决定把流量转给哪个房间。
如果你以后还有：
p.godsun.pro→ OpenListdev.godsun.pro→ 测试站km.godsun.pro→ 以后设备多了再单独做入口页
本质上也还是这套逻辑，只不过前台根据不同门牌，把人带去不同房间而已。
三、二级域名到底应该怎么规划
这一步其实特别重要。很多人后面越折腾越乱，不是服务不会装，而是一开始域名没规划。
我更建议按“功能”来分，而不是按机器名乱命名。比如：
www.xxx.com：主站ai.xxx.com：WordPress 内容站p.xxx.com：OpenList / 文件站dev.xxx.com：测试站
这样做的好处很现实：后面你就算换机器，也不用换二级域名逻辑。今天 WordPress 在机器 A，明天搬到机器 B，对外仍然是 ai.xxx.com。对自己和访问者都更省心。
四、一台机器怎么挂，多台机器又怎么挂
这也是很多人容易想复杂的地方。其实先分两种情况就够了。
1）一台机器方案
如果你现在只有一台主机，那最简单的方式就是：
- WordPress 跑在本机
- 入口也在本机
- 域名直接指向这台机器，或者由 Tunnel 带出去
这种方式的优点是结构简单，排错也直观。新手第一次挂站，非常适合先这样做。
它的缺点也很明显：后面如果你加 OpenList、下载服务、其它子站，所有东西都会堆到这一台机器上。机器压力和维护复杂度会慢慢上来。
2）多台机器方案
如果你后面设备多起来了，就可以拆：
- WordPress 一台
- OpenList 一台
- 其它服务一台或几台
- 公网入口或 Tunnel 继续统一管理
这时候对访问者来说没有区别，别人依然只是访问 ai.xxx.com。只不过入口层会把这个请求再转发到真正跑 WordPress 的那台机器上。
所以新手不用把“一台机器”和“多台机器”想成完全不同的世界。它们只是后端房间安排不一样，对外门牌逻辑并没变。
五、反向代理和 Cloudflare Tunnel，到底是不是一回事
不是一回事，但经常一起出现，所以很多人会混。
反向代理 更像“分流层”。它看到访问的是哪个域名，然后把流量送到后面的正确服务。比如访问 ai.xxx.com 就转给 WordPress，访问 p.xxx.com 就转给 OpenList。
Cloudflare Tunnel 则更像“外网通道”。它解决的是：你家里机器没有公网 IP，或者你不想直接把端口暴露出去，那怎么让外面的人仍然访问到这个站。
所以一个更准确的理解是：
- 反向代理负责“怎么分流”
- Tunnel 负责“怎么让流量进来”
这也是为什么很多文章会把它们一起讲，但你脑子里一定要把这两个概念拆开。
六、为什么 WordPress 最容易在这里出 301 循环
这块是最常见的坑，也是最值得提前讲清楚的地方。
公开社区里长期都有类似案例：WordPress 放在 Docker、本地机器或者内网主机上，本身只收到 HTTP；但外部用户访问的是 HTTPS；入口层（Nginx、Caddy、Cloudflare Tunnel）替它做了 TLS / HTTPS 这一层。结果 WordPress 自己没意识到“外面其实已经是 HTTPS 了”，它就会继续尝试把你往 HTTPS 重定向，最后形成死循环。
简单理解就是：
- 用户看到的是 HTTPS
- WordPress 以为收到的是 HTTP
- 它拼命跳到 HTTPS
- 入口又把它转回来
- 最后浏览器报太多重定向
这不是 WordPress 某个版本单独的问题，而是它在代理、转发、SSL 终止这些场景下，确实比一些纯静态站更容易出这个毛病。
七、这种重定向循环一般怎么避坑
这部分我不想写成一堆配置碎片，而是讲几个最重要的方向。
1）先确认站点真正使用的正式域名
不要一开始站里还留着 localhost、内网地址、旧的 HTTP 地址，后面再硬挂 Tunnel 或反代。这样最容易把跳转关系搞乱。
你应该尽量让 WordPress 认准它真正要对外使用的那个域名，比如 ai.xxx.com，而不是一会儿 localhost、一会儿 192.168.x.x、一会儿又是正式域名。
2）让 WordPress 知道外面来的是 HTTPS
这一点特别关键。很多公开案例本质都指向同一个问题：代理层已经处理了 HTTPS，但 WordPress 自己不知道。常见做法就是让它识别代理带过来的 HTTPS 头信息，比如 X-Forwarded-Proto，再据此把请求视为 HTTPS。
如果不做这一步，就特别容易出现：
- 后台登录反复跳转
- 首页 301 循环
- 明明站能打开，但管理页不正常
3）别把旧的 HTTP 链接和新的 HTTPS 域名混着用
有些人本地先装了一个站，里面已经写满了旧链接，后面才正式挂域名。这时候如果站点内部还有大量 http://localhost 或旧地址引用，也会让整套行为变得非常诡异。
4）Cloudflare / Tunnel 场景更要注意 SSL 认知一致
因为 Tunnel 这类方案最容易让你“感觉已经是 HTTPS 了”，但后端 WordPress 实际拿到的可能还是另一层协议状态。新手最容易在这里踩坑，所以不要只看浏览器地址栏是 HTTPS，就以为后端也完全理解这件事。
八、给新手的最稳顺序
如果你现在刚准备把 WordPress 挂成一个正式二级域名，我建议按这个顺序来：
- 先确定正式域名叫什么
- 先确定是一台机器还是多台机器
- 先确定外网入口是反代还是 Tunnel
- 再去让 WordPress 认这个正式域名
- 最后再处理 HTTPS、后台登录、301 跳转这些细节
这个顺序的意义在于：你先把结构定清楚，后面每一步都知道自己在干什么。最怕的是一边改域名、一边上 Tunnel、一边换反代、一边调 WordPress 后台，这样一旦循环跳转，你根本不知道是哪里出的错。
九、对新手来说，先追求“结构清楚”，不要先追求“配置炫”
很多新手最大的误区，是刚开始就想一步到位：Docker、Caddy、Tunnel、多个子域名、证书自动化、还有一堆别的服务全部一起接入。结果最后不是技术太难，而是层次没分清。
更稳的做法永远是：
- 先确定门牌号是谁
- 再确定前台是谁
- 最后确认房间里到底跑的是什么
你把这三层理顺，WordPress 挂二级域名这件事其实就没那么可怕了。
十、下一篇就该接 OpenList 了
如果这一篇讲的是 ai.xxx.com 这种 WordPress 站，那下一篇最顺的就是接 p.xxx.com 这种文件站。
因为逻辑其实是同一套：
- 域名怎么分
- 一台机器怎么挂
- 多台机器怎么挂
- 入口怎么分流
只不过下一篇会从 WordPress 换成 OpenList，实战味会更浓一点。
👇 如果你现在刚准备把 WordPress 真正挂成一个正式站点，别先急着抄满屏配置。
先把“域名、入口、WordPress 本体”三层关系想明白。很多 301 循环、HTTPS 识别错误、后台跳转问题，根源其实都在这里。
本文 by 数码罗记 · godsun.pro