国内CDN与海外VPS怎么配合

一、先算账：CDN配合海外VPS到底省了多少钱

很多人以为"用CDN就是为了便宜"，其实顺序反了。CDN不直接省钱，它省的是你海外VPS那一侧的流量压力和端口压力。把这两件事分开算，账立刻就清楚了。

先设一个可复现的场景：站点月访问量 100 万 PV，页面平均 2 MB（含图片、脚本、样式），先按完全不缓存、每 PV 都回源一次计算。一个月的回源流量是 100 万乘 2 MB，也就是 1953 GB，约合 1.91 TB。

这个量级放在不同源站上，成本差异非常明显。sixtynet 的 LAX-MEDIUM 是 800 美元/年，折合每月 66.67 美元，配置是 8 核 CPU、8 GB 内存、160 GB 磁盘、10000 Mbps 端口、20000 GB 月流量，它的月流量单价是 3.413 美元/TB。1.91 TB 全部直连，按 1 美元约 7.1 元的估算汇率折算，约合 46 元/月。

同样的流量换成缓存命中率 80% 呢？只有 20% 的请求需要回源，回源流量降到 391 GB，约 0.38 TB，对应费用折算约 9 元/月，相当于直连的五分之一。命中率提到 90%，回源 195 GB，约 0.19 TB，折算约 4.6 元/月，又省掉一半回源量。

这三个数字连起来看，结论很直接：缓存命中率从 0 提到 80%，源站流量账单降到五分之一；命中率从 80% 提到 90%，再省掉一半回源量。 以 100 万 PV 的站点算，后半段那 10 个百分点一个月省下的回源量是 195 GB，按 3.413 美元/TB 的单价折算约 4.6 元。

但真正的关键在于端口。sixtynet LAX-MEDIUM 的端口是 10000 Mbps，而月付的 RosCloud 全部机型都是 500 Mbps 端口。RosCloud-01 是 19.99 美元/月，1 GB 内存、20 GB 磁盘、1024 GB 月流量，折合 19.99 美元/TB。同样是每 TB 流量的价格，LAX-MEDIUM 是 3.413 美元，RosCloud-01 是 19.99 美元，差了 5.86 倍。

这说明了一件事：CDN 能不能省到钱，取决于你的瓶颈是被"端口限速"卡住还是被"月流量额度"卡住。如果你的海外VPS 端口是 10000 Mbps 这种大带宽，你的瓶颈是延迟不是流量，CDN 的收益主要体现在"首字节时间从 800ms 降到 200ms"这种体验指标上，账单上省得不多。如果你的端口只有 500 Mbps，CDN 的收益才真正落到钱上。

再引入第三家做横向对比。云途的 DS.ES.C 是 700 元/月，64 GB 内存、800 GB 磁盘、2000 Mbps 端口、40000 GB 月流量，折合 17.92 元/TB。HK.DS.S 是 800 元/月，128 GB 内存、6000 GB 磁盘、2000 Mbps 端口、40000 GB 月流量，折合 20.48 元/TB。HK.DS.P 是 750 元/月，64 GB 内存、1024 GB 磁盘、40000 GB 流量，折合约 19.2 元/TB。而 LAX-MEDIUM 的 3.413 美元/TB，按 1 美元约 7.1 元的估算汇率折算约 24.23 元/TB——云途 DS.ES.C 的流量单价比它低约 26%，HK.DS.S 低约 15%，而内存分别是 8 倍和 16 倍。这里要说明的是，这个对比里的汇率是估算值，会随时间波动，结论看的是相对倍数而不是绝对金额。

这里要展开说一个容易被忽略的做法：源站和业务机分开部署。源站的负载特征是"带宽压力、CPU 压力小、内存压力小"，业务机（数据库、缓存、构建节点）的特征是"内存压力大、带宽压力小"。混在一台机器上，必然有一边的资源在浪费。按商品库的真实配置，源站应该看 sixtynet 这一类大端口低单价的机型，业务机应该看云途 HK.DS.S、DS.ES.D 这类大内存大硬盘的机型——两种成本模型解耦，各自选最优。

还有一种亏钱的方式要专门讲：缓存规则配错，导致接了 CDN 反而流量没降。如果源站的响应头里带着 Cache-Control: no-cache，CDN 每次都回源，你付了 CDN 的配置成本，源站流量一点没少。第五节会给出完整配法。

查看 iwebfusion 当前月价与库存

最后是流量与带宽的关系要算清楚。10000 Mbps 端口在满打满算时，一秒可以传 1.25 MB，也就是每小时 4500 GB、每月约 32 万 GB。这个数字远大于绝大多数机型的月流量额度，所以大端口机型的真实瓶颈是月流量额度而不是端口，而 500 Mbps 端口机型的瓶颈则是端口（500 Mbps 理论上一小时只能传 225 GB）。这两类机器的优化方向完全相反：前者要算流量费，后者要算并发。

二、备案与CDN的关系：国内节点和海外节点是两套东西

这是整个话题里最容易搞混的地方。先给结论："用不用 CDN"和"要不要备案"不是同一个问题，"用国内 CDN 节点"和"用海外 CDN 节点"才是。

大陆境内的 CDN 节点，通过电信、联通、移动的骨干网直接把内容分发给国内用户，使用的域名必须完成 ICP 备案。这是硬性监管要求，不是厂商能绕过的技术偏好——原因很现实：境内节点承载境内公众信息服务，域名指向境内加速服务并提供经营性服务，需要备案。

海外 CDN 节点（香港、新加坡、日本、美国等）不落在境内，对域名的备案要求就不同。要区分两种情况：域名解析到境内服务器、由境内服务器提供内容，需要备案；域名解析到境外服务器，境内用户通过国际线路访问，通常不需要备案，但也因此用不上境内的骨干网优化。

那么"国内CDN与海外VPS配合"实际能落地的是哪几种形态？

形态A：海外VPS 做源站 + 海外 CDN 节点。 全程境外，境内用户走国际出口。优点是完全不需要备案，部署一天就能上线；缺点是境内用户的首字节时间天然受国际出口拥塞影响，晚高峰抖动明显。适合项目初期、还没有国内主体公司、也没有备案打算的情况。

形态B：海外VPS 做源站 + 境外 CDN + 境内 CDN 双层。 严格说这是多 CDN，境内那层仍然受备案约束，需要有备案主体才能用。

形态C：海外VPS 做源站 + 自建反向代理（VPS 上跑 Nginx 或开源 CDN 软件）+ DNS 分线路解析。 这不是 CDN 服务，是用你自己的 VPS 当地缘节点。这条路的价值在于省掉第三方 CDN 的流量费：国内访客通过 DNS 解析被导向你 VPS 里的缓存节点，境外访客直接走源站。代价是缓存命中逻辑、回源保护、突发带宽成本全在自己身上。

这里必须纠正一个常见误解：把 CDN 软件装在 VPS 上，它不会凭空产生 CDN 的效果。 CDN 的核心价值是边缘节点数量——用户在哪个运营商的哪个城市，就近从哪台机器取数据。一台洛杉矶的 VPS 装再多缓存软件，对一个杭州用户的物理距离也不会缩短一毫米。形态C的真实收益不是"加速"，而是"省掉第三方 CDN 的流量费"，代价是你要自己承担 10000 Mbps 端口被集中回源时的突发成本。

形态D：境内服务器 + 备案域名 + 境内 CDN，海外VPS 只做 API 或其他非公开服务。 这是唯一能真正用上境内 CDN 节点的形态，前提是你有备案主体。

形态选择上有一条实操判断：先看你的用户在哪。如果境内用户占七成以上且你手上有备案主体，走形态D 收益最大；如果没有备案主体，走形态A 或形态C，不要为了"用上国内CDN"去做一个长期用不上的备案流程——ICP 备案本身通常要几周，而且需要国内主体和境内服务器。

查 racknerd 在售套餐与库存

还有一条与成本直接相关的观察：形态D 的源站可以放在境内机房，形态A 的源站必须放在境外机房。 这意味着同样的 2000 Mbps 端口，在境内机房和在洛杉矶机房，能承载的并发用户数不在一个量级上，因为境内用户到境内机房的物理距离只有几十公里，出境则要跨太平洋。如果你已经完成了备案，那么"源站放哪里"这件事带来的收益，通常比"CDN 用哪家"更大。

三、回源策略：IP回源、域名回源与中间层怎么选

回源策略决定了 CDN 节点从哪里取数据，也决定你的海外VPS 每天被拉走多少流量。常见的有四种，各自适用场景不同。

IP 回源是最基础的方式：CDN 节点直接请求源站 IP。优点是配置最简单，源站不需要任何特殊规则；缺点是源站必须能识别出这是 CDN 的请求，否则无法做针对性的缓存策略，也没法在一个 IP 上区分多个站点的请求。

域名回源（把源站域名 CNAME 到 CDN）是最主流的方式。CDN 解析到源站时带上原 Host 头，源站上的 Nginx 可以按域名做多站点分发，也能按域名做日志分析和限速。

回源到中间层（回源节点或边缘中转）是给源站加保护的做法：CDN 不直接打源站，而是打一层专门做回源优化的节点，这层负责合并请求、做回源缓存、过滤恶意请求。适合源站配置比较简单、不想被攻击面直接暴露的场景。

回源到对象存储是静态站点的最优解：把整个站点同步到 OSS/S3 这类对象存储，CDN 直接从对象存储回源，源站VPS 彻底不参与静态请求。这条路的价值在于源站 IP 完全不暴露，也不会被爬虫打到源站。对应到商品库里的配置参考，sixtynet LAX-Storage-1TB 是 700 美元/年、折合每月 58.33 美元，8 GB 内存、1000 GB 磁盘、10000 Mbps 端口、15000 GB 月流量，磁盘单价 0.058 美元/GB、内存单价 7.29 美元/GB、流量单价 3.982 美元/TB；LAX-Storage-500G 是 400 美元/年、折合 33.33 美元/月，磁盘单价 0.067 美元/GB。这两台的定位是存储型机器，适合做静态资源源站或备份节点，而不是通用业务机。

配置回源时有三个参数必须显式设对，否则源站会被 CDN 打垮。

回源超时（Origin Timeout）。 默认常见值是 30 秒。你的源站如果偶尔响应超过 30 秒，CDN 会直接报错，用户看到 502。设成 60 秒更稳，但前提是你的 php-fpm 队列能撑住这期间的并发。

回源连接数（Max Connections per Host）。 这是 CDN 边缘节点对单源站的最大并发连接数。这个值如果大于你源站 Nginx 的上限，超出的请求会排队甚至被 reset，用户侧表现是高峰期大量 502。 具体算一下：Nginx 默认 worker_processes auto（取 CPU 核数），worker_connections 1024。一台 2 核机器的 Nginx 理论上限是 2 乘 1024 也就是 2048 个并发连接，再扣掉 keepalive 复用和 TLS 握手的占用，实际稳定承载在 1200 到 1500 个并发比较安全。所以回源连接数设成 1024 是保守稳妥的选择，设成 4096 就是在赌你的源站扛得住。

回源协议。 HTTP 回源比 HTTPS 回源少一层 TLS 握手，部分厂商对回源 HTTPS 单独计费。但判断依据很简单：看你的源站是不是暴露在公网。是，就必须 HTTPS 回源，这是合规和安全的底线；只有云厂商 VPC 内网回源那种形式，才可以走 HTTP，因为那时加密由内网保证。

还有一个容易漏掉的点：回源要带 Host 头。很多人在 DNS 里把源站域名 CNAME 到 CDN 之后，又把源站的 A 记录指向同一台机器，结果流量在两边各跑一半，统计口径完全对不上。要么把源站 A 记录删掉只留 CNAME，要么用回源 IP 加 Host 头的方式明确指定。

查 spinservers 在售套餐与库存

最后是回源带宽的预留量。这里给一个可以自己算的公式：回源速率上限 = 源站端口带宽 乘以 50%。10000 Mbps 端口留一半就是 5000 Mbps 回源上限，对 sixtynet LAX-MEDIUM 这种 20000 GB 月流量的机型，5000 Mbps 打满一小时能传 2250 GB，约等于月额度的三分之一多，配合缓存命中率完全够用。而 500 Mbps 端口的 RosCloud 系列，留一半就是 250 Mbps，这个数字要严格卡住，否则 CDN 集中回源时会和正常用户流量抢带宽。

四、缓存规则：Cache-Control与TTL的完整配法

缓存规则配错，前面的账全部白算。这一节给可以直接抄的配置。

第一个原则是静态资源长 TTL、动态页面短 TTL 或不缓存。典型设置如下：

资源类型	Cache-Control	边缘 TTL	理由
带 hash 的脚本与样式	public, max-age=31536000, immutable	1 年	文件名带内容指纹，内容变了文件名就变
图片（不含用户上传）	public, max-age=2592000	30 天	体积大、更新少
首页 HTML	public, max-age=60, s-maxage=600	边缘 10 分钟	源站 1 分钟、边缘 10 分钟
文章详情页	public, max-age=60, s-maxage=300	边缘 5 分钟	更新不频繁但要较快生效
搜索结果与分类页	public, max-age=0, s-maxage=120	边缘 2 分钟	兼顾实时性与命中率
后台与接口	no-store, no-cache	不缓存	必须实时
登录态页面	private, no-store	不缓存	绝不能缓存

zenlayer 官网机型与实时报价

注意 s-maxage 这个参数。浏览器缓存由 max-age 控制，CDN 边缘缓存由 s-maxage 控制。很多站长只设了 max-age=3600，结果 CDN 也缓存了 1 小时，改版上线后用户看到的还是旧页面——这就是"改完网站没生效"类投诉里占比最大的一种原因。

第二个原则是源站缓存头与 CDN 控制台里的"忽略源站缓存头"选项要成对设置。如果你开了忽略源站，CDN 就完全按控制台里设的 TTL 走，不管源站发什么头；如果你没开忽略源站，源站发来的 Cache-Control: no-cache 会让 CDN 每次都回源——这正是很多站接了 CDN 反而更慢、源站流量一点没降的第一原因。

排查方法很直接，看源站响应头：

curl -sI https://your-domain.com/ | grep -iE "cache-control|age|x-cache|via"

看到 X-Cache: MISS 并且 Age 一直是 0，说明每次都在回源；Age 有增长说明命中了。

第三个原则是开启 Brotli 或 Gzip 的边缘压缩。这直接决定了 1 MB 文件在边缘被压到多少。经验值是：Brotli 对 HTML、脚本、样式的压缩率通常在 60% 到 75%（相对原始大小），Gzip 在 55% 到 70%。一个 2 MB 的页面开启 Brotli 后实际传输量约 500 KB 到 800 KB。这等于凭空多出 60% 的免费带宽，在同等 VPS 配置下把可承载的访问量抬高了大约 2 到 2.5 倍。换算回上一节的成本账：源站的可承载 PV 直接乘以 2 到 2.5，等价于月流量账单降到四成左右。

验证方法：

curl -s -o /dev/null -w "size_download=%{size_download}\n" \
  -H "Accept-Encoding: br, gzip" https://your-domain.com/test.js

第四个原则是静态资源的版本化。如果你在文件名里不带内容指纹（比如 app.js 而不是 app.a1b2c3.js），那么给资源设长 TTL 就一定会出现"改了代码用户拿到旧文件"的问题。两个办法二选一：文件名带指纹，或者给 HTML 设短 TTL 让浏览器每次都来问一次。后者会吃掉一部分命中率，前者是标准做法。

第五个原则是给用户上传的内容单独设规则。用户上传的图片如果是原文件名保存的，配 30 天 TTL 就会在用户替换同名文件后拿到旧图。正确做法是上传时改名为内容指纹，同步把旧的从边缘刷新（purge）掉。

五、缓存键与忽略规则：为什么命中率上不去

命中率是决定账单的唯一变量，值得单独一节。命中率上不去有四个常见原因，按出现频率排序。

原因一：query string 全进了缓存键。 默认很多 CDN 会把 URL 上的所有查询参数都算进缓存键。这对 WordPress 这类带大量跟踪参数的站点是灾难：同一个页面因为 utm_source 不同，被缓存成成千上万个副本，每个副本只服务过几个请求，命中率接近零。正确做法是把跟踪参数加进忽略列表：

utm_source, utm_medium, utm_campaign, utm_term, utm_content, gclid, fbclid, spm, from, ref

WordPress 用户还要额外注意 ?p=123、?page_id=45 这类参数——它们是页面标识，不能加进忽略列表，加了会导致不同文章共用一个缓存键，页面内容直接串掉。

原因二：源站发了 no-cache 或 no-store。 这个问题上一节讲过。源站应该按第四节表格那样，对该缓存的发 max-age 加 s-maxage，对该不缓存的发 no-store。可以定期扫一遍自己的响应头确认。

原因三：动态内容被放进了不该缓存的路径。 比如整个站点都按目录配了缓存规则，/wp-admin/ 和 /wp-json/ 也被套上了 10 分钟的 TTL。后台操作要等 10 分钟才生效，接口返回旧数据。缓存规则一定要按路径分批配，不要一刀切。

原因四：缓存规则配了但没做预热。 新站点接入 CDN 后，前几分钟所有请求都是 MISS，用户感知就是"变慢了"。大促前应主动做预热，把首页、分类页、热门文章的资源列表批量预热到各边缘节点。

还有两个提升命中率的实用技巧。

合并小文件请求（HTTP/2 或 HTTP/3）。 一个页面如果有 30 个小图标和 5 个脚本文件，走 HTTP/1.1 就要 35 次握手；HTTP/2 多路复用后是 1 次连接。边缘开启 HTTP/2 是默认动作，你要确认的是源站也开了。

按文件后缀配规则，而不是只按目录配。 图片、字体、脚本、样式分别给不同 TTL，比"整个站 10 分钟"精细得多。这条配置量不大，但对命中率影响明显。

监控命中率的方法：主流 CDN 控制台都有"命中率"和"回源流量"两个核心指标。把它们和你的账单放在一起看——如果流量账单涨了而命中率没变，那多半是源站侧的问题（缓存头被改了），如果是命中率掉了，那是缓存键或规则的问题。这两种情况的排查方向完全相反，先定位再动手，能省下大量时间。

查 cloudcone 在售套餐与库存

还有一个容易被忽略的命中率杀手：同一页面被多个域名访问。比如同一份内容同时在 example.com、www.example.com、还有各个国家站点的子域名下发布，如果缓存键不包含主机名归一化规则，每个域名都会独立回源一次，等于把命中率又打散了一轮。正确做法是开启"忽略主机名"或把主域名设为规范源站，其余域名 301 到它。

六、HTTPS证书同步：CDN换证书比源站换证书更容易出事

证书这一节的坑不在技术，在流程。源站只有你一个人管，CDN 后面有边缘节点、回源配置、可能的中间层，一处不同步就是全站报警。

方案一：CDN 控制台托管证书。 在 CDN 厂商处申请证书，厂商自动续期并下发到所有边缘节点，源站装一份用于回源校验即可。这是最省事的做法，适合绝大多数场景，代价是证书私钥在 CDN 厂商手里。

方案二：Let's Encrypt 加 certbot 源站自动续期，再推送到 CDN。 源站用 certbot 续期，续期后通过 API 把新证书推给 CDN：

# 续期后触发 CDN 证书更新（具体参数以各家 CDN 文档为准）
certbot renew --deploy-hook "/usr/local/bin/cert-deploy.sh"

#!/bin/bash
# cert-deploy.sh：上传 CDN 并 reload 源站
CERT=/etc/letsencrypt/live/your-domain.com/fullchain.pem
KEY=/etc/letsencrypt/live/your-domain.com/privkey.pem
curl -s -X POST "https://api.cdn-provider.com/ssl/deploy" \
  --data-urlencode "cert@${CERT}" --data-urlencode "key@${KEY}" \
  --data-urlencode "domain=your-domain.com"
systemctl reload nginx

方案三：源站证书到期等于全站不可用，必须避免。 这里有一个非常经典的故障叫"明明续期成功却报证书过期"：certbot 已经把磁盘上的证书换掉了，但 nginx 进程还拿着旧证书在跑，因为 reload 没有执行。所以 --deploy-hook 脚本里的第一步就应该 reload nginx，让新证书立刻生效。

验收阈值有两个数字：证书剩余有效期必须大于 30 天，且 CDN 边缘返回的证书到期日与源站一致、差值小于 1 天。 检查方法：

# 查 CDN 边缘返回的证书
echo | openssl s_client -connect your-domain.com:443 -servername your-domain.com 2>/dev/null \
  | openssl x509 -noout -dates -issuer -subject

排查证书问题的三条命令：

# 1. 域名解析是否指向 CDN
dig +short your-domain.com

# 2. 源站证书到期时间
echo | openssl s_client -connect origin-ip:443 2>/dev/null | openssl x509 -noout -dates

# 3. TLS 协议与加密套件是否达标
nmap --script ssl-enum-ciphers -p 443 your-domain.com

还有一条必须提前确认的事：启用 HSTS 之前，确保所有子域名都已经能走 HTTPS。HSTS 一旦下发，浏览器在有效期内会强制用 HTTPS 访问，HTTP 请求根本不会发到服务器，你就没有机会再靠 301 跳转兜底。有些团队会先设 max-age=300 试一周，确认没有内网 HTTP 服务被打断，再调到一年。

digitalocean 官网机型与实时报价

如果你的站点同时接了 CDN 和对象存储回源，两边的证书要分别管，不要指望其中一边过期时另一边能顶上。这是很多团队踩过的坑：源站证书由 certbot 管，CDN 证书由 CDN 控制台托管，两套完全独立，任一环节漏掉续期都会导致部分用户看到证书错误。

七、验收阈值：用哪些数字判断方案成功

不给阈值的验收都是"感觉挺快"。下面这组数字是通用工程口径，可以直接拿去用。

指标	达标线	优秀线	怎么测
首字节 TTFB（境内访客）	小于 300ms	小于 150ms	curl 的 time_starttransfer
1 MB 文件下载耗时	小于 2s	小于 800ms	curl 的 time_total
页面最大内容绘制	小于 1.8s	小于 1.2s	Chrome DevTools
缓存命中率	大于 70%	大于 85%	CDN 控制台统计
回源请求占总请求比例	小于 30%	小于 15%	CDN 控制台统计
源站 CPU 峰值占用	小于 40%	小于 20%	top 与 htop
源站内存占用	小于 15% 且无 OOM 记录	小于 10%	free -h 加 dmesg
磁盘占用	小于 50%	小于 35%	df -h
晚高峰丢包率	小于 1%	小于 0.1%	mtr 报告
晚高峰抖动	小于 30ms	小于 10ms	mtr 连续采样
证书剩余有效期	大于 30 天	大于 60 天	openssl x509

查 hostwinds 在售套餐与库存

其中最关键的两个是缓存命中率和回源请求占比，因为它们直接决定账单。经验换算关系是：命中率每提高 10 个百分点，源站月流量大约下降 10%。在 100 万 PV、单页 2 MB 的站点上，命中率从 80% 提到 90%，一月少回源 195 GB，按 LAX-MEDIUM 的 3.413 美元/TB 单价折算约 4.6 元。

源站侧的三个数字也有明确指向。CPU 峰值超过 40%，说明源站承担了本该由边缘完成的计算，通常是缓存规则没生效或者回源连接数设太大。内存占用超过 15%，说明 php-fpm 的 worker 数配得偏高，或者有内存泄漏。磁盘超过 50% 时要立刻处理，因为日志和数据库文件是持续增长的，等到 100% 时服务会以非常难看的姿态挂掉。

这些阈值要在上线后第一个完整的高峰周再复测一次，而不是刚配置完就测。刚配置完的那次只反映了缓存预热后的理想状态，而预热恰恰是最容易骗人的那一份数据。

一个实用的复测清单：连续七天、每天固定三个时段各跑一次 curl 计时，收集 21 组数据，取中位数和最差值。用中位数做验收，用最差值做预案。 只用单次测量下结论，无论测的是最好的那次还是最坏的那次，都会被下一次的随机波动推翻。

八、测延迟：ping、mtr与traceroute的分工

ping 只告诉你"能不能通、平均多少毫秒"，但它不区分"这条路径有 180ms 的物理时延"和"这条路径有 180ms 的排队时延"。而在 CDN 场景里，排队时延才是体验杀手。

三个工具的分工很明确：

ping 测连通性与平均往返时延。丢包率用连续 100 个包的统计看，不要只看前几个包。ping 连续 100 次得到的平均时延，如果和 20 次得到的差别很大，说明链路本身不稳定。

traceroute 看路径拓扑，定位在第几跳开始劣化。用途是判断"是不是在某个国际出口段堵了"，而不是用来测最终时延——因为中间跳的响应可能是路由器代答的，参考价值有限。

mtr 把 traceroute 和 ping 合在一起，连续发包并统计每一跳的丢包率、抖动和时延变化。这是判断晚高峰丢包的标准工具。

正确用法：

# 测 100 个包，看平均时延、最小最大值，以及末尾的丢包统计
ping -c 100 -i 0.2 your-domain.com

