雲伺服器頻寬多少合適：按存取量算頻寬的方法

雲伺服器頻寬多少合適？先給結論：以文字和少量圖片為主的企業官網、部落格、小程式後端，1–3M 夠用；圖片多、有後台管理的站點 5–10M；影片、下載、直播類業務不要用雲伺服器的公網頻寬扛，交給 CDN 或物件儲存。 判斷依據是一個簡單的算式：把頁面大小、同時線上人數和停留時間代進去，就能算出峰值需要多少 Mbps。下面先講清 1M 頻寬到底有多快，再給算式和算例。

1M 頻寬的實際下載速度是 128KB/s

頻寬的單位是 Mbps（兆位元每秒），下載速度的單位是 KB/s 或 MB/s（位元組每秒），1 位元組 = 8 位元。按行業裡習慣的 1024 進位制換算：

1 Mbps = 1024 Kbps，1024 ÷ 8 = 128 KB/s

嚴格按 1 Mbps = 1,000,000 bit/s 折算是 125 KB/s，兩種演算法相差不到 3%，記住 128 KB/s 就夠用。實際下載還要扣掉 TCP/IP 包頭等協議開銷，1M 頻寬跑滿時訪客看到的速度大約是 100–120 KB/s。以此類推：

頻寬	理論速度	傳 1 MB 檔案約需	傳 100 MB 檔案約需
1M	128 KB/s	8 秒	13 分鐘
2M	256 KB/s	4 秒	6.7 分鐘
5M	640 KB/s	1.6 秒	2.7 分鐘
10M	1.25 MB/s	0.8 秒	80 秒
100M	12.5 MB/s	0.08 秒	8 秒

這張表解釋了為什麼 1M 頻寬下載一個 100 MB 的安裝包要十幾分鍾，也解釋了為什麼大多數只有幾百 KB 的網頁在 1M 頻寬下仍然能開啟。

按頁面大小和線上人數估算頻寬

第一步，量頁面大小。 在瀏覽器按 F12 開啟開發者工具，切到 Network（網路）面板重新整理頁面，底部會顯示本次載入傳輸的總位元組數。企業官網首頁壓縮後常見 300 KB–1 MB，圖片多的頁面 2–3 MB。

第二步，估同時線上人數。 注意“同時線上”不等於“日存取量”。如果只知道日 PV，可以這樣折算：

日流量（GB）    = 日 PV × 平均頁面大小（KB）÷ 1024 ÷ 1024
平均頻寬（Mbps）= 日流量（GB）× 1024 × 8 ÷ 86400
峰值頻寬（Mbps）≈ 平均頻寬 × 3–5（存取集中在白天和晚上）

第三步，代入算式。 按同時線上人數算：

頻寬（Mbps）≈ 同時線上人數 × 頁面大小（KB）× 8 ÷ 每頁停留秒數 ÷ 1024

算例 1：企業官網，頁面 500 KB，高峰時同時線上 20 人，平均每頁停留 30 秒：20 × 500 × 8 ÷ 30 ÷ 1024 ≈ 2.6 Mbps。選 3M 合適，1M 會在高峰期明顯變慢。

算例 2：部落格，日 PV 5,000，頁面 300 KB：日流量 5,000 × 300 ÷ 1024 ÷ 1024 ≈ 1.43 GB，平均頻寬 1.43 × 1024 × 8 ÷ 86400 ≈ 0.14 Mbps，峰值按 5 倍算約 0.7 Mbps。1M 夠用，靜態資源再走 CDN 更寬裕。

算例 3：圖片站，日 PV 50,000，頁面 2 MB：日流量約 98 GB，平均頻寬約 9.3 Mbps，峰值 30–45 Mbps。這已經不適合買固定頻寬了，應該把圖片放到物件儲存並用 CDN 分發，雲伺服器只保留動態請求。

按這套方法算完，通常會發現常見站點的需求落在下面這個區間：

站點型別	日 PV 量級	頁面大小	建議頻寬
個人部落格、企業展示站	1 萬以內	300–500 KB	1–2M
內容站、企業官網帶後台	1–5 萬	500 KB–1 MB	3–5M
圖片較多的電商、論壇	5–20 萬	1–2 MB	10M 以上，或 CDN + 按流量
API / 小程式後端	按請求數算	每次幾 KB 的 JSON	1–3M

雲伺服器頻寬 1M 夠用嗎

按上面的算式，1M 夠用的場景：文字為主的部落格和企業站、小程式或 App 的介面後端（每次返回幾 KB 的 JSON）、微信公眾號後台、內網穿透和跳板機、把靜態資源都放到 CDN 或物件儲存之後的動態站點。

