CDN加速并不是简单给网站套一层神秘网络，它的本质是利用分布式边缘节点把内容推到离用户更近的地方。当用户请求一个图片或脚本时，请求会被调度系统引导到地理位置最近的边缘节点，节点如果已经保存了该文件就直接返回，否则就会向源站发起回源请求。整个过程里，回源、缓存命中率和边缘节点是最基础也最容易混淆的三个概念，下面分别从原理、计算和配置角度展开说明。
边缘节点到底是什么，如何参与请求调度
边缘节点是CDN服务商在不同运营商和地区部署的缓存服务器，通常分布在省会城市或骨干网交汇处。它们的主要职责是就近接收用户请求，并在本地存储中被频繁访问的静态资源。当用户在浏览器输入网址时，本地DNS或HTTPDNS会把域名解析到某个边缘节点的IP，这一步就是调度。调度策略可以基于地理位置、网络延迟、节点负载等多个维度，目的就是让请求落到最合适的一台机器上。
从架构上看，边缘节点处于用户和源站之间，它本身不生产内容，只是内容的搬运工和临时保管员。一个边缘节点可能同时为几万用户提供访问，如果命中率高，源站几乎感知不到流量。反之，若节点缓存失效过多，就会集体回源，形成流量洪峰。理解边缘节点的角色，有助于我们在排查访问慢问题时，先判断是节点到用户链路差，还是节点没命中导致回源慢。
在真实业务里，边缘节点还会有层级关系，比如一级节点靠近源站、二级节点靠近用户。某些CDN厂商采用树状回源，边缘节点未命中时先问上级节点，只有顶层节点才回源，这样能进一步保护源站。新手配置时应当关注控制台显示的节点覆盖区域，确认自己用户集中地是否有对应节点，否则加速效果会打折扣。
回源机制与常见触发条件剖析
回源是指边缘节点本地没有所需资源，或者缓存已过期，于是向源站服务器请求原始文件的过程。最直观的触发条件是缓存过期，也就是节点根据配置的Cache-Control或Expires判断文件已到时间，下次请求就会回源验证或重新拉取。另一种情况是节点从未缓存过该URL，即所谓的首次访问或冷启动，此时必然回源。
除了正常过期，很多误操作也会引发回源风暴。例如源站开启了强制校验ETag且节点频繁收到带Cache-Control: no-cache的请求，或者运维人员批量刷新CDN缓存，导致大量URL同时失效。下面是一段简单的Nginx源站日志分析代码，用来识别回源请求特征：
import re
# 读取Nginx访问日志，筛选来自CDN回源的请求
# 通常CDN回源会在User-Agent中包含厂商标识
with open('/var/log/nginx/access.log', 'r', encoding='utf-8') as f:
for line in f:
if re.search(r'User-Agent:.*(CDN|Edge|Cache)', line):
# 提取请求路径与状态码
match = re.match(r'(S+) (S+) (S+) [(.*?)]', line)
if match:
print('回源路径:', match.group(2), '时间:', match.group(4))
上述代码通过正则匹配日志中的回源标识，帮助新手快速看到哪些接口在被回源。实践中，建议对大文件和不常变动的资源设置较长过期时间，并结合版本号或哈希命名来控制更新，而不是盲目依赖回源刷新。这样既能保证内容更新可控，也能把回源比例压到最低。
还要注意，回源协议和端口配置错误是新手常踩的坑。如果边缘节点被设成用HTTPS回源，但源站只开了HTTP，就会出现回源失败进而返回5xx。因此在CDN控制台填写源站信息时，务必确认协议、端口、回源Host与源站Web服务完全对应。
缓存命中率的计算方式与优化思路
缓存命中率一般指一段时间内边缘节点直接返回缓存响应的请求数，占总请求数的比例。公式可以表达为：命中率等于命中次数除以（命中次数加回源次数）。这个指标是衡量CDN省钱和提速效果的核心，命中率越高，源站带宽和负载越低，用户延迟也越小。
很多新手看到命中率只有百分之六十就以为CDN没生效，其实要先看业务类型。动态接口本身不能缓存，若网站以API为主，命中率天然偏低；而图片、视频、安装包等静态资源占比高时，命中率应达到九成以上。我们可以通过分离动静域名，让静态域名全量缓存、动态域名直接回源，从而拉高整体静态命中率。下表列出两类资源的典型配置差异：
| 资源类型 | 缓存时间 | 回源策略 |
|---|---|---|
| 图片与CSS | 30天 | 过期后回源 |
| 用户API | 不缓存 | 始终回源 |
优化命中率还可以从URL规范化入手。同一个文件若因带不同查询参数而被当成不同资源，节点会重复缓存多份，命中率就被稀释。可以在CDN规则里忽略无关参数，或统一在业务侧生成固定URL。最后，利用预热功能在版本发布前把新文件推到边缘节点，也能避免发布瞬间的回源突增，让命中率曲线保持平稳。
当发现命中率异常下降，优先检查是否有人误点全站刷新，或者源站响应里带了不允许缓存的头部。用curl -I命令查看响应头中的Cache-Control字段，确认没有被设成private或no-store，这是新手排查问题的第一步。