香港服务器用于WordPress建站时，正式切换前应先确认两件事：域名解析结果确实指向目标服务器，且Web服务进程对WordPress所需文件具备“能读、必要位置能写”的权限。只要其中一项未验收，就不应直接把生产域名切过去。

验收不能只看DNS管理平台里的记录，也不能只看文件的数字权限。应从权威DNS、递归DNS、目标服务器上的虚拟主机、文件所有者、目录访问链路和实际上传操作几个层面留证，明确什么结果算正常、什么结果需要暂停上线。

一、先确认上线对象和通过条件

在操作前建立一份变更清单，至少记录以下内容：

• 生产域名，例如 example.com。
• www.example.com 是否同时提供访问。
• 当前权威DNS服务器名称。
• 目标服务器的IPv4地址；如果配置了IPv6，还要记录IPv6地址。
• WordPress实际文档根目录，例如 /srv/www/example.com。
• Web服务进程使用的系统用户和用户组。
• 当前解析指向、当前文件所有者与权限。
• 可恢复的旧解析记录、文件备份和权限记录。

上线通过应满足以下条件：

1. 根域名和实际使用的主机名解析到同一套已验收的Web服务。
2. 不存在仍指向旧服务器的过期A记录或AAAA记录。
3. 如果存在AAAA记录，目标服务器确实配置了IPv6监听、防火墙放行和对应虚拟主机。
4. Web服务进程能够读取WordPress入口文件及其父级目录。
5. 只有确有必要的目录允许Web服务写入，WordPress整个目录不能因为方便排错而设置为全员可写。
6. 通过实际HTTP请求和一次低风险写入测试，而不是仅凭目录列表判断权限正确。

域名切换影响的是访问入口，权限调整影响的是应用运行和文件安全。两者应分开实施，先完成目标服务器本地验证，再修改公共DNS。

二、现状核对：先查清DNS和实际文件路径

1. 确认权威DNS和现有记录

以下命令以常见GNU/Linux环境为例，域名请替换为实际值：

DOMAIN=example.com

dig NS "$DOMAIN" +short
dig A "$DOMAIN" +short
dig AAAA "$DOMAIN" +short
dig A "www.$DOMAIN" +short
dig AAAA "www.$DOMAIN" +short
dig CNAME "www.$DOMAIN" +short

判断时不要只看某一条记录：

根域名是否使用A、AAAA或DNS服务商提供的别名记录，要以当前DNS服务商支持的记录类型为准。不要为了追求记录数量少而随意删除现有记录，也不要在没有确认IPv6可用性的情况下保留AAAA记录。

可以先从查询结果中找到权威NS，再直接向权威服务器查询，排除递归缓存干扰：

DOMAIN=example.com
AUTH_NS=ns1.example-dns.net

dig @"$AUTH_NS" A "$DOMAIN" +noall +answer
dig @"$AUTH_NS" AAAA "$DOMAIN" +noall +answer
dig @"$AUTH_NS" A "www.$DOMAIN" +noall +answer
dig @"$AUTH_NS" CNAME "www.$DOMAIN" +noall +answer

AUTH_NS只是示例，应替换为前一步实际查到的权威服务器。权威查询结果正确、公共递归查询仍未更新，通常属于缓存尚未刷新；权威查询本身错误，则不能把问题归因于传播时间。

2. 确认目标服务器上的真实文档根目录

WordPress目录不一定就是部署人员记忆中的路径，尤其是使用软链接、多个站点或多套虚拟主机时。上线前应从Web服务配置中确认实际路径，并检查软链接最终位置：

DOCROOT=/srv/www/example.com

readlink -f "$DOCROOT"
namei -l "$DOCROOT"
stat -c '%A %a %U:%G %n' "$DOCROOT"

如果使用Nginx、Apache或其他Web服务，应查看对应虚拟主机配置中的站点根目录、域名匹配项和PHP处理配置。不能只检查默认站点目录，因为域名解析正确但虚拟主机匹配错误时，用户仍可能看到默认页面。

