给 VPS 网站加速：CDN 拉取(Pull)与推送(Push)两种模式怎么选

你花几十块买的那台海外 VPS，带宽不大、地理位置又远，国内或跨洋访问慢得像在拨号。这时候很多人第一反应是“挂个 CDN”。但 CDN 不是只有一种玩法——最容易被混淆的就是 Pull（拉取 / 回源）和 Push（推送 / 预传）两种模式。选错了，要么缓存从来没热起来、白花了钱，要么维护上传流程累到自己。这篇文章把两种模式的原理、适用场景和几个容易踩的坑一次讲清楚，帮你把“加速”这件事做对。

延伸阅读

更多相关攻略推荐：你是电信还是联通还是移动？按运营商选便宜 VPS 最省钱最不卡、刚买的 VPS 怎么连上去？SSH 新手教程（Windows / M、VPS 的带宽、流量、端口到底是啥？1Gbps 和 10TB 流量怎、运营商在偷看你的 DNS？VPS 自建 DoH/DoT 加密解析、【VPS vs 云 01】VPS 和云服务器是一回事吗？和阿里云/腾。

一、Pull 模式：CDN 主动回源（原理与默认适用场景）

Pull 是目前绝大多数通用 CDN 的默认工作方式，Cloudflare、CloudFront、Fastly 都是典型代表。原理很简单：你只需要在 CDN 后台填一下源站（Origin）的域名或 IP，剩下的交给 CDN。当某个边缘节点第一次收到用户对一个资源的请求、而它本地还没有缓存时，它会“拉”一次源站，把文件取回来，存入自己的缓存，再返回给用户。之后同一个区域内的后续请求，只要 TTL 没过期，就直接由边缘节点吐出，源站完全不知道这件事发生过。

这种“懒加载”的好处是几乎零配置。你不需要写上传脚本，不需要管哪个文件传到哪个节点，CDN 会根据真实流量自动决定缓存什么。对一个普通的网站、博客、API 来说，Pull 模式基本是开箱即用——改个 DNS 指向，剩下的它自己搞定。DigitalOcean 的教程里也把 Pull Zone 描述成“填入源站地址，剩下的 CDN 自动处理”，正是这个意思。

但代价也有两面。第一，冷启动延迟：每个资源在每个区域第一次被请求时，都会触发一次回源，那个“第一人”会多等一个源站往返时间。高流量站点缓存几分钟就热了，问题不大；低流量站点冷启动会更频繁，用户更容易撞上慢请求。第二，源站负载不可预测：缓存全部失效（比如你批量 purge 了一次，或部署后文件名没变）之后，瞬间所有请求都会打到源站，形成一个回源尖峰。如果你的 VPS 本身很小、带宽有限，这个尖峰可能直接把你打挂，反而比原来还慢。

二、Push 模式：提前把资源传上 CDN（静态资源预热）

Push 模式反过来：你主动把文件上传到 CDN 的存储里，边缘节点在用户请求之前就已经有内容了。这里没有传统意义上的“源站”，CDN 的存储本身就是源。常见的实现包括 BunnyCDN 的 Storage Zone、AWS S3 + CloudFront、以及各家的对象存储加 CDN 组合。

Push 最适合的是那种又大、又不常变、还要求“无论何时访问都必须快”的资源：视频库、软件安装包、游戏补丁、固件升级包。它们动辄几百 MB 甚至上 GB，不可能每次都让用户等着回源去慢慢拉。你一次性传上去，之后所有边缘节点直接服务，源站 VPS 几乎零负载。

但它有运维成本。你得自己维护上传流程、追踪版本、处理存储费用。如果内容变化频繁（比如每天改的前端代码），Push 模式会变成一场噩梦——你要不断地重新传、重新失效旧版本。所以实践中，很多人走混合路线：JS / CSS / 图片这些跟着部署走、会变的静态资源用 Pull；视频 / 安装包这些大文件用 Push。CDN77、Bunny 这类厂商也明确区分“pull zone”和“storage zone（push）”两套产品，正是为了覆盖这两种需求。

三、缓存规则与边缘 TTL 怎么设（缓存规则 / 边缘 TTL）

不管用哪种模式，缓存命中的最终效果都取决于 HTTP 响应头里的 Cache-Control。最常用的是 max-age，它告诉边缘节点“这条响应缓存多少秒”。比如：

Cache-Control: public, max-age=86400, immutable

这行意思是：公开缓存一天，且内容永远不变（immutable，浏览器连校验都不用做）。对带哈希文件名的前端产物（如 app.a1b2c3.js）来说，缓存一年都没问题，因为文件名跟着内容变，内容变了文件名就变了，旧 URL 自然没人请求，也就不会拿到旧文件。

动态一点的内容，比如列表页、文章页，可以配合 stale-while-revalidate：

Cache-Control: public, max-age=60, stale-while-revalidate=300

意思是先缓存 60 秒；60 秒之后，在接下来的 300 秒里，边缘节点仍然可以把旧内容立刻返回给用户，同时在后台悄悄拉一份新的回来。用户零等待，缓存也在悄悄更新。Cloudflare 还额外区分“保留期（retention）”和“新鲜度（freshness）”：保留期由 LRU 算法按热度决定，缓存满了就淘汰最久没人访问的内容，这个不可配置；新鲜度由 TTL 决定，过期了才去源站做条件校验（304 还是发新内容）。

需要立刻让旧内容消失时，有几种办法：一是直接调用 CDN 的 purge API（Cloudflare 几秒生效，CloudFront 可能要 5–15 分钟全球同步）；二是用带版本的 URL，内容变了就换 URL，旧地址自然失活；三是改文件内容后被动等 TTL 过期。最干净的策略永远是“版本化 URL”——把内容哈希写进文件名，这样根本不需要手动清缓存，也不会出现用户拿到半新的资源。

四、源站保护：藏好你的真实 IP（源站保护隐藏真实 IP）

很多人上 CDN 只盯着加速，却忽略了另一个巨大价值：隐藏源站 IP。只要你把域名通过 DNS 代理（Cloudflare 的橙色云）走 CDN，用户访问到的都是 CDN 的 Anycast 地址，你的真实 VPS IP 被挡在后面。配合 WAF 和 DDoS 防护，攻击者连你的服务器在哪都摸不到，自然也就没法直接打你。这也是为什么很多“只想加速”的人，最后都留在了 Cloudflare 的代理模式里——安全和性能一次拿到。

但这个保护有个前提：你的源站 IP 不能从别处泄露。常见的泄露渠道包括：之前直接把 IP 解析到过域名、邮件服务走的是源站、SSL 证书透明度日志（CT logs）里记了你的 IP、或者是网站代码里硬编码了 IP。更关键的是，如果你用了 Pull 模式，Pull 的前提是 CDN 能回源，也就是说 CDN 必须知道你的真实 IP——这本身不是问题，问题在于你要限制只有 CDN 的回源网段能访问 80 / 443 端口，其他来源一律拒绝。否则攻击者可以绕过 CDN 直接打源站，前面的隐藏全白做。Cloudflare 提供了一套“仅允许 Cloudflare IP”的防火墙规则，以及 Authenticated Origin Pull（源站证书校验），能把这条路彻底堵死。

五、怎么选：给你一张决策清单（收尾）

简单总结一下：

• 网站、博客、API、频繁更新的内容 → 默认用 Pull，零配置，跟着流量自动缓存。
• 视频库、软件下载、大文件分发 → 用 Push，提前传，源站零压力。
• 既要又快又想隐藏 IP → 走反向代理型 CDN（Cloudflare 代理模式），安全和性能一起拿。
• 内容经常变又用 Pull → 务必用版本化文件名 + 合适的 max-age，别依赖手动 purge。

CDN 拉取与推送没有绝对的好坏，只有适不适合你的业务。先把模式选对，再谈缓存规则和源站保护，你的 VPS 网站才能真正又快又稳。预算有限的机器尤其要算清楚：Pull 省的是运维，Push 省的是源站带宽，别让“加速”反而拖垮了那台小机器。

延伸阅读：如果你正在挑一台适合做源站或挂 CDN 的 VPS，可以参考 RackNerd 评测 与 DMIT 评测；关于边缘安全和隐藏 IP 的更多细节，见 VPS 与 Cloudflare DDoS 防护 2026 与 VPS 安全基础。