跨境电商独立站如何部署在香港服务器？从域名解析到支付网关验收

将跨境电商独立站部署在香港服务器上，建议采用一套边界清晰、便于验收和回滚的环境：Ubuntu Server 24.04 LTS、Nginx、PHP 8.3-FPM、MariaDB 10.11，以及以 WordPress + WooCommerce 为例的商城应用。上线链路依次包括服务器初始化、域名解析、Web 服务与数据库配置、HTTPS 证书、商城安装、支付插件配置、回调验收和故障回滚。

以下示例以 shop.example.com 为站点域名，以 203.0.113.10 为香港服务器公网 IPv4 地址。示例配置中的域名、IP、数据库密码、支付网关地址和商户参数都需要替换为实际值。示例资源规格为 2 vCPU、4 GB 内存、50 GB SSD，适合作为小型或初期业务的参考起点，实际容量还要根据商品数量、访问峰值、订单量和图片资源规模评估。

一、明确上线目标与前置条件

1. 目标环境

如果实际使用的是其他商城程序，仍可以沿用域名、Nginx、PHP、数据库、证书和支付回调的部署顺序，但 PHP 版本、数据库版本和目录结构必须以该程序及支付插件的兼容矩阵为准，不要直接照搬示例版本。

2. 上线前必须具备的条件

• 香港服务器已经分配公网 IPv4 地址，并且可以通过 SSH 登录。
• 域名管理权限可用，可以新增或修改 A、AAAA、CNAME 等记录。
• 已确认域名不再指向旧站，或者已经准备好切换窗口。
• 已准备一个非 root 的运维账号，并使用 SSH 密钥登录。
• 已获得商城程序、支付插件和相关依赖的兼容版本。
• 已开通支付服务商的沙箱或测试商户，具备测试商户号、密钥、签名参数和回调配置权限。
• 已明确收款币种、订单金额精度、库存扣减时机、退款方式和订单状态映射。
• 已准备数据库备份位置，以及旧站或当前版本的文件备份。
• 支付服务商允许服务器向其 API 域名发起 HTTPS 请求，并能够访问站点的 HTTPS 回调地址。

支付回调必须使用公开可访问的 HTTPS 地址。仅能在服务器本机访问、使用内网地址、使用临时 IP 或使用自签名证书，通常无法完成正式支付通知。

二、初始化香港服务器

1. 登录并确认系统版本

先通过服务器控制台或 SSH 登录。首次操作建议保留一个控制台会话和一个 SSH 会话，避免修改 SSH 配置或防火墙后失去管理入口。

ssh root@203.0.113.10

确认操作系统、内核、CPU、内存和磁盘情况：

cat /etc/os-release
uname -m
nproc
free -h
df -h /
timedatectl status

预期能够看到 Ubuntu 24.04、x86_64、CPU 核数、可用内存和磁盘空间。服务器时区可以使用 UTC，订单展示时区再由商城后台按业务需要设置。支付签名和回调验签对系统时间比较敏感，必须确认 NTP 同步正常。

sudo timedatectl set-timezone UTC
sudo timedatectl set-ntp true
timedatectl status

如果 System clock synchronized 显示为 yes，时间同步基本正常。如果时间偏差明显，先处理时间同步，不要直接测试支付签名。

2. 更新系统并安装基础依赖

以下命令适用于 Ubuntu Server 24.04。升级前应确认服务器上没有正在运行的生产业务；如果是已有业务的服务器，应先做快照或完整备份。

apt update
apt full-upgrade -y

apt install -y \
  nginx \
  mariadb-server \
  mariadb-client \
  php8.3-fpm \
  php8.3-cli \
  php8.3-mysql \
  php8.3-curl \
  php8.3-gd \
  php8.3-mbstring \
  php8.3-xml \
  php8.3-zip \
  php8.3-intl \
  php8.3-bcmath \
  unzip \
  curl \
  wget \
  ca-certificates \
  dnsutils \
  certbot \
  python3-certbot-nginx

启动并设置服务开机启动：

systemctl enable --now nginx
systemctl enable --now mariadb
systemctl enable --now php8.3-fpm

检查服务状态和监听端口：

systemctl --no-pager --full status nginx
systemctl --no-pager --full status mariadb
systemctl --no-pager --full status php8.3-fpm

ss -lntp

至少应看到 Nginx 监听 80 端口，MariaDB 默认监听本地回环地址，PHP-FPM 通过 Unix Socket 提供服务。MariaDB 不需要直接暴露到公网，外部访问数据库会扩大攻击面。

3. 创建运维账号并配置防火墙

如果当前通过 root 登录，先创建运维账号。将公钥替换为实际的 SSH 公钥：

adduser deploy
usermod -aG sudo deploy

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

新开一个终端验证密钥登录：

ssh deploy@203.0.113.10
sudo -v

确认新账号可以使用 sudo 后，再考虑关闭 root 远程登录。修改 SSH 配置前应保留现有会话，并准备服务器控制台作为回滚入口。

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sshd -t
sudo systemctl reload ssh

如果 sshd -t 返回错误，不要 reload；先恢复配置并检查错误行。

配置 UFW 前，必须先允许实际使用的 SSH 端口。下面示例假设 SSH 使用 22 端口：

sudo apt install -y ufw

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

sudo ufw enable
sudo ufw status verbose

如果 SSH 已改为其他端口，应把 22/tcp 改成实际端口。如果执行 ufw enable 后当前 SSH 中断，使用服务器控制台恢复规则。防火墙调整的影响范围是整台服务器，回滚方式是通过控制台执行：

sudo ufw disable

生产环境不建议把 MariaDB 的 3306 端口直接开放到公网。应用与数据库在同一台服务器时，保持数据库仅本机访问即可。

三、配置运行环境和数据库

1. 调整 PHP 运行参数

跨境电商独立站通常需要上传商品图片、导入商品数据和处理较复杂的结账请求。可以为站点创建单独的 PHP 配置文件：

sudo tee /etc/php/8.3/fpm/conf.d/99-shop.ini > /dev/null <<'EOF'
memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 120
max_input_vars = 5000
max_input_time = 120
cgi.fix_pathinfo = 0
date.timezone = UTC
EOF

重启 PHP-FPM：

sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager

这些值是可调整的参考值，不代表所有插件都必须使用相同参数。post_max_size 应不小于 upload_max_filesize，否则大文件上传可能在 PHP 层被截断。

2. 创建独立数据库和数据库账号

先确认 MariaDB 可以本地登录：

sudo mariadb -e "SELECT VERSION();"

为商城创建独立数据库和账号。密码只作为示例，实际密码应使用随机高强度字符串，并保存到受控的密码管理位置，不要提交到 Git 或写入公开文档。

sudo mariadb <<'SQL'
CREATE DATABASE shopdb
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

CREATE USER 'shop_app'@'localhost'
  IDENTIFIED BY 'Replace-With-A-Long-Random-Password';

GRANT ALL PRIVILEGES ON shopdb.* TO 'shop_app'@'localhost';
FLUSH PRIVILEGES;
SQL

验证账号权限：

mariadb -u shop_app -p -h 127.0.0.1 shopdb -e "SELECT DATABASE(), CURRENT_USER();"

如果返回数据库名和 shop_app@localhost，说明应用账号可以连接。不要把应用配置为使用 MariaDB root 账号。

3. 创建网站目录并设置权限

sudo install -d -m 755 -o www-data -g www-data /var/www/shop
sudo install -d -m 750 -o www-data -g www-data /var/www/shop/wp-content

网站目录应位于 Nginx 的站点根目录之外的独立路径中，避免多个站点之间互相读取文件。上传目录需要可写，但不应把整个系统目录设置为 777。

四、部署商城程序和 Nginx

1. 安装 WP-CLI 并下载程序

以下命令适用于 WordPress 示例环境。生产部署应先确定已经通过兼容性测试的 WordPress、WooCommerce 和支付插件版本，再用明确版本号下载，不建议上线当天无计划地获取最新版。

cd /tmp

curl -LO https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
php wp-cli.phar --info

sudo install -m 0755 wp-cli.phar /usr/local/bin/wp
wp --info

可以先下载 WordPress 文件。下面的版本变量需要替换为经过测试的版本号：

export WP_VERSION='经过兼容性测试的WordPress版本号'

sudo -u www-data -H wp core download \
  --path=/var/www/shop \
  --version="$WP_VERSION" \
  --locale=en_US

如果使用中文后台，可以把 --locale=en_US 改为经过测试的语言包。下载程序后，检查文件是否存在：

sudo -u www-data -H wp core verify-checksums --path=/var/www/shop

如果使用的是内部构建包或定制程序，不能直接执行 WordPress 校验命令，应使用对应发布包的校验方式。

2. 生成应用配置

在生成配置前设置数据库参数。下面的密码只作示例，不要照抄：

export DB_NAME='shopdb'
export DB_USER='shop_app'
export DB_PASS='Replace-With-A-Long-Random-Password'

sudo -u www-data -H wp config create \
  --path=/var/www/shop \
  --dbname="$DB_NAME" \
  --dbuser="$DB_USER" \
  --dbpass="$DB_PASS" \
  --dbhost='127.0.0.1' \
  --dbcharset='utf8mb4' \
  --skip-check

检查数据库连接：

sudo -u www-data -H wp db check --path=/var/www/shop

预期输出应表示数据库通过检查。如果失败，优先核对数据库名、账号、密码、主机地址和 MariaDB 服务状态，不要先修改文件权限。

3. 配置 Nginx 虚拟主机

创建站点配置：

sudo tee /etc/nginx/sites-available/shop.conf > /dev/null <<'EOF'
server {
    listen 80;
    listen [::]:80;

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

    client_max_body_size 64m;

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

    location ~ \.php$ {
        try_files $uri =404;

        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.3-fpm.sock;
    }

    location = /wp-config.php {
        deny all;
    }

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

启用站点并移除默认站点，移除前确认没有其他业务依赖默认配置：

sudo ln -s /etc/nginx/sites-available/shop.conf /etc/nginx/sites-enabled/shop.conf
sudo rm -f /etc/nginx/sites-enabled/default

sudo nginx -t
sudo systemctl reload nginx

nginx -t 必须返回 syntax is ok 和 test is successful。配置检查失败时，不要 reload，先查看错误位置：

sudo nginx -t
sudo journalctl -u nginx -n 50 --no-pager

4. 在 DNS 生效前测试站点

即使域名还没有完成解析，也可以使用 curl --resolve 将域名临时指向香港服务器：

curl -i --resolve shop.example.com:80:203.0.113.10 \
  http://shop.example.com/

预期可以看到 HTTP 响应。如果返回 502 Bad Gateway，通常表示 Nginx 找不到 PHP-FPM Socket、PHP-FPM 未运行或 PHP 程序启动失败；如果返回 404，检查网站根目录和 WordPress 文件；如果连接超时，优先检查服务器状态和防火墙。

五、完成域名解析和 HTTPS

1. 配置 A 和 AAAA 记录

在域名服务商控制台添加：

如果服务器没有可用 IPv6，不能为了完整而添加错误的 AAAA 记录。部分访问者会优先使用 IPv6，错误的 AAAA 记录可能导致部分地区访问超时，而 IPv4 测试看起来正常。

检查 DNS 结果：

dig +short A shop.example.com
dig +short A www.shop.example.com
dig +short AAAA shop.example.com
dig @1.1.1.1 +short A shop.example.com

预期 A 记录返回 203.0.113.10。DNS 缓存受 TTL 和递归 DNS 缓存影响，不能把本地已经变化的结果直接等同于所有访问者都已完成切换。

2. 申请 HTTPS 证书

当 A 记录已经能够从公网解析到服务器，并且 80 端口可以访问后，执行：

sudo certbot --nginx \
  -d shop.example.com \
  -d www.shop.example.com

根据交互提示选择是否将 HTTP 跳转到 HTTPS。完成后验证：

sudo nginx -t
sudo systemctl reload nginx

curl -I https://shop.example.com/
curl -I http://shop.example.com/

如果启用了跳转，HTTP 请求通常返回 301 或 308，HTTPS 请求应返回站点页面或应用响应，而不是证书错误。

测试自动续期：

sudo certbot renew --dry-run

证书续期测试失败时，重点检查 80/443 端口、DNS 记录、证书域名、Nginx 配置和 Certbot 日志。不要在证书失败时直接删除现有证书或手工覆盖 Nginx 配置。

六、安装商城并固定站点地址

1. 执行 WordPress 安装

HTTPS 已生效后执行安装命令。管理员密码不要使用简单字符串，也不要在多人共享的终端历史中长期保留。

sudo -u www-data -H wp core install \
  --path=/var/www/shop \
  --url='https://shop.example.com' \
  --title='Example Store' \
  --admin_user='storeadmin' \
  --admin_password='Replace-With-A-Strong-Admin-Password' \
  --admin_email='admin@example.com' \
  --skip-email

设置站点 URL 和固定链接：

sudo -u www-data -H wp option update home 'https://shop.example.com' --path=/var/www/shop
sudo -u www-data -H wp option update siteurl 'https://shop.example.com' --path=/var/www/shop
sudo -u www-data -H wp rewrite structure '/%postname%/' --path=/var/www/shop
sudo -u www-data -H wp rewrite flush --path=/var/www/shop

检查首页和后台：

curl -I https://shop.example.com/
curl -I https://shop.example.com/wp-admin/

首页返回 200 或符合应用逻辑的跳转，后台能够加载登录页，说明 Web 服务、PHP-FPM、数据库和站点 URL 基本连通。

2. 安装商城和支付插件

安装 WooCommerce 时，应使用已经验证过的版本。示例命令如下：

sudo -u www-data -H wp plugin install woocommerce --activate --path=/var/www/shop

如果支付服务商提供的是 ZIP 插件包，应将文件上传到受控目录后安装：

sudo -u www-data -H wp plugin install \
  /srv/packages/payment-gateway-tested.zip \
  --activate \
  --path=/var/www/shop

插件安装后，进入商城后台完成以下基础配置：

• 商店国家或经营主体信息；
• 商品销售币种和小数位；
• 税费、运费和库存策略；
• 订单状态与发货状态；
• 沙箱支付模式；
• 支付成功、失败、取消和退款处理方式；
• 支付服务商要求的商户号、API 密钥、签名密钥和证书；
• 插件生成的支付回调或 Webhook 地址。

支付密钥不要写入主题文件、前端 JavaScript、公开日志或 Git 仓库。浏览器端只能出现支付服务商允许公开的参数，私钥、签名密钥和服务端 API 凭据必须保留在服务器端。

3. 检查文件权限

sudo chown -R www-www-data /var/www/shop
sudo find /var/www/shop -type d -exec chmod 755 {} \;
sudo find /var/www/shop -type f -exec chmod 644 {} \;

sudo chmod 640 /var/www/shop/wp-config.php

如果后台需要写入上传目录，确认 wp-content/uploads 归属正确：

sudo install -d -o www-data -g www-data -m 755 /var/www/shop/wp-content/uploads

不要对整个 /var/www/shop 执行 chmod -R 777。这种做法虽然可能暂时消除写入错误，却会扩大恶意文件写入和配置泄露风险。

七、配置支付网关并验收连通性

1. 先检查服务器出站能力

支付过程通常包含服务器向支付服务商 API 发起 HTTPS 请求，因此不仅要保证访客能访问站点，还要保证服务器可以解析支付服务商域名并访问其 443 端口。

将命令中的域名替换为支付服务商实际提供的 API 域名：

getent hosts api.payment-provider.example
curl -Iv https://api.payment-provider.example/

预期可以完成 DNS 解析并建立 TLS 连接。返回 401、403 或业务错误，不一定代表网络不通，可能说明服务端已经收到请求；如果是 Could not resolve host、连接超时或 TLS 握手失败，则先处理 DNS、出口防火墙、系统时间和证书链问题。

检查香港服务器本机防火墙：

sudo ufw status verbose

前面设置了默认允许出站，因此通常不需要单独开放出站 443。若服务器还存在云平台安全组、主机安全策略或上游出口限制，也需要同步检查。

2. 配置回调地址和签名校验

支付插件后台通常会生成一条或多条回调地址。不要根据路径名称自行猜测，也不要把支付成功后的浏览器跳转地址直接当成服务端通知地址。

常见地址用途如下：

支付成功不能只以浏览器返回结果为依据。用户可能在支付完成后关闭页面、网络中断或返回地址加载失败，服务端仍应根据签名验证通过的异步通知更新订单状态。

回调验签至少要验证：

• 请求是否来自插件支持的回调路径；
• 签名是否使用正确的商户密钥计算；
• 商户号、订单号、金额和币种是否与本地订单一致；
• 通知是否为重复通知；
• 事件状态是否为支付成功或退款成功；
• 订单是否已经处理过相同事件；
• 处理结果是否在服务商要求的时间内返回。

金额校验不能只比较格式化后的字符串。例如本地订单金额为 99.90，支付网关可能以分为单位传输 9990。应按照支付服务商的金额单位转换后再比较，避免小数位和四舍五入造成误判。

3. 沙箱验收用例

正式切换前，建议至少完成以下测试。测试卡号、测试账户和测试金额只能使用支付服务商提供的沙箱数据。

支付网关的“连接成功”不能只理解为 API 能访问。至少要同时验证前端跳转、服务端下单、异步通知、签名校验、订单状态、库存和重复通知处理。

4. 查看支付链路日志

测试期间可以按时间查看 Nginx 和 PHP 日志：

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log
sudo journalctl -u php8.3-fpm -f

如果支付插件有独立日志，应在商城后台或插件指定目录查看。日志中可以保留订单号、事件 ID、HTTP 状态和错误类型，但不要记录完整银行卡号、CVV、API 私钥或完整签名原文。

常见结果判断如下：

• 404：回调路径不存在、插件未启用、Nginx 根目录错误或请求被重写到错误入口。
• 405：回调接口要求 POST，但请求使用了错误方法，或者被前端路由拦截。
• 403：可能是权限、后台安全插件、Nginx 规则或来源校验造成，需要确认没有误拦截合法回调。
• 419、403 或 CSRF 错误：支付回调不应被普通后台表单保护机制拦截，需要按插件文档对回调路径进行排除。
• 500：PHP、插件依赖、数据库或签名处理异常，查看 PHP-FPM 和应用日志。
• 502：Nginx 与 PHP-FPM 之间连接失败，检查 Socket 路径和服务状态。
• HTTP 正常但订单不变：重点检查签名、订单号、金额、币种、重复通知和插件日志。

八、上线前结果检查

正式切换到生产支付参数前，按外到内的顺序进行一次完整检查。

1. 域名和证书

dig +short A shop.example.com
curl -I https://shop.example.com/
sudo certbot renew --dry-run

确认域名指向目标香港服务器，HTTPS 证书覆盖实际使用的主域名，HTTP 跳转策略符合预期。

2. 服务和端口

systemctl is-active nginx
systemctl is-active mariadb
systemctl is-active php8.3-fpm

ss -lntp
sudo nginx -t

应当只有计划中的公网入口对外提供服务，数据库不应监听公网地址。

3. 应用和数据库

sudo -u www-data -H wp core version --path=/var/www/shop
sudo -u www-data -H wp plugin list --path=/var/www/shop
sudo -u www-data -H wp db check --path=/var/www/shop

确认 WordPress、WooCommerce 和支付插件均为已经验证的版本，数据库检查通过，后台登录正常，商品页、购物车、结账页和订单页能够加载。

4. 支付生产切换

只有沙箱测试完成后，才切换生产商户号、生产 API 地址和生产签名密钥。切换后不要直接使用大额真实订单验证，可以按照支付服务商允许的测试方式完成小额验证。真实支付可能产生实际扣款、手续费和退款处理，不应把它当作无成本的连通性测试。

生产切换后重点确认：

• 生产环境回调地址与沙箱地址没有混用；
• 生产证书和签名密钥已正确替换；
• 站点币种与支付网关支持的币种一致；
• 订单金额与支付页面金额一致；
• 支付成功后没有错误地跳过库存、发货或风控流程；
• 回调失败时能够在日志中定位订单号和事件 ID；
• 管理员可以从后台查看订单和退款记录。

九、常见失败处理顺序

DNS 已修改但站点仍打不开

先执行：

dig @1.1.1.1 +short A shop.example.com
curl -I --resolve shop.example.com:80:203.0.113.10 \
  http://shop.example.com/

如果 --resolve 可以访问，而公网域名不行，问题通常在 DNS 记录、TTL 缓存或 AAAA 记录。若 --resolve 也不能访问，则检查 Nginx、UFW、安全组和服务器状态。

HTTPS 证书申请失败

检查以下项目：

sudo ss -lntp | grep -E ':80|:443'
sudo nginx -t
dig +short A shop.example.com
sudo journalctl -u nginx -n 50 --no-pager

证书申请阶段必须让验证方访问到正确域名和 80 端口。如果域名仍指向旧服务器，应先完成 DNS 切换或使用对应验证方式，不要反复申请证书。

页面返回 502

检查 PHP-FPM Socket 是否存在：

ls -l /run/php/php8.3-fpm.sock
systemctl status php8.3-fpm --no-pager
sudo journalctl -u php8.3-fpm -n 80 --no-pager

如果 Socket 路径是 /run/php/php8.3-fpm.sock，应与 Nginx 配置一致。如果系统实际安装的是其他 PHP 版本，应以以下命令结果为准：

ls -l /run/php/

不要猜测 Socket 名称，也不要在未确认应用兼容性的情况下随意更换 PHP 主版本。

支付页面能打开，但订单没有更新

按照以下顺序处理：

1. 确认回调域名能够从公网通过 HTTPS 访问。
2. 查看 Nginx access log，确认支付服务商的请求是否到达。
3. 查看应用或支付插件日志，确认是否进入回调处理函数。
4. 检查签名密钥、商户号、API 环境和证书是否混用了沙箱与生产参数。
5. 检查订单号、金额单位、币种和事件状态。
6. 检查安全插件或 Nginx 规则是否拦截了 POST 回调。
7. 检查重复通知和幂等逻辑，避免为了“让订单变成已支付”而手工修改数据库。

生产订单不建议直接通过 SQL 强制改状态。应先保留支付服务商事件 ID、订单号、请求时间和响应结果，再通过插件或业务后台执行可审计的补单流程。

支付服务商提示回调超时

确认回调处理逻辑没有执行耗时任务。理想流程是：验证签名、校验订单、幂等更新状态、快速返回成功；邮件发送、库存同步或其他耗时动作按插件机制异步处理。

服务器端检查：

curl -I https://shop.example.com/
sudo tail -n 100 /var/log/nginx/access.log
sudo tail -n 100 /var/log/nginx/error.log

如果请求已经到达但处理时间过长，再检查 PHP 超时、数据库锁、插件日志和服务器资源：

uptime
free -h
df -h
top

十、备份与失败回滚

1. 上线前制作备份

任何插件升级、支付参数切换、数据库结构变更和 Nginx 大幅修改前，都应先备份。以下命令会备份数据库、网站配置和上传文件，备份目录放在网站根目录之外。

sudo install -d -m 700 /srv/backup/shop

sudo mariadb-dump \
  --single-transaction \
  --routines \
  --triggers \
  shopdb | gzip > /srv/backup/shop/shopdb-before-release.sql.gz

sudo tar -C /var/www/shop \
  -czf /srv/backup/shop/shop-files-before-release.tar.gz \
  wp-content wp-config.php

sudo cp /etc/nginx/sites-available/shop.conf \
  /srv/backup/shop/shop.conf.before-release

sudo chmod 600 /srv/backup/shop/*

数据库备份完成后可以快速检查压缩包：

gzip -t /srv/backup/shop/shopdb-before-release.sql.gz
tar -tzf /srv/backup/shop/shop-files-before-release.tar.gz | head

备份文件中可能包含数据库内容、用户资料和密钥配置，应限制权限，并根据企业数据保留策略存放。

2. Nginx 配置回滚

如果修改 Nginx 后检查失败：

sudo cp /srv/backup/shop/shop.conf.before-release \
  /etc/nginx/sites-available/shop.conf

sudo nginx -t
sudo systemctl reload nginx

如果 Nginx 已经 reload 且站点异常，恢复旧配置后重新执行 nginx -t。不要直接删除整个 sites-enabled 目录，避免影响同机其他站点。

3. 应用文件回滚

插件升级或程序发布失败时，先进入维护状态，阻止新订单写入：

sudo -u www-data -H wp maintenance-mode activate --path=/var/www/shop

恢复文件：

sudo tar -xzf /srv/backup/shop/shop-files-before-release.tar.gz \
  -C /var/www/shop

sudo chown -R www-www-data /var/www/shop
sudo find /var/www/shop -type d -exec chmod 755 {} \;
sudo find /var/www/shop -type f -exec chmod 644 {} \;
sudo chmod 640 /var/www/shop/wp-config.php

确认站点、后台和数据库正常后，再关闭维护模式：

sudo -u www-data -H wp maintenance-mode deactivate --path=/var/www/shop

4. 数据库回滚

数据库恢复会覆盖备份之后产生的订单、用户和配置变更，影响范围大于文件回滚。只有在确认备份时间点、停止写入并完成订单核对后才能执行。

sudo -u www-data -H wp maintenance-mode activate --path=/var/www/shop

sudo mariadb shopdb < /srv/backup/shop/shopdb-before-release.sql.gz

上面的命令不能直接读取 gzip 压缩文件，正确恢复方式是：

gunzip -c /srv/backup/shop/shopdb-before-release.sql.gz | \
  sudo mariadb shopdb

恢复前应暂时停用生产支付入口或阻止新的订单写入，避免支付回调写入正在被覆盖的数据库。恢复后必须核对备份时间点之后的真实支付订单，并通过支付服务商后台与商城订单记录进行对账，不能把数据库恢复视为订单自动找回。

5. 支付配置回滚

支付网关切换失败时，优先在商城后台停用支付方式或恢复上一组经过验证的沙箱、生产参数，不要删除订单表和支付日志。回滚检查包括：

• 站点不再向错误的 API 地址发起请求；
• 回调地址仍然指向当前可用站点；
• 旧密钥未被错误覆盖；
• 待支付订单没有被误标记为已支付；
• 已支付订单没有因应用回滚而重复扣库存；
• 支付服务商后台没有持续重试失败通知。

如果只是支付插件版本导致故障，可以先回滚插件文件和配置；如果涉及数据库结构升级，则必须使用插件支持的降级方案，不能单纯覆盖 PHP 文件。

十一、最终验收清单

完成部署后，可以按以下顺序签字确认：

• [ ] Ubuntu、Nginx、PHP-FPM、MariaDB 服务均正常运行。
• [ ] SSH 使用运维账号和密钥登录，root 远程登录策略符合要求。
• [ ] 防火墙仅开放管理端口、80 和 443，数据库未暴露公网。
• [ ] 域名 A 记录指向香港服务器，错误 AAAA 记录已清理。
• [ ] HTTP 到 HTTPS 的跳转符合预期，证书覆盖正式域名。
• [ ] 首页、商品页、购物车、结账页和后台可以正常访问。
• [ ] WordPress、WooCommerce 和支付插件版本已经固定并通过兼容性测试。
• [ ] 数据库连接、字符集、文件权限和上传功能正常。
• [ ] 沙箱正常支付、失败、取消、重复通知、签名错误和金额不一致场景均已测试。
• [ ] 生产回调地址使用 HTTPS，支付服务商可以访问。
• [ ] 服务端验签、金额校验、币种校验和幂等处理已验证。
• [ ] 生产支付参数切换后完成了受控的小额或服务商允许的验证。
• [ ] 数据库、上传文件、wp-config.php 和 Nginx 配置均有可读的备份。
• [ ] 已确认应用文件回滚、Nginx 回滚、支付配置回滚和数据库恢复步骤。
• [ ] 回滚时不会误删已支付订单，也不会让重复回调重复扣库存或重复发货。

这样部署后，香港服务器承担域名入口、HTTPS、商城程序、数据库和支付回调接收职责；支付服务商负责支付页面或支付 API，服务器只保存业务订单和必要的交易结果，不直接保存银行卡敏感数据。上线验收的核心不是页面能打开，而是从 DNS 解析、TLS、PHP、数据库到支付通知的每一段都能被单独验证，并且在任一环节失败时都有明确的恢复路径。