视频站用VPS怎么选：带宽不够怎么办

一、带宽不够到底是怎么发生的

视频站VPS 卡顿的根因，几乎从来不是「带宽不够」这四个字本身，而是带宽、并发数、码率三者没有对上。买 VPS 的人习惯按网页站的思路看配置，核数多内存大就安心，但视频站的核心矛盾只有一条：出网带宽和它对应的并发承载能力。

延伸对照：interserver 的公开机型与线路说明，可结合本节的判断标准自行核对。

先看最基本的一组换算。假设你的片子是 1080p H.264，码率 4 Mbps，那一个观众从头看到尾下载的数据量约等于码率乘以时长再除以八。10 分钟的片子约 300 MB，1 小时的约 1.8 GB，3 小时的约 5.4 GB。这个数字乘以同时在线人数，就是那个时间窗口里必须真实穿过你服务器出口的字节数。

再往上看一层，播放的是一个码率 4 Mbps 的流，但你买的带宽是 100 Mbps，理论上能同时撑 25 个人看 4 Mbps 的片子，看着还剩一大截。可实际播放时每个观众不是匀速拉流的，播放器会先缓冲，缓冲满了会停一段时间再拉，进度条会卡在一个百分比上不动。这叫「缓冲填充」和「缓冲耗尽」，实测表现往往是画面卡住几秒又跳一下，体感比真的慢还差。

真正决定体验的是下面这个式子里的峰值带宽：所有并发观众同时处于「正在拉流」状态的瞬间，总带宽需求是并发数乘以码率再乘以一个突发系数。突发系数取决于 CDN 命中率、回源比例和播放器缓冲策略，缺货环境下保守按一点五算。也就是说 25 个并发观众实际需要的峰值可能接近 150 Mbps，100 Mbps 的机器在开始播放的头几秒就会被打满。

还有一个容易被忽略的量是首播和拖动进度条。观众进场要拉一段 moov 数据或者首片，拖进度条是随机访问，这些请求对源站是突发的。如果源站只有一块普通网卡，突发时会直接丢包，表现还是卡。

判断自己是不是真的带宽不足，看三个信号：服务器监控里的网卡出网峰值是否长期贴着上限、播放器报缓冲耗尽的比例是否随并发上升而升高、以及如果去掉 HTTPS 直接走 HTTP 之后卡顿是否缓解（缓解说明是 TLS 握手和连接复用的问题，不是纯带宽）。

# 实时看网卡出网峰值（注意 -f 显示的是 bit/s 还是 Byte/s）
iftop -i eth0 -f
# 看一分钟历史，确认峰值和均值
sar -n DEV 1 60 | grep -E "eth0|ens|enp"
# Nginx 侧看当前活跃下载连接数
ss -tn state established '( sport = :80 or sport = :443 )' | wc -l

二、码率、分辨率与并发：先算清楚再谈配置

视频站VPS 的选型如果从「买几核」开始就本末倒置了。正确的顺序是：先定片源规格，再定并发观众数，然后反推带宽和存储，最后才谈 CPU。

延伸对照：itldc 的公开机型与线路说明，可结合本节的判断标准自行核对。

分辨率和码率的关系有一个经验区间可用。360p 常见 0.8 到 1.2 Mbps，720p 常见 1.5 到 3 Mbps，1080p 常见 3 到 6 Mbps，4K 常见 15 到 40 Mbps。同一分辨率下，码率越高画质越好、文件越大、流量越贵。对以文字和画面为主的教学类内容，1080p 给 2.5 Mbps 左右通常够用；对有大量画面运动的游戏或体育内容，1080p 低于 4 Mbps 会出现明显涂抹和色块。

然后是并发和带宽的对应表。下面这张表是按固定码率算出来的经验值，实际还得乘上前面说的突发系数：

码率规格	单人实际拉流	10 并发峰值	50 并发峰值	100 并发峰值
480p 约 1 Mbps	约 0.13 MB 每秒	约 13 Mbps	约 63 Mbps	约 125 Mbps
720p 约 2.5 Mbps	约 0.32 MB 每秒	约 31 Mbps	约 157 Mbps	约 313 Mbps
1080p 约 4.5 Mbps	约 0.56 MB 每秒	约 56 Mbps	约 281 Mbps	约 563 Mbps
4K 约 25 Mbps	约 3.1 MB 每秒	约 313 Mbps	约 1563 Mbps	约 3125 Mbps

从表里能直接看出一个结论：100 并发看 4K，需要的峰值带宽是 3 Gbps 级别，这已经不是普通 VPS 的范畴，必须上独享大带宽或者走 CDN。所以「100 个人同时看 4K」这种需求，选 VPS 这条路一开始就是错的，选型阶段就该把 CDN 和转码服务写进方案。

第二个结论是存储。视频站和普通站最大的不同是存储容量决定内容数量。按 1080p 4.5 Mbps 算，一小时片子约 2 GB；如果你的站点要放 500 小时正片，光原片就是 1 TB。而且还要存转码后的多码率版本，如果是自动生成 480p、720p、1080p 三档，总占用大约是原片的 1.6 到 2 倍。存储规划要按 2 TB 起算才不会三个月后手忙脚乱。另外要留意磁盘类型带来的成本差，机械盘容量单价明显低于 SSD，但随机读性能差一个数量级。视频站的发片、转码和切片写入几乎都是顺序写，机械盘在这一层其实够用；但切片目录的元数据操作和大量小文件请求会吃随机读，这时把成品目录放 SSD、原片目录放机械盘，是最省钱的组合。具体盘位和容量以各商家官网当日报价为准。

第三个结论是 CPU 只在转码时重要。纯分发不转码的话，一台 2 核 4G 就能扛住上千并发，因为它的 CPU 工作只是收发字节。真正吃 CPU 的是转码，而转码是最应该被移出源站的活。

# 用 ffprobe 统计一个目录里所有视频的真实码率和时长，用来反推存储与流量
for f in *.mp4; do
  dur=$(ffprobe -v error -show_entries format=duration -of csv=p=0 "$f")
  bit=$(ffprobe -v error -select_streams v:0 -show_entries stream=bit_rate -of csv=p=0 "$f")
  size=$(du -m "$f" | cut -f1)
  echo "$f 时长${dur}秒 码率${bit}bps ${size}MB"
done

三、转码该怎么安排：不要在源站上跑

视频站VPS 上跑转码是性能自杀的典型做法。很多人买了一台 16 核的机器想「一边转码一边播」，结果转码任务一跑，磁盘 IO 和 CPU 吃满，播放端的响应立刻变差。

延伸对照：iwebfusion 的公开机型与线路说明，可结合本节的判断标准自行核对。

转码和分发的资源特征是冲突的。转码是 CPU 密集 + 磁盘 IO 密集，典型的一次 1080p H.264 转 720p 会跑满一个核，磁盘要顺序读入几 GB、顺序写出几 GB。分发是网络密集 + 内存密集。两者挤在同一台机器上时，转码的写盘缓存会挤掉分发的读盘缓存，表现就是「转码时全站变慢」。

更稳妥的做法有三条，按投入从小到大排：

一是把转码放到一次性或者按时的任务机器上。买个高 CPU 的按小时计费机器批量转，转完把成品同步回源站存储，转码机器释放。这适合更新不频繁的影视站。

二是用现成的转码服务。国内几家主流云厂商都有视频处理服务，按分钟计费，支持 HLS 切片、多码率自适应和截图水印，价格以官网当日报价为准。自己只需要把原片推上去，取回切片地址。

三是用开源的分布式转码方案配合队列，比如用 FFmpeg 配合任务队列在多台机器上切片。这个方案可控性最高，但要自己处理重试、断点续转和切片对齐。

如果一定要在源站做轻量转码，务必要做隔离：转码任务用 cgroup 或 nice 降优先级，限制它的 IO 权重，指定 -threads 数量不超过总核数的一半，并且给播放流量留出独立的网卡队列。下面这组命令是最低限度的隔离：

# 转码时降到低优先级、限死线程数，避免抢走分发资源
nice -n 19 ionice -c3 ffmpeg -i input.mp4 \
  -c:v libx264 -preset veryfast -crf 23 -c:a aac -b:a 128k \
  -threads 2 -vf "scale=-2:720" output_720p.mp4

# 转码完用 ffprobe 验证实际码率，确认和目标一致
ffprobe -v error -show_entries stream=codec_name,width,height,bit_rate \
  -of default=noprint_wrappers=1 output_720p.mp4

判断转码有没有把分发拖慢，最直接的办法是转码前后各测一次首字节时间：

# 测首字节时间和总耗时，转码前后各跑一次做对比
curl -o /dev/null -s -w "首字节:%{time_starttransfer}s 总耗时:%{time_total}s 速度:%{speed_download}B/s\n" \
  "http://127.0.0.1/video/720p/sample.mp4"

四、存储怎么分：原片、转码成品和热点分三层

视频站VPS 的存储如果只有一块盘，很快就变成「删旧片才能发新片」。合理的做法是分三层：原片层、转码层、热点层。

延伸对照：racknerd 的公开机型与线路说明，可结合本节的判断标准自行核对。

原片层放源文件，通常只有你自己和后台在用，不需要高性能，可以放在大容量低价盘或者对象存储上，通过挂载或者定期同步访问。转码层放已经生成好的多码率成品，这层是真正被观众读取的，需要读性能，最好放在 SSD 上。热点层是 CDN 缓存不下来的部分和刚发布的片子，先在转码层放几天，CDN 预热完成、命中率稳定后再回迁到原片层释放空间。

这种分层带来的收益不只是省空间。SSD 上只放活跃内容，读写延迟能维持在毫秒级；同时原片可以放便宜的大容量盘，用成本换容量。视频站存储占总成本的比例往往超过一半，这层设计省下来的钱比在 CPU 上省钱明显。

如果要做自动归档，用定时脚本按访问日志把 N 天没被访问过的成品移走：

# 找出 30 天内没人访问过的视频文件
find /data/transcoded -type f -name "*.m4s" -mtime +30 -print > /tmp/cold.txt
# 移到大容量盘（先测试挂载点存在再执行）
while read -r f; do
  [ -d /mnt/cheap ] && mv "$f" /mnt/cheap/
done < /tmp/cold.txt

另外提醒一个坑：不要用软链接跨文件系统拼目录，然后指望 Nginx 直接跟过去。软链接目标在另一个挂载点时，Nginx 的 sendfile 会正常工作，但某些面板的备份和打包脚本会漏掉这些文件，备份出来的数据是不完整的。要么用挂载，要么在备份脚本里用 rsync -aL 跟随链接。

五、CDN 到底解决了什么，什么时候不该上

视频站VPS 加 CDN 是标准动作，但很多人对 CDN 解决什么问题理解得不对。CDN 解决的是「把内容推到离用户近的边缘节点」，它能扛住突发流量、能扛住源站被攻击时的连带影响，但它解决不了源站出网带宽本身的上限——因为首次回源的那一跳还是你的服务器。

延伸对照：spinservers 的公开机型与线路说明，可结合本节的判断标准自行核对。

CDN 的价值要用命中率来算。假设你的站点有 60% 的播放请求命中 CDN 边缘缓存，剩下 40% 需要回源。那么 100 并发看 4 Mbps 码率时，源站只需要承担 40% 的流量，峰值从 563 Mbps 降到约 225 Mbps。如果把命中率提到 80%，源站峰值降到约 113 Mbps。这就是为什么视频站上 CDN 之后源站配置可以砍一半的原因。

但是有两个前提必须满足。第一是缓存键要正确，mp4 直链通常直接按 URL 缓存就行，但如果是同一个接口按参数返回不同视频，必须把参数写进缓存键，否则会串片。第二是回源要支持 Range 请求，播放器拖进度条依赖 206 响应，CDN 回源到源站时如果源站不支持 Range，拖动就会失败。

配置 CDN 回源的时候，要确认这几项：

# 确认源站支持 Range 请求（返回 206 而不是 200）
curl -sI -H "Range: bytes=0-1023" "http://127.0.0.1/video/sample.mp4" | head -5

# 确认源站返回正确的 Content-Length 和 Accept-Ranges
curl -sI "http://127.0.0.1/video/sample.mp4" | grep -iE "content-length|accept-ranges|content-type"

还有一个常见误区是把 CDN 当成带宽的替代品。CDN 按流量计费，流量越大费用越高，而源站出网通常也按流量计费。视频站真正省钱的顺序是：先做 CDN 命中优化（预热、缓存键、减少无效回源），再考虑压缩和降码率，最后才是比价换服务器。

预热这件事常被漏掉。新发布的片子在没人看过之前，CDN 边缘节点上没有缓存，第一次访问必然回源，而且回源往往是大文件拉取，源站会短时间吃满带宽。如果你在发布后主动把主播放列表和前几分钟的分片推到各区域节点，源站的瞬时压力会小很多。做预热的命令如下：

# 用 curl 逐个预热分片，HEAD 请求即可触发边缘缓存（示例仅演示思路）
for i in $(seq -w 0 30); do
  curl -s -o /dev/null -X HEAD "https://cdn.example.com/video/seg_000${i}.ts"
done

预热之后要验证命中率，别自己以为缓存上了。可以直接看响应头里的缓存标记，或者到 CDN 控制台看缓存命中率和回源流量两条曲线。如果命中率长期低于百分之五十，问题通常在缓存键规则或者 Referer 校验规则上，这两条任何一条写错都会让所有请求变成不缓存。

还有一条经验值得单独说：对片源做分级存储，把访问量最高的前百分之二十内容留在源站 SSD 上，剩下的冷门内容放对象存储，播放时由程序按需回源。这样做能把源站磁盘成本压下来，同时把带宽留给热门内容。注意冷门内容回源延迟更高，如果用户拖进度条到冷门段落，首帧会慢，这一点要在播放器上做缓冲提示。

六、防盗链：热链防护的几种做法和取舍

视频站VPS 的带宽是最容易被盗链吃掉的资源。一个热门视频被论坛或群里一贴，几百人同时看，账单直接见顶。防盗链的做法有几种，效果和成本差别很大。

延伸对照：zenlayer 的公开机型与线路说明，可结合本节的判断标准自行核对。

最弱的是 Referer 校验。配置简单，一条 Nginx 指令就能加上：

location /video/ {
    valid_referers none blocked server_names ~\.baidu\.com ~\.google\.com;
    if ($invalid_referer) { return 403; }
}

它的弱点很明显：Referer 可以伪造，客户端可以主动不发送 Referer（referrerPolicy 或直接不发），移动端 App、播放器 SDK 有时也不带。所以 Referer 只能挡最粗糙的盗链，作为第一层可以留着。

第二层是签名 URL。后端按策略生成带签名和过期时间的地址，Nginx 用 secure_link 模块校验。配置大致是这样：

location /protected/ {
    secure_link $arg_md5,$arg_expires;
    secure_link_md5 "$secure_link_expires$uri$remote_addrsecretkey";
    if ($secure_link = "") { return 403; }
    if ($secure_link_expires < $time_now) { return 410; }
    proxy_pass http://127.0.0.1:8080;
}

签名 URL 的关键是密钥不要写进前端代码，签发逻辑放在你自己的接口里，并且设置较短的过期时间（比如 2 到 6 小时），过期后强制回源重新签发。

第三层是登录态校验加并发限制。视频必须登录才能看，且同一账号同一时间只能有一路播放。这能挡住「把链接发到群里让一堆人白嫖」的情况，是对付国内常见盗链方式最有效的一层。实现上可以用 Redis 记录 IP 或账号的并发数，超限直接拒绝。

第四层是主动监控加自动封禁。看日志找出异常拉流模式：

# 按 IP 汇总下载字节数，找出发流量的头号客户端
awk '{sum[$1]+=$10} END {for (i in sum) printf "%d %.2fGB\n", i, sum[i]/1073741824}' access.log \
  | sort -k2 -rn | head -20

# 找出访问同一个文件次数最多的 IP
awk -F'"' '{print $1, $2}' access.log | awk '{c[$2" "$3]++} END {for (k in c) print c[k], k}' \
  | sort -rn | head -10

# 单 IP 下载速率限制：每秒最多 2MB，超了直接断开
limit_rate zone=dlrate 2m;
limit_conn_zone $binary_remote_addr zone=dlconn:10m;
location /video/ { limit_conn dlconn 8; limit_rate zone=dlrate 2m; }

注意限速别设太狠，正常观众在网络差的时段也会被卡，限速值建议放宽到理论峰值的 3 到 5 倍。

七、切片与 HLS：播放器体验的真正开关

视频站VPS 播放卡顿，很大一部分原因不在带宽，而在没有做切片。单个 mp4 文件直链播放，播放器必须从头读 moov 或者做一次大范围 Range 请求才能起播；做 HLS 切片之后，播放器只拉一个几秒长度的小分片，起播几乎即时，切换码率也更快。

延伸对照：cloudcone 的公开机型与线路说明，可结合本节的判断标准自行核对。

HLS 的基本结构是一个 m3u8 播放列表加一堆 ts 或 fmp4 分片。生成方式用 FFmpeg：

# 生成 HLS 切片，6 秒一片，切片时长决定首播延迟和文件数
ffmpeg -i input.mp4 -c:v libx264 -preset veryfast -crf 22 \
  -c:a aac -b:a 128k -hls_time 6 -hls_playlist_type vod \
  -hls_segment_filename "seg_%05d.ts" playlist.m3u8

# 改成多码率自适应（需要先分别压好三档码率）
ffmpeg -i input.mp4 -filter_complex \
  "[0:v]split=3[v1][v2][v3];[v1]scale=-2:480[v1o];[v2]scale=-2:720[v2o];[v3]scale=-2:1080[v3o]" \
  -map "[v1o]" -c:v:0 libx264 -b:v:0 800k \
  -map "[v2o]" -c:v:1 libx264 -b:v:1 2500k \
  -map "[v3o]" -c:v:2 libx264 -b:v:2 4500k \
  -map a:0 -c:a aac -b:a 128k \
  -f hls -hls_time 6 -hls_playlist_type vod \
  -master_pl_name master.m3u8 \
  -var_stream_map "v:0,a:0 v:1,a:0 v:2,a:0" \
  "v%v/playlist.m3u8"

切片的取舍有三条。切片太长（比如 30 秒）文件少但起播慢、拖动不跟手；切片太短（比如 1 秒）起播快但请求数暴增，服务器连接数和 CDN 请求费用都会上去，播放器兼容性也变差。经验上 4 到 10 秒是比较稳的区间。切片必须对齐关键帧，否则浏览器会在关键帧边界外做额外请求，某些播放器会直接黑屏几秒。

检查切片是否对齐，用这个方法看关键帧间隔：

# 输出每个关键帧的时间点，确认间隔接近目标切片时长
ffprobe -v error -select_streams v:0 -show_entries frame=pts_time \
  -of csv=p=0 -skip_frame nokey input.mp4 | head -20

生成完之后必须实测播放。用 ffplay 在本地起播，或者用 curl 拉取 m3u8 看分片是否连续：

# 拉取播放列表，确认分片编号连续、总时长合理
curl -s "http://127.0.0.1/video/master.m3u8" | head -20
# 逐个拉一个分片验证可用
curl -s -o /dev/null -w "分片状态:%{http_code} 大小:%{size_download}\n" "http://127.0.0.1/video/seg_00000.ts"

另外提醒，HLS 切片对 CDN 非常友好，因为每个切片都是独立可缓存的小文件。但如果你的片源是防盗链保护的，记得签名要覆盖 m3u8 本身，否则播放列表会过期而分片还在。

八、每月成本到底怎么算

视频站VPS 的成本必须按月核算清楚，否则会在某天突然发现入不敷出。下面这张成本表把一个具体场景拆开，假设站点月活观众 8000 人，日播放量 3000 次，平均每次观看 20 分钟，内容是 1080p 4.5 Mbps 码率：

延伸对照：digitalocean 的公开机型与线路说明，可结合本节的判断标准自行核对。

成本项	计算方式	本例估算	说明
源站出网流量	播放量乘时长乘码率	约 900 GB 每月	若 CDN 命中六成则回源约 360 GB
源站带宽	并发乘码率乘突发系数	建议 50 Mbps 起	峰值按 30 并发估算约 135 Mbps，需靠 CDN 削峰
CDN 流量	总播放量对应字节数	约 900 GB	按各 CDN 官网当日报价为准
存储	原片加转码成品	约 1 TB 至 2 TB	SSD 加大容量盘组合
转码	按任务时长计费	每月数十元到数百元	用按小时高配机器或云转码服务
服务器月租	按机型	数十到数百元	具体价格以各商家官网当日报价为准

这张表的用法是：把「播放量」和「平均观看时长」换成你自己的真实数字，其他项按同样结构去查。核心的判断标准有两条。第一是每 GB 流量产生的观看时长，这叫流量效率——如果每 GB 只能换来三分钟观看，说明码率偏高或者内容重复度低，值得回头优化编码而不是加机器。第二是带宽费占总成本的比例，如果带宽月租超过流量费，通常说明你的流量不大但峰值很高，此时换成流量计费加 CDN 的模式往往更划算。

有三个常见的成本盲区必须点出来。第一个是回源流量的双倍计费，源站出网一次、CDN 入网一次，这两段如果分别计费，实际单位成本比表面单价高。第二个是无效流量，爬虫、扫描器、播放器预取会占掉可观份额，装一个 UA 黑名单加速率限制能省下百分之几到十几的流量，具体取决于站点被爬的强度。第三是转码后没删原片，原片和成品同时占着空间，且原片又完全没人访问。

核算完成后再去比价，选型时的顺序也应该是：先确认带宽和流量口径，再看月租，最后看商家有没有月付选项可以先试一个月。有月付选项的商家非常适合第一次采购，因为你可以用真实流量验证自己的估算，而不用一次性押一年。

九、常见误区

视频站用VPS 有几个反复出现的错误判断，代价通常在上线之后才显现。

延伸对照：hostwinds 的公开机型与线路说明，可结合本节的判断标准自行核对。

第一个误区是「带宽标称越大越好」，买 1 Gbps 端口却没有相应的大流量包，结果是钱付了、用不上、还因为超流量被限速。或者反过来，为了省钱买 10 Mbps 结果流量一跑超就打满。带宽是同时在线人数的天花板，不是总流量的容器，两者要分开算。

第二个误区是忽略网卡和系统的层限。一台机器的带宽再大，如果网卡是单队列百兆、或者宿主机给你做了流量整形，实际速度都上不去。租之前直接测：

# 下行测速（需要先装 iperf3 客户端）
iperf3 -c 测速节点地址 -P 4 -t 10
# 看多线程是否线性提升，能提升说明队列数够

第三个误区是以为加了 CDN 就不用管源站。CDN 命中率不到的情况下源站一样会被打满，而 CDN 的默认缓存策略经常对带参数的地址不生效，看起来加了 CDN 流量却没降。

