在实际运维和多站点管理中，很多人常常会遇到这样的问题：
想通过子域名（例如
blog.example.com）来访问某个子目录中的 WordPress，但最终发现跳转逻辑复杂、配置繁琐，甚至会引发各种不必要的麻烦。
💡 WordPress 的设计逻辑
WordPress 是一个需要严格识别「主站 URL」的应用，站点地址（siteurl 和 home）会被写入数据库。
它的架构假设访问地址是唯一且固定的，这与 Nextcloud 等可以完全依赖相对路径的应用不同。
⚡ 子域名访问的复杂性
如果希望通过子域名根路径访问 WordPress，比如 blog.example.com：
- 必须修改数据库
siteurl与home字段 - 需要新增子域名 DNS 配置
- 后端文件需要迁移到根目录，或通过根目录
index.php引导 - 需要更改 Nginx 或 Apache 配置，处理复杂的 rewrite 规则
对于已有多文件的根目录环境，或同一台服务器上有其他重要应用，这种方案会带来较高的风险和维护成本。
✅ 子路径访问：最简单、最稳妥
相比之下，保留原有子路径（例如 https://example.com/wordpress/）具有明显优势：
- 不需要修改数据库
- 不需要迁移文件或新增引导文件
- 不需要额外子域名 DNS 配置
- 不影响服务器中其他应用
- 插件兼容性更好，后续维护更简单
在 Nginx 配置中，可以继续保留：
location / {
proxy_pass http://后端服务器/wordpress/;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
🔥 子路径方案的适用场景
- 后端有多个不同的 Web 应用
- 根目录已经存放重要文件
- 希望简化维护成本，减少后期迁移风险
- 服务器与域名策略希望集中在一个主域名下管理
⭐ 总结
在需要同时管理多个应用、且想要更稳妥、简洁的方案时，保留 WordPress 的子路径访问，是最省心、最稳定、也是官方最推荐的做法。
💬 参考
- WordPress 官方文档：Giving WordPress Its Own Directory
- Nginx 官方代理配置示例
- 常见多站点运维实践经验