WordPress外贸站接入CDN后如何验收？香港服务器部署检查与回源验证

验收 WordPress 外贸站接入 CDN，不能只看 CDN 控制台显示“已连接”。真正达到上线条件，至少要同时确认四件事：香港服务器上的 WordPress、Nginx、PHP-FPM 和数据库运行正常；域名解析已经指向 CDN；CDN 能通过正确的域名和协议回源；静态资源缓存、动态页面、登录后台和表单等功能没有被缓存规则破坏。

如果把这次工作视为“香港服务器WordPress外贸站部署教程：从环境搭建到CDN加速完整步骤”的最后环节，验收应当以浏览器、DNS 查询、HTTP 响应头、服务器日志和回滚结果为依据，而不是以某个配置开关的状态为依据。下面以 www.example.com 为示例域名，香港服务器公网地址使用 203.0.113.10 作为占位符，实际操作时请替换为自己的信息。

一、先确定验收目标和前置条件

1. 验收通过应看到什么结果

HIT、MISS、Age、X-Cache 等响应头名称由 CDN 平台决定，并不是所有平台都会提供同样的字段。验收时应先确认该平台使用哪一种命中标识。

2. 准备好测试条件

开始切换之前，至少准备以下内容：

• 正式域名及所有需要验收的主机名，例如根域名、www、图片或静态资源子域名。
• 香港服务器公网 IP、SSH 登录方式、站点根目录和当前 Nginx 配置文件路径。
• CDN 分配的 CNAME 或接入记录、回源地址、回源协议和 Host 头配置。
• WordPress 管理员账号，以及一个普通未登录浏览器窗口。
• 当前 DNS 记录截图或导出文件、Nginx 配置备份、WordPress 数据库和网站文件备份。
• 一台不受浏览器缓存影响的测试终端，最好同时使用命令行 curl。
• 一个可执行回滚的时间窗口。切换 DNS 前，可将 DNS TTL 临时调低到约 300 秒，但已经被其他 DNS 服务器缓存的记录不会立即失效。

不要在未备份的情况下直接修改数据库、删除 DNS 记录、覆盖 Nginx 配置或收紧防火墙。尤其是 CDN 回源白名单和防火墙规则，配置错误可能导致 CDN 与管理员本人都无法访问源站。

二、检查香港服务器上的 WordPress 环境

CDN 只负责请求分发、缓存和回源，不能替代源站的运行环境。先绕开 CDN 检查源站，能够避免把 PHP 错误、Nginx 配置错误误判为 CDN 故障。

1. 核对系统和服务状态

以下命令适合常见的 Debian 或 Ubuntu 环境。不同发行版的服务名称可能不同，先用查询命令确认，不要直接套用不存在的 PHP-FPM 版本号。

cat /etc/os-release
nginx -v
php -v
mariadb --version
sudo systemctl is-active nginx
sudo systemctl list-units --type=service | grep -E 'php.*fpm|mariadb|mysql'

如果 PHP-FPM 服务未运行，先确认实际服务名称，再检查状态：

sudo systemctl status php8.2-fpm --no-pager
sudo systemctl status mariadb --no-pager

php8.2-fpm 只是示例，实际环境可能是 php8.1-fpm、php8.3-fpm 或其他名称。Nginx 使用的 PHP-FPM Socket 也必须与实际版本一致：

sudo find /run/php -maxdepth 1 -type s -name 'php*-fpm.sock' -print

如果找不到 Socket，先修复 PHP-FPM，不要通过修改 CDN 回源规则来掩盖源站故障。

2. 确认 WordPress 域名没有指向内部地址

在 WordPress 后台的“设置”中检查站点地址和 WordPress 地址。两者通常都应保持为正式 HTTPS 域名，例如：

https://www.example.com

不要让站点地址指向：

• 香港服务器 IP；
• 临时测试域名；
• CDN 分配的内部回源域名；
• 另一个会再次跳转的 HTTP 地址。

如果后台打不开，可先从数据库备份或 WP-CLI 读取当前配置。使用 WP-CLI 修改 home、siteurl 属于数据库写操作，执行前必须备份，并确认命令运行在正确的网站目录：

cd /var/www/example.com
wp option get home
wp option get siteurl

只有在确认域名配置确实错误且已经备份时，才执行类似更新操作：

