摘要：# 当你的源站“抽风”时，自建高防CDN如何帮你兜底？ 上个月，我帮一个朋友看他的电商站。防护做得挺全，高防CDN挂着，流量看着也正常。结果半夜一场促销，源站数据库突然卡了一下，就几秒钟。你猜怎么着？前端用户看到的不是加载转圈，而是直接一片“502 Ba…

当你的源站“抽风”时，自建高防CDN如何帮你兜底？

上个月，我帮一个朋友看他的电商站。防护做得挺全，高防CDN挂着，流量看着也正常。结果半夜一场促销，源站数据库突然卡了一下，就几秒钟。你猜怎么着？前端用户看到的不是加载转圈，而是直接一片“502 Bad Gateway”。订单丢了一堆，客服电话被打爆。事后一查，CDN配置里那个回源重试机制，压根没仔细设置过，用的全是默认值。

说白了，很多朋友砸钱上高防，注意力全在“防得住多少G的流量”、“清洗能力多强”上。这没错，但防护的最终目的，是让业务能跑通。如果源站自己打个喷嚏（任何服务都可能偶尔抽风），你的CDN如果因为一次回源失败就立刻给用户报错，那前面所有的防护都成了摆设。今天咱们就掰开揉碎了聊聊，自建高防CDN里这个常被忽略，却真正决定“连接稳定性”的命门——回源重试机制。

回源重试：不是“要不要”，而是“怎么配”

先泼盆冷水。很多市面上的方案（甚至一些自建的），PPT上把回源重试吹得天花乱坠，真到了配置后台，往往就几个孤零零的输入框：“重试次数”、“超时时间”。填个3，填个5秒，就觉得万事大吉。

大错特错。

这就像你只知道给汽车装个备用轮胎，却不知道备胎也有尺寸、气压、最高时速限制一样。一个有效的重试机制，是一套组合策略，它至少得回答四个问题：

1. 什么时候重试？（触发条件）
2. 向谁重试？（重试对象）
3. 以什么节奏重试？（重试策略）
4. 重试到什么时候放弃？（终止与降级）

咱们一个个说。

触发条件：别等“死了”才救

最常见的触发条件就俩：连接失败和响应异常。

• 连接失败好理解。CDN节点去连你源站IP+端口，根本连不上（比如源站服务器宕机、防火墙策略错误）。这种是硬伤，必须重试。
• 响应异常才是重头戏，也是坑最多的地方。什么叫异常？
  • HTTP状态码异常：比如源站返回了5xx（服务器错误）、408（请求超时），或者某些业务特定的4xx（比如429，请求过多）。你不能一刀切，有些4xx是客户请求有问题（比如404），这你重试一百遍也没用。
  • 响应超时：这是最阴险的。连接建立了，但源站处理得太慢，超过了你设定的时间（比如10秒）。这时候，用户在前端早就等不及了。关键来了：超时后，你CDN是立刻给用户报错，还是默默重试另一个源站？ 我见过太多配置，超时直接算失败，不重试。
  • 响应内容异常：比如源站返回的HTML结构不对，或者JSON格式解析失败。这需要CDN能支持一定程度的内容校验，门槛较高，但非常有用。

我的建议是：在自建时，至少要把连接失败、5xx状态码、请求超时这三项，作为核心的重试触发条件。别用那个笼统的“失败重试”开关。

重试对象：别在一棵树上吊死

这是自建高防CDN最大的优势之一——灵活的源站配置。你的源站不应该只有一个IP。

1. 多源站负载均衡：准备至少两个源站，可以是主备，也可以是双活。重试机制的第一要义，就是在第一次回源失败后，立刻换一个源站IP再试。这比在同一个故障IP上重试3次有用得多。
2. 端口备用：有些时候，可能是特定端口被意外占用或策略封锁。配置时，可以设置主源站“IP:80”失败后，重试“IP:8080”或其他备用端口。
3. 路径降级：对于动态请求，如果主业务接口（/api/order）挂掉，是否可以重试到一个返回简化数据或静态页面的备用接口（/static/fallback.html）？这需要业务配合，但能极大提升用户体验。

说白了，重试的核心思路是“换条路走”，而不是“在死胡同里撞墙”。

重试策略：节奏感决定用户体验

“重试3次，间隔1秒”。这是最傻的配置。想象一下，用户点击购买，页面卡住，他要等你的CDN用“1秒、1秒、1秒”的节奏试完3次，总共3秒后才看到错误页。体验极差。

好的策略要有退避算法，特别是指数退避。

• 第一次失败，等个很短的时间（比如100毫秒）就重试。因为可能是网络瞬间波动。
• 第二次还失败，等待时间翻倍（200毫秒）。
• 第三次失败，再翻倍（400毫秒）……

这样做的目的是：避免在源站已经压力山大或短暂故障时，你还用固定频率的请求去“雪上加霜”。指数退避给源站一个喘息和自我恢复的机会。同时，对于用户来说，大部分成功请求在第一次重试（100毫秒后）就解决了，几乎无感。

终止与降级：学会“优雅地失败”

重试不能无休无止。总要有个终点。

1. 最大重试次数/总超时：设定一个上限，比如总尝试3个不同的源站，或总耗时不超过5秒。一旦达到，就必须给前端一个结果。
2. 失败后的降级：这是体现水平的地方。直接抛个5xx错误页是最low的。你可以：
   • 返回静态缓存：对于商品详情页这类，可以返回上一次成功抓取并缓存的旧页面，至少页面能打开。
   • 返回预设兜底页：一个友好的“系统繁忙，请稍后再试”页面，比冷冰冰的错误码好一万倍。
   • 对于API：可以返回一个结构正确的、带有“服务暂不可用”标识的简化JSON。
3. 标记故障源站：当一个源站被重试多次都失败后，应该暂时将其从健康源站列表中标记为不可用，并在一定时间（如30秒）后再进行健康检查。这叫熔断，防止后续请求继续往这个“火坑”里跳。

一个真实的配置思路（仅供参考）

假设你自建了高防CDN（用Nginx或OpenResty），后端有两个源站：源站A（主）和源站B（备）。

你的重试机制配置逻辑应该是这样的：

upstream backend {
    server 源站A:80 max_fails=2 fail_timeout=30s; # 失败2次，熔断30秒
    server 源站B:80 backup; # 备份源站
}

location / {
    proxy_pass http://backend;
    proxy_next_upstream error timeout http_500 http_502 http_503 http_504; # 什么情况下换下一个源站
    proxy_next_upstream_tries 3; # 最多尝试几个上游服务器
    proxy_next_upstream_timeout 5s; # 所有重试总时间
    proxy_connect_timeout 2s; # 连接源站超时
    proxy_read_timeout 5s; # 读取响应超时

    # 当所有上游都失败后，返回一个友好的50x页面
    error_page 500 502 503 504 =200 /static/maintenance.html;
}

注意看：这里proxy_next_upstream指令是关键，它定义了“换路”的条件。并且，通过error_page，我们把难看的错误码，转换成了一个能正常返回200状态码的静态维护页。用户刷新时不会浏览器报错，体验平滑很多。

最后的大实话

自建高防CDN，技术难点其实不在防DDoS本身（现在开源方案和云厂商的底层防护都很成熟），真正的差距就在这些细节的“运维智慧”里。回源重试机制，就是这种智慧的典型代表。它要求你不仅懂网络，还要懂业务，懂用户体验。

别再只盯着防御峰值流量那个数字了。回去检查一下你的CDN配置，那个重试机制是不是还停留在“裸奔”状态。如果你的源站还只有孤零零的一个，那我劝你，今晚就加一个备用的。这成本，远比一次莫名其妙的业务中断要低得多。

行了，关于“兜底”的艺术，今天就聊到这。下次咱们可以聊聊，怎么在高防CDN里做更细粒度的流量调度和会话保持——那又是另一个故事了。