CDN如何限制请求速率：防止DDoS攻击的配置指南
凌晨三點被手機警報震醒的滋味，所有運維人都懂。螢幕上那條筆直衝破天際線的流量圖，伴隨著應用程式響應時間飆紅的數字，胃部瞬間揪緊——又來了。這次是某個新上線的API接口被盯上，惡意Bot偽裝成正常用戶，每秒數萬次請求癱瘓了後端驗證服務。不是第一次了，但每次面對這種「慢速DDoS」（Low and Slow Attack），傳統防火牆就像用大砲打蚊子，吃力不討好。真正能精準攔截這類「披著羊皮的狼」的武器，其實藏在CDN的請求速率限制（Rate Limiting）設定裡，只是很多人用得太粗糙。
別以為在CDN控制台隨便填個「每分鐘1000次請求」就萬事大吉。去年幫一家電商平台做滲透測試，發現攻擊者用上萬個免費代理IP，每個IP的請求頻率都「乖巧」地壓在閾值下方，結果分散的慢速請求照樣拖垮了購物車結算系統。關鍵在於：速率限制必須分層、多維度，配合行為特徵才能精準攔截。分享幾個實戰中驗證有效的配置邏輯：
第一刀：從IP維度砍，但要砍得聰明。 別只設單一閾值！我習慣用「滑動時間窗」演算法（例如Token Bucket）。假設設定「單IP每10秒50次請求」，當某IP在第8秒突然發起60次請求，前兩秒的額度還沒釋放完，多出的10次就會被立即攔截。更狠的是加上「懲罰機制」：一旦觸發限制，自動將該IP的閾值下調50%並延長監控時間窗。上個月某金融客戶遭撞庫攻擊，靠這招把攻擊IP的請求能力直接壓到正常用戶的1/10。
第二刀：直指業務特徵，揪出異常行為鏈。 攻擊者能偽造IP，但行為模式總有破綻。某遊戲客戶的活動頁面遭爬蟲刷獎勵，我們在CDN上針對「/api/redeem」這個兌換接口，疊加了三層規則：單IP每分鐘請求上限、單IP對該接口的連續調用間隔不得低於200ms、同一Session ID在5分鐘內觸發兌換超過3次即觸發人機驗證。這組合拳打下去，爬蟲成功率從100%暴跌到3%以下。
第三刀：動態閾值才是王道。 死板的數字永遠鬥不過活人。現在主流CDN如Cloudflare、Akamai Prolexic都支援基於AI的動態基線。簡單說，系統會自動學習每個URL路徑在不同時段、不同地理區域的正常流量波動。當某個API突然在凌晨三點被巴西IP以高於歷史均值500%的頻率呼叫，不用等工程師手動調整，CDN會自動觸發速率限制並發送告警。這招專治那些專挑冷門時段下手的「猥瑣流」攻擊者。
配置實戰細節（以Cloudflare為例）：
1. 別只設全域規則！優先保護核心業務路徑，例如登入(/login)、支付(/checkout)。針對這些高風險URL單獨建立Rate Limit Rules，閾值設得比全域更低。
2. 「Counting Period」是關鍵：針對快速暴力破解，用短週期（10-30秒）；防慢速爬蟲則拉長到1-5分鐘。
3. 懲罰動作別只選「Block」！試試「Challenge (CAPTCHA)」或「JS Challenge」。真用戶偶爾超限還能解驗證繼續用，惡意Bot被攔截機率更高。
4. 進階玩法：啟用「匹配特定Header或Cookie」。例如對缺失「X-APP-AUTH」自定義標頭的請求實施更嚴格的速率控制，專打那些不經客戶端、直接調API的簡化攻擊腳本。
上週某媒體客戶的圖文內容被競爭對手用低頻爬蟲持續盜取，我們在CDN層做了個「隱形陷阱」：對所有請求，若User-Agent包含「Python-urllib」或「curl」等常見爬蟲標識，表面上正常響應，但實際悄悄觸發一個獨立計數器，當這類請求每小時超過50次，後續請求直接回應403。攻擊方渾然不覺，還以為爬蟲運作良好，其實拿到的是三天前的舊快取數據。
速率限制從來不是設個數字就完事。得像老獵人佈陷阱，得理解「獵物」的行為模式，在它們必經之路上埋下多個連環扣。當你在CDN上把IP維度、業務路徑、動態基線、行為特徵這幾層網交織起來，才能真正困住那些四處流竄的惡意流量。記住，好的防禦策略是讓攻擊者「以為成功」，卻在不知不覺中耗盡力氣。
評論: