做过跨境的运维大概都遇到过这种场景：CDN 控制台上写着「覆盖 200+ 国家」，账单也不便宜，可德国用户打开首页还是要 4 秒。问题通常不在节点数量，而在节点落在哪、以及回源那段路走得好不好。这篇不讲概念，直接给一棵决策树，把「选节点」和「配回源」拆开说。
先回答三个问题，选择树自然就出来了
别急着挑机房。先把三个变量写清楚：用户主要在哪、源站部署在哪、内容是静态还是动态。这三个答案一确定，节点布局和回源方式基本就定死了。
| 用户分布 | 源站位置 | 内容类型 | 节点布局 | 回源建议 |
|---|---|---|---|---|
| 北美为主 | 美西 | 静态为主 | 美西 + 美东 + 欧洲边缘 | 同区域直连，TTL 可放长 |
| 北美 + 欧洲 | 香港 / 深圳 | 静态 + 少量动态 | 美西、法兰克福、伦敦 | 跨太平洋回源，重点看线路 |
| 东南亚 | 香港 / 新加坡 | 动态为主（下单） | 新加坡、香港、雅加达 | 长连接 + 就近汇聚回源 |
| 中东 / 拉美 | 美东 / 欧洲 | 静态 + API | 区域边缘 + 中心 POP | 区域汇聚，别让每台边缘单独回源 |
展开说两句。做北美 B2B 独立站，源站还压在深圳，那不管边缘铺多少节点，回源那一段还是得跨太平洋，动态接口的首包时间会被硬生生拖住，这时候要么把源站迁到美西，要么在香港或美西做一次中转。反过来，如果订单集中在东南亚，但用户散在多个国家，就别让每台边缘节点各回各的源，把动态请求就近汇聚到一两个 POP 再统一回源，源站压力能降一大截。
节点多≠快，卡点通常在三个地方
我们见过客户拿「全球几千个节点」当卖点，实测下来东南亚还不如一台新加坡的轻量服务器。原因一般是这几个：
- 接入段线路质量：机房对外广播 BGP 是一回事，连到当地 ISP 是不是直连 peer 是另一回事。某些国家走 IXP 换手两三次，延迟比直连多出 30ms 很常见。
- 回源路径：边缘到源站如果走公网绕路，静态内容还能靠缓存兜住，动态 API 的首包时间就全压在回源上了。
- 命中率：节点再多，缓存键设计不对、命中率只有 60%，等于每次都有四成流量回源，白花钱。
选供应商时可以要三样东西：你目标市场的具体节点清单（不是全球总数）、回源线路说明（是否优化线路或专线）、一个测试域名做多地拨测。像 美国西海岸 CDN 节点这种落到区域的说法，比「全球加速」有用得多。
回源怎么配：带宽、鉴权、协议
回源带宽别按峰值直接算
估算公式大概是：边缘总带宽 ×（1 − 缓存命中率）× 回源放大系数。站点峰值 200Mbps、静态命中率 90%，回源约 20Mbps；但如果动态接口多、或者回源没开压缩，实际跑到 40Mbps 也不奇怪。建议按测算值留 2 倍余量，同时给回源单独限速，避免边缘集中回源把源站出口打满。源站自建机房的话，出口带宽要单独评估，出口只有 100Mbps 的情况下，CDN 再强也救不了。
回源鉴权：别让 CDN 变成开放代理
常见做法是回源 IP 白名单 + 回源 HOST 校验 + 自定义 Header 密钥。IP 白名单的麻烦在于节点 IP 会变，得定期同步；自定义 Header 更稳，源站只认带正确 Header 的请求，其他一律拒绝。源站如果挂了 WAF 或高防，记得把 CDN 回源 IP 段加进白名单，否则会出现「CDN 被拦、用户看到 502」这种查半天的问题。回源链路和防护策略最好一起规划，别等被打的时候才发现回源 IP 没放行。
回源协议：长连接能省不少钱和时间
- 边缘到源站用 HTTP/2 或长连接复用，比每次新建 TLS 握手便宜得多，静态资源多时尤其明显。
- 动态接口开 keep-alive，一个 POP 到源站维持几十条连接，跨境抖动时的重连成本会低很多。
- 大文件回源支持 Range 分片，断点续传和视频拖动都依赖它。
- 回源超时别设太短，跨境线路抖动时 3 秒超时会导致大量失败重试，反而放大源站压力。
静态和动态分开配，别一套规则打天下
静态资源走长 TTL：图片 7 到 30 天，带 hash 文件名的 JS/CSS 可以放到一年，开启 Brotli，命中率目标 90% 以上。动态请求不缓存或者只缓存 1 到 10 秒，走回源长连接，条件允许就开动态加速，让请求走优化线路而不是裸奔公网。
缓存键是很容易翻车的地方。默认缓存键通常包含 query string，URL 里带一堆 utm 参数时，同一张图会被缓存成十几份，命中率直接掉下来。把无意义参数排除掉，是性价比很高的一步优化。
上线之后怎么验收加速效果
别只看控制台里的「平均响应时间」，那玩意儿口径经常对不上。按这个顺序测：
- DNS 解析时间：多个公共 DNS 分别 dig，看有没有被解析到远端节点。
- TCP + TLS 握手：用 curl -w 或拨测工具，看目标市场的握手耗时。
- TTFB：首字节时间，静态资源应该接近纯网络往返。
- 下载速度：测 10 秒以上的大文件，看曲线是否平稳。
- 回源率：CDN 日志里回源请求占比，静态资源低于 10% 算正常。
| 指标 | 跨境场景参考区间 | 偏高时先查什么 |
|---|---|---|
| DNS 解析 | 100ms 以内 | 公共 DNS 归属、TTL 设置 |
| TLS 握手 | 200ms 以内 | 会话复用、证书链是否精简 |
| TTFB（静态） | 100-300ms | 节点是否就近、回源是否拖后腿 |
| 缓存命中率 | 静态 85% 以上 | 缓存键、TTL、参数污染 |
| 回源失败率 | 0.5% 以内 | 鉴权配置、源站限流、超时设置 |
测试点位至少覆盖三个地区、两个运营商，能用真实设备就别只用机房拨测。单点数据好看，不代表整体体验好。
几个我们踩过的坑
- 为了「节点多」选了覆盖广的供应商，结果目标市场只有一两个节点质量能打。
- 回源鉴权只做 IP 白名单，节点扩容后新 IP 没同步，半夜被告警叫醒。
- 动态接口也配了缓存，用户看到别人的购物车，本质是缓存键没带上用户标识。
- 合规和备案没提前确认，欧洲用户访问被拦，这事跟 CDN 无关但总是一起出现。
电商站可以对照 跨境电商 CDN 方案里的区域划分来落节点；内容站以图片、视频为主的话，全球 CDN 加速的配置思路差不多，重点还是回源和缓存键这两块。
下一步可以这么做
拿张纸写下用户 TOP3 地区、源站位置、静态动态占比，然后对着上面的表逐条核对。对不上的地方先别加节点，优先解决源站位置和回源线路的问题——这两项带来的收益，通常比多买几个 POP 大得多。想针对自己的站点过一遍决策树，把源站位置、日均 PV、目标市场发到 bd@319keji.com，或从 联系合作 页面留言，我们一条条对。