分析自建高防 CDN 面对复杂业务场景下的路由重写与跳转配置

摘要：## 自建高防CDN，路由配置搞不定？那你的防护可能白做了 前两天跟一个做电商的朋友聊天，他愁得不行。花了大几万自建了一套高防CDN，硬件堆得挺足，结果大促前模拟攻击测试，业务直接崩了。不是带宽被打满，更邪门——用户下单，页面跳转去了一个八竿子打不着的4…

自建高防CDN，路由配置搞不定？那你的防护可能白做了

前两天跟一个做电商的朋友聊天，他愁得不行。花了大几万自建了一套高防CDN，硬件堆得挺足，结果大促前模拟攻击测试，业务直接崩了。不是带宽被打满，更邪门——用户下单，页面跳转去了一个八竿子打不着的404页面；后台管理员的登录请求，莫名其妙被导到了前台商品页。整个系统乱成了一锅粥。

他当时就懵了，在电话里跟我吐槽：“防护规则我抄的大厂最佳实践啊，流量明明都过清洗中心了，怎么内部自己‘打’起来了？”

我听完就明白了。问题根本不在防护规则，而在路由和跳转配置上。这玩意儿，堪称自建高防CDN里最隐秘的“阿喀琉斯之踵”。很多团队盯着流量清洗、DDoS拦截，觉得扛住外部攻击就万事大吉，结果往往是被自己复杂的业务逻辑和错误的路由配置给绊倒了。

说白了，你的高防CDN建得再坚固，如果里面的“交通指挥系统”（也就是路由重写与跳转）是乱的，那所有流量，不管是正常的还是恶意的，进来都得迷路。业务不崩才怪。

路由重写：不是简单的“指路牌”，而是业务的“神经中枢”

很多人觉得路由重写，不就是Nginx里写几行rewrite规则，把/old指向/new吗？太天真了。

在自建高防CDN的语境下，路由重写要处理的是三个层面的复杂纠葛：

1. 用户层面：用户看到的、访问的URL（经过CDN的）。
2. CDN节点层面：CDN服务器接收、处理并需要向后端（源站或下一层）转发的URL。
3. 源站层面：你的业务服务器（源站）真正能识别和处理的URL。

这里最容易出幺蛾子的，就是业务本身已经够复杂了。举个例子，你有一个商城系统：

• 主站：www.abc.com
• 移动端专有域名：m.abc.com
• 后台管理：admin.abc.com（这个你肯定不想暴露给CDN，得隐藏）
• 还有一堆API接口：api.abc.com/user/login，api.abc.com/order/create

你的自建高防CDN在前面扛着，所有*.abc.com的流量都先到CDN。这时候，路由规则就得像老练的交警：

• 对于m.abc.com：CDN需要识别这是移动端流量，可能要做设备适配，然后重写请求，将其转发到源站对应的移动端服务端口或路径上。你不能简单粗暴地直接回源到www.abc.com，那PC端的模板就套到手机上了。
• 对于admin.abc.com：你绝对不希望这个域名被解析到CDN的IP上。理想的做法是，在DNS层面就将它指向一个隐藏的、非公开的源站IP（这就是常说的“源站隐藏”）。但如果因为历史原因，它也必须过CDN呢？那你的路由规则必须包含严格的IP/身份白名单，非指定IP的访问请求，CDN层就应该直接拦截或返回错误，而不是简单转发。
• 对于API请求：这里的水更深。/user/login和/order/create需要的安全策略、缓存策略可能完全相反。登录接口绝对不能缓存，且要重点防CC攻击；下单接口要保证极高的可用性和一致性。你的CDN路由配置，必须能根据URL路径特征，将流量导入不同的“处理管道”——有的管道侧重安全清洗，有的管道侧重快速响应。

我见过最典型的配置失误，就是图省事，在CDN上设置了一个“通配”回源规则：把所有请求的Host头都改成源站的一个统一域名。结果就是，源站Nginx靠Host头来区分不同站点的配置全部失效，所有请求都涌向默认的服务器块，业务逻辑全乱。

所以，路由重写的核心，是让CDN理解你的业务逻辑，并精准地扮演好“流量分发者”和“协议适配器”的角色。 它得知道，什么请求该去哪，以什么样子去。

跳转配置：一个不留神，就是“鬼打墙”循环

跳转（301/302/307这些）的坑，比路由重写更隐蔽，也更让人头疼。因为它经常发生在业务逻辑内部，而CDN很容易被卷进去，形成死循环。

说个真实案例。某公司业务做了架构升级，旧版商品页路径是/product_123.html，新版是/products/123。他们在源站用Nginx配置了301跳转，把旧链接永久重定向到新链接，很标准的SEO操作。

