CDN支持请求重写吗？功能解析与配置教程
深夜改完最后一条规则，盯着监控屏上平稳的流量曲线，终于能喘口气。做CDN运维这些年，最怕半夜被DDoS警报炸醒，但比这更磨人的是——客户突然问：\”这个动态参数能不能在CDN层改掉？后端实在动不了。\” 这时候，\”请求重写\”就是救命稻草。
CDN当然支持请求重写，但这功能像把双刃剑。用好了能解燃眉之急，用岔了可能把整个缓存体系捅个窟窿。它不是简单改个URL，而是直接在边缘节点对流量\”动手术\”。想象一下：用户请求 /product?id=123，经过CDN时瞬间被重写成 /v2/product-detail/123 再回源——后端甚至不知道自己被\”伪装\”了。
什么场景非得用这招？ 去年帮一家电商处理过典型案例：老版APP还在用?sku=XXX传参，新版API已变成REST风格路径。后端重构来不及，APP强制更新率又低。我们在CDN层写规则：if (args_sku exists) rewrite ^/(.*)$ /v2/products/{args_sku} break; 旧请求无缝对接新接口，缓存命中率还涨了30%。
各家CDN的实现水深着呢：
• Akamai的EdgeRewrite藏在Property Manager里，得用JSON配变量捕获，像\"matchValue\": \"/(.*)/old\", \"replace\": \"/new/$1\"。调试时得开EdgeStaging，不然生产环境分分钟教你做人。
• Cloudflare的Transform Rules界面友好，但正则引擎有坑——^(/zh-CN/)(.*)$想重写中文路径？得先确认Works支持中文匹配，不然规则直接哑火。
• 国内厂商如阿里云CDN的\”改写配置\”藏在高级功能里，最大槽点是日志不记录原始请求。某次误配规则把/api全转给静态OSS桶，查半小时才定位到是重写规则背锅。
配置时踩过的血泪坑：
1. 缓存污染：重写后URL不同但内容相同？务必设cache-key！见过有人把/product?id=1和/product?id=2都重写成/product，结果全用户看到同一商品
2. 循环重定向：规则没加last或break标志？重写后的请求可能再次触发规则，死循环直到CDN报错
3. 敏感信息泄露：把Authorization头重写进URL？某金融平台因此被黑产扫到密钥，现在我都强制加Header Filter脱敏
实战建议：上生产前用curl -v -H \"Pragma: akamai-x-debug\" 或Cloudflare的Ruleset Testing跑仿真。别信配置界面的\”预览\”，边缘节点行为可能让你怀疑人生。
说到底，请求重写是CDN的\”器官移植手术\”。能不动就别动，真要动时——备好止血钳（测试方案）、心电图（实时监控）、术后护理（缓存刷新），毕竟用户可不会等你拆线。
评论: