宝塔 LNMP 部署 WordPress：目录、权限与伪静态一次配好 (2)

准备：先固定环境、路径与回滚点

本文假设服务器为 Linux + 宝塔面板 + LNMP，即 Nginx、MySQL/MariaDB、PHP-FPM。2026 年生产环境常见组合是 Nginx 1.24/1.26 或宝塔自带稳定分支、MySQL 8.0/8.4 或 MariaDB 10.11/11.x、PHP 8.2/8.3；WordPress 官方仍建议优先使用受支持的最新 WordPress 与 PHP 8.x 系列，不建议使用已经停止安全支持的 PHP 7.4/8.0。扩展层面至少要确认 mysqli、curl、mbstring、xml、zip、gd、imagick、intl、exif、opcache、fileinfo 可用，其中 imagick 不是所有程序强依赖，但图片裁剪、PDF 预览、媒体库处理更稳。

开始前在宝塔里创建站点，例如域名 example.com，站点目录默认可能是 /www/wwwroot/example.com。数据库名、用户名、密码单独保存；不要把数据库密码写进 wp-config.php 之外的备份文本。若站点要由开发公司做长期迭代，可先阅读 2026年如何挑选 WordPress 专业服务商，把部署、验收、回滚责任写进交付边界，避免上线后因权限和伪静态互相推诿。

准备一个可回滚快照：宝塔「文件」压缩整站目录，宝塔「数据库」导出 SQL，再复制当前 Nginx vhost 配置。命令行可用下面这组命令，路径按实际站点替换。注意代码块中的尖括号已经转义，复制时保持 HTML 实体即可在页面显示，实际终端命令使用普通 < > 符号。

# 1) 进入站点父目录并备份整站
cd /www/wwwroot
tar -czf /root/backup-example-com-2026.tar.gz example.com

# 2) 导出数据库，替换为真实库名与用户
mysqldump -u <db_user> -p --single-transaction --quick <db_name> > /root/example-com-2026.sql

# 3) 备份 Nginx 站点配置
cp /www/server/panel/vhost/nginx/example.com.conf /root/example.com.conf.bak

# 4) 记录当前属主、权限、PHP-FPM 用户
ls -ld /www/wwwroot/example.com
stat -c '%U:%G %a %n' /www/wwwroot/example.com/index.php
ps -eo user,group,cmd | grep 'php-fpm' | grep -v grep

# 5) 测试配置语法，后续每次改 vhost 都执行
nginx -t

如果项目已经有代码，先确认 WordPress 核心文件在哪里：wp-settings.php、wp-load.php、wp-admin、wp-content、wp-includes 是否在同一层。如果它们位于 /www/wwwroot/example.com/wordpress 或 /www/wwwroot/example.com/public，就属于「代码在子目录」场景，后面必须处理运行目录，不能只把压缩包上传了事。

实施步骤：按准备 → 步骤 → 验证 → 回滚一次配好

1. 在宝塔「网站 → 设置 → 基本配置」确认站点根目录、运行目录、默认文档，记录原值。
2. 上传或解压 WordPress 到最终目录，修正 wp-config.php 数据库常量与表前缀，禁止把核心文件散落到两层目录。
3. 用 chown、find、chmod 统一属主、目录 755、文件 644，wp-content/uploads 单独验证可写。
4. 在宝塔「设置 → 伪静态」写入 WordPress Nginx 规则，保存后用 nginx -t 检查并重载。
5. 在「设置 → PHP版本」切换到 PHP 8.2/8.3，安装缺失扩展，调整 upload_max_filesize、post_max_size、memory_limit、max_execution_time。
6. 执行浏览器验收、WP-CLI 验收、日志验收；失败时按备份文件、SQL、vhost 配置逐项回滚。

运行目录指向子目录的坑

宝塔的「网站目录」里有「运行目录」选项，常见值有 / 与 /public。很多团队把 WordPress 解压到 /www/wwwroot/example.com/wordpress，却在宝塔里保持运行目录为 /，结果访问首页看到目录列表、403，或安装器跳转到 /wordpress/wp-admin/install.php；也有人把运行目录设为 /public，但代码实际在根目录，Nginx 直接返回 404。还有一种更隐蔽的情况：运行目录改对了，wp-config.php 被留在上一层，站点能打开但自动更新、常量读取、WP-CLI 路径判断异常。

先判断代码属于哪一种目录结构

在站点根目录执行 ls -la。如果看到 wp-admin、wp-content、wp-includes、wp-settings.php、wp-load.php，说明 WordPress 核心就在根目录，运行目录应保持 /。如果看到 public、wordpress、cms 之类的子目录，且 WordPress 核心文件在子目录里，要么把子目录内容整体上移到站点根目录，要么把宝塔运行目录指向该子目录。生产环境更推荐「核心文件直接位于站点根目录」，因为伪静态、缓存插件、安全规则、WP-CLI、备份脚本、CDN 回源路径都更容易对齐。

如果代码来自 Composer 或 Bedrock 风格结构，Web 根目录通常是 /www/wwwroot/example.com/web 或 /public，wp-config.php 与 vendor 在上一层，这是可接受的，但必须保证 Nginx root 指向含 index.php 的那一层，并且 wp-config.php 中 ABSPATH、站点 URL、内容目录路径没有被硬编码成旧环境。Bedrock 这类结构不要直接套普通 WordPress 的「一键迁移」习惯。

宝塔面板里的具体操作

进入「网站 → 站点名 → 设置 → 网站目录」，把「网站目录」设为 /www/wwwroot/example.com；若采用根目录部署，「运行目录」选 /；若采用 public 结构，「运行目录」选 /public。保存后打开「配置文件」或 SSH 查看 /www/server/panel/vhost/nginx/example.com.conf，确认 root 指令类似下面片段。

server {
    listen 80;
    server_name example.com www.example.com;
    root /www/wwwroot/example.com; # 根目录部署
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ .php$ {
        fastcgi_pass unix:/tmp/php-cgi-83.sock;
        fastcgi_index index.php;
        include fastcgi.conf;
    }
}

如果使用 /public，root 应为 /www/wwwroot/example.com/public;，而不是在 try_files 里硬写 /public/index.php。不要同时改 root、rewrite、try_files 三处来「补救」同一个问题，这会让后台、REST API、静态资源出现不同路径行为。

为什么会出现「首页能开，后台 404」

Nginx 的 root 决定文件系统路径，WordPress 的 siteurl 与 home 决定生成链接。若运行目录指向子目录，但数据库 wp_options 里仍是旧域名或旧路径，前台可能靠缓存打开，后台却跳到不存在的 /wp-admin。用 WP-CLI 校准最稳：

cd /www/wwwroot/example.com
wp option get siteurl
wp option get home
wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'
wp rewrite flush --hard
wp cache flush

没有 WP-CLI 时，可在 wp-config.php 临时加入常量，验证后移除动态拼接或保留明确值：

define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );
// 子目录安装仅前台域名时使用：
// define( 'WP_SITEURL', 'https://example.com/wordpress' );

验证与回退

验证：访问 https://example.com/、/wp-admin/、/wp-json/、一个非首页固定链接、/wp-content/uploads/2026/01/test.jpg；执行 wp core verify-checksums；查看 Nginx error log 是否出现 No such file or directory 或 Access denied。回退：把「运行目录」恢复为保存的原值，恢复 /root/example.com.conf.bak，执行 nginx -t && nginx -s reload；若改过 WP_HOME/WP_SITEURL，用备份 SQL 或 wp option update 写回原值。

目录 755 / 文件 644 权限

Linux 权限问题不要用 777 解决。宝塔 LNMP 下，PHP-FPM 通常以 www 用户运行，Nginx 静态文件读取也依赖目录的可执行位。标准基线是：目录 755、文件 644、站点目录属主 www:www 或部署用户与 www 同组；wp-config.php 可收紧到 600/640，但前提是 PHP-FPM 运行用户确实能读；wp-content/uploads 必须让 PHP-FPM 可写，但仍保持目录 755、文件 644，靠属主解决写入，不靠放开其他用户写位。

具体命令

先确认 PHP-FPM 用户，再设置属主。若宝塔面板、SFTP、Git 部署使用 root 或单独运维账号，建议把部署账号加入 www 组，或部署完成后统一 chown 回 www:www。下面命令适用于代码位于 /www/wwwroot/example.com 的常规部署。

cd /www/wwwroot/example.com

# 确认 PHP-FPM 运行用户，宝塔常见为 www
ps -eo user,group,cmd | grep 'php-fpm: pool' | grep -v grep

# 统一属主；如使用 deploy:www，可改为 deploy:www 并配合 setgid
chown -R www:www /www/wwwroot/example.com

# 目录 755，文件 644
find /www/wwwroot/example.com -type d -exec chmod 755 {} ;
find /www/wwwroot/example.com -type f -exec chmod 644 {} ;

# 收紧 wp-config.php，确认 PHP-FPM 可读后再执行
chmod 640 wp-config.php

# uploads 目录仍遵守 755/644，但属主必须是 PHP-FPM 用户
mkdir -p wp-content/uploads
chown -R www:www wp-content/uploads
find wp-content/uploads -type d -exec chmod 755 {} ;
find wp-content/uploads -type f -exec chmod 644 {} ;

# 抽样验证
stat -c '%U:%G %a %n' . index.php wp-config.php wp-content/uploads

如果启用了 Git 自动拉取，直接 git pull 可能把新文件属主改成 root。处理方式是给目录设置 setgid 并保持同组写权限，或在部署脚本末尾固定执行 chown/chmod。示例：

chgrp -R www /www/wwwroot/example.com
chmod g+s /www/wwwroot/example.com
find /www/wwwroot/example.com -type d -exec chmod 2755 {} ;
# 部署脚本末尾追加：
chown -R www:www /www/wwwroot/example.com
find /www/wwwroot/example.com -type d -exec chmod 755 {} ;
find /www/wwwroot/example.com -type f -exec chmod 644 {} ;

为什么 777 是故障放大器

777 让任意本机用户可写，一旦同服务器另一个站点被入侵，攻击者可跨目录写 webshell；同时它会掩盖真实问题：属主不对、PHP-FPM 用户不同、SELinux 上下文错误、open_basedir 限制、磁盘只读挂载。宝塔面板的「修复权限」按钮可以快速回到基线，但开发者仍应知道它改了什么，尤其是多站点共用一台服务器时。

验证与回退

验证动作：在后台「媒体 → 添加新」上传一张图片；安装或更新一个小插件；在「仪表盘 → 更新」触发核心版本检查；执行 wp plugin update --all --dry-run；查看 /www/wwwlogs/example.com_error.log 与 PHP-FPM slow/error log，确认没有 Permission denied、failed to open stream。若 wp-config.php 设 640 后站点白屏，先改回 644 恢复访问，再检查 PHP-FPM 用户与文件属组，而不是改 777。回退时使用备份包解压覆盖，或从同环境复制一份权限清单：

# 生成权限基线，便于回滚对比
cd /www/wwwroot/example.com
find . -printf '%u:%g %m %pn' | sort > /root/example-com-perms-2026.txt

# 回退后对比
find . -printf '%u:%g %m %pn' | sort > /root/example-com-perms-now.txt
diff -u /root/example-com-perms-2026.txt /root/example-com-perms-now.txt | head -80

伪静态规则

LNMP 下 WordPress 固定链接依赖 Nginx 把不存在的路径交给 index.php 处理，而不是 Apache 的 .htaccess。宝塔「网站 → 设置 → 伪静态」提供 WordPress 规则模板，但 2026 年线上站点经常叠加静态缓存、CDN、多站点、子目录安装、REST API、woocommerce 自定义端点，必须检查规则没有把真实文件、目录、wp-admin、wp-json、上传文件错误 rewrite 掉。

推荐配置片段

单站点、代码位于站点根目录时，在宝塔伪静态框写入以下规则。保存后面板会写入 vhost，仍建议用 nginx -t 校验。注意 Nginx 变量中的 $ 不要被 shell 或模板引擎转义。

location / {
    try_files $uri $uri/ /index.php?$args;
}

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

location ~* ^/wp-content/uploads/.*.php$ {
    deny all;
}

location ~* ^/wp-includes/.*.php$ {
    deny all;
}

location ~* /.(?!well-known) {
    deny all;
}

location = /xmlrpc.php {
    # 不需要 XML-RPC 时直接拒绝；需要时改为交给 PHP
    deny all;
}

如果启用了 Nginx 级缓存或宝塔「网站加速」类插件，规则顺序要谨慎：先匹配真实静态文件，再处理 PHP，最后把动态请求回源到 PHP-FPM。不要把 try_files 写成 /index.php?$uri，这会丢失 query string，导致预览、搜索、分页、OAuth 回调、REST 参数失效。也不要把 location ~ .php$ 放在 location / 之前却遗漏 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;，否则常见报错是 Primary script unknown。

WordPress 子目录多站点与静态资源

子目录形式 Multisite 需要额外规则，例如 /sites/<site-id>/files/ 映射到 wp-content/blogs.dir 或新版媒体路径；不要直接复制普通单站点规则。固定链接结构建议在「设置 → 固定链接」选择「文章名」，保存一次让 WordPress 写入 rewrite_rules，然后执行 wp rewrite flush --hard。官方对固定链接与服务器 rewrite 的说明可参考 WordPress 官方文档 Using Permalinks。

验证与回退

验证清单：访问一篇非首页文章；访问带参数的搜索页 /?s=test；访问 /wp-json/wp/v2/posts 应返回 JSON 或按站点策略要求登录；访问 /wp-admin/ 应 301 到带斜杠地址并最终进入登录；上传目录中的 PHP 文件应返回 403；执行 curl -I https://example.com/sample-post/ 查看状态码与缓存头。若保存规则后全站 500，回退到 /root/example.com.conf.bak 或在宝塔伪静态框清空为上一次可用规则，执行 nginx -t && nginx -s reload；若只是固定链接 404，先清空浏览器与 CDN 缓存，再执行 wp rewrite flush --hard。

PHP 版本与扩展

2026 年新部署不建议再选 PHP 7.4 或 PHP 8.0。WordPress 核心对 PHP 8.2/8.3 的支持已经成熟，主流商业插件、页面构建器、WooCommerce 也以 PHP 8.1+ 为基线；PHP 8.4 可用但部分老插件仍可能触发弃用警告，生产上线前要在预发布环境跑一遍。宝塔可在「网站 → 设置 → PHP版本」为单个站点切换版本，切换本质上是更换 PHP-FPM socket，例如 unix:/tmp/php-cgi-82.sock 或 unix:/tmp/php-cgi-83.sock。

必须检查的扩展与参数

在宝塔「软件商店 → 已安装 → PHP 8.3 → 设置 → 安装扩展」确认扩展；命令行用 php -m 检查。注意命令行 PHP 与站点 PHP-FPM 可能不是同一个二进制，宝塔多版本共存时要用对应路径，例如 /www/server/php/83/bin/php -v。站点真实值以 phpinfo() 或 WP-CLI 输出为准。

项目	建议值 / 检查命令	失败表现
PHP 版本	PHP 8.2 或 8.3；/www/server/php/83/bin/php -v	插件致命错误、后台白屏、composer 包不兼容
数据库扩展	mysqli、pdo_mysql；php -m | grep mysqli	建立数据库连接时出错
字符与文本	mbstring、xml、dom、intl	中文截断、导入失败、REST/XML 解析异常
网络与更新	curl、openssl、zip、fileinfo	无法安装插件、无法连接官方 API、升级包解压失败
图片处理	gd 或 imagick、exif	缩略图不生成、媒体库报错、图片方向错误
性能与缓存	opcache、可选 redis	响应慢、对象缓存插件无法连接
上传与执行	upload_max_filesize=64M、post_max_size=64M、memory_limit=256M、max_execution_time=120	大图上传失败、导入中断、后台 500

在宝塔 PHP「配置修改」里调整上述参数后重载 PHP-FPM。也可以直接检查对应 ini：

/www/server/php/83/bin/php -i | grep -E 'upload_max_filesize|post_max_size|memory_limit|max_execution_time'
/www/server/php/83/bin/php -m | grep -E 'mysqli|curl|mbstring|xml|zip|gd|imagick|intl|exif|opcache|fileinfo'

# WP-CLI 使用站点同一 PHP 版本
php --version
wp core version --allow-root
wp plugin list --allow-root | head -20

为什么切换版本后仍报扩展缺失

常见原因有三个：第一，宝塔里装到了 PHP 8.2，但站点切到了 PHP 8.3；第二，CLI 用的是系统 /usr/bin/php，站点用的是 /www/server/php/83/bin/php；第三，修改 ini 后只 reload 了 Nginx，没有重启 PHP-FPM。处理顺序是：在站点设置确认版本 → 在对应 PHP 设置安装扩展 → 重启 PHP-FPM → 用站点根目录临时 phpinfo 或 wp eval 'echo PHP_VERSION;' 验证 → 删除临时文件。

对需要长期维护的企业站，部署完成还应把 PHP 版本、扩展、ini 参数、composer 约束写进交付文档。我们的 WordPress 企业网站开发 通常会把这部分和发布脚本、备份策略一起交付，后续换服务器或扩容时能按同一基线复现，而不是靠面板截图猜配置。

验证与回退

验证：后台「工具 → 站点健康 → 信息 → 服务器」查看 PHP 版本、内存限制、上传限制；执行 wp core update --dry-run、wp plugin install wordpress-seo --dry-run 之类只读或预演命令；上传一个 20MB 附件；触发图片缩略图生成；查看 PHP error log 是否有 Call to undefined function。回退：在宝塔把站点 PHP 版本切回原版本，恢复 /www/server/php/<version>/etc/php.ini 备份，重启对应 PHP-FPM；若插件已自动升级导致不兼容，用备份包恢复插件目录并用 SQL 备份回滚数据库。

验证流程：上线前按状态码、日志、写入能力验收

验收不要只看首页截图。把下面动作做成上线工单，逐项记录结果、操作人、时间、回退点。若项目还涉及 SEO 迁移或改版，可配合 2026年修复后怎么验证：验收标准与服务商对比 检查跳转、索引与结构化数据，避免部署层面正确但URL策略出错。

• HTTP 验收：curl -I 检查首页、文章页、分类页、后台、REST API、静态资源、404 页面；确认 HTTPS 跳转只有一跳，固定链接无 404。
• 写入验收：后台上传图片、安装插件、更新主题、保存固定链接、清空缓存；确认没有要求 FTP 凭据，没有出现 Unable to create directory wp-content/uploads。
• 权限验收：抽样 stat 目录与文件；确认无 777；确认 wp-config.php 不可被 Web 直接下载；确认 uploads 下 PHP 被拒绝执行。
• PHP 验收：站点健康页、phpinfo 临时文件、WP-CLI、PHP-FPM 日志四方一致；确认 opcache 开启且部署后有清理或重启策略。
• 日志验收：查看 /www/wwwlogs/example.com_error.log、/www/wwwlogs/example.com.log、PHP-FPM error log、宝塔「安全」告警；连续刷新 10 次无新增 500/403。
• 性能验收：关闭页面缓存与开启页面缓存各测一次 TTFB；确认 Nginx 静态资源直接命中，PHP 请求没有被静态规则误吞。

推荐把核心验收命令保存为脚本，便于 2026 年每次发布重复执行：

#!/usr/bin/env bash
set -euo pipefail
DOMAIN='example.com'
ROOT='/www/wwwroot/example.com'

nginx -t
cd "$ROOT"
wp core verify-checksums
wp option get siteurl
wp option get home
wp rewrite flush --hard
wp cache flush

for path in '/' '/sample-post/' '/wp-admin/' '/wp-json/wp/v2/posts' '/wp-content/uploads/'; do
  code=$(curl -L -s -o /dev/null -w '%{http_code}' "https://$DOMAIN$path")
  echo "$path -> $code"
done

find "$ROOT" -type d -perm /002 -print | head -20
find "$ROOT" -type f -perm /002 -print | head -20
tail -n 50 "/www/wwwlogs/$DOMAIN"_error.log

回滚：按配置、代码、数据库三层恢复

回滚原则是先恢复可解释的最小变更，不要一上来全量覆盖。若只是伪静态或运行目录改错，恢复 vhost 即可；若上传了新主题/插件导致 PHP fatal，先切回旧目录；若执行了数据库迁移或批量替换域名，才使用 SQL 备份。每次回滚后重复验证流程中的 HTTP、写入、日志三项。

配置层回滚

在宝塔伪静态框恢复上一次文本，或执行 cp /root/example.com.conf.bak /www/server/panel/vhost/nginx/example.com.conf，然后 nginx -t && nginx -s reload。若面板自动生成了额外 include 文件，检查 /www/server/panel/vhost/rewrite/ 下对应域名规则，避免只恢复主 conf 却遗漏 rewrite 文件。

代码层回滚

把当前目录改名保留现场，再解压备份包到原路径，最后重跑属主与权限命令：

cd /www/wwwroot
mv example.com example.com.broken-2026
tar -xzf /root/backup-example-com-2026.tar.gz
chown -R www:www example.com
find example.com -type d -exec chmod 755 {} ;
find example.com -type f -exec chmod 644 {} ;
nginx -t && nginx -s reload

数据库层回滚

先在宝塔创建新库 example_com_rollback 导入 SQL，确认应用指向测试库可正常读取，再决定是否覆盖生产库。生产库覆盖前必须再导出一次当前数据，避免把回滚之后产生的订单、表单、评论丢掉。命令示例：

mysql -u <db_user> -p -e 'CREATE DATABASE example_com_rollback CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;'
mysql -u <db_user> -p example_com_rollback < /root/example-com-2026.sql
# 确认无误后再改 wp-config.php 的 DB_NAME，或按变更窗口覆盖原库

若回滚涉及 URL、表前缀、序列化数据，不要手工 SQL 替换字符串；使用 wp search-replace 'https://old.example.com' 'https://example.com' --all-tables --dry-run 先预演，去掉 --dry-run 后再执行，并保留导出的 SQL。WordPress 官方对 Changing The Site URL 也有说明，适合与 WP-CLI 方案交叉核对。

常见问题

宝塔部署 WordPress 时，运行目录设成 /public 后后台一直 404，怎么办？

先确认 /public 里是否真的存在 index.php、wp-admin、wp-content；再检查 vhost 的 root 是否为 /www/wwwroot/example.com/public，且 try_files 没有额外拼接 /public。最后用 wp option get siteurl 与 wp option get home 校准 URL，执行 wp rewrite flush --hard。仍失败就恢复运行目录为 / 并把代码上移到站点根目录。

目录 755 / 文件 644 已经设置，为什么后台更新插件仍提示无法创建目录？

多数是属主不对，而不是权限数字不对。用 ps -eo user,group,cmd | grep 'php-fpm: pool' 查运行用户，再 chown -R www:www wp-content。若服务器启用 SELinux，还需检查上下文；若挂载为只读或 open_basedir 限制，日志会出现不同错误。不要改成 777，先按日志定位。

伪静态保存后全站 500 或下载 PHP 文件，优先回退哪一步？

先在宝塔伪静态框恢复上一次规则并重载 Nginx；若仍异常，恢复 /root/example.com.conf.bak。下载 PHP 文件通常说明 location ~ .php$ 或 fastcgi_pass 被覆盖、PHP-FPM socket 路径失效；用 nginx -t 与 ls -l /tmp/php-cgi-*.sock 检查，再按站点 PHP 版本修正 socket。

上线动作清单

• 导出整站 tar、数据库 SQL、Nginx vhost、伪静态文本、权限基线各一份，文件名带 2026 与时间戳，保存到服务器之外。
• 在宝塔固定「网站目录 / 运行目录 / PHP版本」三项，写入交付文档；禁止上线当天临时切换运行目录。
• 每次发布脚本末尾执行 chown、目录 755、文件 644、wp-config.php 640、wp cache flush 与 wp rewrite flush --hard。
• 把 curl 状态码、后台上传、插件更新、REST API、错误日志 tail 做成验收表，任何 403/404/500 未清零不切 DNS。
• 为 PHP 8.2/8.3 建立扩展与 ini 基线，预发布环境先跑主题、插件、WooCommerce、表单、支付回调，再切生产。

需要把部署、验收与长期维护交给同一团队？查看 WordPress 企业网站开发 或 服务页，获取可落地的 LNMP 交付方案。

参考资料与延伸阅读

• WordPress 开发者文档
• WordPress 主题开发手册
• WordPress 插件开发手册