cd /var/www/example.com
wp option update home 'https://www.example.com'
wp option update siteurl 'https://www.example.com'

站点实际路径和运行用户可能不同，不能把 /var/www/example.com 和命令执行用户直接照搬到生产环境。

3. 检查源站 Nginx 的基础路由

WordPress 的基本 Nginx 路由需要将不存在的静态文件交给 index.php，PHP 请求再交给正确的 PHP-FPM Socket。下面是一个简化示例，适合用于核对思路，不代表所有系统的完整配置：

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.php index.html;

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

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HTTPS $https if_not_empty;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

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

实际使用前检查三项：

1. root 是否是当前 WordPress 文件目录；
2. fastcgi_pass 是否对应 find /run/php 查到的 Socket；
3. server_name 是否包含用户访问的正式域名。

查看 Nginx 最终加载的配置，而不是只查看某个未生效的站点文件：

sudo nginx -T

修改配置前先备份，检查通过后再平滑加载：

sudo cp /etc/nginx/sites-available/example.com \
  /etc/nginx/sites-available/example.com.bak.$(date +%F-%H%M)

sudo nginx -t
sudo systemctl reload nginx

reload 通常不会中断已有连接，但配置错误会导致新配置无法加载。若 nginx -t 失败，应恢复备份文件或修正语法后再操作，不要强行重启服务。

三、先绕过 CDN 验证香港源站

1. 使用 --resolve 直接访问源站

在测试终端执行以下命令，可以让指定域名在 HTTPS 请求中解析到香港源站 IP，同时保留正式域名的 Host 和 SNI：

curl --resolve www.example.com:443:203.0.113.10 \
  -sS -D - -o /dev/null \
  https://www.example.com/

重点观察：

• HTTP 状态码是否为预期的 200、301 或 302；
• Location 是否跳转到正确的 HTTPS 正式域名；
• 是否出现跳转到源站 IP、临时域名或错误主机名；
• server、content-type、content-length 等响应信息是否合理。

如果源站暂时只监听 HTTP，可先用 HTTP 检查路由，但正式 CDN 回源建议使用 HTTPS：

curl --resolve www.example.com:80:203.0.113.10 \
  -sS -D - -o /dev/null \
  http://www.example.com/

若源站防火墙只允许 CDN 地址访问，测试终端直接访问可能得到 403 或连接超时。这时不要盲目关闭防火墙，可以临时从允许的管理网络测试，或在确认管理来源 IP 后增加临时规则。防火墙调整前要保存现有规则，并保留 SSH 管理通道。

2. 分别测量源站响应时间

可以用 curl 记录 DNS、TCP、TLS、首字节和总耗时：

curl --resolve www.example.com:443:203.0.113.10 \
  -sS -o /dev/null \
  -w 'code=%{http_code}\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nttfb=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  https://www.example.com/

这组数据用于建立源站基线，不应被当成固定的行业合格线。测试机位置、页面大小、PHP 执行时间、数据库缓存和当前访问量都会影响结果。后面测试 CDN 时，应尽量使用同一台终端、同一个 URL 和相近的时间进行对比。

如果源站直连的 TTFB 已经很高，先检查 PHP、数据库、插件和服务器资源；CDN 只能减少一部分静态资源和缓存页面请求，不能替源站处理缓慢的动态请求。

四、配置 CDN 接入和回源参数

1. 设置 DNS 时同时检查 A、AAAA 和 CNAME

切换前先保存当前记录，并查询所有相关类型：

dig example.com A +short
dig example.com AAAA +short
dig www.example.com A +short
dig www.example.com AAAA +short
dig www.example.com CNAME +short

验收时要特别注意 IPv6 的 AAAA 记录。如果 A 已指向 CDN，但 AAAA 仍指向香港源站，支持 IPv6 的访问者可能绕过 CDN；如果 AAAA 指向旧服务器，还可能出现部分地区正常、部分地区异常的情况。

根域名是否能使用 CNAME 取决于 DNS 服务商和 CDN 提供的接入方式。不要在根域名位置盲目添加 CNAME，应按照平台提供的记录类型使用 A、CNAME、ALIAS 或等效方式。www、根域名和其他业务子域名要分别验收，不能只测试其中一个。

2. 核对回源协议、Host 和 SNI

CDN 回源配置至少需要确认：

• 回源地址是香港服务器公网 IP 或正确的源站域名；
• 回源协议与源站监听方式一致；
• 回源 Host 保留为正式域名；
• HTTPS 回源时，源站证书覆盖该 Host；
• CDN 到源站的端口与 Nginx 监听端口一致。

推荐优先使用 HTTPS 回源。若 CDN 访问者使用 HTTPS，但 CDN 到源站使用 HTTP，可能出现以下问题：

• WordPress 生成 HTTP 资源链接；
• 源站根据 X-Forwarded-Proto 判断错误，形成 HTTPS 重定向循环；
• Cookie 的 Secure 属性和站点实际协议不一致；
• 页面出现混合内容。

不要直接信任任意客户端传入的 X-Forwarded-Proto。如果必须由 CDN 传递协议头，应按照 CDN 的源站 IP 范围限制可信来源，并结合平台文档配置。

3. 先采用保守的缓存规则

第一次接入时，建议先只缓存静态资源，确认网站功能正常后，再考虑缓存匿名 HTML 页面。典型静态扩展名包括：

.css .js .jpg .jpeg .png .gif .svg .webp .ico .woff .woff2

以下路径通常应设置为绕过缓存或不参与页面缓存：

/wp-admin/
/wp-login.php
/wp-cron.php
/wp-json/
/wp-comments-post.php

同时应对带有登录态 Cookie 的请求绕过页面缓存，常见 Cookie 名称包括 wordpress_logged_in_、wordpress_sec_ 和评论相关 Cookie。不同 WordPress 插件可能使用自己的会话 Cookie，电商、会员、报价或表单功能尤其需要逐项确认。

源站可以为静态资源提供基础缓存头。例如：

location ~* \.(css|js|jpg|jpeg|png|gif|svg|webp|ico|woff|woff2)$ {
    try_files $uri =404;
    expires 7d;
    add_header Cache-Control "public, max-age=604800";
}

这段配置修改前要备份，并执行：

sudo nginx -t
sudo systemctl reload nginx

如果主题或插件更新后文件名不变，七天缓存可能让访客继续看到旧文件。更稳妥的做法是让构建系统、主题或插件使用带版本号的资源 URL；临时更新时则在 CDN 控制台执行精准刷新，避免直接清空全部缓存。

五、验证 CDN 是否真正回源

1. 先检查公网 DNS 结果

DNS 生效后再次查询：

dig www.example.com A +short
dig www.example.com AAAA +short
dig www.example.com CNAME +short

返回结果应符合 CDN 的接入设计。很多 CDN 会返回多个边缘节点地址，因此不同时间、不同网络查询到的 IP 可能不同。验收重点不是某一个固定 IP，而是是否已经不再直接暴露旧源站记录、是否存在 IPv4 和 IPv6 分流不一致。

2. 查看 CDN 返回的响应头

使用正常的 HTTPS 请求：

curl -sS -D - -o /dev/null https://www.example.com/

再重复执行一次相同请求：

curl -sS -D - -o /dev/null https://www.example.com/

对静态文件也执行两次：

curl -sS -D - -o /dev/null \
  https://www.example.com/wp-content/themes/example/assets/site.css

curl -sS -D - -o /dev/null \
  https://www.example.com/wp-content/themes/example/assets/site.css

关注以下类型的结果：

• CDN 特有的缓存状态从 MISS 变为 HIT；
• Age 在第二次请求后出现或增大；
• X-Cache、Via 或等效字段显示请求经过缓存节点；
• Cache-Control 与配置规则一致；
• Content-Encoding、Content-Type 和状态码没有异常。

如果每次都是 MISS，不应立即判断 CDN 无效。可能原因包括资源带有不同查询参数、响应设置了 private 或 no-store、请求带有绕过缓存的 Cookie、CDN 配置了短 TTL，或者刚刚执行过刷新。应先固定同一个 URL，关闭浏览器缓存，再从响应头和 CDN 规则逐项核对。

3. 用源站日志确认回源

在香港服务器上查看 Nginx 访问日志：

sudo tail -f /var/log/nginx/access.log

如果站点使用独立日志文件，应先从 Nginx 配置中的 access_log 项确认实际路径。然后从测试终端请求一个静态文件和一个页面，观察源站是否产生新日志。

判断逻辑如下：

• 第一次访问静态资源时源站出现请求，随后重复访问不再出现，通常符合缓存命中预期；
• 每次访问都到达源站，说明没有命中、缓存规则绕过，或该响应本身不适合缓存；
• CDN 页面返回成功但源站完全没有请求，可能是边缘已有缓存，也可能请求没有经过当前这台服务器，需要结合 CDN 回源日志核对；
• 日志出现大量 499、502、504，应转向检查源站连接、PHP-FPM 和超时配置。

4. 使用临时回源探针进行明确验证

如果仅看访问日志仍无法确认请求是否到达指定香港服务器，可以临时增加一个不含敏感信息的探针路径。修改前备份 Nginx 配置：

location = /__origin-check {
    default_type text/plain;
    add_header Cache-Control "no-store, no-cache, must-revalidate" always;
    add_header X-Origin-Node "hk-origin-check" always;
    return 200 "origin-ok\n";
}

检查并加载：

sudo nginx -t
sudo systemctl reload nginx

先直连源站：

curl --resolve www.example.com:443:203.0.113.10 \
  -sS -D - https://www.example.com/__origin-check

再通过正式域名访问：

curl -sS -D - https://www.example.com/__origin-check

如果第二次请求也返回 X-Origin-Node: hk-origin-check，并且 CDN 规则没有缓存该路径，说明请求能够回到这台香港服务器。该探针只能返回固定字符串，不应输出 IP、系统版本、环境变量、数据库状态或任何内部信息。

验证结束后删除这段临时配置，重新检查并加载 Nginx。删除配置属于变更操作，应根据前面保存的备份恢复，不要直接删除整个站点配置文件：

sudo nginx -t
sudo systemctl reload nginx

同时在 CDN 侧确认探针路径已经从测试规则中移除。

六、完成 WordPress 功能和缓存验收

1. 访问路径验收

使用未登录窗口依次测试：

• 首页；
• 至少两篇或两类内容页；
• 图片、CSS、JavaScript 和字体；
• 搜索或站内筛选功能；
• 联系表单、询盘表单或其他提交功能；
• robots.txt；
• XML Sitemap；
• 语言切换或外贸站实际使用的区域页面。

检查浏览器开发者工具的 Network 面板，重点看：

• 是否存在 301、302 循环；
• CSS 和 JavaScript 是否返回 HTML 错误页；
• 图片是否出现跨域、403 或 404；
• 是否存在 HTTP 资源导致混合内容；
• POST 请求是否被 CDN 缓存或改写；
• 表单提交后是否真的到达 WordPress。

robots.txt、Sitemap 和规范链接中的域名应保持正式域名，不能输出源站 IP、临时域名或 CDN 内部域名。

2. 验收登录态和后台

使用管理员账号登录后检查：

• /wp-login.php 可以打开并提交；
• 登录后能进入 /wp-admin/；
• 仪表盘资源正常加载；
• 发布一条测试草稿或修改一个不影响业务的字段；
• 退出登录后，普通访客不会看到管理员专属内容。

登录状态下如果仍返回访客缓存页面，通常是 CDN 没有识别 WordPress 登录 Cookie。此时应优先扩大绕过条件，而不是继续提高缓存时间。后台、登录、评论提交和表单接口的可用性优先级高于页面缓存命中率。

3. 验收内容更新和刷新策略

先修改一个容易识别的内容，例如测试页面标题或一个草稿转公开页面，然后从未登录窗口访问。记录内容何时可见，再执行 CDN 的精准刷新，观察刷新后是否立即变化。

建议形成一条明确规则：

• 静态文件采用带版本号的 URL，或在文件变更后刷新对应目录；
• 首页和重要内容页如启用 HTML 缓存，发布后刷新相关 URL；
• 不确定影响范围时先刷新单个 URL，再考虑目录级刷新；
• 避免频繁执行全站清缓存，因为这会让大量请求同时回源。

七、用可观察指标形成最终验收结果

可以用同一测试终端建立一张简单记录表，不必把某个参考数值当作所有站点的硬性标准。

如果需要记录性能，可以固定测试 5 至 10 个 URL，每个 URL 连续请求两次，分别记录源站直连和 CDN 访问的 TTFB、总耗时、状态码和缓存状态。第二次请求更适合观察缓存效果；首次请求可能包含 DNS、TLS、边缘节点建立连接和源站生成页面的额外开销。

不要把 ping 通不通当成网页是否正常的结论。服务器可能禁用 ICMP，但 HTTPS 完全可用；反过来，ping 正常也不能证明 CDN 已经正确回源。最终应以 DNS、TLS、HTTP 状态、响应头、源站日志和实际业务操作共同判断。

八、常见失败现象和处理顺序

排查时建议由外到内进行，先确认域名和连接，再查看 CDN 规则，最后进入 WordPress 和 PHP 层。

每次只修改一个变量，并在修改后重复同一条 curl 命令或同一组浏览器操作。这样才能判断结果究竟来自 DNS、回源、缓存规则还是 WordPress 本身。

九、失败时的回滚方案

如果 CDN 接入后出现大面积 5xx、登录不可用、表单丢失或内容持续错误，优先恢复可用性，不要在故障期间继续叠加缓存规则。

1. 快速切回源站

回滚顺序可以按以下方式执行：

1. 暂停正在进行的主题、插件和数据库变更。
2. 在 CDN 侧先关闭新增的 HTML 缓存规则，必要时暂停加速或将缓存设为绕过。
3. 将 DNS 记录恢复到切换前的值。根域名、www、静态资源子域名和 IPv6 记录要一起检查。
4. 通过 --resolve 直接验证香港源站的 HTTPS、首页、登录和表单。
5. 等待 DNS 缓存逐步更新，同时保留源站服务，不要立刻关机或删除站点。
6. CDN 和 DNS 状态稳定后，再根据日志定位问题，修复后重新进行小范围接入。

DNS 回滚不会让所有访问者立即切换，因为递归 DNS 可能仍保留旧 TTL。回滚期间应继续保持源站可用，并观察 CDN 和源站两侧日志。

2. 恢复源站 Nginx 配置

如果问题来自新增的缓存头、回源探针或路由配置，应先用备份恢复对应站点文件，再检查语法：

sudo cp /etc/nginx/sites-available/example.com.bak.YYYY-MM-DD-HHMM \
  /etc/nginx/sites-available/example.com

sudo nginx -t
sudo systemctl reload nginx

上面的备份文件名只是示例，请先用 ls -l /etc/nginx/sites-available/ 找到实际文件。不要恢复整个 /etc/nginx 目录，以免覆盖其他站点和证书配置。

3. 处理错误的 WordPress 域名设置

如果误把 WordPress 的 home 或 siteurl 改成了 CDN 内部域名，先确认数据库备份有效，再使用与网站目录和运行环境匹配的 WP-CLI 恢复正式域名：

cd /var/www/example.com
wp option update home 'https://www.example.com'
wp option update siteurl 'https://www.example.com'

修改后清理应用层和 CDN 中与错误域名相关的缓存，并用未登录窗口重新检查规范链接、图片 URL、登录跳转和后台地址。

上线验收清单

• [ ] 已保存切换前的 DNS、CDN、Nginx 和防火墙配置。
• [ ] 香港服务器上的 Nginx、PHP-FPM、数据库运行正常。
• [ ] WordPress 的 home 和 siteurl 使用正式 HTTPS 域名。
• [ ] A、AAAA、CNAME 记录没有留下绕过 CDN 的旧路径。
• [ ] CDN 边缘证书和回源证书均覆盖实际访问域名。
• [ ] CDN 回源协议、端口、Host 和 SNI 已核对。
• [ ] 源站通过 --resolve 访问正常。
• [ ] 正式域名访问首页、内容页和静态资源正常。
• [ ] 静态资源重复请求能看到命中标记或等效缓存证据。
• [ ] /wp-admin/、/wp-login.php、表单和登录 Cookie 不被错误缓存。
• [ ] 内容更新和 CDN 刷新策略已经实际测试。
• [ ] 源站日志能够解释 CDN 命中、回源和绕过缓存的差异。
• [ ] 已准备 DNS 回滚、CDN 规则回滚和 Nginx 配置恢复方案。
• [ ] 验收探针等临时配置已经删除，不再暴露内部测试信息。