服务器带宽不够用怎么办？带宽计算、流量分析与优化方法

"带宽不够用"是一个结论，但它背后至少有三种完全不同的情况：一种是带宽确实到了上限，晚高峰一上来网站就卡，云监控上出网带宽曲线走成一条平顶线；一种是带宽没满但流量账单很高，说明总量大而非瞬时高；还有一种是带宽根本没跑满，但用户依然觉得慢，这其实不是带宽问题，而是延迟、丢包或者页面体积的问题。这三种情况的解法完全不同，第一种要扩容或削峰，第二种要压缩体积或上 CDN，第三种扩容带宽纯粹是浪费钱。

这篇文章先给出一套带宽估算和流量测算的方法，让你能回答"我到底需要多大带宽"；再给出定位流量去向的具体命令，搞清楚是谁在吃带宽；最后按投入产出比列出优化手段，并讨论升级带宽与按流量计费怎么选。

一、三个容易混淆的概念：带宽、流量、并发

讨论之前先把单位对齐，很多争论其实是三个人在说三件事。

带宽是"管子有多粗"，流量是"总共放了多少水"。 一根粗管子可以只放很少的水（大带宽、低流量），一根细管子也可以慢慢放很多水（小带宽、高流量）。所以"带宽不够"和"流量超标"是两个独立的问题。

单位换算必须记牢，这是所有计算的基础：

• 运营商和云厂商说的 1 Mbps = 1,000,000 bit/s（不是 1024 进制）
• 除以 8 得到字节：1 Mbps ≈ 125 KB/s，常被粗略记成 128 KB/s
• 再考虑 TCP/IP 头部、TLS 记录层、以太网帧等开销，实际有效载荷大约只有标称值的 90% 到 95%

所以 1 Mbps 的实际可用下载速度大约是 110 到 120 KB/s，做估算时取 110 KB/s 更稳妥。

二、带宽需求怎么估算

基础公式

最实用的估算公式是：

所需带宽(Mbps) = 页面平均大小(MB) × 峰值每秒请求数 × 8 × 冗余系数

其中"页面平均大小"指一次完整访问传输的总字节数（HTML + CSS + JS + 图片 + 字体 + 接口响应），不是单个 HTML 的大小。这个数字可以从 Nginx 日志或者浏览器 DevTools 底部的传输量汇总拿到。

冗余系数一般取 1.3 到 2。它覆盖几个因素：协议开销（约 5% 到 10%）、峰值波动、以及你不想让带宽跑满（跑满会排队，延迟急剧上升）。

从 PV 反推峰值

大多数业务给的是日 PV，需要换算成每秒请求数。关键是不能直接用日均值，因为访问在时间上高度不均匀。

平均 QPS = 日PV / 86400
峰值 QPS ≈ 平均 QPS × 峰值系数

峰值系数取决于业务形态：

举个例子算一遍：一个资讯站，日 PV 10 万，页面平均大小 1.5 MB（图片站这个值很常见），峰值系数取 5。

平均 QPS = 100000 / 86400 ≈ 1.16
峰值 QPS = 1.16 × 5 ≈ 5.8
所需带宽 = 1.5 MB × 5.8 × 8 × 1.5 ≈ 104 Mbps

也就是说这个站峰值要 100 Mbps 左右才不卡。如果只买了 10 Mbps，晚高峰必然卡。这就是为什么很多站"平时挺快、一到晚上就打不开"——不是服务器坏了，是带宽曲线的峰值超出了上限。

反过来，如果页面平均大小优化到 0.3 MB（图片转 WebP、开了压缩和缓存），同样条件下：

所需带宽 = 0.3 × 5.8 × 8 × 1.5 ≈ 21 Mbps

带宽需求降到五分之一。这就是"先优化再扩容"的量化依据。

峰值与均值的关系

规划带宽时永远按峰值算，不要按均值算。均值会把 20 小时的低谷和 4 小时的高峰平均掉，得出一个看似够用、实际高峰必崩的数字。

一个判断经验：如果云监控上带宽曲线的峰值达到带宽上限的 70% 以上，就该处理了。因为 TCP 在接近满带宽时排队延迟会非线性上升，用户感受到的"卡"往往在带宽真正跑满之前就出现了。

三、带宽与月流量的换算

这是选型时最常用的一条换算：

月流量(GB) ≈ 带宽(Mbps) × 0.3 × 1000
即：1 Mbps 满跑一个月 ≈ 330 GB ≈ 0.33 TB

推导过程：1 Mbps × 86400 秒 × 30 天 ÷ 8 = 324,000,000,000 字节 ≈ 324 GB。

必须强调的是：这是"24 小时 × 30 天持续满跑"的理论上限，现实中几乎不可能达到。真实业务通常只能跑到理论值的 20% 到 50%，因为访问有明显的波谷。所以：

这条换算的正经用法有两个：一是校验账单是否合理——如果你买 5 Mbps 但月流量跑到 3 TB，那是不可能的事，说明统计口径或计费方式（比如按流量计费、带宽是出网而非入网）和你理解的不一样；二是从已知月流量反推平均带宽占用，看离上限还有多远。

四、流量分析：搞清楚谁在吃带宽

扩容之前先做这件事。很多时候流量的一半以上是几个大文件或被盗链的图片吃掉的，处理掉比加带宽划算得多。

用 Nginx 日志统计

默认的 combined 日志格式里，第 10 个字段是响应字节数。统计总出流量：

awk '{sum += $10} END {printf "总出流量: %.2f GB\n", sum/1024/1024/1024}' \
  /var/log/nginx/access.log

找出最吃流量的 URL：

awk '{bytes[$7] += $10; cnt[$7]++} END {
  for (u in bytes) printf "%10.2f MB %8d %s\n", bytes[u]/1024/1024, cnt[u], u
}' /var/log/nginx/access.log | sort -rn | head -n 20

按小时看分布，定位高峰时段：

awk '{print $4}' /var/log/nginx/access.log | cut -c2-15 | sort | uniq -c | \
  sort -rn | head -n 24

按来源 IP 聚合，顺便发现异常抓取：

awk '{ip[$1] += $10} END {
  for (i in ip) printf "%10.2f MB %s\n", ip[i]/1024/1024, i
}' /var/log/nginx/access.log | sort -rn | head -n 20

如果某个 IP 的流量远超其他，大概率是爬虫或被盗链。日志分析的一个前提：静态资源如果已经交给 CDN，Nginx 日志里就看不到这部分流量了，总量会显著变小，这时候要以 CDN 侧的统计为准。

用系统工具看实时流量

sudo apt install -y vnstat iftop nethogs sysstat    # Debian、Ubuntu
sudo dnf install -y vnstat iftop nethogs sysstat    # Rocky、RHEL、CentOS

vnstat -l -i eth0            # 实时速率
vnstat -d                    # 按天汇总
vnstat -m                    # 按月汇总
sudo iftop -i eth0 -P        # 按连接看实时流量，-P 显示端口
sudo nethogs eth0            # 按进程看流量，定位是哪个程序在跑
sar -n DEV 1 5               # 网卡吞吐，看是否接近上限

vnstat 的价值在于它长期在后台累计，能给出准确的日月流量，而不用自己去解析日志。nethogs 则能直接回答"哪个进程在吃带宽"，对定位异常同步任务、备份任务特别有用。

注意流量方向的口径：云厂商计费的出网流量对应网卡的 TX，镜像下载、系统更新产生的是入网流量，多数厂商入网不计费。看的时候别把 RX 当成 TX。

云监控看趋势

云厂商控制台的监控图是最直观的，重点看三条曲线：出网带宽（是否出现平顶）、出网流量（日累计是否异常增长）、以及 TCP 连接数（是否异常高）。建议把带宽使用率超过 80% 设为告警项，在用户投诉之前就收到通知。

五、优化手段：按性价比排序

第一梯队：配置改动，当天见效

开启压缩。 对 HTML、CSS、JS、JSON、SVG 这类文本资源，gzip 能减少 60% 到 80% 体积，brotli 还能再好 15% 到 20%。这是投入产出比最高的一项。

gzip on;
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css application/javascript application/json \
           application/xml image/svg+xml;
# 有 brotli 模块时优先用 brotli
# brotli on;
# brotli_comp_level 5;

不要对 JPEG、PNG、MP4、PDF 这些已经是压缩格式的内容再做 gzip，浪费 CPU 且几乎无收益。

配置缓存头。 没有缓存策略，老用户每次访问都要重新下载所有静态资源，这部分流量完全是白花的。

location ~* \.(jpg|jpeg|png|gif|webp|avif|ico|css|js|woff2)$ {
    expires 30d;
    add_header Cache-Control "public";
    access_log off;
}
# 构建产物带内容哈希，可以设一年并不验证
location ^~ /assets/ {
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
}

图片转格式。 同一张图，WebP 通常比 JPEG 小 25% 到 35%，AVIF 还能再小一截（代价是编码慢、部分老浏览器不支持）。图片站上这一项经常能砍掉一半以上的流量。

第二梯队：架构调整，收益最大

上 CDN。 这是解决带宽问题最彻底的手段。静态资源被缓存到边缘节点后，源站的出网流量可能下降 80% 到 95%，同时用户访问延迟也大幅降低。要注意两点：正确设置缓存规则（静态长缓存、HTML 短缓存或不缓存），以及资源 URL 带版本号或哈希，便于更新时刷新。

动静分离。 把图片、视频、下载包迁到对象存储，主站只跑动态逻辑。对象存储的流量单价通常低于云主机出网带宽，而且天然支持高并发下载，不会拖垮主站。

视频和大文件绝不能走应用服务器。 一个 200 MB 的安装包被下载 1000 次就是 200 GB 流量，还会在传输期间长时间占用连接。这类内容一律放对象存储加 CDN，必要时开启分片和断点续传。

第三梯队：限制与治理

防止盗链。 图片被别的站直接引用是最常见的"流量黑洞"，用户不是你的，流量却是你的。

location ~* \.(jpg|jpeg|png|webp|gif)$ {
    valid_referers none blocked server_names *.example.com example.com;
    if ($invalid_referer) {
        return 403;
    }
}

限制单连接速度和大文件下载。 下载站常用这一招保护带宽：

location /download/ {
    limit_rate 1m;          # 单连接限速 1MB/s
    limit_rate_after 10m;   # 前 10MB 不限速，小文件体验不受影响
}

限流与并发控制。 防止单个 IP 刷接口拖垮整体：

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=perconn:10m;

server {
    location /api/ {
        limit_req zone=perip burst=20 nodelay;
        limit_conn perconn 20;
    }
}

处理异常爬虫。 日志里发现某个 UA 或 IP 段高频抓取，用 Nginx 或安全组的 IP 黑名单处理，或者在 robots.txt 里声明并限制速率。

优化手段对比

六、升级带宽还是按流量计费

两种计费模式的取舍，核心是看你的带宽曲线形状。

判断方法很直接：用月流量除以理论上限（带宽 × 0.3 × 1000 GB）得到带宽利用率。 如果利用率长期高于 50%，说明带宽一直在跑，选固定带宽更划算；如果只有 10% 到 20%，说明大部分时间闲着，按流量计费能省不少。

选按流量计费必须做的两件事：设账单告警阈值，防止被盗刷或攻击导致天价账单；以及配置带宽上限（多数厂商支持在按流量模式下设一个带宽封顶），用可控的性能损失换取成本上限。

还有一个中间选项：先用 CDN 把大部分流量卸载掉，再把剩余的小流量用按流量计费的机器承载。 对中小站点这往往是成本最优的组合。CDN 的流量单价通常低于云主机出网带宽的单价，还能顺带解决延迟问题。

常见问题

带宽跑满了，用户就一定卡吗？

会。带宽接近上限时，数据包在网卡队列里排队，延迟非线性上升；再往上就开始丢包，TCP 触发重传和拥塞控制降窗，吞吐量反而下降。所以告警阈值建议设在 70% 到 80%，不要等到 100% 才处理。

为什么我买了 100 Mbps，实测下载只有 11 MB/s？

这是单位问题。100 Mbps ÷ 8 = 12.5 MB/s，再扣掉协议开销大约剩 11 到 12 MB/s，完全正常。另外要确认这个 100 Mbps 是出网带宽——很多厂商入网带宽给得很大，出网才是计费和限速的那一侧。

加了带宽网站还是慢，是怎么回事？

说明瓶颈不在带宽。按这个顺序查：延迟和丢包（用 ping、mtr 看，跨境链路丢包 2% 就能让吞吐腰斩）、服务端响应时间（用 curl -w 看 time_starttransfer，超过几百毫秒就是应用或数据库的问题）、页面请求数和渲染（用浏览器 DevTools 看瀑布图）。这三种情况加带宽都没用。

日志统计的流量和厂商账单对不上？

常见原因有三个：一是 CDN 已经卸载了部分流量，源站日志看不到；二是日志里统计的是应用层响应体大小，不含 TCP/TLS 头部开销，实际链路流量会多出 5% 到 10%；三是日志轮转期间有丢失，或者统计时包含了入网流量。以厂商账单为准，日志只用来看分布和占比。

1 Mbps 到底能跑多少流量？

满跑理论值约每月 330 GB，实际业务一般只用几十 GB。带宽小的时候问题通常不是"总量不够"，而是"高峰跑不动"——用户卡在峰值那几个小时，而整月流量其实很低。这种情况按流量计费配一个较高的带宽上限，往往比买大固定带宽更划算。

限流会不会影响正常用户？

合理的限流只会影响异常流量。关键是阈值要基于实测数据设：先统计正常用户的请求速率分布，把限制设在正常峰值之上。同时给用户返回 429 而不是 503，并配合 Retry-After 头，让客户端知道稍后重试。

总结

• 先分清是"带宽不足""流量超标"还是"其实不慢但用户觉得慢"，三者解法不同；判断依据是云监控的带宽曲线是否出现平顶、以及 curl -w 的各阶段耗时。
• 带宽估算公式：页面平均大小(MB) × 峰值 QPS × 8 × 冗余系数(1.3~2)，峰值 QPS 由日 PV ÷ 86400 再乘峰值系数得到，峰值系数按业务形态取 3 到 50，永远按峰值规划而不是均值。
• 单位换算是所有计算的地基：1 Mbps ≈ 125 KB/s 标称，扣掉协议开销实际约 110 KB/s；月流量理论上限 ≈ 带宽(Mbps) × 0.3 × 1000 GB，这只是满跑上限，实际通常只用到 20% 到 50%。
• 优化按性价比推进：gzip/brotli 加缓存头当天见效；图片转 WebP/AVIF 和上 CDN 收益最大，CDN 能把源站出网削掉 80% 到 95%；视频和大文件必须迁对象存储，绝不能走应用服务器。
• 治理手段别忽略：防盗链、单连接限速、限流和封禁异常爬虫，往往能砍掉一大块"莫名其妙"的流量，成本几乎为零。
• 计费模式按带宽利用率选：长期高于 50% 选固定带宽，只有 10% 到 20% 选按流量计费；选按流量一定要设账单告警和带宽封顶，避免攻击导致账单失控。