# 每跳丢包与时延，跑几分钟看抖动
mtr -r -c 300 -i 0.2 your-domain.com

# 持续监控模式，观察晚高峰变化
mtr -u -i 1 your-domain.com

# UDP 端口探测（有些节点会限速 ICMP）
mtr --udp --port 443 -r -c 300 your-domain.com

判读方法有三条：

某跳丢包率高、但后续跳正常，说明这一跳在限速 ICMP 而不是真的丢包，直接忽略。很多运营商的路由器对 ICMP 有速率限制。

从某一跳开始丢包且持续到终点，这是真实丢包，这一段路径有问题。

时延在某跳突然跳升 100ms 以上，这是典型的国际出口拥塞，或者走了绕路线路。

需要特别强调的是晚高峰的定义：国内用户访问高峰是 20:00 到 23:00，其中 21:00 到 22:00 是最典型的拥塞时段。只在上午测一次得出的结论几乎没有参考价值，因为限速策略往往是在特定时段动态下发的。

查看 interserver 当前月价与库存

还有一个常被忽略的测法选择：ping 的间隔不要用默认的 1 秒。 默认间隔会让 100 个包跑将近两分钟，这段时间里链路状态可能已经变了。改成 0.2 秒间隔，100 个包 20 秒跑完，能在同一个时间窗口里拿到更密集的采样，看到的丢包也更真实。

九、晚高峰怎么测：时段、抖动与丢包的判读

延迟测试单列一节，是因为它决定了你买不买错线路。

测试时段的最低要求是三个。 上午 10:00 测一次代表业务低谷，下午 15:00 测一次代表平峰，晚间 21:00 到 22:00 测一次代表真实高峰。三个时段的差值本身就是重要信息：如果晚高峰比上午高出 100ms 以上，说明这条线路的拥塞是时段的，不是线路本身的，这属于正常现象，需要在选型时把晚高峰数值作为唯一标准。

丢包的判读要看它出现在哪一跳。 具体做法是先用 mtr 定位到丢包起始的那一跳，然后用普通 traceroute 再走一遍确认。如果两跳都显示丢包，丢包点是真实的。

抖动的判读标准是相邻包的时延差。 连续发包的时延如果忽高忽低，比平均时延高更影响体验——TCP 会因为抖动而频繁触发重传，页面加载时间被拉长。抖动小于 30ms 属于可接受，小于 10ms 属于优秀。mtr 的连续采样模式下，相邻两次输出的时延差超过 30ms 就要记一笔。

去程与回程要分别测。 用 mtr 从你的国内网络测到海外VPS 是去程（通常走电信、联通、移动的骨干网出海口），用 mtr 从海外VPS 测回国内是回程（通常走对方的网络）。两者差别很大，因为出海和回国走的是不同的链路。很多商家标注的线路类型（CN2 GIA、9929、CUG 等）说的正是回程，所以验收时必须自己测回程，不能信商家页面。

自测回程的方法：先在你的海外VPS 上装一个 mtr 或 nexttrace，向你的国内测试机 IP 连续发包：

mtr -u -i 1 -r -c 300 your-cn-test-ip

延迟达标线是多少？ 通用参考：面向普通用户的站点，境内访客 TTFB 小于 300ms 算及格；面向国内用户的企业后台类应用，小于 150ms 才好用；游戏、实时音视频这类对延迟敏感的业务，跨境方案基本不达标，这不是测量的结果而是物理限制。

丢包的达标线是 1%。 超过 1% 时 TCP 重传会明显增加，页面加载时间波动变大；超过 3% 时会出现间歇性卡顿和请求失败。

查看 itldc 当前月价与库存

需要说明的是，测延迟和选线路是两件事。延迟测试帮你判断"现在这台机器能不能用"，选线路是"这类业务应该买哪种线路"。商品库里的机型名已经能看出定位，比如 sixtynet 的 LAX-MEDIUM 和 LAX-LARGE 是通用大带宽型，Los Angeles China Unicom-Premium 是 2500 美元/年、折合每月 208.33 美元、端口只有 100 Mbps 的联通精品线路型——端口小到 100 Mbps 本身就说明它卖的是线路质量不是带宽，这类机型不适合跑大流量静态资源分发，把它放在 CDN 源站的位置上会浪费它的价值。

十、什么情况下不该上CDN：四类反常识场景

这一节是全文最重要的部分。很多站上了 CDN 之后体验反而变差，原因是场景不匹配。

场景一：访问量极低的站点。 月 PV 不到 1000，日均访问只有几十次。这个规模下，CDN 的起订、缓存预热、配置时间成本完全不成比例，直接用一台海外VPS 跑 Nginx 反而更简单更快。用数字感受一下：1000 PV 乘 2 MB 是 1.95 GB 月流量，按 sixtynet LAX-STARTER 的 3.413 美元/TB 单价计算，1.95 GB 折合不到 0.05 元。流量费用低到可以忽略，CDN 省下的钱还不够付配置时间的成本。替代方案：选一台月付的最低配机型即可。

场景二：API 接口为主、返回数据不可缓存。 后端接口的响应每请求都不同，缓存命中率趋近于 0，你付出了配置成本却一点流量都没省下。替代方案：API 不上 CDN，只给静态资源和前端页面加 CDN，或者在 Nginx 层用 proxy_cache 单独缓存那些确实有重复请求的查询接口。

场景三：源站本身就要求低延迟的实时业务。 游戏服务端、实时音视频、WebSocket、在线撮合这类业务，CDN 的边缘缓存反而会引入不必要的排队。替代方案：这类业务走直连，并在 Nginx 里显式关闭缓存。

location /ws {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_cache off;
    proxy_read_timeout 3600s;
}

场景四：目标用户全在境外，或者就在机房所在国家。 用户全在欧洲却用一台美国西雅图的 VPS 加美国 CDN 节点毫无意义——多绕一圈，还多一个故障点。替代方案：按用户分布选机房，选对区域比加多少层缓存都管用。

除了这四类，还有两个不属于"场景"但同样重要的限制条件。

带宽是共享还是独享。 如果你的 VPS 端口是共享带宽（500 Mbps 端口按比例分配），CDN 集中回源时突发流量会被立刻抢占，表现是"平时很快，一到高峰源站就慢"。替代方案：给 CDN 配回源限速，比如源站出口 50 Mbps 就把回源上限设成 30 Mbps，宁可回源慢一点也不让源站被打挂。

IP 资源与暴露面。 如果你的业务对 IP 有要求（需要特定国家、需要在多个 IP 间轮换、或者不希望源站 IP 出现在公开记录里），CDN 边缘节点的 IP 是厂商的，源站 IP 是否暴露需要单独考虑。替代方案：用防火墙白名单把源站锁死，只允许 CDN 回源 IP 段访问。

# 只允许 CDN 回源 IP 段访问 80 端口
iptables -A INPUT -p tcp --dport 80 -s 203.0.113.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

查 justg 在售套餐与库存

必须强调：以上判断依据全部是机房位置、线路类型、计费方式、IP 资源这些公开事实，与具体商家的服务好坏无关。 同一台机器、同一套配置，在不同场景下的最优选择完全相反。

十一、成本对比表与配置选型

把前面的计算汇总成表。场景：月 100 万 PV，单页 2 MB，海外源站。

架构	源站机型	月流量成本	额外成本	首字节体验
纯海外VPS 直连	sixtynet LAX-STARTER（2000 Mbps / 5000 GB）	1.91 TB 乘 3.413 美元/TB，约合 46 元	无	600 到 900ms，晚高峰抖动大
海外VPS 加海外CDN	sixtynet LAX-STARTER	回源 0.38 TB，约合 9 元	加上 CDN 流量费	150 到 300ms
自建缓存层（VPS 加 CDN 软件）	sixtynet LAX-MEDIUM（10000 Mbps / 20000 GB）	仍按 1.91 TB 计，约合 46 元	无额外	取决于边缘节点数，本质无提升
大内存大流量源站	云途 DS.ES.C（64 GB / 800 GB / 2000 Mbps / 40000 GB）	700 元/月，17.92 元/TB	无	境内节点，150ms 内

rabisu 官网机型与实时报价

第四行值得单独说。云途 DS.ES.C 是 700 元/月、64 GB 内存、800 GB 磁盘、2000 Mbps 端口、40000 GB 月流量、库存 1 台的机型；同价位段还有云途 HK.DS.P（750 元/月，64 GB 内存、1024 GB 磁盘、40000 GB 流量，库存 5 台）和云途 HK.DS.S（800 元/月，128 GB 内存、6000 GB 磁盘、40000 GB 流量，库存 13 台）。它们的定位是大内存大流量大硬盘，适合跑数据库、缓存、构建节点，也适合承接静态资源源站或备份节点。

而 sixtynet LAX-MEDIUM 这类 8 GB 内存、160 GB 磁盘、10000 Mbps 端口、20000 GB 流的机型，定位是大带宽，适合做源站和下载分发节点。

把源站和业务机拆开，就是把两种成本模型解耦。 这一句话是本文最实用的结论。

另外要提醒一个容易忽略的对比维度：磁盘单价和内存单价在不同产品线里的差距，比流量单价还大。 LAX-Storage-1TB 的磁盘单价是 0.058 美元/GB，而 LAX-MEDIUM 是 0.417 美元/GB，差了 7.2 倍。如果你只是要存文件（备份、镜像、静态资源），却买了一台通用型的机器，磁盘成本就是白付的高价。反过来，要跑数据库却买存储型机器，内存单价 7.29 美元/GB 对上通用型同规格，配置又完全不够用。

所有价格口径必须交代清楚：上表价格来自渠道库快照（数据时间 2026-11-05 09:01），以官网当日报价为准。商品库的 notes 字段明确写着部分参数"入库前请核对原页；未提供的参数留空"，所以实际下单前务必到商家页面确认当前价格、库存和配置。库存字段是动态的：云途多数机型显示为 0，HK.DS.P 是 5 台，HK.DS.S 是 13 台，DS.ES.C 和 DS.ES.D 各 1 台，下单前先确认，不要按缓存的页面信息决策。

十二、结论：四类人分别该买哪一档

不做"视情况而定"式的收尾，按四类人给出具体选择。

第一类：月 PV 在 1 万以下、刚开始建站的新手。 不要碰 CDN，也不用买大带宽。直接选一台月付的最低配：端口 500 Mbps、1 TB 月流量的机型完全够用，流量单价虽然贵，但你的用量根本触不到额度上限。把钱省下来买域名和证书。

第二类：月 PV 10 万到 100 万、有静态资源（图片、脚本、样式）的中小站点。 这是 CDN 收益最大的区间。选一台 2000 Mbps 以上端口、5000 GB 以上月流量的源站机型，CDN 命中率目标定在 85% 以上。缓存规则按第四节那张表逐条配，先配缓存再降配置，顺序不能反。

第三类：月 PV 100 万以上、有数据库和业务后端的团队。 源站与业务机必须分开。源站用大带宽低流量单价的大端口机型，业务机用大内存大硬盘的机型（云途 HK.DS.S 这一档）。回源连接数保守设在 1024，回源限速设在源站出口的一半。CDN 只覆盖静态资源和页面层，API 直连。

第四类：没有 ICP 备案主体、但需要境内访问速度的团队。 只能走形态A 或形态C。先实测三时段延迟，把晚高峰数值作为唯一标准。如果晚高峰比上午高出 100ms 以上且你的业务对延迟敏感，境外节点的方案不要硬上——替代方案是把核心业务放在境内节点，境外VPS 只承担不需要低延迟的部分（异步任务、备份、镜像分发）。

sixtynet 官网机型与实时报价

选型的共同原则只有一条：先量后买，先配后降。把第七节那张阈值表打印出来，验收通过再付钱。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

• 只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看 iwebfusion 当前机型与价格
• 做跨境或店群、需要多 IP：优先看 IP 类型与换 IP 政策，别只看配置。看 racknerd 当前机型与价格
• 主要访客在国内、在意打开速度：先确认回程线路，再谈配置。看 spinservers 当前机型与价格
• 跑游戏服或实时业务：看上行抖动与防御能力，普通套餐往往不达标。看 zenlayer 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

十三、常见问题

接了 CDN 之后源站 IP 还是被攻击了，为什么？ 通常三个原因：一是你在 DNS 里同时保留了源站 A 记录和 CDN 的 CNAME，搜索引擎和扫描器都能猜到源站 IP；二是回源用的是域名解析而不是固定 IP，解析记录里能看到源站地址；三是历史解析记录已被第三方数据库收录。解决办法是删除源站 A 记录、只用 CNAME、并用防火墙白名单限制只有 CDN 回源 IP 能访问。

CDN 缓存命中率很低，怎么排查？ 按顺序查三件事：第一，看源站响应头里有没有 Cache-Control: no-cache 或 no-store，有的话 CDN 每次都回源；第二，看缓存键是不是把 query string 全带上了，WordPress 站最常见；第三，看 X-Cache 头是 MISS 还是 HIT，以及 Age 头是否在增长。

源站和 CDN 之间要不要加密？ 源站暴露在公网时必须用 HTTPS 回源，这是合规与安全的基本要求。只有云厂商 VPC 内网回源那种形式才可以用 HTTP，因为那时加密由内网保证。

为什么换了 CDN 之后打开速度反而慢了？ 三个高频原因：一是冷启动，第一次访问没有缓存，节点要回源，表现为"刚开始慢、用一会儿就快了"；二是缓存规则配了很短的 TTL，页面几乎不回源，等于多绕了一层节点；三是源站到 CDN 节点的回源路径质量差，特别是跨境回源时源站机房位置选得不合适。

海外VPS做源站，回源带宽应该留多少余量？ 经验上按峰值回源速率的 2 到 3 倍预留。如果你的站点在晚高峰集中来量，把源站端口的 50% 以上留空。10000 Mbps 端口的机型基本不用担心这个问题，500 Mbps 端口的机型则要严格控制回源并发。

CDN 能不能让我的海外VPS换一个更便宜的配置？ 能，而且这正是它最实际的省钱方式。做法是先把回源缓存规则配好、确认命中率稳定在 80% 以上，再把源站从 10000 Mbps 端口的机型降到 2000 Mbps 端口的机型。直接反过来做——先降配置再加 CDN——必然翻车。

网站要备案才能用国内 CDN，那海外 VPS 配国内 CDN 还有意义吗？ 如果确实没有备案主体，走国内节点这条路是不通的。此时可行的是境外节点方案，或者境外 VPS 加自建边缘缓存的形态，代价是你要自己承担全部流量成本。

该选独立 IP 还是共享 IP？ 需要对外提供服务、需要做搜索引擎收录、或者你的业务逻辑依赖 IP 稳定性时，选独立 IP，商品库里多数机型标注 IPv4 一个地址。资源型、纯内部使用的场景可以考虑共享，但要注意共享 IP 上邻居的行为会影响你的端口。

CDN 计费是按流量还是按请求数？ 主流厂商两种都有，静态资源一般按流量、动态请求和函数计算按请求数。选型时看你的流量特征：大文件多按流量便宜，小文件海量请求多则按请求数的套餐可能更划算。这个要以各家官网当日报价为准。