同时确认Web服务进程用户。不同发行版和部署方式可能使用不同用户组，不能直接假定一定是某个固定账号：

ps -eo user,group,comm,args | grep -E '[n]ginx|[a]pache|[p]hp-fpm'

如果PHP由独立的PHP-FPM池运行，应继续查看对应池配置中的运行用户和用户组。后续的读写测试必须以实际处理PHP请求的用户进行，而不是以当前登录的管理员账号进行。

三、变更准备：备份文件、数据库和权限状态

权限调整前至少保留三类恢复信息：

• WordPress程序、主题、插件、上传文件的备份。
• 与当前站点对应的数据库备份，并确认备份可以恢复。
• 文件所有者、用户组、模式位和ACL记录。

文件备份不等于数据库备份。只归档WordPress目录，无法恢复文章、页面、用户和部分插件配置；数据库备份也不能替代上传目录和配置文件备份。

在确认备份位置有足够空间、权限正确且不会被站点进程覆盖后，可以记录文件和ACL状态：

DOCROOT=/srv/www/example.com
BACKUP_DIR=/srv/backup/example.com

sudo mkdir -p "$BACKUP_DIR"
sudo tar --acls --xattrs -czf "$BACKUP_DIR/files-before-permission-change.tar.gz" "$DOCROOT"
sudo find "$DOCROOT" -xdev -printf '%M %u:%g %p\n' > "$BACKUP_DIR/permissions-before.txt"

如果系统安装了getfacl，还应额外保存ACL：

sudo getfacl -R "$DOCROOT" > "$BACKUP_DIR/acl-before.txt"

备份文件可能包含wp-config.php中的数据库凭据，应限制备份目录访问权限。若备份未完成、无法读取或没有验证恢复路径，不应继续做批量权限修改。

四、文件权限验收：区分可读、可执行和可写

1. 目录和文件的基本判断

Linux文件权限中，目录的执行权限表示能否进入和遍历目录，文件的读权限决定能否读取内容。即使目标文件本身是可读的，只要它上级目录缺少遍历权限，Web服务仍然无法访问。

常见的基础策略是：

• 目录通常采用所有者可读写执行、其他用户可读和执行的权限，例如755。
• 普通程序文件通常采用644。
• wp-config.php应比普通程序文件更严格，例如在Web服务用户可通过用户组读取时使用640，或者由Web服务用户直接拥有时使用600。
• wp-content/uploads等确需由WordPress写入的目录，才授予对应Web服务用户或用户组写权限。
• 备份文件、部署密钥和站点外部配置不应放在可被Web直接访问的位置。

这些数字不是脱离环境的硬性标准。实际通过条件是：权限满足既定部署模型，没有无关账号写权限，Web服务实际请求能够成功。若使用ACL、安全增强模块或容器挂载，还要同时检查这些控制层。

可以先找出明显的全员可写对象：

DOCROOT=/srv/www/example.com

sudo find "$DOCROOT" -xdev -type d -perm -0002 -print
sudo find "$DOCROOT" -xdev -type f -perm -0002 -print
sudo find "$DOCROOT" -xdev -type f -perm /0222 -print

结果解释如下：

• 普通WordPress程序目录或PHP文件出现在全员可写列表中，属于高风险，应暂停并重新确认权限策略。
• 上传目录出现在列表中不一定代表错误，但必须确认写权限只服务于该目录，且没有扩大到整个站点。
• 没有发现异常不代表权限一定可用，还要用实际Web服务用户测试读取和写入。

2. 检查关键路径和ACL

对入口文件、配置文件和上传目录进行针对性检查：

DOCROOT=/srv/www/example.com

namei -l "$DOCROOT/index.php"
namei -l "$DOCROOT/wp-config.php"
namei -l "$DOCROOT/wp-content/uploads"

stat -c '%A %a %U:%G %n' \
  "$DOCROOT/index.php" \
  "$DOCROOT/wp-config.php" \
  "$DOCROOT/wp-content/uploads"

