一、外贸站选新加坡节点,先算清三笔账

很多外贸站把"新加坡"当成一个笼统的选择,其实你要回答的是三个具体问题:你的客户在哪个大区、你的支付走哪个通道、你的产品是否受管制。
先说清楚外贸站的负载特征,它和国内博客完全不同:
| 特征 | 国内博客站 | 外贸独立站 |
|---|---|---|
| 访客地域 | 单一 | 多国分散 |
| 页面加载 | 一次会话多页面 | 通常落地即转化,页面少 |
| 图片量 | 少 | 多(产品图、模特图、场景图) |
| 流量峰值 | 明显(晚高峰) | 分散(跟着各国作息走) |
| 转化路径 | 注册/评论 | 下单/留资 |
| 支付 | 微信/支付宝 | 信用卡/PayPal/本地支付 |
这张表推出三个结论:
结论一:内存比 CPU 重要。 外贸站的页面数少,但产品图多、图集大、后台媒体库重,PHP 渲染一张 2000 像素的产品图裁切要吃掉不少内存。所以同样是 2 核,2 GB 和 4 GB 的实际体验差得很远。
结论二:流量配额要算,因为图片多。 假设你的产品页有 8 张图,每张 150 KB,加上 JS/CSS 约 50 KB,单个页面约 1.2 MB。月 PV 5000 的外贸站:
- 月流量 ≈ 5000 × 1.2 MB ≈ 6 GB;
- 商品库里 1024 GB 月流量那档(RosCloud-01,19.99 美元/月、2 核 1 GB 内存 20 GB 硬盘 500 Mbps 带宽)用掉 0.6%;
- 但如果你不做图片优化,一个产品页放 8 张 500 KB 的原图,月流量会翻三倍多。 图片压缩和 WebP 转换是外贸站的第一优先级优化,比换机器有用得多。
结论三:硬盘要留够,因为图片和订单数据都在涨。 起步留 40 GB,图片多的品类留 80 GB 以上。
现在算真正的钱。 商品库里这几档的真实价格与配置(采样时间 2026-11-14 12:47,以官网当日显示为准):
| 机型 | 计费 | 价格 | 内存 | 硬盘 | 带宽 | 月流量 | 每 GB 内存 |
|---|---|---|---|---|---|---|---|
| RosCloud-03 | 月付 | 39.99 美元 | 4 GB | 80 GB | 500 Mbps | 3072 GB | 10 美元 |
| RosCloud-05 | 月付 | 59.99 美元 | 16 GB | 240 GB | 500 Mbps | 5120 GB | 3.75 美元 |
| LAX-STARTER | 年付 | 200 美元(折月 16.67 美元) | 2 GB | 40 GB NVMe | 2000 Mbps | 5000 GB | 8.33 美元 |
| LAX-MEDIUM | 年付 | 800 美元(折月 66.67 美元) | 8 GB | 160 GB NVMe | 10000 Mbps | 20000 GB | 8.33 美元 |
| 云途 HK.DS.P | 月付 | 750 元 | 64 GB | 1024 GB SSD | 2000 Mbps | 40000 GB | 11.72 元 |
| 云途 HK.DS.S | 月付 | 800 元 | 128 GB | 6000 GB SAS HDD | 2000 Mbps | 40000 GB | 6.25 元 |
看这张表能得出三个可以直接用的判断:
第一,RosCloud 系列往上走一档,单位内存成本快速下降。 4 GB 是 10 美元每 GB,16 GB 只有 3.75 美元每 GB。 所以如果你确定要多站合用或者要跑大媒体库,直接上 16 GB 那档比买两台 4 GB 更划算——还少一套运维。
第二,LAX 系列是年付,折月 16.67 美元起。 如果你的外贸站面向欧美客户,LAX-MEDIUM(折月 66.67 美元、8 GB 内存 160 GB NVMe、10000 Mbps 带宽、20000 GB 流量)每 GB 内存 8.33 美元、每 TB 流量 3.41 美元,这个组合在磁盘和带宽上都宽裕。
第三,注意云途系列的货币和流量机制。 云途是人民币计价(750 元、800 元),LAX 和 RosCloud 是美元计价——跨商家比价时必须先统一货币,直接比数字大小一定错。 另外云途的流量超额是单独收费的:HK.DS.P 是 750 元一个月、流量超额重置 500 元,HK.DS.M 是 350 元一个月、超额重置 200 元。这笔钱要写进预算。
最后一条免费但极有价值的建议:先按月买。 外贸站最忌讳一上来就签年付——产品图没压缩好、支付没对接通、CDN 配错了,一年后才发现,这些年付的钱就白花了。
二、新加坡节点适合什么业务,不适合什么业务

这一节讲清楚新加坡的地理特性,因为它直接决定你的客户打开速度。
新加坡的地理优势是明确的:它处在东南亚枢纽位置,到亚太各国(香港、台湾、越南、泰国、马来西亚、菲律宾、印尼)的延迟普遍在 30 到 90 毫秒。 这意味着:你的客户如果主要在东南亚,新加坡是相当合理的选择。
但对欧美客户,新加坡就不占优势了。 新加坡到北美西岸的延迟通常在 200 毫秒以上,到欧洲在 200 到 250 毫秒。如果你的客户 90% 在北美,商品库里的 LAX 系列(LAX-STARTER 折月 16.67 美元、LAX-MEDIUM 折月 66.67 美元)从洛杉矶出发到北美用户延迟在 50 毫秒以内,这个差距是能感知到的。
所以第一条判断规则很明确:客户在哪,节点就往哪放,别用"离中国近"当唯一标准。
第二条规则:线路类型比城市更重要。 商品库里 backwaves 提供"美国/日本 VPS 接入 CU 9929 / AS10099 (CUG) 顶级联通精品网",zorocloud 提供"CN2 GIA、9929、CMIN2"等线路,这些是线路产品不是机房位置产品。 如果你的客户里有相当比例在国内,那么"回程优化线路"带来的体验提升,通常比"从新加坡换到香港"更明显。
第三条规则:产品管制。 外贸站如果卖的是受限品类(某些国家管制的商品),机房位置会直接影响能不能做。 这是公开的合规信息,下单前应该直接问商家的客服,而不是自己推测。
第四条规则:IP 属性。 商品库里干杯cloud 提供"美西 AT&T 原生住宅宽带独立 IP",goodlyclouds 提供"美国双 ISP 与英国原生 IP",sixtynet 有完整的 Residential 系列(Residential-STARTER 折月 21.67 美元、Residential-MEDIUM 折月 71.67 美元、Residential-LARGE 折月 138.33 美元)。为什么外贸站要关心这个?因为支付网关和部分平台会检查 IP 的归属地——用数据中心 IP 开通某些支付通道可能被拒,用住宅 IP 则通过率高得多。这是事实层面的差异,不涉及谁好谁坏。
具体到新加坡节点:joysol 明确提供"在香港、东京、新加坡与洛杉矶等节点提供云服务器",景文互联提供"香港、日本、新加坡、美国等各国云服务器",zorocloud 的节点覆盖里也有新加坡,webhorizon 的新加坡数据中心托管在 Equinix JH1 机房、底层 KVM 虚拟、AMD Ryzen 9000 系列处理器、DDR5 内存、NVMe SSD 阵列、10 Gbps 带宽。 这些是公开的硬件与机房信息,买之前可以对得上。
三、服务器初始化,海外 VPS 要额外做的几步

海外 VPS 和国内 VPS 最大的不同是:你的客户在地球另一边,所以「网络」相关的排查权重更高。
第一步:更新系统。 这一步不能省,海外机器的镜像往往比国内更新得慢:
apt update && apt upgrade -y
第二步:设置时区。 外贸站的服务器时区建议设成 UTC 或者你的主要市场时区,但更重要的是保证时钟同步——海外机器的时钟漂移比国内机器常见,NTP 没配好会导致 HTTPS 证书校验失败、支付网关签名验证失败:
timedatectl set-timezone UTC
timedatectl set-ntp true
timedatectl status
看到 System clock synchronized: yes 才行。
第三步:装防火墙,规则要覆盖支付回调。
apt install -y ufw fail2ban
ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose
第四步:海外机器必查的一步——从外部测你的机器延迟和丢包。 这一步不能在自己机器上测:
# 在你自己的电脑上测(不是在服务器上)
ping -c 20 你的服务器IP
mtr -c 50 你的服务器IP
mtr 输出里如果有中间节点超时(Loss 列有 100% 但终点正常),说明只是那一跳限速,不影响实际使用;但如果终点本身有丢包,就是真问题。
第五步:装环境。 WordPress 用 LNMP,纯静态或 Shopify 类的用 Nginx 加 Node:
apt install -y nginx mariadb-server php-fpm php-mysql php-curl php-xml php-mbstring php-zip php-gd php-imagick
外贸站的图片处理尤其重要,所以 php-gd 和 php-imagick 都要装——它们负责生成缩略图,没有它们的话你的商品页会直接加载原图,一张 500 KB 的图乘以 8 张就是 4 MB。
第六步:设置主机名和时区,这些在海外机器上更容易被忽略但会影响邮件发送:
hostnamectl set-hostname yourdomain.com
timedatectl set-timezone UTC
主机名改成域名是海外 VPS 的常见惯例,它影响 Postfix 判断哪些域名该由本机投递,配置不对会导致订单确认邮件进垃圾箱。
四、外贸站的站点部署,WordPress 还是 Shopify 还是自建

这一节讲三条技术路线的取舍,选错了后面所有优化都白费。
路线一:WordPress + WooCommerce(自托管)。
适合:产品 SKU 多(超过 200 个)、需要高度定制、团队有运维能力。
mkdir -p /var/www/你的域名/public
chown -R www-data:www-data /var/www/你的域名
cat > /etc/nginx/sites-available/你的域名.conf << 'EOF'
server {
listen 80;
server_name 你的域名 www.你的域名;
root /var/www/你的域名/public;
index index.php index.html;
client_max_body_size = 64M;
location / {
try_files $uri $uri/ /index.php?$query_string;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}
location ~ /\. {
deny all;
}
}
EOF
ln -s /etc/nginx/sites-available/你的域名.conf /etc/nginx/sites-enabled/
nginx -t
systemctl reload nginx
路线二:Shopify / SaaS 建站平台。
适合:SKU 少于 200、团队零运维能力、想最快上线。
这条路的关键认知是:你不需要 VPS。 Shopify 这类平台自己托管代码,你买 VPS 反而多了一层——要自己保证服务器和 Shopify 应用之间的连接稳定。
如果确定走这条路,VPS 的用途通常只有一个:跑反向代理或数据同步脚本。 那就要一个最小配置的机器,商品库里 RosCloud-01 是 19.99 美元/月、2 核 1 GB 内存 20 GB 硬盘 500 Mbps 带宽 1024 GB 流量,这个规格跑同步脚本完全够用。
路线三:静态站 + Headless CMS(Next.js / Nuxt + API)。
适合:极度重视首屏速度、访客以移动端为主、需要多语言切换。
这条路对服务器配置要求最低,因为渲染在构建期完成,运行期只发静态文件——但需要一台能跑构建的机器。 商品库里 LAX-MEDIUM 是 8 核 8 GB 内存 160 GB NVMe 硬盘,这个规格在构建 Next.js 时不会卡。
三条路线的取舍,一句话版本:
| 路线 | 上线速度 | 定制能力 | 运维成本 | 服务器配置要求 |
|---|---|---|---|---|
| WordPress + WooCommerce | 中 | 最高 | 高 | 中(4 GB 起步) |
| Shopify / SaaS | 最快 | 中 | 最低 | 最低(同步脚本 1 GB) |
| 静态站 + Headless | 中 | 高 | 中 | 构建期吃配置,运行期几乎不吃 |
第四种情况值得单独说:如果你做的是纯展示型外贸站(产品不多、只是获取询盘),静态站是最划算的。 RosCloud-01 那个 19.99 美元的配置配 Cloudflare 免费版,月成本二十几美元,能扛住绝大部分展示型站点的访问。
五、支付网关怎么对接,Stripe、PayPal 的配置要点

