自建CDN这件事在一人团队里往往不是“要不要做”的问题而是“能做到什么程度”的问题。你下单买一台高带宽机器装上一套企业版CDN软件接上源站解析一条加速域名看起来就像有了一套CDN但真正考验人的是后续缓存规则怎么配、回源失败怎么处理、节点流量怎么观察、刷新和预热多久生效、被攻击时源站还能不能撑住。这篇文章以一台测试服务器、一个演示源站和一套99CDN企业版为例记录从搭建到测试的完整流程。文章不会假设你拥有复杂的基础设施而是按一人团队能操作的边界来设计重点说明每步为什么要这么做以及测试时到底要看哪些指标。1. 自建CDN先想清楚你要解决的是速度问题还是可用性问题1.1 自建CDN和公有云CDN的差异很多人一听到自建CDN第一反应是“我要在一个机房部署一堆边缘节点”。这是最常见的误解。自建CDN并不是复制一套像公有云那样覆盖全国上百个城市的调度网络而是在你控制力范围内用软件把“源站 - 节点 - 用户”这条链路整理出来。对于一人团队自建CDN真正解决的是三个问题静态资源请求压力从源站剥离掉源站只需要处理动态请求和回源。用户实际访问的节点距离源站更近或者至少有一个可观测的中间层来缓冲波动。缓存策略和刷新预热可以由自己控制不依赖第三方控制台的黑盒逻辑。而代价也很直接你需要维护至少一台带宽充足的节点机器需要处理域名解析、证书、回源鉴权、缓存失效、日志收集、故障切换。这些工作在没有商业化团队支持时会持续消耗时间。1.2 99CDN企业版在这个场景里的定位99CDN企业版属于商业化CDN软件覆盖的范畴通常用来给已有源站增加缓存分发能力。它和控制台一键接入公有云CDN最大的不同在于你可以把控制面、调度逻辑和缓存节点放在自己可控的环境里有利于调试和私有化部署。在本文中我把99CDN企业版当作一套“具备控制面和管理面的CDN服务端软件”来使用不展开具体版本号差异。落地前你需要确认安装包对应的系统版本、依赖软件和要求不同发行版之间的命令细节会有差异。注意自建CDN适合学习原理、内部系统加速、边缘试验场景。如果你的站点已经有较大访问量自建CDN的稳定性很难直接对标商业云CDN的冗余水平建议先做小流量灰度。1.3 先明确失败边界一个人团队搭建CDN最先要考虑的不是性能而是失败边界节点宕机后流量怎么切回源站。回源超时后用户拿到的是缓存内容还是错误页。缓存数据膨胀后磁盘什么时候会被写满。控制面挂掉后节点是否还能继续服务。这些问题在设计架构时就要想好否则测试阶段看似正常上线后第一次故障就会消耗大量时间。2. 搭建前的资源规划和最小架构设计2.1 一台机器够不够跑控制面和节点很多CDN软件的架构会把控制面和数据面分开控制面负责配置下发数据面负责处理请求。一个人团队在刚开始测试时没有必要把控制面和数据面拆到两台机器可以在同一台服务器上先完成最小化部署等确认业务模型后再拆分。以一台4核8GB内存、100Mbps带宽的服务器为例学习环境完全可以跑通控制面和一个节点。角色建议配置职责说明控制面2核4GB域名管理、节点管理、缓存规则配置、刷新预热、日志查询节点2核4GB缓存存储、回源请求、访问控制、请求日志源站可复用现有业务服务器提供真实内容接收节点回源请求如果只有一台服务器资源和带宽会被控制面和数据面共享测试结果只适合做功能验证不能当作真实带宽模型。2.2 DNS、证书和回源方式要提前决定自建CDN测试时至少需要三样东西一个加速域名例如cdn.example.com。一个源站域名或源站IP例如origin.example.com。一张证书负责HTTPS访问。在测试环境可以用自签证书跳过验证但测试HTTPS缓存命中时要注意如果源站证书校验不通过很多节点会直接回源失败。回源方式常见有三种回源方式场景注意点HTTP回源内网或测试环境不需要证书但明文传输HTTPS回源公网生产环境需要处理证书校验回源Host源站配置了多个站点需要在源站确认Host匹配2.3 最小架构一人团队推荐先画一张这样的图不必画复杂架构图先明确请求链路用户 - 加速域名解析 - CDN节点 - 节点命中缓存则直接返回 - 未命中则回源 - 源站返回内容 - 节点写入缓存 - 返回用户这里最关键的是两个决策点解析层面加速域名通过解析服务把流量指向CDN节点IP。应用层面CDN节点收到请求后用缓存键去查找本地缓存找到就短路返回。在做任何安装操作前建议先在文本文件里把这三类信息写清楚源站地址origin.example.com加速域名cdn.example.com节点IP例如203.0.113.10不要边安装边想配置很多自建CDN测试失败都不是软件问题而是域名、Host、证书和端口这几个基础信息没有对齐。3. 基础环境准备和99CDN企业版安装3.1 操作系统和基础依赖这一步的目标是让服务器处于一个“可安装、可排除依赖问题”的状态。不同版本的操作系统、CDN软件包结构、依赖组件要求不同下面以常见Linux发行版为例表示流程而不代表所有版本通用。# 更新系统 apt-get update apt-get upgrade -y # 或 yum update -y # 安装常用依赖 apt-get install -y curl wget vim net-tools # 或 yum install -y curl wget vim net-tools检查时间同步CDN节点的缓存过期、日志时间戳都依赖系统时间时间漂移会造成刷新不生效和日志错乱date timedatectl set-ntp true systemctl status systemd-timesyncd如果服务器时间与标准时间偏差超过几十秒后续看到的缓存命中记录、刷新任务执行时间都会对不上。3.2 安装控制面和数据面安装流程需要根据实际拿到的安装包调整。下面用占位目录演示安装后的基本布局# 假设你下载了99cdn企业版安装包 tar -zxvf 99cdn-enterprise.tar.gz cd 99cdn-enterprise # 查看安装说明 ls -la cat README.md如果安装包内有安装脚本通常会先执行初始化# 注意具体命令以安装包内说明为准 ./install.sh --rolecontrol ./install.sh --rolenode安装完成后先确认服务和端口状态systemctl status 99cdn-control systemctl status 99cdn-node # 查看监听端口 ss -lnpt常见的预期监听端口包括控制台端口、节点服务端口、回源连接端口。如果端口冲突需要在配置文件中调整。这里最容易出错的地方是直接按网上的通用教程执行安装没有检查软件要求的端口是否已经被占用。建议在安装前先执行ss -tlnp并把正在监听的端口记录下来避免安装后才发现端口冲突。3.3 初始化控制台并接入节点控制面安装完成后首次访问通常会进入初始化向导需要配置管理员账号和密码。控制台访问地址。节点注册令牌或密钥。默认缓存磁盘路径。节点接入控制面的过程一般有两种模式接入方式使用场景优缺点同机注册学习和最小化测试配置简单但不代表生产链路异地注册模拟真实节点调度能测试回源延迟和节点就近性需要多台机器在测试环境先使用同机注册模式跑通。接入后检查节点状态确认节点处于“在线”状态同时确认节点与控制面的版本一致。注意安装包版本不一致会导致配置下发失败。常见现象是控制面显示配置已下发但节点端没有任何变化。此时优先检查控制面和节点版本是否可以配套。4. 配置源站、加速域名和缓存规则4.1 先添加源站再添加加速域名添加源站的目的是让节点知道“请求没命中时去找谁”。源站配置字段通常包括字段示例值说明源站名称origin-example便于识别的名称源站协议HTTPSHTTP或HTTPS源站地址origin.example.com域名或IP源站端口443默认端口回源Hostwww.example.com源站识别站点用配置完成后建议先做一次源站连通性验证。如果节点已经注册到控制面可以在控制台执行“回源测试”或“节点探测”如果没有该功能直接使用节点所在机器上的curl验证curl -s -I https://origin.example.com/static/test.txt预期得到一个HTTP响应状态码。如果出现证书错误常见原因是源站证书链不完整。4.2 加速域名和证书配置添加加速域名时需要把cdn.example.com的证书上传到控制面。注意加速域名证书和源站证书是两个不同角色。加速域名证书用于用户到节点之间的HTTPS。源站证书用于节点到源站之间的HTTPS。如果证书不匹配用户会看到证书告警如果两者都使用同一张证书也要确认域名覆盖范围是否一致。配置完成后不要急着改DNS解析。可以先通过本地Host指定节点IP来测试# 编辑 /etc/hosts 203.0.113.10 cdn.example.com然后执行curl -s -I -H Host: cdn.example.com https://127.0.0.1/这一步能验证节点是否正确响应加速域名请求同时不干扰真实用户流量。4.3 缓存规则最小配置也要包含命中、回源和过期缓存规则是自建CDN里对技术颗粒度要求最高的部分。最少需要配置三块缓存键。缓存过期时间。缓存优先级。一个典型的缓存规则可以写成缓存规则: - 匹配路径: /static/* 缓存键: 请求URL 忽略参数: true 缓存过期: 30天 开启压缩: true - 匹配路径: /api/* 缓存键: 请求URL 用户ID参数 忽略参数: false 缓存过期: 0 优先回源: true这里的逻辑是静态文件使用URL作为缓存键不因后面的时间戳参数而重复缓存API请求则必须回源并且带上用户维度参数避免串数据。缓存优先级表示当多个规则匹配时哪条生效。很多自建CDN测试时会遇到“我明明加了缓存规则但节点就是不缓存”原因往往是规则写反了优先级。路径匹配符写错。源站响应头里带了Cache-Control: no-store节点遵从而不缓存。因此配置后一定要测试缓存是否真实命中。5. 域名解析接入和缓存命中验证5.1 解析切换前做一次完整链路测试修改DNS解析前建议在测试环境用Host文件模拟真实链路把以下流程全部走通用户请求http://cdn.example.com/static/test.png。节点接收到请求。返回内容来自源站或节点缓存。查看请求头是否包含CDN节点信息例如Via或X-Cache响应头。再次请求同一URL确认X-Cache: HIT。典型测试命令# 第一次请求期望看到 MISS curl -s -I -H Host: cdn.example.com http://127.0.0.1/static/test.png # 第二次请求期望看到 HIT curl -s -I -H Host: cdn.example.com http://127.0.0.1/static/test.png如果自建CDN在响应头中输出Via字段通常能看到节点标识。如果没有相关字段可以通过节点访问日志确认缓存是否命中。5.2 解析生效后验证节点是否真的被命中把加速域名的解析指向CDN节点后使用dig或nslookup确认解析结果dig cdn.example.com A short如果解析结果不是CDN节点IP而是源站IP说明解析配置还未生效或没有把流量指向节点。再执行访问测试curl -s -o /dev/null -I -w time_total: %{time_total}s\nhttp_code: %{http_code}\n https://cdn.example.com/static/test.png对比直连源站的访问耗时curl -s -o /dev/null -I -w time_total: %{time_total}s\nhttp_code: %{http_code}\n https://origin.example.com/static/test.png这里的对比结果只作为参考不能直接说明CDN一定“更快”。因为用户如果离源站很近而CDN节点在同机部署两者耗时可能很接近甚至源站更快。此时不要急着下结论要看缓存命中情况和回源次数。5.3 缓存刷新和预热测试自建CDN测试阶段一定要把刷新和预热功能验证一遍。刷新删除节点上的缓存下次请求回源常用于更新文件后让节点重新获取。预热提前把指定URL缓存到节点常用于活动页、大文件发布。刷新测试步骤# 在控制台发起刷新请求 # 请求 /static/test.png # 刷新完成后再次请求应答头应回到 MISS curl -s -I -H Host: cdn.example.com http://127.0.0.1/static/test.png预热测试后立刻请求一次观察是否命中如果预热后请求仍然MISS通常原因是预热URL和实际请求URL不完全一致。预热请求没有按照加速域名格式化。预热任务虽然显示成功但节点没有正确加载URL。刷新和预热是自建CDN里最容易被忽略但又是最高频使用的操作。上线前建议把这两个功能写入日常发布流程。6. 测试阶段如何量化CDN效果6.1 测试指标不要只看“快了很多”合理的效果评估需要从三个维度看维度指标说明缓存效率缓存命中率HIT次数占请求次数比例延迟time_total、TCP连接时间、首字节时间对比有无节点访问下的差异源站压力回源请求数、回源失败率体现节点到底卸载了多少请求缓存命中率不是越高越好。如果所有API都被缓存会带来数据一致性问题。理想情况是静态资源命中率高、动态请求全部回源。计算命中率示例如果100次请求中有90次命中命中率为90%。但要看统计粒度。按请求数计算的命中率和按流量字节计算的命中率不同前者适合判断缓存策略合理性后者适合判断带宽节约效果。6.2 用日志确认缓存行为测试阶段不要依赖控制台显示的曲线直接查看节点访问日志是最可靠的确认方式。日志字段里通常有请求时间 来源IP 请求方法 请求URL 状态码 响应字节 命中状态 回源IP示例2025-01-06 10:00:01 1.2.3.4 GET /static/test.png 200 53210 HIT - 2025-01-06 10:00:02 5.6.7.8 GET /api/user 200 1200 MISS 203.0.113.11看到HIT后还要确认节点返回的响应头是否正确例如Content-Length是否依然正确。Content-Type是否因为压缩发生了变化。源站设置的Set-Cookie是否被错误缓存。如果日志中所有请求都是MISS大概率是缓存规则没有匹配或源站响应头禁止缓存。这比看面板统计更有排查价值。6.3 压力测试的合理范围一人团队用压测工具做测试时不要追求“把机器打满”。压测的目的不是证明CDN有多快而是验证链路在多少并发下会出现回源放大。推荐按这个顺序测试10并发连续请求同一URL观察缓存命中率和节点CPU。100并发请求多个URL观察回源请求数和失败率。用预热脚本把核心资源预热到节点再压测节点能力。压测时注意测试工具所在机器的网络带宽如果压测机本身带宽不高测量结果会被压测机限制。7. 常见问题排查从现象到原因7.1 访问返回502或524现象加速域名访问时返回502或超时类错误。可能原因源站服务没有监听在配置的地址和端口。源站地址填写错误。节点到源站之间存在防火墙拦截。HTTPS回源证书校验失败。排查步骤# 在节点机器上直接测试源站 curl -s -I http://origin.example.com/static/test.png curl -s -I https://origin.example.com/static/test.png如果节点机器能访问源站但从加速域名访问失败需要检查节点面板里的回源配置和源站Host取值。7.2 刷新后请求仍然HIT现象控制台执行刷新但再次访问还是命中旧缓存。可能原因刷新URL与缓存键不一致。刷新任务只发送到部分节点。节点时间不同步刷新任务被忽略。排查顺序检查刷新任务的执行状态。查看节点日志中刷新任务记录。对比节点时间与标准时间。使用带响应头的方式手动确认。7.3 静态文件没有被缓存现象节点日志显示所有请求都是MISS静态文件也一直回源。可能原因路径匹配规则没有覆盖目标路径。规则优先级被其他回源规则抢占。源站返回了Cache-Control: private/no-store。缓存磁盘路径不可写或空间不足。建议先缩小范围把目标文件归属的目录单独写一条规则并设置较长的过期时间再检查响应头中与缓存相关的字段。8. 一人团队运行CDN的实践清单8.1 上线前检查清单以下是可以在每次上线前逐项打钩的清单检查项操作DNS解析确认加速域名指向节点IP证书确认加速域名证书未过期源站可用性节点能正常访问源站缓存规则静态资源和动态API规则已分开刷新预热发布流程中已加入刷新步骤回源超时已设置合理的回源超时时间监控节点CPU、磁盘、带宽有告警日志节点日志落盘且不会迅速占满磁盘8.2 日常运维建议一个人团队最怕的不是技术复杂而是没有稳定的排错入口。建议至少做到每天查看一次节点日志大小避免日志膨胀导致磁盘写满。每周抽查一次缓存命中率命中率突然下降时检查是否有规则被误改。每次发布前刷新相关URL不要全目录刷新避免回源量突增。回源鉴权改成共享密钥时提前验证节点是否会因为鉴权失败而缓存到错误内容。8.3 扩展方向99CDN企业版搭建完成后可以继续尝试以下方向把控制面和节点拆分到不同机器验证跨机配置下发。增加第二节点配置相同缓存规则观察刷新任务是否同步。为核心接口配置回源重试和超时降级。接入日志采集系统把节点访问日志汇总后分析命中率和热点资源。对于想真正把自建CDN投入生产的人最重要的不是继续增加节点而是先把回源失败保护、缓存数据一致性、监控告警三件事做扎实。只有把失败场景控制住自建CDN才有长期运行的基础。从测试结果回到最初的判断自建CDN可行但它更适合作为源站压力的分流层和CDN原理实验平台。如果业务量很小、源站本身就可以扛住自建CDN的收益并不明显。如果业务量增长、源站带宽紧张那么一套99CDN企业版这样的自建方案至少能让你在成本和可控性之间找到一个平衡点。