如果系统启用了ACL，普通的ls -l可能无法完整反映实际授权，应检查：

sudo getfacl "$DOCROOT/wp-config.php"
sudo getfacl "$DOCROOT/wp-content/uploads"

如果系统启用了SELinux等安全机制，还要查看文件安全上下文和相关日志。此类机制可能导致文件模式看起来正常，但PHP进程仍无法写入。不要为了快速排错而直接关闭安全机制，应先确认具体拒绝对象和策略。

3. 用实际Web服务用户验证读写

先以实际Web服务用户测试读取入口文件和配置文件：

DOCROOT=/srv/www/example.com
WEBUSER=实际的Web服务用户

sudo -u "$WEBUSER" test -r "$DOCROOT/index.php"
sudo -u "$WEBUSER" test -r "$DOCROOT/wp-config.php"
sudo -u "$WEBUSER" test -x "$DOCROOT"
sudo -u "$WEBUSER" test -x "$DOCROOT/wp-content/uploads"

命令返回成功，只说明当前用户具备相应权限；如果失败，应检查父级目录、所有者、用户组、ACL和安全模块，而不是立即执行chmod -R 777。

对确实需要写入的上传目录，可在该目录中创建一个明确命名的临时文件，再立即清理：

sudo -u "$WEBUSER" sh -c 'set -eu
f="/srv/www/example.com/wp-content/uploads/.permission-check"
printf "%s\n" "permission-check" > "$f"
test -s "$f"
rm -f -- "$f"
'

执行前必须把路径改成实际上传目录，并确认该文件名不会覆盖现有文件。这个测试只应在专门的测试目录或明确的临时文件名上进行，不要在站点根目录执行任意写入测试。

正常与异常的分界可以按下表判断：

五、需要调整权限时，先做最小范围变更

权限变更属于可能影响生产服务的操作。执行前应确认备份可用、站点是否仍有上传或发布任务、目标用户组是否真实存在，并记录原始权限用于回滚。

不要在没有核对用户组的情况下直接执行递归chown，也不要把整个WordPress目录递归设置为Web服务用户所有。这样可能导致部署账号失去更新能力，也会扩大应用被入侵后的可写范围。

如果已经确认目录结构、Web服务用户和权限策略，可以采用“普通目录和文件按策略收敛、可写目录单独处理”的方式。下面仅为操作形式示例，变量必须替换为已核对的实际值：

DOCROOT=/srv/www/example.com

sudo find "$DOCROOT" -xdev -type d -exec chmod 755 {} +
sudo find "$DOCROOT" -xdev -type f -exec chmod 644 {} +
sudo chmod 640 "$DOCROOT/wp-config.php"

这组命令会影响站点下大量文件，不能在未备份、未确认特殊脚本需求或未记录原权限的情况下执行。某些部署方式需要脚本执行位、组继承位或专用ACL，不能机械套用755和644。

对于上传目录，应根据实际运行用户选择所有者、用户组或ACL方案。修改后立即重新执行读写测试，并通过WordPress后台进行一次低风险媒体上传验证。若上传、缓存生成或插件更新依赖其他目录，也应逐项确认其写入需求，不能因为一个目录失败就把整个站点放开写权限。

六、分步实施：先本机验收，再切换域名

1. 先绕过公共DNS验证目标服务器

在修改公共解析前，可以使用curl --resolve让测试请求直接访问目标服务器，同时保留真实域名和Host信息：

DOMAIN=example.com
SERVER_IP=替换为目标服务器IPv4

curl -sS -D - -o /dev/null \
  --resolve "$DOMAIN:80:$SERVER_IP" \
  "http://$DOMAIN/"

curl -sS -D - -o /dev/null \
  --resolve "$DOMAIN:443:$SERVER_IP" \
  "https://$DOMAIN/"

这一步用于验证虚拟主机匹配、HTTP响应和HTTPS站点配置。若HTTPS证书尚未部署，测试可能因证书校验失败；不要把忽略证书校验当作上线通过条件，应先确认域名、证书和虚拟主机配置一致。

检查响应时关注：

• 是否命中WordPress目标站点，而不是默认站点。
• 是否出现异常的多次重定向。
• 是否返回持续的4xx或5xx。
• HTTPS访问是否使用正确域名和证书。
• Web服务错误日志和PHP日志是否在请求时出现权限拒绝。

2. 再修改权威DNS

确认本机验证通过后，再在权威DNS中按最小范围修改根域名和www记录。不要同时删除大量无关记录，也不要在未确认AAAA用途时随意增删IPv6记录。

修改后立即分别查询权威DNS和递归DNS：

DOMAIN=example.com
AUTH_NS=ns1.example-dns.net

dig @"$AUTH_NS" A "$DOMAIN" +noall +answer
dig @"$AUTH_NS" AAAA "$DOMAIN" +noall +answer
dig @"$AUTH_NS" A "www.$DOMAIN" +noall +answer

dig A "$DOMAIN" +noall +answer
dig A "www.$DOMAIN" +noall +answer

如果权威查询已经返回新地址，而递归查询仍返回旧地址，通常是缓存尚未更新；如果权威查询没有变化，应检查是否修改了错误的DNS区域、错误的记录名或非权威平台。

3. 通过真实访问验证WordPress功能

解析逐步更新后，从不同网络环境访问根域名和www域名，至少验证：

• 首页和一篇已有内容可以正常打开。
• 登录页能够返回预期状态。
• 静态资源路径不出现大量404。
• 后台媒体上传能够写入指定上传目录。
• 新上传文件能够被Web服务读取。
• 页面访问期间没有持续的PHP权限错误或服务器错误。

媒体写入测试完成后，应删除测试媒体并确认删除动作只针对测试对象。若只是首页正常而上传失败，不应宣布上线完全通过，因为这通常说明文件权限、用户组、ACL或磁盘路径仍未满足应用要求。

七、验证观察与证据留存

建议将以下材料按变更时间保存：

• 变更前后的NS、A、AAAA、CNAME查询结果。
• 权威DNS和递归DNS的查询时间。
• 目标服务器IPv4、IPv6和虚拟主机验证结果。
• namei、stat、find和ACL检查输出。
• 权限调整前的文件归档、权限清单和ACL备份。
• 实际Web服务用户的读写测试结果。
• 首页、后台登录、媒体上传和日志检查结果。
• 变更操作人、变更时间、旧值与新值。

观察窗口应以变更前DNS记录的TTL和实际缓存情况为参考，至少覆盖一个完整缓存周期；如果无法确认递归缓存范围，应延长观察，不宜用固定的几分钟判断切换完成。观察期间重点关注根域名、www域名、IPv4与IPv6访问是否表现一致，以及上传、登录和后台操作是否出现间歇性错误。

八、明确回滚条件

出现以下情况之一，应暂停继续调整并评估回滚：

• 权威DNS返回错误地址、解析为空或出现持续SERVFAIL。
• 根域名和www分别命中不同站点，且不是预期架构。
• 目标服务器返回默认站点、持续5xx或明显的重定向循环。
• AAAA访问失败，而该记录无法在短时间内修正。
• WordPress程序文件无法读取，或后台媒体持续无法写入。
• 权限调整后部署流程、缓存生成或其他既定功能受到影响。
• 发现无法解释的ACL、安全策略拒绝或文件被异常覆盖。

回滚DNS时，应把记录恢复为已保存的旧值，而不是直接删除记录。恢复后分别查询权威DNS和递归DNS，并保留回滚时间与结果。回滚文件权限时，应依据变更前的权限清单、ACL备份和文件备份恢复，不要凭记忆重新执行一组递归命令。

如果只是个别递归DNS仍缓存旧地址，而权威记录、目标服务器和功能验证均正常，不应因缓存差异立即反复修改DNS；应先区分缓存延迟与真实配置错误。只有当错误访问持续超出既定观察窗口，或出现服务不可用、数据写入异常和权限风险时，才触发DNS或文件权限回滚。