騰訊雲企業帳號開通 騰訊雲 CDN 啟用 gzip/brotli 壓縮不生效，流量費暴增排查
先別急著怪壓縮，先看問題到底出在哪裡
很多人第一次發現騰訊雲 CDN 流量費突然變高，第一反應就是：不是已經開了 gzip 和 brotli 嗎，怎麼還會這麼大？其實這種情況很常見，真正的問題往往不是「沒開」，而是「沒有命中壓縮條件」，或者「開了，但只對一小部分請求生效」。
CDN 壓縮不是萬能開關。它只會對符合條件的文本資源生效，對圖片、影片、壓縮包這些本來就很難再壓縮的內容幾乎沒有幫助。更麻煩的是，很多站點表面上看起來一切正常，實際上回應頭裡根本沒有 Content-Encoding，也就是說瀏覽器收到的依然是原始大小的內容。當訪問量一上來，流量自然跟著飆。
所以排查這類問題，不要先盯著控制台的開關，而是先回答三個問題：第一，請求有沒有真的打到 CDN；第二，CDN 有沒有對該資源進行壓縮；第三，壓縮之後有沒有被正確快取和復用。只要這三個環節中任何一個掉鏈子，流量費都可能比預期高出一截。
第一步：確認回應頭，別只看控制台狀態
最直接的方式，是抓一個真實請求看回應頭。不要只用瀏覽器表面點開，最好直接用命令列測試。比如對同一個資源分別帶上和不帶上壓縮能力：curl -I -H 'Accept-Encoding: gzip, br' 目標地址。重點看幾個欄位。
- 騰訊雲企業帳號開通
Content-Encoding：如果是gzip或br，代表壓縮真的生效了。 Content-Type：是否屬於可壓縮的文本類型，例如 HTML、CSS、JS、JSON、XML、SVG。Vary：通常應該關注是否帶有Accept-Encoding，否則不同能力的客戶端可能會拿到不匹配的版本。Age、X-Cache、Via：用來判斷是否命中 CDN 快取，以及回應是從哪一層返回。
很多故障的第一個信號，就是 Content-Encoding 一直沒有出現。這意味著不是壓縮沒開，而是壓縮條件沒達到。這一步能把大量「看起來像壓縮故障」的問題直接篩掉。
第二步：先排除最常見的誤區
不是所有資源都值得壓縮
gzip 和 brotli 對文本類內容效果最好。對 CSS、JS、HTML、JSON 這些文件，壓縮率往往很可觀；但對 JPG、PNG、MP4、ZIP、RAR 這類已經高度壓縮的內容，效果幾乎可以忽略。很多團隊在看流量報表時，只盯著總流量，以為壓縮失敗，其實真正吃流量的是圖片、影片、安裝包和大附件。
如果你的站點是圖片站、視頻站或者下載站，gzip/brotli 只會影響一小部分請求，甚至可以說只是錦上添花。這時候流量費暴增，真正該檢查的是資源結構，而不是壓縮開關。
文件太小，壓縮可能根本不划算
很多 CDN 會對壓縮設置最小文件大小限制。道理很簡單，太小的文件壓縮後節省不了多少流量，反而多了壓縮和解壓的開銷。比如一個幾百字節的 JS 段，壓縮前後差距有限；如果站點大量使用小文件，從總流量看，節省效果就不明顯。
所以別只看單個文件的壓縮率，要看整體請求結構。是少量大文件，還是大量中小文件，這兩種情況的優化方式完全不同。
客戶端不支持 brotli，不代表配置失敗
brotli 的壓縮效率通常比 gzip 更好，但不是所有瀏覽器、App 或爬蟲都支持。當客戶端不支持時，正常情況下應該回退到 gzip，或者直接返回未壓縮版本。如果你只測了某些老舊客戶端，看到沒帶 br，不代表配置有問題；反過來，如果某些設備明明支持，卻仍然拿不到壓縮內容，那才需要進一步查原因。
第三步：把快取和壓縮分開看
很多人會把快取命中率和壓縮效果混為一談，這是排查中很容易踩的坑。事實上，這兩件事雖然相關，但不是同一個問題。
如果 CDN 沒有快取住文件，每次都回源，那麼即便壓縮能在邊緣節點生效，整體效果還是會打折扣。因為你節省的是下行流量，但回源流量、源站壓力、請求耗時都可能依然很高。相反，如果資源被穩定快取，哪怕壓縮不完美，總體流量也會低很多。
排查時要看兩件事：一是快取是否命中，二是命中的那份內容是不是壓縮後的版本。有些場景下，源站回應頭設置不合理，例如 Cache-Control: no-store、private，或者動態頁面每次都變，導致 CDN 幾乎無法穩定快取。這時候你看到的流量暴增，不一定是壓縮失效，而是快取根本沒起來。
還有一種情況比較隱蔽：同一個 URL 因為查詢參數、簽名參數、版本號不同，被拆成了很多快取鍵。表面上看資源都是同一份，實際上 CDN 眼裡是很多不同文件。這會讓快取命中率變差，壓縮效果也被稀釋。
第四步：檢查回源配置，看看是不是源站把事情弄複雜了
壓縮問題裡，源站配置常常是幕後黑手。最常見的幾種情況如下。
源站已經返回壓縮內容，但 CDN 或瀏覽器識別不一致
如果源站本身就返回了 Content-Encoding: gzip，而 CDN 又嘗試再次處理，就可能出現行為不一致。理想情況下，整條鏈路要統一策略：要麼由源站負責壓縮，要麼由 CDN 邊緣負責壓縮，不要兩邊都半吊子地做。
尤其是某些框架或中間件會自動壓縮 HTML，源站也開了壓縮，CDN 又開了壓縮，最後出現頭部混亂、緩存混亂，甚至個別客戶端收到異常內容。這種問題不一定每次都報錯，但會表現成流量高、命中率低、內容大小不對。
回源頭缺少正確的 MIME 類型
騰訊雲企業帳號開通 CDN 判斷是否壓縮，通常會依賴文件類型。如果源站把 JS 當成普通二進制文件返回，或者 Content-Type 填得不對，壓縮策略就可能失效。這種錯誤在前後端分離、對象存儲掛源站、Nginx 規則混亂的場景中特別常見。
所以不只要看文件內容，還要看回應頭是否乾淨。文本就是文本，圖片就是圖片，別讓錯誤類型把整套壓縮策略帶歪。
回源文件本身已經是壓縮包
有些團隊把前端靜態資源預先打包成了 .gz 或 .br 文件，卻沒有配好對應的回應頭。結果瀏覽器拿到的不是預期內容，或者 CDN 直接把它當成普通文件處理，導致壓縮失真。這種方案不是不能用，但一旦配置錯，故障會非常難看。
如果你不確定自己是否在用預壓縮資源，最好先回到最簡單的策略：讓 CDN 根據客戶端能力動態壓縮，先把整體邏輯跑通，再考慮更細的性能優化。
第五步：別忽略資源本身的結構問題
有時候壓縮沒有問題，問題出在資源太臃腫。這種情況很容易讓人誤判成 CDN 配置故障。
例如首頁首屏就引了幾個超大的 JS 包，裡面還塞了 source map、測試代碼、沒用上的 locale 文件，或者把很多業務邏輯打成一個超大 bundle。這些文件即使能壓縮，壓縮後還是大。再加上請求數多、命中率差，總流量依然嚇人。
騰訊雲企業帳號開通 這時候要做的不是一味提高壓縮級別，而是先瘦身：拆包、懶加載、刪除未使用代碼、去掉公開環境的 source map、把大 JSON 做分頁或增量返回。很多時候，把單頁應用的首屏體積降下來，比單純把壓縮從 gzip 換成 brotli 更有效。
第六步：一套可落地的排查流程
如果你現在正面臨流量暴增，可以按下面順序排查，效率會高很多。
- 抽一個最典型的靜態資源，查看回應頭，確認是否有
Content-Encoding。 - 同時檢查
Content-Type，確認文件類型是否本來就屬於可壓縮範圍。 - 騰訊雲企業帳號開通 比對帶
Accept-Encoding: gzip, br和不帶壓縮能力時的返回差異。 - 觀察
Age、X-Cache，判斷是否命中 CDN 快取。 - 檢查 URL 是否帶過多參數，導致快取鍵被拆碎。
- 檢查源站是否自己已經開啟壓縮，是否與 CDN 策略重疊。
- 檢查回源的
Cache-Control是否過於保守，是否讓 CDN 無法正常緩存。 - 統計實際流量構成，看看是不是圖片、影片、下載文件才是大頭。
這一套流程跑完，基本就能知道問題是在「沒壓縮」、「壓縮沒命中」、「壓縮有了但沒快取」，還是「壓縮本來就救不了這類資源」。
第七步：真正能把流量降下來的做法
找到原因之後，接下來要做的是把問題從根上解掉，而不是只修表面。比較有效的做法有幾個。
第一，把壓縮策略對準正確的文件類型。HTML、CSS、JS、JSON、XML 這些內容優先開啟 gzip 和 brotli，圖片、影片、壓縮包就不要指望它們能帶來明顯收益。
第二，讓可快取資源真正長期留在 CDN 節點上。對版本化的靜態資源設置合理的快取時間，避免每次都回源。對於變化頻率高的接口，至少要分清哪些內容可以緩存，哪些一定不能緩存。
第三，優化前端資源體積。大文件拆分、小文件合併要有節制，刪掉不必要的依賴和 source map，減少首次傳輸體積。壓縮只是最後一層，真正省流量的是少傳。
第四，做好瀏覽器兼容和回退。brotli 效果好，但不要把希望全部壓在它身上；gzip 仍然是最穩的底線。CDN 配置裡，兩者都要考慮，讓支援的客戶端吃到更高壓縮率，不支援的客戶端也能正常拿到 gzip。
第五，持續觀察報表，而不是只在出問題時才看一次。流量費暴增往往不是瞬間發生的，通常是某次發版、某個活動頁、某批圖片上線後慢慢抬頭。只要建立起版本、資源類型、快取命中率的對照，就比較容易在早期把問題抓出來。
一個很典型的排查結論
有些案例看起來是「CDN 壓縮不生效」，最後定位下來其實是三件事疊加：第一，JS 包過大，還把 source map 一起放到了生產環境；第二，部分接口返回了不可快取的頭部，導致大量回源；第三，圖片、下載文件佔了流量大頭，壓縮對它們幾乎沒有幫助。這三件事單獨看都不算致命，放在一起就會讓月度流量費直接失控。
修正之後，真正有效的不是單一開關，而是整套策略一起改：壓縮只給文本資源，靜態文件長緩存，動態接口分級處理，前端資源瘦身，無用大文件下線。這樣做完，通常比單純把壓縮等級調高更有用。
結語：壓縮只是手段，控制傳輸才是目的
騰訊雲 CDN 的 gzip 和 brotli 沒生效，表面上是壓縮問題，本質上往往是資源治理問題。你要解的不是某個開關，而是整條鏈路：資源類型是否正確、回應頭是否乾淨、快取是否合理、前端包是否過大、流量大頭到底在哪裡。
如果只看「我明明開了功能，為什麼沒效果」，很容易陷在配置細節裡打轉；但如果把問題放回整體傳輸效率來看，排查路線就清楚了。先確認壓縮是否真的命中，再確認快取是否真正起來，最後再看是不是資源結構本身有問題。這樣一步步走，流量費暴增的原因通常都能被揪出來。
記住一句話：壓縮不是省流量的全部，它只是把本來該少傳的內容盡量少傳一點。真正讓成本下降的，是少生成、少傳輸、少回源、少浪費。