然后他们上了自建高防CDN。问题来了：用户请求旧链接/product_123.html，这个请求先到了CDN节点。如果CDN节点上没有缓存这个URL，它会将请求转发给源站。源站返回301响应，Location头是新的/products/123。

关键点到了：这个301响应是返回给谁的？是返回给CDN节点的，还是直接告诉浏览器？

在大多数默认配置下，CDN节点会“聪明”地接过这个301响应，然后自己再去请求新的/products/123，拿到内容后再返回给用户。这看起来没问题，对吧？

但如果你的CDN配置里，对旧URL和新URL的回源策略、缓存策略不一致，麻烦就来了。比如，旧URL/product_123.html你设置了“不回源，直接缓存”，而新URL/products/123设置了“总是回源验证”。那么，当CDN节点收到301后，去请求/products/123时，它又会触发回源。这时候，如果源站针对这个新URL的处理逻辑里，又包含了某种条件跳转（比如根据用户身份跳不同页面），或者更极端一点，源站某个配置错误，把/products/123又跳转回了/product_123.html……

恭喜你，“鬼打墙”形成了。CDN和源站之间可能会陷入短暂的跳转循环，直到某一方超时。用户看到的就是白屏或504错误。

所以，在自建高防CDN里处理跳转，你必须明确：

1. 穿透式跳转 vs 代理式跳转：对于业务发起的、重要的跳转（如登录后跳转回原页面），你通常希望CDN“穿透”它，即把跳转响应直接传给浏览器，让浏览器和源站完成后续“对话”。这需要在CDN（如OpenResty）里精细控制proxy_redirect等指令。
2. 缓存与跳转的博弈：你能缓存一个301响应吗？通常可以，而且这对性能有好处。但你能缓存一个302临时跳转吗？这就要非常小心了，特别是这个跳转里包含了用户会话状态（比如带了个token参数）。缓存错了，用户A的登录状态可能就跳到了用户B的页面，那真是灾难。
3. 绝对路径与相对路径：源站返回的跳转Location头，是/products/123这样的相对路径，还是https://www.abc.com/products/123这样的绝对路径？这在CDN多层代理的环境下，处理起来天差地别。相对路径很可能在CDN层被错误地拼接，导致跳转目标错误。

面对复杂业务，你的配置清单不能只抄作业

说了这么多，到底该怎么配？我给你几个不是标准答案，但能救命的核心思路：

1. 画张“流量地图”：别急着写配置。先把你的业务域名、子域名、关键API路径、它们之间的跳转关系，在一张白纸上画出来。标清楚哪些必须过CDN，哪些必须隐藏，哪些流量大，哪些安全性要求高。这张图，就是你所有配置的宪法。
2. 实施“渐进式上线”：别把所有业务域名一次性切到自建高防CDN上。先拿一个不重要的、但流量模式有代表性的子域名（比如static.abc.com静态资源）做测试。重点测试：缓存是否生效、回源是否正常、HTTPS证书有没有问题、跳转逻辑是否如预期。
3. 给配置加上“监控探头”：在CDN的日志里，不仅要看访问量、带宽，更要重点分析HTTP状态码的分布。突然出现大量的301/302/307，或者大量的404、502，都是路由或跳转配置出问题的强烈信号。在关键的重写和跳转规则处，可以打印自定义日志，跟踪一个请求的完整生命周期。
4. 准备“一键熔断”：再好的配置也可能有没想到的角落。必须有一个快速切换DNS，将流量从自建高防CDN回退到旧方案（或直接回源）的能力。这不是承认失败，这是业务连续性的底线。
5. 接受“不完美”：想用一套路由规则适配所有业务场景，几乎不可能。对于特别复杂、个性化的跳转逻辑（比如支付完成后，根据支付渠道跳转不同商户页面），有时候更稳妥的做法是让这部分流量绕过CDN的路由重写，通过IP白名单或其他方式，让CDN以最“透明”的模式代理到源站，把复杂的逻辑交给后端的业务代码来处理。CDN，应该做它最擅长的事：扛流量、防攻击、加速静态资源，而不是变成一个臃肿的业务路由器。

说到底，自建高防CDN就像给自己家盖了一座坚固的城堡。路由重写和跳转配置，就是城堡内部错综复杂的走廊和暗门。你把大门（防护）修得再厚，如果内部走廊是堵死的、暗门会把人带进死胡同，那这座城堡不仅保护不了你，反而会困住你自己。

别让最复杂的业务逻辑，死在最简单的配置疏忽上。多测试，慢切流，常盯着日志看。这活儿，没捷径。