使用 1Panel 和内网穿透部署 WordPress 实例要点备忘

今天为了测试一个程序，需要同时搭建两个 WordPress 实例，特别是依赖于部分非缺省的 PHP 扩展，1Panel 应用商店里的 WordPress 对应的 PHP 环境相对固化，难以满足个性化需求，因此最终选择了手动创建网站实例，然后通过容器化方式单独挂载运行 PHP 和 MySQL。这样做的最大好处是自由度较高，可自由选择 PHP 或 MySQL 版本，如对 PHP 扩展有特定要求，也方便安装维护。 我的服务器在内网，通过 FRP 内网穿透方式实现公网访问，且两个实例均使用了 Redis 缓存。 今天在部署过程中踩了不少坑，为方便后续查阅，避免反复通过 AI 寻求解决办法，因此把几个核心要点记录下来。 一、frp 内网穿透下的端口暴露与 Nginx 配置 因为使用了 frp 进行内网穿透，外部流量经过穿透到达本地的 Nginx （具体为：OpenResty）时，会发生端口号暴露。例如访问 domain.com/wp-admin （最后没有以 / 结尾）时，会默认跳转为 domain.com:8585/wp-admin/ （出现的端口号 8585 即本地搭建时网站实例的端口号），导致无法访问。 1、修改本地 1Panel 的 Nginx 配置 为解决这个问题，需修改本地网站的 Nginx 配置文件，关闭绝对重定向和端口重定向： # 在 Nginx 站点的 server 块中添加或修改以下配置（找个位置靠前些的） server { # ... 其他配置 ... # 避免 Nginx 在做目录重定向时带上非标准端口号 absolute_redirect off; # 会让 Nginx 直接返回相对路径的重定向指令，比如让浏览器直接跳到 /wp-admin/，从而完美避开域名和端口的拼接错误。 port_in_redirect off; # ... 其他配置 ... } 剩余 5 行代码 展开剩余代码 2、检查反向代理的 Header 头（可选但推荐） 为了防止 WordPress 内部的其他链接也错误识别端口，需确保 frp 服务端在反向代理时，把真实情况传递给了内网。