跨境电商旺季前，香港服务器十二项体检如何核查容量与访问链路？

旺季前的服务器交付验收，不能只确认香港服务器已经开机、域名能够打开。真正容易在高峰期暴露的问题，往往是可用带宽低于标称规格、磁盘和数据库连接池没有余量、DNS仍指向旧地址，或者首页能访问但下单、支付回调和库存接口在链路中间失败。

这十二项体检应同时覆盖两部分：一是服务器本身还能承受多少 CPU、内存、磁盘、数据库连接和网络流量；二是客户从目标市场访问时，能否沿着 DNS、TCP、TLS、CDN或负载均衡、源站、应用及外部接口完整走通。下面按照交付验收视角，逐项说明核对内容、检查原因和通过依据。

验收前先统一检查范围

先画出实际访问链路

跨境电商网站通常不只有“域名—香港服务器”这一段，至少应把下列对象列入验收范围：

• 客户端所在地区及网络类型。
• DNS解析服务和域名记录。
• CDN、WAF或负载均衡，如业务使用了这些组件。
• 香港服务器的公网IP、云平台安全组和系统防火墙。
• Nginx或其他Web入口服务。
• 应用服务、数据库、缓存、对象存储。
• 支付、物流、库存、邮件、税费或订单同步等外部接口。
• 支付回调、异步通知和管理端访问入口。

如果网站使用CDN，源站带宽和CDN回源带宽要分别核对；如果没有CDN，则用户静态资源、动态页面和接口流量都可能直接占用香港服务器的公网出口。不能因为首页加载正常，就默认支付回调或库存接口也没有问题。

A5数据面向跨境电商网站、订单后台和接口服务，提供香港物理服务器租用，涵盖Xeon Gold与AMD EPYC平台，搭配不同容量的内存及SSD、NVMe存储，为应用运行、数据库和缓存提供计算与存储资源。香港产品的CN2与国际带宽方案，可承接不同访问人群的网络需求；另有大容量存储系列，为商品素材、业务文件和备份归档提供存储空间，形成覆盖旺季容量与访问链路需求的资源基础。

统一容量和网络的统计口径

服务器验收建议同时查看最近7至14天的监控数据、最近一次业务高峰数据，以及一次经过控制的业务压测或回放结果。平均值只能说明日常状态，不能代替高峰期的95分位、99分位和短时峰值。

还要区分计量单位：

• GB、MB通常用于存储或文件大小。
• Gbps、Mbps用于网络速率。
• 按十进制口径计算时，1 Gbps等于1000 Mbps。
• 如果10分钟内产生36 GB出站流量，换算平均速率为：36,000 MB × 8 ÷ 600秒 = 480 Mbps。

下表可以作为验收总览。表中的比例是便于建立预警线的参考值，不是适用于所有业务的硬性标准，最终还要结合应用类型和历史基线。

一、服务器规格与实际配额

1. 核对交付规格是否真正可用

核对什么： 把服务商控制台、订单或资源清单中的规格，与香港服务器操作系统里看到的实际资源逐项对照：

• vCPU数量和CPU型号或计算级别。
• 内存总量及是否存在系统预留。
• 系统盘、数据盘、临时盘的容量和类型。
• 公网带宽是固定带宽、共享带宽还是按峰值计费。
• 入站和出站方向是否有不同限制。
• 月流量包、超额限速或超额计费规则。
• 公网IPv4、IPv6数量及是否真正分配到实例。
• 并发连接数、每秒新建连接数或PPS限制。
• 云平台安全组、负载均衡和CDN是否另外计费或有独立配额。

为什么要核对： “4核8 GB、100 Mbps”只是一组规格描述，不能直接推出应用能稳定使用4个逻辑核、全部8 GB内存和完整100 Mbps出口。有些环境会因为虚拟化争用、带宽共享、流量包或PPS限制，在高峰期表现出与基础配置不一致的结果。

如何判断： 至少保留控制台截图或资源清单、系统命令输出和公网测试记录。Linux环境可以先使用只读命令确认资源：

nproc
free -h
lsblk
ip -br addr
ip -s link

如果系统显示的CPU、内存或磁盘容量与交付清单明显不符，不应直接进入应用验收。先确认是否存在未挂载数据盘、容器资源限制、虚拟机模板限制或尚未生效的配额。公网带宽则要以云平台监控和授权的外部测试结果共同判断，不能只看服务器本机网卡名称。

二、计算与存储容量

2. 核对CPU、内存和调度余量

核对什么：

• CPU使用率的平均值、95分位和短时峰值。
• load average是否长期高于可用CPU数量。
• iowait是否因为磁盘读写拖高负载。
• 虚拟化环境中的CPU steal是否异常。
• 内存available是否持续下降。
• 是否发生swap使用、OOM或应用被系统终止。
• 高峰期间Web进程、应用进程和数据库进程的资源占用是否互相挤压。

为什么要核对： CPU达到100%时，最先出现的可能不是网站完全打不开，而是接口排队、TLS握手变慢、后台任务延迟和数据库连接堆积。内存不足也不一定立即表现为“内存用完”，频繁交换会先让页面响应时间明显变长。

如何判断： 可将持续运行状态下的CPU 95分位控制在约70%以内，短时峰值尽量不长期超过85%；内存可用量保留约20%或更多，并且没有持续swap输入输出。对于计算密集型图片处理、报表或推荐服务，这些比例还需要更保守。

load average不能单独作为CPU是否够用的结论。例如4核服务器负载为4，可能代表所有CPU都在运行，也可能包含大量等待磁盘的任务。可以用以下只读命令辅助观察：

uptime
free -h
vmstat 1 5

在vmstat结果中，r可观察运行队列，wa反映I/O等待，si和so反映交换分区活动；如果安装了系统统计工具，还应关注不同CPU的steal值。出现持续高负载时，要区分是应用计算、数据库查询、磁盘等待还是虚拟化争用，不能仅通过增加CPU规格处理所有问题。

3. 核对磁盘空间、inode和写入能力

核对什么：

• 根分区、应用分区、数据库分区、日志分区和临时目录。
• 数据盘剩余容量和inode剩余量。
• 访问日志、错误日志、订单文件、导出文件和备份文件的增长速度。
• 数据库写入延迟、磁盘队列和高峰期I/O等待。
• 是否把备份、日志和业务数据全部放在同一块盘上。
• 磁盘满载后，应用是否有明确的降级或告警机制。

为什么要核对： 磁盘空间不足会导致日志无法写入、数据库无法扩展、临时文件创建失败，最终可能表现为下单失败或后台无法登录。即使容量尚未用完，inode耗尽也会让小文件无法创建。电商系统的图片缩略图、订单导出、支付对账文件和日志通常会在旺季明显增加。

如何判断： 普通业务数据盘可把70%至75%作为日常控制线，把80%左右作为需要处理的预警线；日志盘和临时盘应根据写入速度设置更早的告警。不要等到90%以后才规划扩容。

增长容量可以按下列方式估算：

需要容量 = 日均增长量 × 保留天数 + 固定数据量 + 临时空间 + 预留余量

例如：

• 每日新增订单及日志约8 GB。
• 需要保留14天在线数据。
• 固定数据和临时文件约40 GB。
• 预留30%的缓冲。

计算为：8 GB × 14 + 40 GB = 152 GB；152 GB × 1.3 = 197.6 GB。实际规划时应至少按约200 GB计算，还要把系统盘、数据库临时空间和备份存储独立评估。

可以使用以下命令查看文件系统和inode，不要在生产盘上直接执行未经审批的删除操作：

df -hT
df -ih
du -xhd1 /var 2>/dev/null

如果发现日志增长过快，应先确认日志轮转、归档和保留策略，再决定是否扩盘或调整级别。不要把“清理日志”当成唯一解决方式，因为正在排查旺季故障时，日志本身也是重要留证。

4. 核对数据库、连接池与缓存容量

核对什么：

• 数据库最大连接数、当前连接数和连接等待。
• 每个应用实例的连接池上限，所有实例连接池总和是否超出数据库承受能力。
• 慢查询、锁等待、事务持续时间和临时表空间。
• 数据库磁盘增长、备份空间和日志空间。
• 缓存内存使用率、命中率和淘汰情况。
• 购物车、会话、库存锁和支付状态是否会因为缓存淘汰而丢失。
• 结算、库存扣减、订单查询等关键接口是否与首页使用同一套连接池。

为什么要核对： 应用进程数量增加后，连接池可能按实例数成倍增长。数据库CPU看起来不高，但连接耗尽、锁等待或临时空间不足，仍会导致下单接口超时。缓存达到上限后，如果把会话或库存状态和普通页面缓存一样淘汰，业务风险会更大。

如何判断： 可以把数据库活动连接数控制在有效上限的70%至80%以内，并为管理操作、复制、监控和故障处理保留专用余量。计算连接池时，应使用：

应用可用连接上限 = 数据库最大连接数 - 管理及系统预留连接数

例如数据库最大连接数为300，预留40个给管理和系统任务，3个应用实例各配置60个连接，则应用理论上占用180个连接，尚未超过260个有效上限。但这不代表可以直接放大连接池，还要查看查询耗时、事务持续时间和高峰期连接是否长期不释放。

缓存则应按数据类型判断。静态页面缓存命中率较低未必异常，但购物车、登录会话和库存状态不能仅以“缓存命中率高”作为通过条件。检查应在预发布或隔离环境完成，避免为了验证连接上限而修改生产数据库参数。

三、网络出口与访问链路

5. 核对公网带宽、PPS和连接队列

核对什么：

• 香港服务器实际出站和入站Mbps。
• 出站带宽是独享、共享还是按端口限速。
• 每秒数据包数PPS是否接近平台限制。
• TCP已建立连接、TIME_WAIT、半连接队列和监听队列。
• TCP重传、网卡丢包、软中断和连接建立失败。
• CDN回源、图片加载、接口调用和后台下载是否共享同一出口。
• 带宽超限时平台是丢包、限速、排队还是额外计费。

为什么要核对： 带宽达到上限时，轻量级的首页可能仍能打开，但图片、接口和支付回调会排队。PPS和连接数限制也可能在低Mbps流量下触发，尤其是大量小请求、健康检查或静态资源请求集中到源站时。

如何判断： 不要只对照套餐中的“100 Mbps”或“1 Gbps”，应比较高峰95分位和端口上限。一般可以把高峰95分位控制在购买带宽的70%至80%以内，将剩余部分留给突发流量、回源和异常重试。还要分别判断带宽和PPS，二者不是同一指标。

例如香港服务器在10分钟内产生36 GB出站流量：

1. 36 GB按十进制换算为36,000 MB。
2. 36,000 MB × 8 = 288,000 Mb。
3. 288,000 Mb ÷ 600秒 = 480 Mbps。

这表示这10分钟的平均出站速率约为480 Mbps，不等于瞬时峰值。如果该时间段内还有明显的图片突发、接口重试或带宽波动，验收应使用监控的峰值和95分位，而不是只使用这个平均值。

服务器端可以查看连接和网卡统计：

ss -s
ip -s link

云平台流量图通常比单次命令更适合观察带宽峰值。若发现TIME_WAIT、重传或监听队列持续偏高，应结合Nginx、应用和上游服务确认原因，不要未经评估直接修改内核连接参数。

6. 核对DNS记录、TTL和IPv4/IPv6一致性

核对什么：

• A记录是否指向当前公网IPv4。
• AAAA记录是否确实指向可用的IPv6入口。
• 使用CDN时，CNAME是否指向正确的接入域名。
• 权威DNS记录之间是否存在旧地址、重复记录或错误优先级。
• 主域名、商城子域名、支付回调域名和静态资源域名是否都已更新。
• TTL是否与旺季前的变更计划相匹配。
• 各目标区域的递归解析结果是否符合预期。

为什么要核对： 域名能够在一个网络中打开，不代表所有递归DNS都已经得到同样的结果。尤其是迁移香港服务器、切换CDN或增加IPv6时，残留的旧A记录和不可用AAAA记录都可能造成部分客户访问失败。

如果业务没有完整支持IPv6，不应为了“看起来配置齐全”而保留不可达的AAAA记录。反过来，如果已经对外发布AAAA记录，就必须把IPv6下的DNS、端口、TLS、应用和回源路径一起测试。

如何判断： DNS解析结果应与设计文档一致。使用CDN或多线路解析时，不一定要求所有地区返回同一个IP，但返回的CNAME或地址必须属于已验收的接入链路。TTL可在计划变更期间临时调低，例如设置为300至600秒；稳定运行后再根据DNS服务和变更频率调整，不能把TTL当成切换立即生效的保证。

可以从多个递归DNS查询示例域名：

dig +noall +answer shop.example.com A @1.1.1.1
dig +noall +answer shop.example.com A @8.8.8.8
dig +noall +answer shop.example.com AAAA @1.1.1.1
dig +noall +answer shop.example.com CNAME @1.1.1.1

验收记录中应保存查询时间、查询地点、返回结果和预期值。若采用DNS故障切换，还要验证健康检查条件、切换目标和恢复逻辑，而不只是查看主记录是否存在。

7. 从目标市场核对实际访问路径

核对什么：

• 目标客户所在地区的DNS解析耗时。
• TCP连接建立耗时。
• TLS握手耗时。
• 首字节时间TTFB和完整响应时间。
• 丢包、抖动、重传和路径变化。
• IPv4与IPv6是否存在明显差异。
• 首页、商品详情、登录、加购、结算和订单查询是否都能访问。

为什么要核对： 香港服务器距离不同市场的网络路径并不相同。客户访问体验由运营商、跨境线路、DNS、CDN、源站负载和页面资源共同决定，不能用机房到某一个测试点的ping值推断所有用户的结果。

ICMP被限制时，ping或路径探测的丢包也不一定代表HTTPS请求失败。因此，网络质量要与真实的TCP和HTTPS请求结合判断。

如何判断： 应从中国内地、香港、东南亚及实际海外目标市场选择监测点；如果客户集中在某几个运营商，还应尽量覆盖相应网络。建议至少分别记录DNS、TCP、TLS、TTFB和完整请求的95分位，而不是只看平均值。静态资源、普通页面和结算接口可以有不同基线，但结算接口不能因为首页正常而被判定为通过。

以下命令可用于授权测试点对域名进行基础HTTPS计时：

curl -sS -o /dev/null \
  --connect-timeout 10 \
  --max-time 30 \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n' \
  https://shop.example.com/health

这条命令只能检查一个健康地址，不能代替真实业务流程。验收时还要使用不产生真实扣款的测试账号或预发布环境，验证登录、购物车、结算和回调相关接口。

8. 核对安全组、系统防火墙和监听端口

核对什么：

• 云平台安全组或网络访问控制列表。
• 香港服务器系统防火墙规则。
• Nginx、应用、数据库和缓存实际监听的端口。
• 负载均衡或CDN健康检查的来源地址。
• 管理端口是否仅允许办公网、跳板机或指定运维地址访问。
• 后端数据库和缓存端口是否错误暴露到公网。
• IPv4与IPv6是否使用了同等的访问控制规则。

为什么要核对： 安全组放行并不意味着系统防火墙放行，系统端口监听也不代表公网一定可达。反过来，某些默认服务可能已经监听公网地址，却没有被业务清单记录。双层防火墙或IPv6规则不一致，也会造成“部分网络能访问、部分网络超时”的隐蔽问题。

如何判断： 对外公布的业务端口应与设计一致，通常只包括HTTPS入口及确有必要的HTTP入口；数据库、缓存和内部管理端口应限制在内网或授权来源。对外测试应从授权的外部探测点进行，并分别测试IPv4和IPv6。

服务器本机可先查看监听情况：

ss -lntup

这只是本机视角，不能代替外部可达性测试。检查期间不应直接修改防火墙规则；如果必须调整，应先导出当前规则、确认管理连接不会被切断，安排控制台或带外回退方式，并在变更后重新验证全部入口。

9. 核对TLS证书和Web入口处理

核对什么：

• 证书是否覆盖实际访问域名和必要的子域名。
• 证书链是否完整，SNI是否返回正确证书。
• 证书到期时间和自动续期任务。
• HTTP到HTTPS跳转是否形成循环。
• 正确域名、错误域名和非标准Host头的处理。
• Nginx到应用的连接超时、读取超时和请求体大小限制。
• 4xx、5xx、502、503、504的比例和来源。
• 连接复用、压缩和静态文件处理是否符合业务设计。

为什么要核对： 证书问题会直接阻断用户访问，反向代理参数不匹配则可能只在结算、上传凭证或提交订单时暴露。健康检查接口返回200，也不代表真实应用链路不存在上游超时。

如何判断： 从客户实际使用的域名发起访问，不能只访问源站IP。浏览器或命令行不应出现证书名称错误、链不完整或不安全警告。证书续期应设置提前告警，例如到期前30天预警；如果续期依赖HTTP验证，还要确认DNS、端口和验证目录没有被CDN或安全规则拦截。

Web入口的通过标准应以历史基线为基础：高峰时错误率没有异常抬升，502/504能够区分是入口、应用还是数据库超时。若需要修改Nginx配置，应先保存当前配置和生效版本，使用配置检查后再 reload，并保留恢复原配置的方法。

四、CDN、源站和外部服务

10. 核对CDN、负载均衡到香港源站的回源链路

核对什么：

• 静态资源是否按预期从边缘节点返回。
• 商品图片、JS、CSS等资源的缓存命中率。
• 商品价格、库存、购物车、结算和账户页面是否被错误缓存。
• CDN或负载均衡到香港源站的回源带宽和连接数。
• 源站Host头、证书、健康检查和真实客户端IP传递。
• 缓存刷新或失效是否会造成瞬时回源洪峰。
• 源站是否能绕过接入层被直接访问，是否符合安全设计。
• 没有使用CDN时，是否已按直连源站重新计算带宽和连接容量。

为什么要核对： CDN可以减少静态资源回源，但不会自动解决动态接口、订单提交和第三方API的问题。缓存策略配置错误可能让客户看到旧价格或旧库存；缓存全部失效时，又可能让大量请求同时回到香港服务器。

如何判断： 静态资源应能从接入层返回，并通过响应头或控制台确认缓存状态；动态接口应根据业务规则决定是否缓存，结算、订单状态和个人信息通常不能使用普通页面缓存策略。静态资源的缓存命中率可以设置一个示例目标，例如稳定业务下达到80%左右，但商品更新频繁、资源版本化方式不同，合理值也会不同。

应至少进行两轮测试：

1. 冷缓存或刷新后的访问，观察源站回源峰值。
2. 热缓存访问，观察边缘响应时间和源站流量下降情况。

如果源站必须只接受CDN或负载均衡回源，应确认接入层的源地址范围、健康检查和回源证书均已记录。任何源站防护调整都要保留当前规则和管理入口，避免把合法回源或运维通道一并拦截。

11. 核对支付、库存和其他外部依赖

核对什么：

• 香港服务器到支付、库存、物流、邮件、税费和订单同步接口的DNS解析。
• 出站TCP/TLS连接是否被安全组、系统防火墙或对方IP白名单阻断。
• 外部接口的连接超时、读取超时、重试次数和连接池。
• 对方API的并发、频率和请求体限制。
• 支付回调、异步通知、物流状态回调是否能从外部进入服务器。
• 第三方接口异常时，订单是否会重复提交或长期处于未知状态。
• 外部服务的证书变更、域名变更和备用地址是否有通知机制。

为什么要核对： 跨境电商常见的故障不是页面打不开，而是页面能打开、订单也提交了，但支付确认、库存扣减或回调没有完成。香港服务器的出站路径和客户访问入口是两条不同链路，不能用首页访问成功替代外部依赖验收。

如何判断： 优先使用第三方提供的沙箱或健康检查接口，不要在生产环境用测试命令创建真实支付订单。每一个关键外部接口都应有明确的超时和失败状态，重试应有上限和退避机制，不能在对方故障时无限重试形成流量放大。

回调验收要验证完整闭环：测试订单进入待支付或待确认状态，使用授权的沙箱回调完成状态更新，再检查订单、库存和通知记录是否一致。若第三方采用IP白名单，应同时记录当前出口公网IP和变更流程，避免香港服务器扩容、迁移或更换公网IP后回调突然失效。

五、监控、备份与旺季前变更

12. 核对监控告警、备份恢复和回滚能力

这一项不是单纯查看“监控面板是否有数据”，而是确认出现容量或链路异常时，团队是否能及时发现，并且有可执行的恢复路径。

先核对监控覆盖：

• CPU、内存、swap、CPU steal和系统负载。
• 根分区、数据盘、inode、数据库日志和备份空间。
• 出入站Mbps、PPS、连接数、重传和监听队列。
• DNS解析、HTTPS可用性、TLS证书有效期和关键接口TTFB。
• Nginx及应用的4xx、5xx、502、503、504。
• 数据库连接数、锁等待、慢查询和缓存淘汰。
• CDN命中率、回源错误和源站健康状态。
• 支付、库存和回调接口的成功率、超时率及积压量。

外部监控至少应覆盖域名解析和HTTPS请求，不能只在服务器内部部署监控。服务器宕机或出口中断时，内部监控也可能一起失效。

再核对告警是否能触发：

可以使用分级阈值建立示例规则，例如磁盘使用率75%预警、85%严重；数据库连接使用率70%预警、85%严重；公网带宽95分位达到端口的70%时提示扩容评估。阈值应结合历史基线调整，重点是每个告警都有负责人、通知渠道和处理时限。

最后核对备份和恢复：

• 最近一次数据库备份是否在目标时间内完成。
• 备份是否存放在与生产服务器不同的存储或故障域。
• 是否覆盖订单、商品、库存、配置、证书和必要的静态文件。
• 备份保留周期是否满足业务和合规要求。
• 是否验证过备份文件可读取，而不是只看任务状态为成功。
• 是否在隔离环境恢复过数据库，并完成应用连接、订单查询和关键数据校验。
• 是否明确RPO和RTO。

RPO表示最多允许丢失多长时间的数据，例如15分钟；RTO表示发生故障后恢复业务所需的目标时间，例如60分钟。这两个数值应由业务确定，不能因为服务器有快照就默认已经满足。

恢复测试应在隔离实例或预发布环境中进行，避免覆盖生产数据。测试完成后要清理测试凭据、回调地址和敏感数据，记录备份版本、恢复耗时、失败原因及改进措施。旺季前如果还要升级软件、切换IP、修改CDN策略或调整数据库参数，应先保存当前配置、明确影响范围和回滚版本，再安排变更窗口。

交付判定与复核记录

十二项检查完成后，可以按“通过、限期处理、阻断交付”三类记录，而不是只写一个“服务器正常”。

可以判定为通过的条件

• 控制台规格与系统实际资源一致，带宽、流量、PPS和连接限制已经确认。
• CPU、内存、磁盘、数据库和网络在目标峰值下仍有明确余量。
• 目标地区的DNS、IPv4/IPv6、TCP、TLS和HTTPS访问结果符合设计。
• 首页、商品、登录、加购、结算和订单查询等关键路径均已验证。
• CDN、源站、支付、库存和回调链路有对应的测试记录。
• 监控能覆盖关键指标，告警能送达负责人。
• 备份不仅存在，而且已经在隔离环境完成恢复验证。
• 旺季前的配置变更有版本、负责人、窗口和回滚方案。

需要限期处理的问题

例如磁盘增长速度较快但仍有短期余量、部分区域TTFB偏高但没有错误、静态资源缓存命中率低于目标、某个第三方接口没有沙箱测试记录等。这类问题应明确负责人和完成时间，不能用“当前还能访问”作为关闭依据。

应阻断上线或扩容验收的问题

以下情况不宜带入旺季：

• 域名仍可能解析到旧服务器或错误源站。
• 对外发布了不可用的AAAA记录。
• 结算、支付回调或库存扣减存在稳定的5xx、超时或状态不一致。
• 生产磁盘、数据库连接或公网带宽已经接近上限，且没有扩容方案。
• 管理端口或数据库端口意外暴露。
• 备份任务显示成功，但从未完成过恢复验证。
• 修改防火墙、DNS或入口配置后没有可用的回滚路径。

验收留证建议至少包含检查时间、服务器实例标识、域名和解析结果、测试区域、监控时间范围、关键接口响应记录、配置版本、异常截图及处理负责人。旺季期间如果出现访问变慢或订单失败，可以据此快速判断问题发生在DNS、跨境路径、接入层、香港源站、数据库还是外部依赖，而不是重新从“服务器是否开机”开始排查。