1M 不夠用的場景：一次要載入幾 MB 圖片的頁面（同時開啟兩三個人就卡）、後台管理系統裡有大表格匯出、需要用伺服器直接提供檔案下載、透過 Windows 遠端桌面（RDP）圖形化操作時會明顯示卡頓（SSH 命令列不受影響）、有影片或大附件的站點。

還有一個經常被忽略的點：多數雲廠商標註的頻寬是出方向，即伺服器發往訪客的速率；訪客看你的頁面、從伺服器下載檔案，走的都是出方向。而入方向（把檔案傳到伺服器、伺服器從外網拉取映象）通常給得更寬，所以 1M 頻寬的伺服器上 yum 或 apt 更新並不慢，具體以廠商說明為準。

固定頻寬和按流量計費在不同存取量下的成本

兩種計費方式的成本結構不同：固定頻寬按 Mbps 每月付費，不限總量；按流量計費按實際出方向流量的 GB 數付費，頻寬峰值可以設得很高（如 100M）。

先算固定頻寬跑滿一個月能傳多少流量：

5M 滿跑一個月 = 5 × 86400 × 30 ÷ 8 ÷ 1024 ≈ 1,582 GB

實際站點的頻寬利用率很低（有峰有谷，夜裡幾乎沒人），所以月流量往往只有滿跑值的 10%–30%。平衡點的演算法是：

平衡點流量（GB）= 固定頻寬月費 ÷ 流量單價

用一個假設的算例：假設 5M 固定頻寬月費 150 元，按流量計費 0.8 元/GB，平衡點是 150 ÷ 0.8 ≈ 188 GB。

月出方向流量	5M 固定頻寬（假設 150 元）	按流量（假設 0.8 元/GB）	更划算的
50 GB	150 元	40 元	按流量
150 GB	150 元	120 元	按流量
188 GB	150 元	150 元	持平
400 GB	150 元	320 元	固定頻寬
1,000 GB	150 元，但月均利用率已超過六成，高峰必然打滿	800 元	需要升頻寬或走 CDN

規律是：流量小、存取有明顯峰值的站點，按流量計費便宜，而且峰值時速度更快；流量大且穩定的站點，固定頻寬便宜。 另外要提防兩種風險：按流量計費遇到被刷流量或爬蟲，帳單會失控，要設流量告警；固定頻寬被打滿時不會多扣錢，但所有訪客都變慢。

影片、下載、直播類業務怎麼算

這類業務的頻寬是按位元速率 × 併發或檔案大小 × 併發 ÷ 期望時長算的，數字會大得多：

• 影片點播：1080p 影片位元速率按 3 Mbps 估，100 人同時觀看就是 300 Mbps；720p 按 1.5 Mbps 估，也要 150 Mbps；
• 檔案下載：一個 500 MB 的安裝包，希望 50 個人同時下載時每人都有 1 MB/s，需要 50 × 8 = 400 Mbps；
• 直播：推流走入方向（一路 2–5 Mbps），分發走出方向，觀眾數 × 位元速率。

雲伺服器的固定頻寬買到 100M、200M 就已經很貴，這類業務的常規做法是：原始檔放物件儲存，透過 CDN 分發，按流量付費；或者租用帶大頻寬的獨立伺服器。雲伺服器只處理鑑權、生成播放位址等動態邏輯，佔用的頻寬很小。

怎麼判斷現在的頻寬夠不夠

雲廠商的監控面板裡看“出方向頻寬”曲線：如果高峰時段曲線長時間貼著上限走平，就是頻寬打滿了；曲線偶爾衝頂、大部分時間在一半以下，就還夠用。

也可以在伺服器上直接看即時速率：

# 每秒統計一次網路卡收發速率，共 10 次（rxkB/s 入方向，txkB/s 出方向）
sar -n DEV 1 10

# 或安裝 nload 看即時曲線，網路卡名以 ip addr 的輸出為準（常見 eth0、ens3）
nload eth0

頻寬打滿時的典型表現是：CPU、記憶體佔用都很低，但訪客反映開啟慢，伺服器上 txkB/s 的數值換算後正好等於購買的頻寬（例如 5M 對應約 640 KB/s）。這時先做三件事再考慮加頻寬：開啟 gzip 壓縮、把圖片和靜態檔案放到 CDN、給介面加快取，通常能把頻寬需求降一半以上。

服務商這一側看的也是同樣的資料：接入交換器上按連接埠統計流量，作為流量計費、95 計費和超量限速的依據。如果你租的是獨立伺服器並按 95 峰值結算，可以參考95 計費的計算方法理解帳單。