第四个误区是只看 CPU 和内存指标做决策。监控面板上的 CPU 使用率很低，播放却卡，因为瓶颈在网卡队列和带宽，监控面板根本不看这两项。

第五个误区是所有内容用同一个码率存一份，然后用播放器硬缩放。这样做的问题是移动端用户在弱网下拉取了高清码率却解不出来，白白浪费流量还卡。正确做法是做多码率版本。

第六个误区是先买大机器再想内容。视频站的算力需求极低而带宽存储需求极高，把预算花在大内存大核的机器上是把钱花在错的地方。

第七个误区是忽略 HTTPS 开销。视频站的流量全部走 TLS，加密本身不耗带宽，但握手和会话复用配置不当会显著增加连接数。默认每条连接单独握手会让高并发场景的 CPU 和连接数暴涨，开启会话复用并把 TLS 握手交给 Nginx 的 worker 线程处理，能让长连接场景的 CPU 占用降下来：

# 开启会话复用与缓冲，减少重复握手
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1h;
ssl_session_tickets on;
proxy_buffering on;
proxy_buffers 16 16k;
proxy_busy_buffers_size 32k;

第八个误区是认为端口带宽标称值就是实际可用速度。商家的标称端口常常是共享的，宿主机出口才是真正瓶颈，上线前一定要用自己的网络实测一次：

# 用多线程测速看单线程与多线程的差距，差距过大说明是共享瓶颈
iperf3 -c 测速节点地址 -P 1 -t 10
iperf3 -c 测速节点地址 -P 8 -t 10

第九个误区是上线后不做流量复盘。带宽和流量的估算一定会偏，因为没人能准确预测观众什么时候来看、会不会看完整段。正确做法是每月导出一次日志，用前面那几个 awk 命令重新算一遍实际出网流量，然后修正预算，而不是每年都按同一个拍脑袋的数字付钱。

十、常见问题

视频站用VPS 到底要多大带宽？ 先算并发乘码率乘突发系数。举例：50 个人同时看 1080p 的 4.5 Mbps 片子，理论值约 225 Mbps，乘上一点五的突发系数约 340 Mbps，这还没算首播和拖动。算出来的数就是源站带宽下限，但实际采购时应该优先靠 CDN 削峰，源站留够余量即可。

码率和分辨率怎么定才不浪费流量？ 按内容类型选上限：教学、访谈类画面静态多，1080p 给 2.5 到 3 Mbps 通常够用；体育、游戏等高动态内容，1080p 需要 4 Mbps 以上才有基本观感。定完之后用 ffprobe 检查成片实际码率，别让编码器偷偷给了个很高的码率。

带 HLS 切片的站还需要大带宽吗？ 需要，但峰值形态变了。切片让起播更快、请求更均匀，削掉了首播的尖峰，但总流量一点没少。CDN 命中率高的站点，源站带宽可以降到总需求的四成左右。

CDN 回源到源站要怎么配置才不出错？ 三件事必须做对：缓存键包含所有影响内容的参数、回源支持 Range 请求、源站返回正确的 Content-Length 和 Accept-Ranges。上线前用带 Range 的 curl 请求验证一次，比事后排查省事得多。

防盗链做到什么程度算够？ 普通内容用 Referer 加签名 URL 就够用，重点内容再加登录态和并发限制。三层叠加加上对异常 IP 的自动封禁，基本能挡住绝大部分盗链。别指望单靠 Referer，那是最容易被绕过的一层。

转码放在自己的 VPS 上做可以吗？ 可以，但必须和分发做资源隔离，且只做轻量转码。批量高质量转码应该交给按小时计费的机器或云转码服务，否则转码一跑全站变慢。具体机型和报价以各商家官网当日报价为准。

怎么防止转码之后忘记删原片？ 用脚本按访问日志做冷热分离：N 天无访问的成品迁到低价大容量盘，原片单独放一份并按发布周期清理。清理前务必确认备份脚本用 rsync -aL 跟随了软链接，否则备份出来是残缺的。