CDN回源配置实例：优化设置步骤与常见问题解决方案
上週幫遊戲公司做CDN架構稽核，發現工程師把回源端口設成8080卻沒開防火牆，直接讓源站暴露在公網。這種低級錯誤每年都要遇到幾次，今天就來拆解那些藏在回源配置裡的魔鬼細節。
多數人以為CDN設定就是填個源站IP完事，實際連阿里雲文檔都藏著關鍵提示：「HTTPS回源時若啟用證書校驗，請確保證書鏈完整」。去年某證券App閃退事故，就因源站用了自簽證書但CDN沒關閉校驗，流量全卡在邊緣節點。
實戰中最要命的是協議轉換陷阱。當客戶端用HTTP/2訪問CDN，而源站只支持HTTP/1.1時，若沒開啟協議降級（如Cloudflare的HTTP/2 to Origin功能），會觸發504錯誤。曾見證某電商大促時因此丟失千萬訂單，運維團隊查了通宵才揪出這條毒蛇。
關於回源策略，我偏愛多級源站架構。用Nginx在源站前做緩衝層：靜態資源直接回源，動態請求通過專線走私有協議到應用伺服器。某跨境支付平台用這招把澳洲用戶的回源延遲從230ms壓到89ms，秘訣在於讓CDN的悉尼節點直連本地緩衝層，而非跨洋回香港源站。
遇到最棘手的案例是某直播平台源站頻繁502。抓包發現CDN節點每秒新建300個TCP連接，源站Nginx的worker_connections早爆了。解法很騷：在CDN配置裡把「回源連接複用」從默認5秒提到120秒，同時調整keepalive_timeout參數。這個參數Akamai藏在Advanced Settings三層菜單裡，Cloudfront則要改Origin Behaviors，沒點耐心真找不到。
最後提醒防火牆白名單的冷知識：當CDN啟用Anycast IP時，回源IP段可能跨地區動態變更。某次幫銀行做合規檢查，發現他們只加了Cloudfront美國IP段，結果東南亞流量全被攔截。現在都要求客戶在CDN後掛WAF，用X-Forwarded-For溯源才是正解。
評論: