境外站点源站与边缘缓存的部署比例，不宜简单按服务器数量或预算平均分配。对用户真正有意义的是：多少请求能在边缘节点直接响应，多少必须回到源站取数据。比例应由内容是否可缓存、用户分布和更新要求共同决定。
先区分两个常被混为一谈的指标：边缘流量占比反映用户请求由缓存响应的程度；源站与边缘的资源投入比例则涉及计算、存储和网络容量。前者可用缓存命中率、回源率观察，后者不能直接从命中率推算。
先按请求类型划分，而不是先定百分比
CSS、JavaScript、字体、图片等版本化静态文件通常适合放在边缘缓存；内容更新后，通过更换文件名或清理缓存发布新版本。公开且变化不频繁的页面也可设置较短缓存时间。登录后的账户信息、购物车、支付状态等个性化内容，则通常应由源站或应用实时处理，避免共享缓存误发用户数据。
CDN边缘缓存可以减少跨境往返，但并不能替代源站：未命中、动态请求和缓存失效仍会回源。设置缓存策略时，应检查响应中的 Cache-Control 等头部，并确认 Cookie、查询参数及授权信息是否会影响缓存键。TTL（缓存存活时间）越长，回源通常越少，但内容更新不及时的风险也越高。
用可验证的比例作为起点
对以公开页面和静态资源为主的站点，可先把可缓存请求的边缘命中目标设在约 80%—95%；这是规划起点，不是所有地区、协议和内容都能达到的保证。若站点主要提供实时 API 或个性化服务，整体命中率可能明显更低，不应为了追求数字而缓存敏感响应。统计时同时看请求数和传输字节：大图片命中会显著降低带宽回源，却未必代表大多数请求都命中。
因此，境外站点源站与边缘缓存的部署比例应按内容拆分。可缓存资源由边缘承担大部分重复交付；源站容量则至少要覆盖动态流量、缓存未命中流量及更新或故障期间的回源峰值。比例要结合流量峰谷、源站承载能力和可接受的内容延迟调整，不能只看月平均值。
按顺序配置并复核
- 盘点请求。从访问日志或 CDN 报表中区分静态文件、公开页面、API 与登录后请求，并标记可能包含个人信息的响应。
- 设置缓存规则。为版本化静态文件配置较长 TTL；对会更新的公开页面使用较短 TTL 或按需清理；对账户、支付等响应设置不缓存或仅允许明确的私有缓存。
- 选定监测窗口。先覆盖一个完整业务周期，观察不同地区的请求数、字节数、缓存命中率、回源率和源站错误。短期突发与日常情况分开看。
- 逐步调整。若源站带宽或并发压力偏高，先检查可缓存内容是否因 Cookie、查询参数或响应头配置而意外绕过缓存；若用户看到旧内容，则缩短 TTL 或完善版本发布和清理流程。
根据风险决定边缘范围
把更多可公开内容放到边缘，通常有利于降低跨境延迟和源站负载；代价是缓存规则、失效流程和隐私边界需要维护。让更多请求回源，内容控制更直接，但源站更依赖国际链路，访问时延和带宽成本也可能上升。对于更新频繁的内容，较短 TTL 加主动清理往往比盲目拉长缓存更稳妥。
最终应将缓存命中率、回源率与页面新鲜度一起评估。境外站点源站与边缘缓存的部署比例不是一次性定值：当访问地区、内容结构或流量峰值变化时，重新分组测量，再调整规则与容量。
常见问题
边缘命中率越高越好吗？
不一定。公开静态内容通常适合提高命中率；个性化或敏感内容应优先保证隔离和实时性。
该按请求数还是流量计算比例？
两种都要看。请求数反映命中范围，字节数反映带宽收益；大文件会让两项结果差别很大。
源站是否要按全部流量配置容量？
应按动态请求、预计未命中及缓存故障时可能回源的峰值评估，并结合压测和源站上限留出余量。
TTL 设置多长合适？
没有统一时长。内容越稳定，通常可以设得越长；更新频繁或错误缓存影响较大的内容，应缩短 TTL 并设计清理流程。