一个人要不要自建CDN？从99CDN企业版看可行条件与运维边界

“要不要自建 CDN？”这是一个很值得反复讨论的问题，尤其是当你只有一个人维护整套网络服务的时候。我这次以 99CDN 企业版为切入点，完整走了一遍从部署边缘节点、接入源站，到多区域访问测试和异常排查的流程。先说结论：自建 CDN 不是不可行，但它的可行建立在几个非常具体的条件之上。如果你只是想省钱，或者觉得商业 CDN 太贵，那自建未必能让你省心，反而可能把成本转移到运维和排障上。但如果你要的是可控性、可观测性和对缓存策略的完全掌握，那这种尝试就值得做。

一个人做网络服务，最容易产生的错觉是“工具越大越好”。CDN 就是这样一套体系，单看概念并不复杂：让用户从离自己更近的节点拿资源，减少回源压力和访问延迟。可真要自己搭起来，就会遇到一系列和概念无关的问题：节点怎么选、回源怎么设计、缓存怎么失效、证书谁来续期、源站 IP 怎么藏。这些问题每一个都不至于难倒一个人，但它们叠加在一起，会吃掉你大量本应用来写业务的时间。这也是为什么我更愿意把这次尝试理解为：不是“自研 CDN”，而是“用成熟方案做一套自己能控制的网络分发系统”。

1. 先想清楚：你需要的到底是 CDN，还是一次流量链路改造

1.1 为什么一个人也会想自建 CDN

商业 CDN 已经很成熟了，按量付费、全球节点、智能调度、安全防护，看起来什么都不缺。但真到某些业务场景里，商业 CDN 给的是一套标准服务，你只能在默认规则里做选择。比如缓存规则不够细、日志保留时间短、回源行为不透明、某类请求被平台策略限制。对普通业务来说这些不是问题，可一旦你的业务对访问链路、资源更新时效、日志留痕有特殊要求，商业产品的边界就会变得很明显。

我这次尝试 99CDN 企业版，背景也很简单：想做一套能自己控制边缘节点、自己决定缓存策略、回源链路完全可查的 CDN 服务。不是从零写调度和缓存，而是用企业版方案把 CDN 常见能力打包起来，部署到自己的机器上。这个定位很重要，因为它决定了整件事的难度。如果你以为自建 CDN 就是自己写一个 Nginx 加缓存模块，那后续的证书、监控、刷新预热、异常流量处理都会变成无底洞。成熟方案的价值，就是把这些工程能力先兜住，让你把精力放在配置和测试上。

1.2 判断真需求的三条标准

在动手之前，我一般先问自己三个问题：

1. 我是不是对回源链路、缓存规则、节点位置有明确的控制需求？
2. 我是不是需要把日志、访问记录、源站响应数据完整保留下来？
3. 我是不是能接受一个需要自己盯监控、自己处理证书、自己维护节点状态的系统？

如果三个问题的答案都是否，那就别自建。直接用商业 CDN，按量付费，出现问题找服务商，从成本和时间上都是更优选择。如果至少前两条成立，自建 CDN 才有讨论价值。很多人一开始只是想省钱，结果搭完之后发现，为了省那点流量费，自己多付出了十倍的时间成本。这是自建 CDN 最常见的“假需求”。

1.3 一人团队的技术边界

一个合格的 CDN 系统，拆开看至少包含这些部分：DNS 调度、边缘节点、缓存层、回源策略、健康检查、日志与监控、刷新预热、HTTPS 证书管理、安全防护。一个人全部从零实现，不是不可能，但从工程回报率看非常不划算。真实 CDN 的难度通常不在“缓存怎么存”，而在“缓存怎么失效”“回源异常怎么降级”“证书过期怎么避免”“用户看到的到底是哪个节点”这类细节上。

所以“自建 CDN”这四个字，对一人团队来说更准确的理解是“自建 CDN 服务”：用开源方案或企业版产品，把控制端、节点、源站组合起来，形成一套自己可管理的体系。这样你拥有的是流量链路的控制权，而不是把所有软件都写一遍。99CDN 企业版这类方案，本质上就是帮你完成“组件组装”，把 CDN 常用的控制台、节点接入、缓存规则、证书配置等能力集成好。你需要做的，是理解底层逻辑，然后把配置调对。

2. 搭建之前，先把四个基础问题定下来

2.1 节点规划：你的 CDN 覆盖到哪里

CDN 的价值在于“离用户更近”。如果你只有一个边缘节点，而且这个节点和源站还在同一个机房，那它本质上是一个带缓存的 Nginx 反代，不能算 CDN。对一人团队来说，最合理的起步方式是先有一个源站，再根据用户分布选一到两个边缘节点。用户主要集中在华东，边缘节点就放华东；用户分散，就至少放两个区域。节点不是越多越好，因为每多一个节点，你就多一台机器要维护，多一层日志要看，多一个证书要处理。

如果你刚开始只能部署一个节点，也不必觉得没有意义。先把单边缘节点跑通，验证回源、缓存、刷新、证书这一套流程是否正常，再慢慢加节点。这是一个从“单点缓存”走向“区域分发”的过程，不要一上来就追求全国甚至全球覆盖。对一个人来说，能稳定的节点比看起来漂亮的节点地图重要得多。

2.2 回源链路：缓存未命中时，源站能不能扛住

自建 CDN 最容易忽略的是回源设计。用户第一次访问某个文件，边缘节点没有缓存，就会回源站拉取。如果回源链路设计得不好，并发一高，源站瞬间被打挂。回源方式一般有 HTTP 回源、内网回源、对象存储回源。个人或小型团队最常见的是 HTTP 回源：边缘节点通过公网或内网向源站发起请求，拿到资源后缓存到边缘节点，再返回给用户。

这里要注意回源 Host 和回源超时。回源 Host 填错了，源站上的虚拟主机无法识别请求，会返回错误页面；回源超时设置太短，大文件还没拉完就断掉，用户就会看到 502。实际操作中，我会先确认源站自己的访问路径是正常的，再配置回源地址和回源 Host。回源链路是不是通，比边缘节点本身更能决定用户能不能拿到内容。如果你发现自建 CDN 后访问速度反而变慢，第一步不是调缓存参数，而是看回源请求是不是因为超时被反复重试。

2.3 缓存规则：不是所有资源都适合长缓存

缓存规则是自建 CDN 配置里的核心，也是最容易出错的部分。很多人以为缓存时间越长越好，实际上要分资源类型。如果 HTML 页面被缓存七天，你发布新版本后用户只能看到旧页面；如果接口被缓存，用户数据实时性就没了。下面这个判断表是我在实际配置里经常用的基准，具体时间要结合业务调整。

自建 CDN 之后，你会慢慢理解一个词叫“缓存命中率”。命中率高，回源少，源站压力小，访问速度也稳定；命中率低，说明你的缓存规则和业务不匹配。对静态资源为主的站点，命中率应该能到 90% 以上；如果大量请求都是动态接口，CDN 能发挥的空间本来就有限。

2.4 域名与证书：最容易被忽略的前置条件

自建 CDN 需要至少两个域名视角：用户访问的加速域名，以及源站域名。加速域名建议独立设置，比如cdn.example.com，不要和源站域名混用。这样方便以后切换 DNS、调整证书、做灰度验证。HTTPS 证书最好由边缘节点统一处理，边缘节点和源站之间可以走内网或 HTTP。好处是证书只维护一份，用户侧看到的是完整 HTTPS 链路，回源环节少一层 TLS 开销。

证书问题是自建 CDN 最典型的事故来源。商业 CDN 会自动帮你续期，自建方案里这个动作很容易被忘掉。我建议从第一天就把证书自动续期配置好，不要用手动续期的方式，否则半年后一次证书过期，就会让整个站点出现“浏览器打开不安全”的尴尬局面。域名解析 API 权限也要提前准备好，因为后面做 DNS 切换、自动签发证书都会用到。

3. 以 99CDN 企业版为例，把最小闭环跑通

3.1 部署前需要准备的环境

我这次尝试 99CDN 企业版，省去了很多从零组装的工作，但前置环境还是要准备干净。一个比较稳妥的配置是这样的：

• 一台源站服务器：跑你的实际业务，建议至少 2 核 4G，带宽根据业务量评估。
• 至少一台边缘节点服务器：磁盘容量要留足，因为缓存文件会持续增加。
• 一个可以解析的域名，并有 DNS 管理权限。
• 一个可用的 HTTPS 证书，或者支持自动签发证书的方案。
• 管理端口和防火墙规则：控制端、节点之间的通信端口要先确认，别装完才发现互相访问不了。

这里有一个很容易踩的坑：不要在你的源站机器上又跑数据库、又跑缓存、又跑 CDN 控制端。一个人维护的时候，机器能少则少，但角色要分开。源站、边缘节点、控制端如果挤在同一台机器上，一旦缓存占满磁盘或控制端异常，你的业务也会跟着受影响。

3.2 搭建主流程：控制端、节点、源站、域名四步走

99CDN 企业版这类方案的通用流程，大致可以归纳为四步：

1. 初始化控制端。控制端负责管理节点、域名、证书和缓存规则。
2. 添加边缘节点。节点会从控制端拉取域名和缓存配置。
3. 添加源站。源站地址决定了节点回源时去哪个服务器拿数据。
4. 创建加速域名。配置回源 Host、缓存规则和证书，然后把 DNS 解析指向边缘节点。

不同版本的界面和字段会有差异，但底层的网络逻辑是一样的。你要做的事情不是记住每个按钮，而是理解每一步在整个流量链路里的位置。控制端是大脑，节点是触手，源站是内容库，域名是用户入口。四者接起来，流量才走得通。

3.3 最小可运行配置示例

如果你第一次搭，建议先绑定一个带版本号的静态资源路径来验证，比如https://cdn.example.com/static/test.txt。对应的配置可以参照这个表：

配置完先不要急着切换全站 DNS。用本地 hosts 文件把cdn.example.com指向边缘节点 IP，访问测试文件，确认响应正常，再考虑让线上用户接入。很多人自建 CDN 失败，不是配置不对，而是步子迈太大，一把梭全量切换，出了问题连回退方案都没有。

3.4 第一刀切多小：先让一个路径跑起来

我比较推荐的方案是把某个目录先切成 CDN 流量。比如先只加速/static/路径，剩下的动态请求依然直接访问源站。跑一两天，观察缓存命中率、源站负载和访问日志，稳定后再把图片目录、下载目录加进来。这样即使出问题，影响面也可控。自建 CDN 是一套系统，但它首先要能作为一个“局部中间层”工作，而不是一开始就试图接管所有东西。

4. 自建 CDN 的测试，不能只看“首页能打开”

4.1 功能连通性测试：确认请求真的经过了 CDN

搭建完成后的第一个测试，不是打开浏览器看页面，而是确认流量链路是否按要求工作。一个很简单的办法是用 curl 看响应头：

curl -I https://cdn.example.com/static/test.txt

观察响应头里是否有 CDN 节点相关的标记，比如X-Cache、Via、Age，或者边缘节点特有的 Server 信息。如果响应头里看不到任何中间层痕迹，就要查 DNS 是否真的解析到了边缘节点，或者本地是否有缓存。另一个判断方法是去源站日志里看请求来源。如果边缘节点正常工作，源站日志里应该只能看到边缘节点 IP 的回源请求，而不是大量直接来自用户 IP 的请求。

4.2 缓存生效测试：命中与回源要分开看

缓存是否生效，可以用两次请求来验证。第一次访问静态文件，记录响应头里的X-Cache: MISS或Age: 0；第二次访问，看是否变成X-Cache: HIT，并且源站日志里没有新增请求。如果产品没有暴露缓存状态，可以通过源站访问日志数量来判断：同一个文件访问两次，源站日志里只有一条记录，说明第二次被缓存拦截了。

这里可以把自动化测试加进来。不要每次都手动 curl，写一个简单脚本，循环请求某个静态文件，检查响应头里的缓存状态，超过 N 次非 HIT 就告警。对一个人来说，自动化测试不是“要不要做”的问题，而是“如何用最简单脚本替自己盯着线上”的问题。一个十几行的 shell 或 Python 脚本，就能把重复检查自动化掉。

4.3 多地区和弱网测试：CDN 的价值要在不同网络下体现

如果你的业务用户分布在不同城市，测试就不能只在本地局域网做。可以找在线拨测工具，或者在不同云厂商的区域各开一台低配机器，用 curl 请求同一个资源，比较 DNS 解析结果和响应时间。理想状态下，华东用户解析到华东节点，华南用户解析到华南节点，响应时间应该比直连源站更短。

弱网测试同样重要。用网络工具模拟丢包、延迟、带宽限制，看用户在弱网环境下能否拿到内容、是否会等待过久、是否有超时重试。自建 CDN 很多时候不是“快不快”的问题，而是“在弱网下稳不稳定”的问题。如果源站带宽本身很小，而你又没有限制回源并发，用户请求一多，边缘节点会不断回源排队，最终表现为页面加载慢、图片反复加载失败。

4.4 异常状态和源站保护测试

测试不能只测“正常情况”。你需要主动制造一些异常场景：比如把源站服务停掉，看边缘节点是否返回 502，错误信息是不是友好；把证书撤掉，看 HTTPS 访问是否失败；查看 4xx、5xx 状态码分布，确认问题出在边缘节点还是源站。

更关键的是源站保护测试。如果你已经配置了防火墙只允许边缘节点回源 IP 访问源站端口，就可以验证一下：直接用 curl 访问源站地址，应该失败；通过 CDN 访问同一个资源，应该正常。这一条非常重要，因为很多自建 CDN 翻车，不是节点出了问题，而是源站 IP 暴露后被人绕过 CDN 直打源站，整个服务直接不可用。

注意：源站保护不是可选项。只要做了自建 CDN，就必须确保除了边缘节点之外，其他来源不能直接访问源站。否则你在缓存上做的所有努力，都会被一次绕过打得稀碎。

4.5 五维测试评估表

把测试经验沉淀成一张表，方便以后每次调整配置后复查：

这五维测试不是只做一次。每次调整节点、缓存规则或证书之后，至少要跑一遍前三维，确认没有把线上链路改坏。测试应该是持续行为，而不是交付前的仪式。

5. 一个人长期维护，真正的成本在“看不见的地方”

5.1 证书过期和缓存不刷新，是最常见的两个事故

自建 CDN 上线之后，第一个容易踩的坑是证书过期。商业 CDN 的服务商会在后台自动续期，你感知不到；自建方案里，证书续期变成了你自己的责任。如果控制端支持自动签发证书，务必把自动续期开启，并且定期做一次续期演练，不能等到证书过期的邮件出现才处理。

第二个坑是缓存不刷新。你更新了源站上的文件，但用户拿到的还是边缘节点上的旧版本。解决办法有两个方向：一是资源文件名带版本号或 hash，每次更新换一个新 URL；二是使用 CDN 的刷新功能，主动清除指定路径的缓存。路径带版本号比刷新更可靠，因为刷新一旦失败，或者漏刷了一个 CDN 节点，用户还是会看到旧内容。

5.2 日志、监控、告警缺一不可

一个人维护一套 CDN，最大的问题不是你处理不了故障，而是你不知道已经发生了故障。访问日志、回源日志、节点磁盘占用量、带宽曲线、5xx 错误率，这些指标至少要有一个能看到的地方。不用做得特别复杂，一套能够记录日志、定时统计、异常告警的轻量方案就够。

告警规则要克制。不要每个异常都发告警，否则一天收到几百条，你很快就不看了。我一般只保留四类告警：节点不可达、5xx 比例超过阈值、磁盘使用率超过 80%、证书剩余有效期低于 15 天。这四类告警基本覆盖了自建 CDN 最致命的问题，又不会让人产生“狼来了”的疲劳。

5.3 容量和磁盘：缓存是拿磁盘换速度

边缘节点的缓存会持续占用磁盘。如果缓存目录没有清理策略，时间长了磁盘会满，进而影响节点进程，甚至导致整个服务器卡死。在实际使用中，要关注缓存淘汰策略、缓存目录上限、磁盘增长趋势。你可以设置一个阈值，比如磁盘使用率达到 80% 时告警，达到 90% 时手动或自动清理缓存。

如果节点需要缓存大量视频或镜像文件，磁盘规划就更加重要。缓存命中再高，文件还是要落到磁盘上。对一个人来说，与其无限扩大缓存目录，不如从源站层做好文件体积优化、从业务层做好 URL 版本管理，减少无效缓存。

5.4 源站安全：被绕过是自建 CDN 最大的坑

自建 CDN 之后，你的源站 IP 就成了最需要保护的信息。一个直接请求源站的用户，可以绕过缓存、绕过安全策略、拿到源站最新内容，甚至拖着源站发起高并发请求。防护思路至少要有两层：

1. 网络层限制：在防火墙或安全组里，只允许边缘节点的回源 IP 访问源站端口。
2. 应用层校验：在回源路径上增加自定义 Header 或鉴权信息，边缘节点回源时带上，源站校验通过才返回内容。

第二层看起来更安全，但也更复杂。如果团队只有一个人，建议先做第一层，把 80/443 端口对外访问限制到边缘节点 IP。等整个链路稳定了，再评估是否需要做回源鉴权。安全测试也不是可选项。上线前至少要模拟一次“绕过 CDN 访问源站”的验证，确认直连源站请求会被拒绝。

6. 什么时候该收手：自建 CDN 的适用边界

6.1 比较适合自建的三种场景

自建 CDN 并不是一个“绝对行”或“绝对不行”的命题，它有自己的适用边界。从我这次尝试的经验看，比较适合的场景有三种：

1. 内部系统或工具站：用户量不大，但对数据链路、日志留存有要求。
2. 静态资源为主的内容站：图片、文档、CSS、JS 占大头，缓存命中率天然高。
3. 特定用户群或区域集中的业务：节点不需要铺全国，一个边缘节点就能覆盖主要用户。

在这些场景里，自建 CDN 的成本可控，收益明确，出现问题也容易排查。

6.2 不建议自建的场景

反过来，下面这些场景我建议你再想想：

• 业务流量高峰不可控，可能突然出现几倍甚至几十倍增长。
• 用户分布在全国甚至全球，需要密集节点和智能调度。
• 对外提供可用性承诺，要求 99.9% 以上 SLA。
• 团队只有一个人，且没有时间看监控、处理告警。
• 需要复杂的视频直播、动态加速、全球范围实时调度等能力。

这些需求不是“加油就能解决”的。商业 CDN 那么多年的节点积累、调度算法和边缘网络，并不是一个一个人维护几个节点就能替代的。

6.3 务实的混合方案：自建节点 + 商业 CDN 兜底

对一人团队来说，更务实的路径其实是混合架构：平时流量走自建节点，你自己掌握缓存策略和日志；一旦遇到异常流量、节点故障或需要重大版本发布，通过 DNS 快速切回商业 CDN。这个方案听起来不如“全自建”纯粹，但它给了你一个很关键的兜底能力。

前提是你必须把 DNS 切换文档写好。写清楚加速域名、源站地址、DNS 服务商、切换步骤和回退条件。不要等到故障发生的那一刻再去翻控制台，手忙脚乱。技术选型的核心不是证明自己什么都能做，而是让系统在你自己能承受的维护边界里稳定运行。

回到开头的问题：自建 CDN 可行吗？我的答案已经很具体了：可行，但它的可行建立在“用成熟方案构建可控链路”这个前提上，而不是从零自研一套 CDN。以 99CDN 企业版这类方案为起点，先跑通最小闭环，再做五维测试，再把证书、刷新、日志、监控、源站保护这些“看不见的运维”补上，最后给自己留一条切回商业 CDN 的退路。一个人不是不能做网络服务，关键是要选择一个让你把精力放在业务上、而不是整天救火的维护边界。如果哪天自建带来的维护量已经超过它解决的问题，就果断切回去。技术选型没有唯一解，只有最适合你当前状态的答案。