騰訊雲企業帳號充值 騰訊云 COS 存儲桶防盜鏈（Referer）配置無效，流量被盜刷排查
先看現象：為什麼已經開了防盜鏈，流量還是在漲
很多人第一次碰到 COS 流量被盜刷時，第一反應都是去改 Referer 防盜鏈。配置完之後，心裡以為問題就解決了，結果過兩天一看賬單，外網流量照樣往上飄，請求量也沒有明顯下降。這種情況最容易讓人產生一個錯覺：防盜鏈失效了。
其實大多數時候，問題不在 COS 這項功能本身，而在於你對它的作用範圍預期過高。Referer 防盜鏈本質上只是根據請求頭裡的來源頁做一層過濾，它不是鑑權，不是加密，也不是資源授權。只要請求方式、代理鏈路、域名配置或訪問路徑稍微有一點偏差，結果就可能和你想的不一樣。
所以排查這類問題時，不能只盯著「有沒有開防盜鏈」，而要先弄清楚三件事：到底是誰在請求，請求是從哪條鏈路進來的，COS 最後看到的 Referer 是什麼。只要把這三件事查清楚，很多看似玄學的問題其實都能落到具體原因上。
先弄明白：COS 的 Referer 防盜鏈到底管什麼，不管什麼
Referer 防盜鏈最適合處理的是這類場景：你的圖片、音頻、視頻或靜態文件被別人的網站直接引用，瀏覽器在載入資源時會帶上來源頁地址，COS 根據這個 Referer 判斷是否放行。這種情況下，如果規則設得對，確實可以擋掉很多站外熱鏈。
但它有幾個明顯邊界。第一，Referer 是客戶端發送的頭，並不是服務端強制生成的，所以它天然不可靠。第二，很多請求根本不會帶 Referer，比如直接在地址欄打開、部分 APP 內部請求、腳本工具下載、某些隱私模式瀏覽器，甚至一些代理中間層都可能把它去掉。第三，即便帶了 Referer，也可能被人偽造。
騰訊雲企業帳號充值 這意味著，Referer 防盜鏈只能作為第一道門，而不能當成唯一門。你如果把它當成「只要開了就一定沒人能偷」來用，後面就很容易碰到配置看起來正常、實際卻擋不住的情況。
不要把防盜鏈和權限控制混為一談
很多流量被盜刷的案例，真正的問題其實不是熱鏈，而是桶本身對外太開放。比如桶是公有讀，對象路徑規律又很強，文件名還能被猜出來，這時候哪怕你加了 Referer 白名單，別人只要不經過瀏覽器或者把頭偽造好，照樣能直接拉資源。
如果你要的是「只有自己的業務可以拿到資源」，那靠 Referer 是不夠的，還得結合私有桶、臨時簽名、STS、應用層授權這些手段。防盜鏈更像是減少裸露面，而不是徹底封死入口。
配置無效的常見原因，往往就藏在這幾個細節裡
一、域名用錯了，請求根本沒走你配置的那個入口
這是最常見也最容易被忽略的一種。很多人配置防盜鏈時，實際檢查的是 COS 的默認訪問域名，但業務真正對外使用的卻是自定義域名、CDN 域名，甚至是別的加速節點。如果請求並不是直接打到你設置防盜鏈的那個訪問入口，規則自然不會生效。
騰訊雲企業帳號充值 比如你在 COS 上配置了來源白名單，結果前端圖片地址走的是 CDN，CDN 又回源到 COS。這時候 COS 看到的請求很可能來自 CDN 節點，而不是原始網站頁面。Referer 有時候會被 CDN 改寫、裁剪，甚至完全不傳，最後就出現兩種極端：要麼全放行，要麼全誤殺。看起來像防盜鏈沒起作用，其實是鏈路已經變了。
二、白名單和黑名單的邏輯搞反了
不少人剛接觸時，容易把「允許哪些域名」和「拒絕哪些域名」弄混。配置時如果選了錯誤的模式，再加上規則順序或默認行為沒看清，就會出現和預期完全相反的結果。尤其是多條規則並存時，最後到底是命中哪一條，很容易被忽略。
建議你重新確認一次：你到底是想「只允許這些來源」，還是想「除了這些來源，其餘全部拒絕」。這兩種思路的配置方式並不一樣。前者更穩妥，後者更容易因為漏寫規則而把自己也擋在外面，或者因為默認放行而留下口子。
三、通配符寫得太寬或太窄
Referer 規則裡最容易出問題的就是通配符。寫得太窄，像主域名能過、子域名不過；寫得太寬，又可能把不該放行的站點放進來。很多人喜歡直接寫成一個看起來很省事的規則，實際上卻忽略了協議、子域名層級和尾部路徑的差異。
比如你的業務頁面可能有 www、m、static 幾個子域，甚至還有測試域名。如果你只配了主站，其他入口發出的請求就會被當成陌生來源；反過來，如果你把匹配範圍開得過大，外站也可能因為某些寬鬆匹配而蹭到資源。防盜鏈看起來開了，卻既沒擋住壞人，也誤傷了自己。
四、空 Referer 沒處理好
這一點尤其重要。很多人以為只要配置了允許的域名，其他全部拒絕就完事了，但實際上大量真實請求可能根本沒有 Referer。比如用戶把圖片鏈接直接貼到聊天工具裡打開、瀏覽器隱私策略限制了 Referer、APP 內置 WebView 做了裁剪、某些反代服務器主動去掉了該頭部，這些請求都可能顯示為空。
如果你的規則默認對空值放行，那外站直接訪問就能繞過。相反，如果你把空 Referer 一刀切拒掉，自己的正常訪問又可能被誤殺。所以這裡要看業務形態。如果你的資源就是純網站內展示，並且客戶端環境可控，拒絕空 Referer 通常更安全；如果資源會被分享、嵌入或通過第三方頁面打開，就要仔細評估誤傷風險。
五、請求不是瀏覽器發出的，Referer 天生不可信
這是很多排查時最容易被低估的一點。Referer 防盜鏈對瀏覽器最友好，對工具和腳本最無力。只要對方用的是下載器、爬蟲、腳本、服務端轉發、APP SDK 直連，Referer 很可能就不是你熟悉的那種形態。更直接一點說，別人完全可以自己加一個看起來合法的 Referer 頭，再去拉取你的資源。
所以如果你的流量被盜刷很嚴重，而且對方明顯是批量請求，單靠 Referer 很難根治。它能擋一部分粗暴的熱鏈，但擋不住有意繞過的人。這也是為什麼很多靜態資源平台最終都會走向簽名 URL、短期令牌或私有化授權，而不是只靠來源頁判斷。
六、你以為走的是 COS，實際上先經過了 CDN 或代理
如果你的架構裡有 CDN、反向代理、網關、WAF 或 LB，就要特別注意請求頭在中間鏈路中會不會被改寫。很多時候流量的入口看似是你的域名，實際上最終到 COS 時，來源信息已經變了。這種情況下，COS 看到的 Referer 可能是 CDN 節點，或者乾脆被清空。
騰訊雲企業帳號充值 這就是為什麼有人把 COS 防盜鏈打開之後，發現自己網站裡的圖片能顯示，外站也能顯示，甚至某些地方還出現偶發 403。問題不一定出在 COS 規則本身，而是 CDN 的回源策略、Header 透傳策略和緩存命中行為沒有對齊。你在前面設的規則，未必能原封不動地傳到最後一跳。
排查流量被盜刷，按這個順序查最省時間
第一步：先確認流量到底是誰在用
不要一上來就改配置。先看監控、訪問量、帶寬曲線和熱點對象，找出是哪幾個文件在消耗大部分流量。通常被盜刷的不是整個桶，而是少數幾個圖片、視頻、安裝包或大文件。只要把熱點找出來，你就能迅速縮小排查範圍。
接著看訪問時間分佈。正常業務流量通常跟你的產品活躍時間、活動節奏、內容更新有關；盜刷流量則常常表現出連續、穩定、機械化的特徵。若是夜間突然大幅拉升，或者某個文件被同一類請求高頻拉取，基本就能判斷不是正常用戶行為。
第二步：看實際請求頭，不要只看配置頁
很多人排查時喜歡截圖配置頁，但真正有價值的是請求樣本。你要看的是 COS 實際收到的 Referer、User-Agent、來源 IP、請求路徑和狀態碼。只有把樣本擺出來，才能知道是空 Referer、偽造 Referer，還是根本沒有經過你以為的那條鏈路。
如果發現大量請求都來自同一批 IP 或同一機房，基本可以朝機器化抓取方向查。如果 Referer 五花八門，但資源請求高度集中，可能是某些站點嵌入了你的資源。如果 Referer 大量為空，則要優先看是不是工具下載、APP 直連或代理層把頭去掉了。
第三步：把請求分成正常、可疑、明顯異常三類
這一步很有用。正常請求是你自己網站、官方小程序或業務系統發出的；可疑請求是來源不明但行為不算太兇；明顯異常則是高頻、批量、無規律、Referer 異常或明顯偽造。不要急著下結論，先分類，因為不同類型對應的解法不一樣。
騰訊雲企業帳號充值 比如正常業務因為跨域、分享頁或 APP WebView 導致 Referer 丟失，你就不能簡單地一刀切；如果是明顯異常，那就可以直接收緊規則，甚至上升到 IP 黑白名單、簽名校驗、CDN 防盜鏈和應用層封禁。
第四步：回頭核對配置是否真的命中
把域名、協議、通配符、空 Referer、默認策略逐項核對一遍。很多人以為配置成功就是生效，實際上有可能只是保存成功，並沒有命中真實請求。尤其是切換了自定義域名、更新了 CDN 配置、改了回源策略之後，舊規則仍然在，但入口已經不是原來那個入口了。
如果條件允許，建議直接做一次可控測試：用正常頁面訪問、用空 Referer 訪問、用錯誤來源訪問、用帶偽造 Referer 的工具訪問，分別看返回結果。這樣你能很快知道規則是「完全沒生效」，還是「生效了但邏輯有漏洞」，或者「生效了但誤殺了正常流量」。
真正能止血的，不是單點配置，而是多層組合
一、把 Referer 防盜鏈當作基礎防線，而不是終局方案
如果你的資源是公開展示型內容，Referer 防盜鏈可以繼續保留，因為它成本低、配置快、對普通熱鏈有一定效果。但你要接受它只能攔住一部分粗糙請求。對真正的濫用者，還得疊加其他控制手段。
最實用的思路是：公開資源減少暴露面，半公開資源加短期簽名，核心資源改私有讀，業務端負責發放臨時授權。這樣即使鏈接被轉發出去，也不至於長期裸奔。
二、對自家業務，優先考慮私有桶加臨時授權
如果文件只需要在你自己的系統裡使用，直接把桶設成私有會更穩。前端不要硬拼公開 URL，而是由後端根據業務身份下發短時可用的簽名地址。這種方式雖然比單純的 Referer 配置麻煩一點，但安全性高得多，對抗盜刷的效果也更穩定。
短期簽名的核心好處是即使鏈接外泄，也只有短時間可用。對方就算把資源頁扒走，也不能長期免費復用。這對圖片、附件、安裝包、課件、媒體文件都很有效。
三、有 CDN 的話，防盜鏈要在 CDN 和源站兩邊一起想
很多流量問題最後都落在 CDN 上。CDN 一旦參與分發，規則就不能只看源站。你需要確認 CDN 是否支持防盜鏈、是否透傳 Referer、是否有回源保護、是否有熱鏈限制。因為從攻擊者視角看，只要拿到 CDN 地址，源站的部分規則可能就被繞開了。
正確做法是讓 CDN 承擔面向用戶的第一層防護，源站 COS 再做第二層校驗。即便前端鏈接被外部拿走，也先在邊緣節點攔掉，避免回源流量和外網流量雙重消耗。這樣不僅安全性更好，賬單也更可控。
四、對高價值資源，別依賴單一標頭
如果是重要安裝包、內部資料、付費內容或高頻被爬的媒體文件，單靠 Referer 幾乎一定不夠。最好增加時間戳、簽名串、IP 限制、訪問次數限制，或者直接走應用層權限校驗。換句話說，讓資源的可訪問性和業務身份綁在一起，而不是只靠一個可偽造的請求頭。
很多企業把盜刷壓下去，靠的不是某一個神奇配置，而是一整套策略：公開內容做邊界控制，半公開內容做短期授權，敏感內容做身份驗證，異常流量做監控告警。這套組合比任何單點方案都更耐用。
一個實戰思路：從「配置沒生效」轉成「鏈路哪一層沒攔住」
真遇到 COS 流量被盜刷時，最怕的是一上來就反覆調參，結果把正常業務也一起打掛。更高效的做法，是把問題拆成一條鏈路：用戶頁面、前端引用、CDN、代理、COS、賬單。每一層都問自己一句話：這一層到底有沒有看到來源，這一層能不能攔住，這一層攔不住的話下一層是否還有補救。
如果最後發現來源是外站直接引用，那就從前端和 CDN 下手；如果發現是工具批量下載，那就從私有化和簽名下手；如果發現是內部鏈路透傳異常，那就先修代理和回源策略。不要把所有問題都歸結為 COS 配置無效，因為很多時候，真正失守的不是 COS，而是整條鏈路的信任模型。
說到底，Referer 防盜鏈不是沒用，而是它只適合放在正確的位置。它適合做低成本、低門檻、面向瀏覽器的第一道限制，不適合承擔全部安全責任。當你把它放回應有的位置，再配合私有桶、臨時簽名、CDN 防護和日志監控，流量被盜刷的問題通常就能真正收住。