这一节是外贸站最容易翻车的地方。 支付不通,站点再漂亮也没用。
先说一个原则:外贸站的支付必须用「无密钥」模式,也就是前端直接跳转到网关的托管页面。 不要试图把卡号输入框做在自己页面上再 POST 到网关——PCI 合规成本极高,而且大多数网关对这种接入方式根本不开放个人开发者权限。
WordPress + WooCommerce 装 Stripe 插件:
wp plugin install woocommerce
wp plugin install woocommerce-gateway-stripe
wp plugin activate woocommerce woocommerce-gateway-stripe
后台要填的四项:
1. Live publishable key 和 Live secret key——测试阶段用 test 开头的两个;
2. Webhook 端点——填 https://你的域名/?wc-api=wc_webhook;
3. 货币设置——站点币种设成你的结算币种(比如 USD);
4. 税务设置——这个最容易被漏,但漏了会在结账报错。
Webhook 是重点,必须单独测。 Stripe 有专门的测试工具:
# Stripe CLI 监听 webhook 事件(本地开发用)
stripe listen --forward-to https://你的域名/?wc-api=wc_webhook
上生产前一定要在 Stripe 后台手动点一次 "Send test event"。 如果 webhook 没通,订单会一直停在"待付款",而用户在浏览器上看到的往往是"支付成功"——这种不一致会造成大量客诉和退款。
PayPal 的配置逻辑类似,但有个坑:PayPal 的 IP 回调机制需要你的服务器能出站访问 PayPal。 检查:
curl -I https://api.paypal.com
能正常返回 200 就说明出站没问题。 海外 VPS 这一项基本都能过,但如果你的服务商做了出站限制(有些便宜商家会),PayPal 就会一直回调失败。
其他常见的支付通道要准备的资料:
- 信用卡(Stripe / PayPal / Payoneer):需要公司或个体户营业执照;
- 本地支付(iDEAL、Klarna、PayPay 等):多数需要单独申请,且很多只支持特定国家的商户主体;
- 加密货币:这是外贸站一个现实的选择,但要注意它和信用卡通道的转化率和用户群体不一样,而且各国监管在收紧。
关于地区限制的一个技术细节:很多支付网关会按 IP 归属地限制可用方式。 商品库里那些住宅 IP 和双 ISP 的产品线(Residential 系列、干杯cloud 的 AT&T 原生住宅 IP、goodlyclouds 的双 ISP),在这一点上确实有实际用途。
最后说三条通用建议:
第一,支付一定要做完整的端到端测试,不要只测成功路径。 测试:支付成功、支付失败、用户中途取消、银行卡被拒、3D Secure 验证超时、退款。 每一条都要在小额真实订单上跑一遍。
第二,退款流程必须先于上线准备好。 跨境退款的到账时间、汇率损失、手续费承担方,这些规则要先写清楚。
第三,别把支付密钥硬编码在前端 JS 里。 这在 Node/Next.js 项目里是常见错误,密钥必须只在服务端环境变量里。
六、CDN 怎么配,静态资源加速和跨区加速的取舍

外贸站几乎一定要用 CDN,但用错了比不用还糟。
先说三种 CDN 用法的区别:
第一种:只加速静态资源。 图片、JS、CSS 走 CDN,HTML 动态生成不加速。这是最安全的用法,配置简单,缓存失效问题少。
第二种:整站缓存。 连 HTML 一起缓存。页面打开最快,但后台预览、购物车、结账流程都会出问题——因为 HTML 是带用户状态的,缓存之后 A 用户会看到 B 用户的内容。
第三种:只加速图片。 对外贸站来说这个最实用,因为图片是体积大头,而且图片内容不会因用户而变。
所以给外贸站的建议是第一种或第三种,不要用第二种。
Nginx 里给静态资源加长缓存头:
location ~* \.(jpg|jpeg|png|webp|gif|svg|ico|woff2)$ {
expires 30d;
add_header Cache-Control "public, max-age=2592000";
access_log off;
}
location ~* \.(css|js)$ {
expires 7d;
add_header Cache-Control "public, max-age=604800";
}
图片文件名里带版本号或哈希(比如 product-abc123.webp),这样改图之后文件名变了,CDN 自然不会返回旧图。 这比手动刷新缓存可靠得多。
然后是关键的图片优化部分,这是外贸站省带宽最有效的一步。
第一步:批量转 WebP。 WebP 相比 JPEG 通常小 25% 到 35%,而且商品库里 LAX 系列用的正是 NVMe SSD,云途的 SSD 档也是 SSD——这些机器跑批量转码没问题。
apt install -y webp
cd /var/www/你的域名/public/wp-content/uploads
# 单张转换
cwebp -q 80 原图.jpg -o 原图.webp
# 批量转换并保留原图
for f in $(find . -name "*.jpg"); do
cwebp -q 80 "$f" -o "${f%.jpg}.webp"
done
第二步:生成多尺寸缩略图。 WordPress 本身能生成,但默认尺寸可能不够。**
# 在后台设置里把缩略图尺寸加上这几档
wp option update thumbnail_size_w 300
wp option update medium_size_w 600
wp option update medium_size_h 600
wp option update large_size_w 1200
第三步:把商品图换成 WebP 并写进 HTML。 WordPress 的输出格式可以用插件或过滤器控制,命令行刷一遍缓存即可生效。
第四步:用 lazy load。 首屏之外的图片延迟加载:**
wp plugin install autoptimize
wp plugin install smush
这一步对外贸站的移动端转化率影响很直接——移动网络下首屏加载超过 3 秒,跳出率会明显上升。
第五步:CDN 缓存刷新。 改完价格或者活动页之后必须刷新缓存,否则老客户看到的是旧价格。这一条在外贸站是事故级的。
# Cloudflare 刷缓存
curl -X POST "https://api.cloudflare.com/client/v4/zones/你的ZoneID/purge_cache" \
-H "Authorization: Bearer 你的API Token" \
-H "Content-Type: application/json" \
--data '{"purge_everything":true}'
第六步:跨区加速的取舍。 如果你的客户横跨欧美亚三个大区,单个节点的 CDN 覆盖不全,考虑多节点方案。 商品库里 zenlayer 就是这类分布式基础设施服务商——它的定位是"分布式云",覆盖洛杉矶、新加坡、上海、孟买、东京、河内等节点,如果你的业务是全球分布的,分布式方案比单个新加坡节点更合适。
七、多语言和 SEO 怎么配,hreflang 和 sitemap

多语言外贸站的 SEO 配置有两个必须做对的点:hreflang 和 sitemap。
hreflang 告诉搜索引擎"这个内容的其他语言版本在哪"。 做错的典型后果是:不同语言的页面互相抢收录,你的中文页和英文页都排不上去。
WordPress 里用 WPML 或 Polylang 插件:
wp plugin install wpml-media
核心规则有三条:
第一,hreflang 必须双向标注。 如果英文页指向西班牙语页,西班牙语页也必须指回英文页。单向标注等于没标。
第二,语言代码要用标准格式。 英文是 en,英文(英国)是 en-gb,西班牙语是 es,巴西葡语是 pt-br。不要用 english 或者 cn 这种非标准写法——虽然 cn 实际上很多人这么写,但标准是 zh-cn。
第三,每种语言一个自指(self-referencing)标签。 每个页面都要包含指向自己的那一条。
Sitemap 的配置:
# 装 SEO 插件
wp plugin install yoast
# 生成并提交
wp sitemap generate
Sitemap 要提交到 Google Search Console 和 Bing Webmaster Tools。 这一步很多人跳过,等于放弃了主动告诉搜索引擎"你的站有哪些页面"的机会。
多语言站还有几个必须单独处理的:
第一,Hreflang 标签要放在 head 里,不能用 JS 注入。 用 JS 注入的 hreflang,Google 能渲染但 Bing 有时不能,这是已知的不一致。
第二,每种语言的 URL 结构要提前定好。 三种常见方案:
| 结构 | 示例 | 优点 | 缺点 |
|---|---|---|---|
| 子域名 | es.yourdomain.com | 权重独立,清晰 | 需分别配置 DNS 和证书 |
| 子目录 | yourdomain.com/es/ | 集中权重,最省事 | 需要 hreflang 标注 |
| ccTLD | yourdomain.es | 本地 SEO 最强 | 成本高,维护难 |
外贸站最常用的是子目录方案,因为它能把所有语言页的权重集中到主域,而且只用一个证书、一套 Nginx 配置、一个后台。
第三,翻译内容不能机翻直出。 Google 的 Helpful Content 系统专门打击低价值机翻内容, 表现为页面收录了但没有排名。如果你用 AI 翻译,至少要人工过一遍产品描述和 FAQ 部分。
第四,hreflang 要和 sitemap 一起提交,而且要定期检查有没有失效页面。
八、外贸站的性能优化,测速目标应该定多少

外贸站的性能目标不能照搬国内站,因为你不可能同时优化所有地区。
先定原则:优化要对着你最大的市场做,其他市场接受一定程度的妥协。 如果你的客户 60% 在美国,那 Google PageSpeed 的测速目标就以美国节点为准。
具体的目标值:
| 指标 | 目标值 | 说明 |
|---|---|---|
| LCP(最大内容渲染) | 小于 2.5 秒 | Google 的"良好"标准 |
| FCP(首次内容渲染) | 小于 1.8 秒 | Google 的"良好"标准 |
| CLS(累积布局偏移) | 小于 0.1 | 防止页面加载时跳动 |
| TTFB(首字节时间) | 小于 600 毫秒 | 跨境链路放宽到 600 |
| 首屏总传输 | 小于 1.5 MB | 移动端尤其重要 |
| 图片平均大小 | 小于 200 KB | 转 WebP 后应该能到 |
注意 TTFB 这一项和国内站的差别。 前面几篇讲国内业务时用的阈值是 300 毫秒,跨境链路从新加坡到北美本来就到不了 300 毫秒,把 300 毫秒当验收标准会让你永远不达标。 600 毫秒是跨境场景下的合理线。
怎么优化,按收益排序:
第一步,图片。 这一项的收益最大,通常能省掉一半以上的传输量。 具体做法见上一节。
第二步,CDN 缓存静态资源。 见上一节的 Nginx 配置。
第三步,数据库查询优化。 外贸站的 WordPress 查询慢,通常是这几个原因:
# 装 Query Monitor 插件看真实数据
wp plugin install query-monitor
常见的三个原因: 站点选项表(wp_options)太大(装了很多插件之后会膨胀)、文章关联查询没走索引、图片附件表没优化。
修复方式:
# 清理膨胀的 transient(临时缓存)
wp transient delete --all
# 优化所有表
wp db optimize
第四步,延迟加载非首屏内容。 除了图片懒加载,视频、地图组件、聊天工具也要延后加载——很多外贸站挂着 WhatsApp 客服组件和一堆追踪脚本,这些在东南亚和南美用户的网络下加载极慢。
第五步,减少第三方脚本。 数一下你的页面加载了多少个第三方域名:
curl -s https://你的域名 | grep -oE 'https?://[^/"]+' | sort -u
超过 5 个外部域名就要警惕了。 每多一个外部域名,就多一次 DNS 解析和一次 TLS 握手,在跨境链路上这两项都不便宜。
第六步,服务器本身的优化。 确认 PHP-FPM 进程数和内存匹配:
ps aux | grep -c "[p]hp-fpm"
free -m
按 pm.max_children = (内存 MB 1024) ÷ 60 计算,4 GB 机器填 25 左右,8 GB 机器填 45 左右。 这一步是外贸站最容易被忽略的,因为流量大的时候 CPU 占用高,大家会以为是 CPU 不够,其实是内存不够导致进程数上不去。
九、数据备份、外贸站的邮件发送和合规

这一节讲三件外贸站特有的运营事务。
第一件:备份。 外贸站的备份比国内站更关键,因为订单数据和客户数据涉及跨境合规,丢失不只是业务损失。
# 数据库备份(每天凌晨 3 点,用低权限账号)
echo "0 3 * * * root mysqldump -u backupuser -p你的密码 --single-transaction --quick wordpress | gzip > /var/backups/wp_$(date +\%F).sql.gz" >> /etc/cron.d/dbbackup
# 文件备份(每天 4 点)
echo "0 4 * * * root rsync -avz --delete /var/www/你的域名/ /var/backups/www/" >> /etc/cron.d/wwwbackup
# 清理 7 天前的旧备份
echo "0 5 * * * root find /var/backups -name '*.sql.gz' -mtime +7 -delete" >> /etc/cron.d/cleanbackup
备份必须同步到另一台机器或对象存储。 本机备份在磁盘坏掉时一起没。
第二件:邮件发送。 外贸站的订单确认、密码重置、运费通知全靠邮件,邮件进垃圾箱等于丢单。
这是海外 VPS 建站最高频的问题之一。 解决办法是配置 SPF、DKIM、DMARC 三个记录:
# 装 Postfix 并检查基础配置
apt install -y postfix mailutils
postconf -n | grep -E "myhostname|myorigin|smtpd"
SPF 记录(在域名 DNS 里加 TXT):v=spf1 a mx ip4:你的服务器IP ~all
DKIM 记录(装 Postfix 后生成):
# 安装 opendkim
apt install -y opendkim opendkim-tools
postfix conf -d 'opendkim.key = /etc/dkimkeys/dkim.private'
postfix conf -e 'opendkim.key = /etc/dkimkeys/dkim.private'
opendkim-genkey -D /etc/dkimkeys -d 你的域名 -r rsa
生成之后把输出的 TXT 记录加到 DNS 里,然后重启并测试:
systemctl restart opendkim postfix
# 测试发信
echo "test" | mail -s "Mail test" yourtest@你的邮箱
DMARC 记录(在 SPF 和 DKIM 都验证通过之后再加):v=DMARC1; p=none; rua=mailto:dmarc@你的域名
DMARC 建议先用 p=none 观察一段时间,确认没有邮件被误判之后再改成 p=quarantine 或 p=reject。
第三件:合规。 外贸站常见的三个要求:
- 隐私政策页——用 GDPR 口径写,说明收集什么数据、存多久、怎么删除;
- Cookie 同意横幅——欧盟和英国要求,在放任何追踪脚本(包括 Google Analytics 和 Facebook Pixel)之前就要弹;
- 退订链接——营销邮件里必须带一键退订,这是美国 CAN-SPAM 法案的硬要求。
这三个页面和技术实现都有现成插件,但更重要的是别把弹窗做成"点了才加载追踪脚本"—— 很多插件默认是加载即追踪,这不符合 GDPR 的"事先同意"要求。
按你的情况,下一步该看哪家
上面讲的是判断标准,但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条,直接去看对应的机型页比继续比价更快:
- 只想搭个站、预算优先:先看价格最低那档够不够用,别为用不上的配置付钱。看 zenlayer 当前机型与价格
- 做跨境或店群、需要多 IP:优先看 IP 类型与换 IP 政策,别只看配置。看 joysol 当前机型与价格
- 主要访客在国内、在意打开速度:先确认回程线路,再谈配置。看 zorocloud 当前机型与价格
- 只是开发测试、临时用:按小时或月付,用完就删,别买年付。看 zgovps 当前机型与价格
价格与库存以商家页面当日显示为准,下单前建议先确认退款窗口与是否支持按月付费。
十、上线验收清单和常见报错处理

外贸站上线的验收比国内站多两项:支付端到端测试和多语言验证。
| 验收项 | 通过阈值 | 怎么测 | |
|---|---|---|---|
| 首页首字节时间 | 小于 600 毫秒 | curl -o /dev/null -s -w "%{time_starttransfer}\n" https://你的域名 |
|
| LCP | 小于 2.5 秒 | Google PageSpeed Insights | |
| 首屏总传输 | 小于 1.5 MB | `curl -s https://你的域名 \ | wc -c` |
| 5xx 比例 | 0 | 连续 20 次请求统计状态码 | |
| 内存谷值 | 可用内存不低于 15% | free -m 连续采样 |
|
| 磁盘使用率 | 低于 80% | df -h |
|
| 证书链 | 验证通过 | openssl s_client -connect 你的域名:443 -servername 你的域名 |
|
| 证书自动续期 | dry-run 成功 | certbot renew --dry-run |
|
| 支付成功流程 | 小额真实订单走通 | 完整下单 | |
| 支付失败流程 | 能正确回滚订单 | 手动拒付测试 | |
| Webhook 事件 | 订单状态自动更新 | Stripe 后台发测试事件 | |
| 多语言切换 | 每种语言页都能打开 | 逐语言点击 | |
| hreflang | 双向标注完整 | `curl -s https://你的域名 \ | grep hreflang` |
| Sitemap | 已生成并提交 | Search Console | |
| 订单邮件 | 进收件箱不进垃圾箱 | 实发一封到外部邮箱 | |
| 数据库备份 | 当天文件存在 | ls -la /var/backups/ |
|
| 服务器时间 | synchronized 为 yes | timedatectl |
常见报错逐个对照处理:
报错一:支付成功但订单状态一直是"待付款"。 Webhook 没通。 查 WooCommerce 日志 tail -50 wp-content/uploads/wc-logs/*.log,在 Stripe 后台手动发测试事件,同时确认 Nginx 没拦 POST 请求。
报错二:checkout 页面 502。 PHP 内存不够,WooCommerce 结账是内存消耗大户。 改 memory_limit = 512M,重启 PHP-FPM。
报错三:后台很慢,尤其是商品列表页。 媒体库图片太多,缩略图生成拖慢查询。 跑 wp db optimize 并限制列表页每页显示数量。
报错四:CDN 刷新后价格还是旧的。 HTML 被缓存了。 改价格后必须刷新对应路径的缓存,或者给价格页面设置不缓存。
报错五:多语言页互相 404。 hreflang 指向的 URL 不存在,或者插件的翻译规则和实际 URL 结构对不上。 用 curl -s https://你的域名/es/ -o /dev/null -w "%{http_code}" 逐个测。
报错六:订单邮件进垃圾箱。 SPF、DKIM、DMARC 没配全,或者 SPF 里包含了发信服务商但 DNS 里没有那条记录。 用 dig +short TXT 你的域名 逐条核对。
报错七:图片上传后显示裂图。 PHP 内存不足或者上传大小限制。 改 PHP 的 upload_max_filesize、post_max_size、memory_limit 三项,加上 Nginx 的 client_max_body_size,四项都要改。
报错八:切换语言后某些产品页 404。 同一产品在不同语言的 slug 不一致。 用 WPML 的翻译关联功能重新绑定,不要手工建分类。
报错九:客户下单后一直收到重复的库存扣减通知。 Webhook 端点重复注册,或者队列任务重复消费。 检查 Stripe 后台的 webhook 列表里有没有同一个端点被添加两次。
最后三条收尾建议。 第一,上线前用真实小额订单完整走一遍支付和退款,不要只测支付成功这一条路径。 第二,上线后第一周每天看一次 PageSpeed 和 Search Console,把掉速和索引问题在早期抓出来。 第三,本文涉及的价格与配置来自真实商品库数据,采样时间 2026-11-14 12:47,未列出的项以官网当日报价为准;支付通道的开通条件、结算币种和费率以各支付服务商官网当日说明为准。

喜欢
高兴
鬼脸
呵呵
无聊
伤心