CDN节点缓存刷新频繁，会不会被服务商限流 会，而且不少服务商都会限。只是这个“限流”不一定表现为接口直接报错，有时候是刷新任务排队变慢，有时候是同一批 URL 里部分成功、部分延迟生效，还有些平台会把刷新额度按天、按分钟、按账号、按域名拆开限制。 实际使用中发现，很多人理解的 CDN 刷新是“点一下，边缘节点马上删缓存”。真实情况更接近于：控制台或 API 提交刷新任务，服务商的调度系统把任务下

CDN节点延迟高但源站正常，问题通常不在源站本身 线上排障时经常遇到这种场景：源站直接 ping 只有 20ms 到 40ms，curl 源站接口也很快，但用户访问 CDN 域名就是慢，瀑布图里 TTFB 飙到 800ms、1.5s，甚至偶发 5xx。很多人第一反应是源站扛不住，或者 CDN 厂商有问题，但实际使用中发现，这类问题更常见的是“用户到 CDN 节点”“CDN 节点到源站”“CDN 调

CDN节点在日本、香港都有，国内用户访问回源还是慢，问题通常不在“有没有节点” 实际使用中发现，很多站点上了海外 CDN 以后，控制台里能看到日本节点、香港节点，甚至测试静态文件也能跑出不错的速度，但一到国内用户访问业务页面、接口、图片首次加载，就开始慢。这里容易误判，以为“香港节点离国内近，肯定快”。 CDN快不快，要分两段看：用户到 CDN 边缘节点这一段，CDN 边缘节点到源站这一段。国内用

CDN怎么防止源站IP泄露 CDN接入后，正常访问链路应该是用户请求打到CDN节点，CDN再回源到源站。外部用户只看到CDN节点IP，看不到源站IP。问题在于，很多站点虽然上了CDN，但源站IP还是能通过各种旁路被摸出来。 实际使用中发现，源站IP泄露不是CDN本身“没防住”，更多是接入方式、DNS历史记录、源站安全组、业务旁路暴露导致的。CDN只负责代理流量，不会自动帮你清理历史解析，也不会替你

CDN开了之后，源站IP还要不要藏 CDN上线以后，很多人会下意识觉得源站安全了：用户访问域名，DNS解析到CDN节点，源站只跟CDN回源通信，外面看不到真实服务器IP。这个理解方向没错，但在实际环境里，只要源站IP曾经暴露过，或者业务架构里还有旁路入口，攻击流量就可能绕过CDN直接打到源站。 所以这个问题不能只看“有没有开CDN”，要看源站有没有能力承受被直接访问、有没有历史暴露记录、有没有做访

CDN开了之后，源站IP还要不要做防火墙策略隐藏 要做，而且大多数线上故障和攻击绕过，问题就出在这里。 CDN的作用不是让源站天然隐身，它只是让用户访问域名时，流量先到CDN节点，再由CDN回源。这个链路成立的前提是：用户不知道源站IP，或者知道了也打不进去。如果源站IP暴露，并且源站80、443、SSH、数据库端口还对公网开放，那CDN前面挡得再漂亮，攻击流量也可以直接打源站。 实际使用中发现，

CDN 开了之后 HTTPS 证书报错，别急着甩锅源站 CDN 接入后 HTTPS 报错，现场最常见的反应是：源站证书是不是过期了？其实不一定。浏览器看到的证书，很多时候是 CDN 节点返回的证书，不是源站直接返回的证书。 这里要先把链路拆开。用户访问域名时，DNS 解析到 CDN 节点，浏览器和 CDN 节点建立 TLS 连接；CDN 节点再去回源，可能用 HTTP，也可能用 HTTPS。也就是

CDN回源走私网还是公网，费用差距到底能拉到多大 CDN费用里很多人盯着的是下行流量，也就是用户从CDN节点下载资源产生的费用。但实际账单里，经常还有一块容易被忽略：CDN回源流量。 回源这件事看起来很简单，CDN节点缓存没有命中，就去源站取一次文件。问题在于，这个“去源站取”到底走的是公网IP，还是云厂商内部网络。走公网，通常会吃源站公网出方向流量或公网带宽；走私网，很多场景下不计公网带宽，成本

CDN回源地址选私网还是公网，费用差在源站出方向 CDN回源这件事，很多人一开始只盯着访问速度，实际账单出来以后才发现，源站带宽费用才是容易被忽略的地方。用户访问 CDN，CDN再去源站取文件，这一段叫回源。回源用公网地址还是私网地址，主要影响的是源站出方向流量怎么计费。 这里先把口径说清楚：CDN给用户下发的流量，正常还是按 CDN 流量计费；源站到 CDN 节点的流量，如果走公网，一般会算源站

CDN回源到底能不能只配一个源站 CDN节点离用户近，抗住大部分静态请求没问题，但只要缓存 miss、动态接口、刷新预热、带鉴权的资源、Range 回源下载，一定会打到源站。源站如果只有一台机器或者只有一个公网入口，CDN本身再稳，链路还是会被这个源站拖住。 实际使用中发现，很多站点出问题不是CDN节点挂了，而是回源链路抖了、源站带宽打满了、源站安全组误改了、机房出口被 DDoS 牵连了。用户看到