先定义验收状态与前置条件

部署电商网站到韩国服务器前，不能只确认“服务器能登录”。至少要同时完成三项核对：带宽测试结果能够覆盖业务峰值，端口从正确的来源开放到正确的目标，数据库引擎、版本、字符集、扩展和应用驱动能够完成一次真实备份恢复与业务验证。任意一项没有通过，都不应直接切换生产流量。

准备一个与生产尽量一致的测试环境，记录源服务器和韩国服务器的操作系统、应用运行时、Web 服务、数据库引擎及版本。数据库版本支持范围、安全策略和驱动兼容性会随软件更新变化，最终应以应用、数据库和驱动的当前官方文档为准。

上线前至少准备以下内容：

• 源站数据库的可恢复备份，并完成备份文件校验。
• 韩国服务器的管理员权限、应用部署账号和数据库账号。
• 应用依赖清单、锁定文件、环境变量模板和数据库迁移记录。
• 测试域名或临时访问地址，避免直接在生产域名上反复试错。
• 端口清单，包括来源地址、目标地址、协议、端口、用途和暴露范围。
• 一份当前防火墙规则、Web 配置和数据库参数的备份。
• 可执行的回滚方案，包括旧应用版本、旧数据库连接信息和恢复方式。

一、先建立源站与目标环境基线

1. 核对应用运行环境

先在源站和韩国服务器分别记录实际运行环境，不要只依据控制面板显示的版本。以 Linux 环境为例：

uname -a
cat /etc/os-release
ss -lntup

ss -lntup 可以查看正在监听的 TCP、UDP 端口及关联进程。命令输出中的端口才是后续端口矩阵的依据，不要仅按某个软件的默认端口配置防火墙。

应用侧需要记录：

• 编程语言及运行时版本。
• Web 服务和反向代理版本。
• 应用依赖锁定文件，例如 composer.lock、package-lock.json、poetry.lock 等。
• 定时任务、队列、文件上传目录和静态资源目录。
• 应用需要访问的数据库、缓存、对象存储或其他内部服务。
• 当前生产环境变量，但不要把真实密钥提交到代码仓库或粘贴到工单中。

目标机部署后，应用配置中的数据库地址应优先使用内部地址或私有域名。配置示例只表示字段含义，实际变量名称应以应用文档为准：

APP_ENV=production
APP_URL=https://shop.example.com

DB_HOST=
DB_PORT=
DB_NAME=
DB_USER=
DB_PASSWORD=
DB_SSL_MODE=

如果数据库与应用部署在同一台韩国服务器上，应用连接地址也应明确写成 127.0.0.1、Unix Socket 或实际监听地址，不能在不同配置之间混用，否则容易把本地连接误判为远程网络故障。

2. 查询数据库服务器真实版本

客户端版本不一定等于数据库服务器版本，必须直接连接数据库查询。MySQL 或兼容引擎可以执行：

mysql -h  -u  -p -e \
"SELECT VERSION(), @@version_comment, @@character_set_server, @@collation_server, @@sql_mode;"

PostgreSQL 可以执行：

psql "host= dbname= user=" -W -c \
"SELECT version(), current_setting('server_version'), current_setting('server_encoding'), current_setting('lc_collate'), current_setting('lc_ctype');"

分别保存源站和目标数据库的输出，并继续核对：

• 数据库引擎是否相同。
• 目标版本是否在应用和数据库驱动支持范围内。
• 字符集、排序规则和大小写规则是否一致。
• SQL 模式、时区和严格校验参数是否一致或已被应用明确支持。
• 应用使用的扩展、插件、存储过程、触发器、事件和全文索引是否存在。
• 数据库账号是否拥有应用运行所需的最小权限，以及迁移时是否需要临时的结构变更权限。

如果目标版本低于源站，不能默认认为导出的数据一定可以导入；如果目标版本更高，也不能默认所有旧查询、驱动和扩展都没有变化。应以实际备份恢复和业务测试作为放行条件。

二、核对带宽：先计算需求，再做受控测试

1. 区分带宽方向和业务流量

电商网站通常至少有以下几类流量：

• 用户访问商品页、图片和前端静态文件产生的下行流量。
• 图片上传、后台导入和文件提交产生的上行流量。
• 应用与远程数据库或内部服务之间的流量。
• 备份、日志传输和发布包下载产生的后台流量。

可以用下面的方式估算基础需求：

峰值下行带宽 ≈ 峰值请求数/秒 × 平均响应字节数 × 8

实际核对时，还应加入上传流量、连接协议开销、后台任务和业务预留空间。平均响应大小不能用首页的单次结果代替，应分别统计商品页、搜索接口、购物车、结算接口和静态资源。

带宽是否足够，不能脱离时间和测试环境下结论。应记录：

