回源流量比觀眾還多？直播 CDN 的三個架構漏點
老闆把財務的信轉寄給你，正文只有一句話：「我們觀眾沒多少，這個月的頻寬費為什麼這麼多？」後面跟著兩張後台曲線：觀眾那條平平，回源那條高出一截。他補了一句：「是不是廠商亂收錢？」
回源這筆帳，通常不在廠商的帳單上。要回得有把握，得先弄清楚兩件事：回源流量在帳單上到底誰收錢，以及你的架構裡是哪一處在把流量放大。這兩件都查清，那封信兩行就能回完。
回源費到底是誰收的？
回源（origin pull，報價單上常寫 back-to-origin）這筆流量，指的是邊緣節點手上沒有這條流，回你的源站再拿一趟。阿里雲的計費文檔是同一口徑：計費的是觀眾下載的下行流量（帳單篇裡說的下游分發那塊），回源不在計費項裡；AWS 對來自 AWS 源站的回源也免費。看起來回源像是白送的，但錢會從別處漏。
| 回源這筆錢 | 收不收 | 錢實際落在哪 |
|---|---|---|
| CDN 廠商的回源流量 | 多數不收 | 阿里、AWS 的文檔都是這個口徑 |
| 源站那一側 | 照收 | 源站流出流量、轉碼打包，該多少是多少 |
| 跨雲對接的公網回源 | 另算 | 華為雲媒體直播寫明僅對第三方 CDN 的回源流量計費 |
如果你讀過帳單那篇的四塊拆法，這裡會有個疙瘩：四塊裡明明有「回源流量」一塊，怎麼這裡說不收？兩篇說的是同一筆錢的兩個位置——四塊裡那塊回源，錢實際落在源站側和第三方對接上，不是 CDN 廠商自家帳單上那一行。這篇就是把這一塊拆開看。
最後一行要停下來算：華為雲媒體直播的計費文檔寫明，「華為 CDN 產生的回源流量不計費，僅對第三方 CDN 產生的回源流量進行計費」，撰文時（2026 年 9 月）新加坡區按階梯從 US$0.192/GB 起算，還註明香港使用新加坡定價；港台團隊常把香港和新加坡放進同一張報價比，這條就是對照點。同一條流，回源走自家網路不收錢，走了第三方 CDN 的公網就開始按 GB 累計。看回源貴不貴，先看這條線接的是誰。
數據來源: 華為雲媒體直播第三方 CDN 計費（2026-09-19 親自核對）；阿里雲 CDN 計費概述、AWS CloudFront Pricing（同日搜索核得，頁面未能逐字展開）。
廠商這邊不收，不代表回源高不花錢。代價走三條路。源站的流出流量費：回源多少趟，源站就出多少流量，走公網的回源才是同一根管子，同雲內網回源是另一條路、另一套價。轉碼打包費：觀眾要的切片是現做的，回源幾遍，封裝的工作就重做幾遍，這份負載不是落在打包服務的帳上，就是落在自建打包器的機器上。還有源站容量：命中越低管子越滿，自建機房最容易先被壓垮。所以「回源高要不要緊」的答案是：錢不一定落在 CDN 那行，但一定會落在某一行。
分不清自己走的是哪條錢路，直播 CDN 成本健檢把回源與命中的檢查項列成了清單，可以照著核。
一千個觀眾，為什麼變成一千次回源
第一個漏點在快取設定上。直播影片會被切成一個個小檔案（切片），觀眾拉的其實是這些小檔案；邊緣節點把拉過的存著（快取），下次有人要同一檔就不用再回源。節點判斷「這是不是同一檔」，靠的是 cache key（快取鑰匙）：由網址和部分參數拼出來的識別碼，識別碼相同就交同一份快取。AWS 文檔的定義很直白：cache key 是快取裡每個檔案的身份識別，觀眾請求算不算命中，由它決定。
問題出在直播的播放位址幾乎都帶參數。防盜連的 token（觀眾拉流時帶的參數）、session ID（連線編號）、時間戳記，都可能混進快取鑰匙：自建棧多半預設整條網址連參數都算進鑰匙，託管雲則常是設定時把查詢字串全選了進去。OpenResty（一套常用的自建快取閘道）的工程文檔把後果寫得最狠：參數進了鑰匙，每個觀眾各拿各的鑰匙，命中率悄悄歸零，一千個觀眾要同一段切片，源站就挨一千次回源；歸零的是觀眾之間的共享，同一個觀眾自己的請求照樣命中。日誌裡的症狀很好認：同一個檔案反覆 MISS（未命中），唯一區別是問號後面那串參數在變。
修法是把鑑權（核對參數真偽）移出鑰匙：快取時忽略 token 這類參數，讓觀眾共享同一份快取；簽名校驗放到獨立的存取規則裡先驗，驗過再讀快取。代價也直說：共享快取意味著這層不再幫你擋盜連，防盜連全靠那條驗簽規則，漏配了等於沒設防；改動前先在測試網域過一遍，沒有測試網域，就把設定頁交給廠商技術支持核一輪，別直接動正式環境。
鑰匙之外，同一族裡還有一個開關：存活時間。切片在節點上留多久、播放清單留多久，是兩個要分開設定的值；共用同一套存活時間，或者整條直播路徑設成了不快取，症狀和鑰匙配錯一模一樣：每個請求都 MISS，回源跟著觀眾走。OpenResty 在同一篇文檔裡給的做法是把兩者分開設定，一短一長。這一步不用動架構，改設定就行，代價是設長了觀眾會拿到舊切片。
數據來源: AWS CloudFront Developer Guide — Control the cache key、OpenResty Edge HLS Live Streaming，2026-09-19 親自核對。
觀眾分了三個區，沒有聚合層就回源三遍
第二個漏點在回源的路線上。觀眾分布在香港、台灣、新加坡，像 CloudFront 這類分層的網路，在邊緣節點和源站之間還有一層區域快取（regional edge cache，可以想成區域大倉）。沒有聚合層的時候，每個區域大倉會各自向源站要一遍同一條流。AWS 給聚合層 Origin Shield 寫的機制說明是這樣：開了之後，各快取層到源站的請求都先經過這一層（源站同區的請求除外），同一檔案同時湧來的請求在這裡合併，最好情況少到只剩一次回源；切片過期後的新一輪拉取，還是要再回源。
直播場景裡這個漏點放大得特別快，因為切片是現做的。源站做即時封裝（just-in-time packaging，觀眾要的時候才把母流（原始那一路完整流）切成小段）時，每個區域獨立回源，同一條流就被反覆封裝；「觀眾分布在多個地理區域」和「源站做直播即時封裝」都在 AWS 列的聚合層適用場景清單裡。自建體系也有同樣的做法：專門用一層閘道做聚合，思路和 Origin Shield 是同一個。
修法就是加這層聚合，代價有兩筆。一筆是 Origin Shield 另收費用，得拿回源省下的量去抵。另一筆藏在適用條件裡——同一份 AWS 文檔也列了不適合的場景：每個觀眾要的內容都不一樣（動態內容）、幾乎在節點上留不住（快取性低）、很少有人重複要的內容，這三種進聚合層沒有東西可合併，純付費。觀眾全在源站同區時，請求本來就會繞開聚合層，這筆錢就是白付，不用開。
數據來源: AWS CloudFront Developer Guide — Origin Shield，2026-09-19 親自核對。
源站形態：第三個最少人查的漏點
第三個漏點最少人注意到：源站的形態和位置。推流機（把畫面送上雲的機器）在新加坡，觀眾主力在台灣，台灣的節點就得整條流跨區去新加坡拉，這一趟多半落在源站那側的出流帳上。更隱密的是跨雲對接：源站放在一家，分發交給另一家的 CDN，回源走公網出流，華為雲那條「僅對第三方 CDN 的回源流量計費」正是這個場景的價目表。
自建源站還有一層容量問題。AWS 把自建機房、容量或頻寬受限的源站也寫進了聚合層的適用場景清單，這類源站撐不住高回源，不是理論擔憂，是常見到寫進文檔的部署形態。命中一低，源站流出流量和機器負載同時上去，經驗裡半夜斷線多半先從這裡開始。
修法按源頭動：源站盡量落在觀眾主力的區域，台灣觀眾多就把源站往台北或香港移，東南亞觀眾占大頭再議新加坡。要注意跨區那一跳沒有消失，只是挪到了推流腿上：省掉的是重複回源的放大，省不掉單條流跨區那一次傳輸，推流端的延遲和穩定要接得住。跨雲架構想省公網出流，可以讓分發方經聚合層接入，把回源次數壓下來再談單價，遷移和多源維護的成本別漏進比較裡。
把兩條曲線疊進同一張圖，漏點自己跳出來
三個漏點查起來不需要新工具，後台就有。把回源頻寬和觀眾頻寬兩條曲線疊到同一張圖——多數後台有 Hit Ratio（命中率）與 Origin Bandwidth（回源頻寬）兩欄，按小時拉出來對著讀。
回源跟著觀眾等比例走，先別下結論是節點密度：鑰匙和存活時間配錯時，每個請求都 MISS，曲線同樣是等比例走。先查上一節那兩個設定，都乾淨，再談長尾頻道和節點密度（同一個節點上同時有多少觀眾）；查的時候分清口徑，請求命中率數次數、位元組命中率數流量，跟頻寬帳對照時看位元組那個。
回源在觀眾平穩時獨自爬高，看日誌裡有沒有同一個檔案反覆 MISS、只差問號後面的參數：有，是鑰匙漏點。觀眾分散多區而源站收得到重複拉流，把網域設定裡回源（origin / back-to-origin）相關的欄位翻出來，看回源走的線路接的是誰。
每一條對上，就能帶著「漏點在哪、修法是什麼、代價是什麼」三個答案回去回那封轉寄信。對不上也別硬猜，把回源頁和網域設定攤開來看一遍，多數時候漏點藏在第二問的設定裡。
FAQ
回源流量到底收不收費？
分三層：CDN 廠商對自家回源多數不收費，阿里雲的計費文檔是同一口徑，計費的是觀眾下載的下行流量，回源不在計費項裡；AWS 對來自 AWS 源站的回源免費。例外是源站那一側，源站流出流量、轉碼打包這類費用照算；再一個例外是跨雲對接，華為雲的媒體直播寫明僅對第三方 CDN 的回源流量計費，各家口徑要逐家核。看回源貴不貴，先看這條線接的是誰。
命中率多少才算正常？
直播沒有統一健康線。決定命中率的是切片在節點上存活的短暫窗口裡，有多少觀眾同時來拉：設置得當時熱門頻道可以到九成以上，長尾頻道結構性地低。命中率分兩種口徑，請求命中率數次數、位元組命中率數流量，跟頻寬帳對照時看位元組那個。再跟自己平時的數字比，別拿靜態網站 95 到 99% 的基準來套直播。
把鑑權參數從快取鑰匙拿掉，防盜連怎麼辦？
鑑權和快取是兩件事。簽名校驗不必依賴快取鑰匙：可以在邊緣用獨立的存取規則先驗簽，驗過再看快取。代價是要多維護一條規則，漏配了等於沒設防；沒有測試環境就別自己動，把設定頁交給廠商技術支持核一輪再上線。
Origin Shield 這類聚合層什麼時候不該開？
AWS 文檔列了不適合的場景：每個觀眾要的內容都不一樣的動態內容、幾乎在節點上留不住的請求、很少有人重複要的內容——這三種進聚合層沒有東西可合併，純付費。觀眾集中在源站同區時請求本來就會繞過聚合層，也是白付。觀眾分多區、源站又做即時封裝的直播場景才是它的主場。
回源頻寬高，會把源站壓垮嗎？
會。走公網的回源頻寬和源站流出流量走的是同一根管子，命中率低時源站要同時應付成百上千路重複拉流，自建機房或頻寬小的源站最容易先撐不住。聚合層能把同一檔案的併發請求合併，最好情況壓到一次回源，源站容量因此多出一條緩衝。
關於新星雲
回源這類問題最容易被歸給廠商，因為那行數字確實出現在別人的後台裡。我是新星雲，一個人做的遊戲與直播雲選型顧問，看回源只看線路和設定，不替任何一家說話。
兩條曲線對完還是解釋不了那行數字，或者懷疑自己屬於跨雲接錯線的那一種，直播 CDN 成本健檢的回源檢查項可以先對一遍；還是不對，就別一個人在後台裡繼續翻，來 Telegram 把回源頁逐欄過一遍，通常一次就能聊清。
相關閱讀
- 直播 CDN 帳單為什麼暴增？拆成四塊自己查：還沒定位到回源這一塊的話，先從四塊拆帳開始，命中與回源的概念和 110% 口徑也在這篇。
- 雲端報價單為什麼看不懂？把行話逐行翻譯完，才輪到比單價：back-to-origin 這類行話的讀法，報價階段先釘清楚。
- 開直播平台要多少錢？先畫觀眾曲線，再拿曲線對報價單：還沒開台的話，回源這個問題可以在預算階段就避掉一半。
- 前進新加坡做互動直播，6 類雲服務的採購清單與預算邏輯：觀眾流量為什麼佔成本大頭，東南亞場景的採購帳怎麼算。
- 回到部落格總覽看其他成本拆解與選型文章。