这次折腾的过程其实证明了一件事：在复杂的内网穿透架构中，协议和端口的组合方式远比复杂的 Nginx 配置更关键。在尝试了多种代理组合失败后，最终发现想要跑通 WordPress 和 Nextcloud 这种 PHP 项目，核心在于一套非常具体的链路逻辑。
正确的方法是：云服务器的 Nginx 只负责外网域名的 SSL 解析，然后通过 proxy_pass 将流量打向 FRP 的服务端端口。关键在于 FRP 的映射策略，不能简单地为了省事去做“非标端口”对“非标端口”的映射（比如 8001 对 8001），而是必须将 FRP 的本地端口指向物理机 Nginx 的 80 端口。
在物理机（本地服务器）端，Nginx 站点的配置要严格遵循标准的 80 端口监听，并且在宝塔或 Nginx 的站点管理中，必须清晰地填写项目的公网域名，而不是使用 127.0.0.1 或者 0.0.0.0。同时，物理机站点内部严禁开启 SSL，所有的加密工作全部交给云服务器。
最后针对 WordPress 的特殊性，只需要在 wp-config.php 文件中加入几行协议识别代码。通过判断请求头中的 HTTP_X_FORWARDED_PROTO，手动在代码层面给 PHP 补上 $_SERVER['HTTPS'] = 'on' 的标记。
这套方案不需要在 Nginx 里写各种复杂的跳转规则，本质上是让物理机回归到最原始的“80 端口 HTTP 环境”，通过 FRP 充当“透明导线”，最后在 PHP 入口处完成环境补偿。这不仅解决了 404 和 502 的连接问题，也从根源上消除了 HTTPS 环境下静态资源加载失败的报错。
如果你以后需要部署新的 PHP 项目，只需要按照“云端 SSL -> FRP -> 物理机 80 端口 -> PHP 环境补偿”这个固定公式走，就不会再出现链路不通的情况。