• 测试节点所在网络及其到韩国服务器的连接方式。
• 测试日期和时间。
• 服务器当时的 CPU、内存、磁盘和网络使用情况。
• 测试文件大小、是否启用压缩、是否经过反向代理。
• 并发数、测试持续时间和重复次数。
• 测试期间是否有其他下载、备份或发布任务。

2. 使用真实大小的测试文件

不要用几 KB 的健康检查接口判断带宽。应在测试站点放置一个与实际静态资源大小接近、不会触发动态逻辑的测试文件，并从计划中的用户访问节点重复下载。

curl -o /dev/null -sS \
  -w 'code=%{http_code} dns=%{time_namelookup}s connect=%{time_connect}s ttfb=%{time_starttransfer}s total=%{time_total}s speed=%{speed_download}B/s\n' \
  https://staging.example.com/test-assets/test-file.bin

这个结果只能反映该节点、该文件、该时刻和该连接条件下的传输表现，不能直接等同于韩国服务器的可用带宽。至少重复多次，并分别记录成功率、总耗时和下载速度；测试期间还要查看服务器侧网络监控，确认是否碰到了实例、系统、防火墙或服务端限速。

如果具备独立测试端点，可以使用 iperf3 进行受控测试。该方法需要双方明确授权，并且测试端口只在测试窗口内开放：

iperf3 -c  -P 4 -t 30
iperf3 -c  -P 4 -t 30 -R

服务器端和客户端的角色必须根据测试方向确定。测试结束后关闭临时端口和测试进程，不要在没有审批的生产环境中长时间运行大流量测试。

带宽验收应采用业务自己的阈值：峰值期间的实测结果能够覆盖预估峰值，且没有持续丢包、连接失败或服务端限速。如果只测得单次高速度，不能据此承诺长期稳定容量。

三、建立端口矩阵并逐条验证

1. 先写清楚“谁访问谁”

端口开放前，建立一张最小权限矩阵：

公网只开放确实需要被公网访问的服务。数据库端口、内部管理端口和测试端口不应因为“方便测试”而长期暴露。

在韩国服务器上查看监听情况：

sudo ss -lntup

重点确认监听地址：

• 127.0.0.1:端口 通常只接受本机连接。
• 内网地址通常只接受指定网络内连接。
• 0.0.0.0:端口 或 [::]:端口 可能接受所有地址族的连接，必须结合防火墙和云平台安全策略检查。
• 没有监听进程时，即使防火墙放行，外部连接也不会成功。

2. 从正确的来源测试端口

TCP 连接测试应从真实访问方执行。例如，从应用主机测试数据库端口：

nc -vz -w 5  

从管理网络测试 Web 服务：

nc -vz -w 5  
curl -I --connect-timeout 5 https:///

结果可以这样判断：

• succeeded 或 open：TCP 连接建立，不能证明应用认证、TLS 配置或业务接口正常。
• Connection refused：目标地址可达，但没有服务监听，或主动拒绝连接。
• timed out：常见原因包括防火墙丢弃、来源地址未加入允许列表、路由不通或目标服务没有响应。
• TCP 成功但 HTTP 返回 4xx 或 5xx：端口通常已经连通，应转向域名、证书、反向代理、应用配置或权限检查。

如果域名同时存在 IPv4 和 IPv6 记录，应分别验证两种地址族，避免一部分访问者能够连接、另一部分访问者超时。域名解析结果可用以下命令查看：

getent ahosts 

3. 修改防火墙前保存规则

防火墙调整属于高影响操作。执行前应保存当前规则，并确认有控制台或带外管理方式，防止误删规则后无法远程登录。使用哪一种命令取决于系统实际采用的防火墙管理器，不要在未知环境中直接执行清空规则的命令。

例如，确认系统确实使用 nftables 后再导出：

sudo nft list ruleset > /root/firewall-before-change.conf

修改时只增加经过端口矩阵确认的规则，先校验语法，再应用变更。不要在生产环境执行类似 flush ruleset 的清空操作。应用后从外部来源重新验证 Web、管理和数据库端口；如果出现管理连接中断，应使用控制台恢复变更前的规则文件。

四、验证数据库版本兼容性

1. 用兼容性清单逐项比对

数据库兼容性不只是“版本号相同”。建议至少形成以下记录：

特别检查商品名称、订单备注、收货信息中可能出现的中文、韩文、特殊符号和表情字符。导入后查询、排序、模糊搜索和写入回读都应符合业务预期。若字符集或排序规则不同，不能只看“数据导入成功”，还要验证实际查询结果。

2. 先恢复到空的测试数据库

正式迁移前，把源站备份恢复到韩国服务器上的空测试库。备份和恢复会占用磁盘、CPU、网络和数据库资源；生产数据库在备份期间是否允许持续写入，取决于引擎、表结构和备份工具，不能一概而论。

MySQL 或兼容引擎可以使用与服务器版本匹配的客户端工具：

mysqldump -h  -u  -p \
  --single-transaction --routines --events --triggers \
  --databases  > /secure-backup/appdb.sql

--single-transaction 适用于特定事务型存储引擎，不代表所有表和对象都能在不停写状态下获得一致备份。若数据库包含非事务表、结构变更或高频写入，应按照数据库官方文档采用停写、快照或其他一致性方案。

PostgreSQL 可以使用：

pg_dump -Fc -h  -U  \
  -d  -f /secure-backup/appdb.dump

恢复前确认目标是空测试库，并确保备份文件权限只允许授权账号读取。不要把生产库恢复命令直接套用到目标生产库，也不要在没有快照或可验证备份的情况下使用会删除现有对象的恢复参数。

恢复完成后检查：

• 表数量、关键表记录数量和索引是否存在。
• 触发器、函数、事件、序列和扩展是否恢复。
• 是否出现排序规则、字符集、权限、所有者或 DEFINER 相关错误。
• 应用迁移工具是否能够在测试库完成升级。
• 读写、事务提交、回滚和并发下的关键订单流程是否正常。

如果导入报错，不要直接在生产库中逐条修改结构。先记录完整错误、失败对象和目标数据库版本，在测试库修正版本、扩展、权限或迁移脚本后重新恢复。

五、在测试站完成连续验证

将应用部署到韩国服务器的测试地址，按以下顺序验证，尽量由低风险检查到真实业务操作：

1. 检查域名解析、Web 端口、TLS 握手和健康检查接口。
2. 检查应用日志，确认数据库连接成功且没有循环重试。
3. 浏览商品列表、商品详情和搜索结果，验证字符集、排序和图片加载。
4. 加入购物车，修改数量，验证库存和价格计算。
5. 使用测试账号创建一笔测试订单，验证事务、订单号、库存扣减和后台查询。
6. 执行后台登录、商品编辑和订单状态变更，确认权限没有因数据库账号或排序规则变化而失效。
7. 运行队列、定时任务和必要的数据库迁移，检查任务是否重复执行或积压。
8. 从代表性用户访问节点重复下载测试文件，并对照服务器侧网络监控。
9. 记录接口状态码、响应时间、数据库错误、慢查询和网络失败次数。

任何带有真实支付、真实短信或真实订单副作用的流程，都应使用相应的测试模式或隔离账号。测试成功的标准不是页面能打开，而是关键读写链路能够完成，并且日志没有未处理异常。

六、常见失败处理与上线回滚

带宽测试结果不稳定

先区分是测试节点、测试文件、服务器出口、应用限速还是其他任务占用了网络。重新测试时固定文件、节点、时间段和并发参数，并同时查看服务器网络监控。不要仅凭一次结果修改应用缓存或购买更高规格；无法解释差异时，应暂停切换并补充样本。

端口开放但应用仍不可用

如果 TCP 测试成功而应用返回错误，重点检查监听进程、虚拟主机、域名、TLS、反向代理和应用环境变量。如果数据库端口可达但登录失败，检查数据库账号、来源地址限制、认证方式、SSL 要求和数据库名称。端口放行不能替代应用认证。

数据库恢复失败

先保留错误日志和失败备份，不要覆盖原始文件。按照错误类型检查版本、字符集、排序规则、扩展、对象所有者、导出权限和目标库容量。修正后重新恢复到空测试库；只有测试库恢复完整且业务验证通过，才进入生产迁移。

上线后出现应用或数据库异常

回滚前先停止继续写入，保留应用日志、数据库错误和当前配置。若数据库结构没有发生不兼容变更，可以将流量切回旧应用和旧数据库连接；若已经执行了不可逆结构迁移，不要直接把数据库版本降回去，应优先采用经过测试的向前修复方案。

如果必须恢复数据库，影响范围是恢复时间点之后的新增或修改数据。应在维护窗口内停止写入，确认备份时间点和数据损失边界，再恢复到经过验证的备份。防火墙回滚则使用变更前保存的规则，恢复后重新验证管理端口和 Web 端口。

上线前验收清单

• [ ] 韩国服务器的应用运行时、依赖和数据库服务器版本已记录。
• [ ] 源站数据库已完成可恢复备份，并验证过备份文件。
• [ ] 带宽测试记录了节点、时间、环境、文件、并发和重复次数。
• [ ] 带宽实测结果能够覆盖业务峰值，测试期间没有未说明的限速因素。
• [ ] 端口矩阵已明确来源、目标、协议、用途和暴露范围。
• [ ] 公网只开放必要服务，数据库和管理端口未向无关地址开放。
• [ ] 数据库备份已恢复到韩国服务器的空测试库。
• [ ] 字符集、排序规则、SQL 模式、时区、扩展和权限已逐项核对。
• [ ] 商品、搜索、购物车、订单、库存和后台操作已完成测试。
• [ ] 应用、数据库和防火墙的变更前配置均已备份。
• [ ] 已确定切换失败时的停写、旧版本切回、数据库恢复和端口回滚顺序。