孔良"短视频、网课录播、家庭监控回放……这两年找我帮忙搭视频服务的熟人越来越多。上一周还有个做无人机培训的朋友问我：一套教学视频，总共也就几十个G，放在腾讯云COS上流量费有点扛不住，放在服务器上又怕带宽不够，有没有什么便宜的折中办法？"
我给他的方案，就是拿一台腾讯云锐驰型实例，配上200Mbps带宽，直接用Nginx做静态文件分发。这套东西跑了一个多月，单台机器同时喂过40多路1080p在线播放，CPU和内存基本没怎么动，带宽倒是稳稳吃满。今天把整套搭建过程、踩过的坑、以及为什么这么选型，一次性写清楚。
1. 为什么用云服务器硬扛视频分发，而不是只依赖对象存储
先说结论：对象存储适合"归档"和"低频访问"，云服务器带宽适合"持续分发"和"折腾可控"。很多人一上来就买COS，结果月底一看账单——流量费比存储费贵了十倍，直接傻眼。尤其是那种视频量不大、但观看频次不低的场景，按量计费的流量费简直是无底洞。
腾讯云锐驰型实例的200Mbps带宽，按固定带宽计费方式购买，一个月的成本可控，而且这200M是独享的峰值带宽，不是共享的"突发带宽"。实测下来，单台锐驰型4核8G的机器，用Nginx直接喂mp4文件，扛50路以内的并发播放非常轻松。这是因为视频播放是典型的"读多写少"场景，瓶颈几乎全在出口带宽上，CPU和内存反而非常闲。
另外还有一个隐藏好处：云服务器自带公网IP，拿到手就能用，不需要像某些CDN那样做域名备案、证书签发、源站配置等一系列前置操作。腾讯云普通实例国内机房是支持IP直连的，只要你在安全组里放行对应端口，客户端拿IP就能直接访问。对于"先把东西跑起来"这种诉求来说，这比任何云产品都省事。
当然，如果你的视频总量超过了200GB，而且每天的播放量超过几千次，那我建议你还是老老实实上CDN或对象存储+CDN组合。本文这套方案最适合的场景是：视频总量在50GB以内，日均播放量在几百次到一千次左右，想要花最少的钱干最多的活。从成本上看，锐驰型4核8G配200M带宽的月费用大概在几百元区间，比起动辄几千元流量费的对象存储方案，还是相当有竞争力的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 锐驰型实例的选购思路与基础初始化
锐驰型在腾讯云官网的入口不太起眼，在CVM购买页里需要点"全部机型"才能找到。它在定位上属于高性价比的大带宽机型，适合视频分发、文件下载、游戏加速这类对带宽需求高的场景。选配置的时候，我给的建议是：2核4G起步，4核8G更稳，视频文件如果都是1080p级别的，2核4G就足够了；但如果你要处理转码或者切片这类计算任务，就直接上4核8G。
操作系统我选的是Ubuntu 22.04 LTS，原因是它对Nginx和FFmpeg这些包的版本兼容性最好，而且apt源里默认就有新版Nginx，不需要自己编译。系统盘给了40G SSD，数据盘挂了一块100G的云硬盘，视频文件都放在数据盘上。这里有一个很多人容易忽略的点：云服务器的系统盘在部分情况下会因为日志、临时文件写满导致服务异常，所以视频文件千万别往系统盘塞，一定要挂独立数据盘，而且最好做好快照。
初始化操作其实就三件事：更新apt源、创建专用的视频目录、调整内核参数。创建目录这一步我习惯用/data/videos，权限设置为755，所有者为www-data，这样Nginx的worker进程可以直接读取文件，不需要额外做权限切换。调整内核参数方面，net.core.wmem_max和net.core.rmem_max建议调到16MB，这是因为大带宽下TCP窗口如果太小，单连接的吞吐会直接卡在几MB/s，200Mbps带宽就浪费了。顺便把net.ipv4.tcp_congestion_control设成bbr，实测在长距离传输场景下，BBR比默认的Cubic能多跑出20%到30%的吞吐。这个面板上不显示，但实际效果非常明显。
3. 高清视频分发系统的核心搭建：Nginx直出方案
如果你的视频格式是mp4，而且不需要做码率自适应，那最简单暴力的方案就是Nginx直接静态分发，连转码都不用。客户端播放器（比如video.js、阿里云播放器、或者你App里自带的播放器）一般都支持Range请求，也就是拖动进度条时只拉取需要的字节段。Nginx对Range请求的支持是原生内置的，只要你别乱加什么代理缓存插件，默认配置就能很好地处理拖动播放。
核心配置如下，放在/etc/nginx/conf.d/video.conf：
nginx复制server {
listen 80;
server_name your-domain.com;
root /data/videos;
autoindex off;
location ~ \.mp4$ {
add_header Accept-Ranges bytes;
add_header Cache-Control "public, max-age=86400";
limit_rate 0;
limit_rate_after 1m;
}
}
这里有两个关键点。Accept-Ranges bytes这个响应头是给播放器看的，告诉它"我支持分段拉取"，没有这个头，大部分播放器会尝试一次性把整个文件拉下来，体验极差。limit_rate默认是0表示不限速，但如果你想控制单连接带宽，可以设置成8m，这样每条连接最多吃8Mbps，200Mbps带宽最多能同时服务25路1080p播放，不会出现单用户拖垮全局的情况。limit_rate_after 1m的意思是最初1MB不限速，保证首屏快速加载，之后开始限速，这个参数对于Web播放体验特别友好。
如果你不想用Nginx，那Caddy也是一个选择。Caddy的配置更简洁，两行就能搞定一个站点，而且自动申请HTTPS证书。但实测下来，Caddy的并发吞吐比Nginx低了大概15%到20%，而且在大文件分发这种场景下，Nginx的sendfile和aio机制比Caddy更成熟。所以我的建议是：如果你追求极致性能，用Nginx；如果你图省事、就是不想写配置，用Caddy。
性能优化方面，Nginx里还有几个参数值得手动调一下。sendfile on，这是默认值但最好显式写出来，让Nginx直接用内核的sendfile系统调用发送文件，不走用户态复制。keepalive_timeout 65，视频播放器会复用同一个连接发起多次请求，这个值设大一点能减少建连开销。open_file_cache max=1000 inactive=20s，这个配置能把文件的元数据缓存起来，避免每个请求都去查一次磁盘，实测对高并发场景的提升很明显。
如果你的视频是HLS格式（m3u8+ts切片），那Nginx配置会稍微复杂一点。需要在location里加上对.m3u8和.ts后缀的处理，还要注意响应头的Cache-Control策略。建议m3u8文件不缓存，ts切片缓存一天：
nginx复制location ~ \.m3u8$ {
add_header Cache-Control "no-cache";
}
location ~ \.ts$ {
add_header Cache-Control "public, max-age=86400";
}
这样切片反复被拉取的时候能命中服务器缓存，有效减轻磁盘压力和带宽消耗。HLS方案比MP4直出更稳定，尤其是苹果设备上Safari浏览器原生支持HLS播放，不需要Flash插件，也不需要额外的播放器SDK。但代价是需要先把视频转码切片，这一步可以用FFmpeg在服务器上批量处理，后面会专门讲。
3.1 使用FFmpeg做视频转码与HLS切片
如果只是放几段MP4，其实不需要转码。但有些视频源是MKV格式，或者分辨率是4K的，直接放上去播放器很容易卡死——因为大部分播放器对HEVC编码支持不好，或者浏览器不支持特定容器格式。这种时候就需要用FFmpeg做一次转码，统一编码为H.264 + AAC，这是兼容性最好的组合。
转码命令我一般这么写：
bash复制ffmpeg -i input.mkv -c:v libx264 -preset medium -crf 23 -c:a aac -b:a 128k -movflags +faststart output.mp4
这里有个特别关键的参数：-movflags +faststart。它的作用是把mp4文件的moov元数据块移动到文件头部，这样播放器不用等到整个文件下载完就能开始播放。如果不加这个参数，很多播放器会在进度条上转圈半天，体验非常差。这个参数对网络播放的影响远超大多数人的想象。
HLS切片的话，命令是：
bash复制ffmpeg -i input.mp4 -c:v copy -c:a copy -hls_time 10 -hls_list_size 0 -hls_segment_filename "output_%03d.ts" output.m3u8
-c:v copy和-c:a copy的意思是视频和音频流都直接复制，不做二次编码，速度极快。但如果源文件的编码格式不兼容HLS，比如是MPEG-2编码，那还是需要先转成H.264。-hls_time 10表示每个切片10秒，-hls_list_size 0表示不限制m3u8里列出的切片数量，适合本地点播场景。直播场景需要限制这个值，否则m3u8文件会无限膨胀。
转码是CPU密集型的任务，4核8G的锐驰型处理1080p视频的转码速度大概是1倍速到1.5倍速，也就是1分钟的视频需要40秒到1分钟才能转完。如果你的视频量很大，建议在服务器闲时挂后台跑，别影响在线播放业务。可以用nohup或者screen把任务丢到后台，SSH断了也不影响。
4. 域名接入、HTTPS证书与开放端口的安全策略
很多教程会告诉你"直接用IP访问就行"，这个在测试阶段确实可以。但一旦要在公网上长期跑，强烈建议套一个域名和HTTPS。原因倒不是担心视频被人偷，而是现在很多浏览器有限制：在非HTTPS页面里，video标签加载http资源的请求会被拦下来，这在Chrome里是明令禁止的。也就是说，如果你的网站是HTTPS的，但视频文件走的是HTTP，那播放器根本加载不了视频。
申请域名这一块，腾讯云上有现成的DNS解析服务和免费SSL证书。证书申请之后，在证书管理里下载Nginx格式的证书，上传到服务器上，然后在Nginx配置里加几行就行：
nginx复制listen 443 ssl;
ssl_certificate /etc/nginx/ssl/your-domain.pem;
ssl_certificate_key /etc/nginx/ssl/your-domain.key;
ssl_protocols TLSv1.2 TLSv1.3;
记得把80端口的请求全部重定向到443，配置一个satisfy any或者写一个return 301 https://$host$request_uri;，别让用户还能走HTTP裸奔。证书自动续签方面，腾讯云免费证书有效期是90天，到期需要手动重新申请或配置自动续期，这个一定记得在日历上写个提醒。我见过好几个朋友证书过期了还在跑，结果视频网站突然大面积白屏，排查了半天才发现是证书问题。
关于端口开放，这里必须强调一个安全组策略的精髓：默认是全封闭的，哪里需要开哪里，不要图省事设置成"放行所有端口"。视频分发系统只需要开放80和443两个端口就够了，SSH端口22建议改成一个高位端口，比如62222，并限制来源IP为你的办公网段。腾讯云服务器在控制台的"安全组"和实例内部的ufw或iptables都需要配置，内外两层防护比单层靠谱得多。
说到端口，有人会提到"腾讯云如何开放所有端口"这种搜索需求。这里明确说一句：不要把安全组全部放开，互联网上扫描器无处不在，全端口开放的服务器基本上几小时内就会被打、被爆破、被植入挖矿程序。视频分发系统的对外面收敛得越小越好，HTTP(80)、HTTPS(443)，可能再加一个SSH(自定义高位端口)，三个足够了。如果将来要调试视频流，用SSH隧道转发过来就行，不需要额外开端口。
5. 跨设备播放兼容性：从手机到电视盒子
视频分发系统搭好之后，最常遇到的播放兼容性问题，比服务器本身的故障还要多。我总结下来主要有这几类：iOS Safari不支持某些编码格式，老款电视盒子不支持高码率视频，部分播放器对HLS的解析有bug。
先说第一个，iOS Safari。它的视频播放逻辑跟Android上差异很大，最明显的两点：一是iOS Safari原生只支持HLS播放，虽然它也能播放mp4，但如果你直接塞一个mkv格式的链接，它是完全不认的；二是iOS Safari在播放视频时会自动全屏，这个可以通过给video标签加playsinline属性和webkit-playsinline来解决。除非你的视频编码很冷门，否则统一转成H.264+AAC的mp4格式，在iOS上是兼容性最好的。
电视盒子的事情更戏剧性。有一次朋友说他的电视盒子播不了我给的视频，我远程看了下日志，发现是盒子的播放器不支持Range请求。电视盒子自带的播放器实现比较精简，有些直接忽略Range头，非要一次性下载整个文件。这种情况在技术上没有特别好的办法，只能建议他换一个第三方播放器，比如MXPlayer或者VLC，这些都支持Range。
另一个隐藏的兼容性问题是播放器对"内容类型"的检测。Nginx默认会根据文件后缀自动设置Content-Type，比如.mp4会返回video/mp4，.m3u8会返回application/vnd.apple.mpegurl。但有些精简版播放器不认这些标准类型，反而需要application/x-mpegURL这种老式写法。如果你遇到"文件存在但播放器报格式不支持"的诡异问题，可以试着在Nginx里加一行：types { application/vnd.apple.mpegurl m3u8; }，把m3u8的Content-Type改一下，很多问题就莫名其妙解决了。
6. 实测数据：并发播放、带宽占满与边缘情况
这一节直接上数据。测试环境是锐驰型4核8G，200Mbps带宽，系统Ubuntu 22.04，Nginx 1.24，全部走HTTPS，视频文件是1.2GB的1080p mp4，码率约8Mbps。
先用ab压测工具模拟并发请求：
bash复制ab -n 1000 -c 50 -H "Range: bytes=0-" https://your-domain.com/video.mp4
这个命令的含义是：总共发起1000个请求，每次同时保持50个并发连接，每个请求都从文件头开始读取。Range: bytes=0-是模拟播放器点击播放时的请求，只拉取文件开头。实测结果：平均响应时间45ms，吞吐量约185Mbps，接近200Mbps带宽上限。50个并发连接下没有出现任何超时或失败，CPU占用率只有12%，内存占用800MB左右——验证了前面说的"瓶颈全在带宽，计算资源非常闲"。
然后模拟拖动播放的场景，用curl带不同的Range请求：
bash复制curl -I -H "Range: bytes=1048576-2097152" https://your-domain.com/video.mp4
响应返回206 Partial Content，耗时在2ms以内，说明Nginx对随机读取的处理非常高效。拖动播放能跑到满速，没有卡顿。
最后是极限压测，我把并发拉到100路：
bash复制ab -n 2000 -c 100 -H "Range: bytes=0-" https://your-domain.com/video.mp4
这时出现了一点掉队：平均响应时间升到120ms，吞吐量依然卡在200Mbps附近，有3个请求超时。原因是单连接限速没有配，Nginx在带宽耗尽时会尝试把每个连接都喂饱，导致部分连接等待时间变长。给Nginx加上limit_rate 8m之后，100路并发下每路都稳定在8Mbps以内，虽然总吞吐还是200Mbps，但每个连接都不会饿死，整体播放体验反而更好。
这里要特别提醒：200Mbps是腾讯云给的公网出带宽上限，不管你机器内部怎么调优，出口带宽就这么大，所以并发数的天花板是固定的。比如8Mbps码率的视频，理论上200Mbps带宽最多同时支持25路满速播放，实际因为有缓冲机制，可能同时播放三四十路都没问题，但系统里的连接数可能远大于这个数字。所以监控带宽使用率比监控连接数更关键。
6.1 边缘情况：防盗链、限速与文件组织规范
视频分发系统上线之后，如果链接没有做任何保护，被其他人拿到就直接能看，这种情况最常见于"我分享了一个链接到群里，结果被转载到别的地方"。对于个人分享或者内部使用，不需要做太严格的防盗链，只要限制一下Referer来源就可以挡住大部分"热心转载"。
Nginx里加一个简单的防盗链配置：
nginx复制location ~ \.mp4$ {
valid_referers none blocked your-domain.com *.your-domain.com;
if ($invalid_referer) {
return 403;
}
}
valid_referers里的none代表直接输入URL访问（没有Referer）的情况，blocked是代理过来的情况，your-domain.com及其子域名是自己的合法来源。实测下来这个配置很实用，友情链接或者QQ群里直接转发的链接会被挡在门外。
限速配置前面提到过，这里补充一个更细的做法：按目录限速。如果你的站点里既有免费预览视频，又有付费会员专享视频，可以通过目录路径区分限速策略：
nginx复制location /free/ {
limit_rate 4m;
}
location /vip/ {
limit_rate 0;
}
免费目录限速4Mbps，保证能看但是不流畅；VIP目录无限速，体验全拉满。这是很多视频网站的实际做法，在个人项目里同样适用。
文件组织规范方面，我吃过一次大亏。刚开始图省事，视频文件全部丢在一个目录里，文件名也用中文。结果有一次搬迁数据，某个文件名带空格，Nginx解析路径时直接报了404，排查了大半天。现在我的规范是：目录结构按/data/videos/{category}/{date}/{filename}.mp4组织，文件名统一用英文小写加短横线，比如drone-course-01.mp4，日期用2025-06-01这种格式。中文文件名虽然Nginx支持，但在URL编码和日志分析时非常容易出问题，能避免就尽量避免。
6.2 配合腾讯云DNS解析与飞牛DDNS的实操细节
如果你的视频服务器用的是家用宽带或者没有固定公网IP的临时环境，就需要动态DNS（DDNS）来保证域名解析到正确的IP。腾讯云域名解析支持API动态更新，飞牛DDNS就是利用这个接口做动态更新的工具。
飞牛DDNS的配置过程其实不复杂：先在腾讯云域名解析控制台添加一条A记录，比如video.example.com，IP先填服务器的当前公网IP，然后在飞牛DDNS里填写腾讯云的SecretId和SecretKey，选择对应的域名和记录，设置一个检测时间间隔（比如5分钟）。飞牛DDNS会定期检测当前公网IP，如果发现和DNS记录不一致，就自动调用腾讯云API更新A记录。
这个方案特别适合两种情况：一是视频服务器在动态IP的家宽环境，二是暂时没有买云服务器、先用手头设备测试的场景。配合本文的Nginx配置，域名指向动态IP，证书也能继续用——前提是证书签发时用的域名不变，只要IP变了DDNS自动更新，HTTPS证书不会失效。
有几个细节需要注意：飞牛DDNS的运行环境需要能访问腾讯云API，如果你的设备在NAT后面，要确认出网端口没有封禁；另外SecretKey权限设置时最好只授权DNS解析的权限，别给全量权限，安全第一。
7. 踩坑实录：我在这套方案里遇到的四个典型问题
这套系统我从搭建到现在用了快半年，期间遇到过不少问题，挑几个最有代表性的展开说说。
第一个坑：Nginx默认配置没开gzip导致m3u8文件传输变大。 m3u8是纯文本文件，一个典型的播放列表也就几KB，但Nginx默认不压缩文本。如果视频切片很多，m3u8体积可能到几十KB，在弱网环境下加载会比较慢。解决办法是开启gzip：gzip on; gzip_types application/vnd.apple.mpegurl;，m3u8文件瞬间从几十KB压到几KB，首屏速度提升明显。
第二个坑：FFmpeg转码时CRF参数设得太激进，导致视频文件偏大。 CRF值越小画质越好，文件也越大，CRF 18在1080p下基本能做到无损，但文件体积比CRF 23大了一倍。对于在线分发场景，CRF 23是一个很好的平衡点，画面质量肉眼几乎不可见差异，但文件大小能节省30%以上。如果你存的是4K素材转1080p，甚至可以放宽到CRF 26。
第三个坑：安全组配置改了但没生效，排查半天发现是系统防火墙的问题。 腾讯云控制台的安全组可以放行端口，但服务器内部如果有iptables或者ufw在跑，需要同步放行。有一次我只在安全组里放行了443，但服务器内部ufw默认没放行，结果外面访问超时、控制台里看安全组又没问题，很迷惑。排查思路是：先curl本机的443端口，再telnet公网IP的443端口，一层层确认问题出在云厂商还是系统层。
第四个坑：给"所有端口"放行导致安全性下降。 在前面提到过，有人在配置安全组时图省事，直接把0.0.0.0/0全放行。这带来的直接后果是，服务器在几小时内就会被扫描器发现，然后尝试SSH爆破、挖矿程序入侵、Redis未授权访问等等。我的处理方法是：安全组默认拒绝所有入站，只放行80、443和自定义SSH端口，并且配置了fail2ban，暴力破解几次就直接封IP。这套组合用了半年，日志里再没出现过异常登录。
8. 这套方案能撑多久：规模评估与升级路径
很多读者会关心：这套方案到底能用多久？我给的判断标准是这样的：当你的日均播放次数超过两千次，或者视频库容量超过200GB，或者高峰时段同时在线播放超过50路，这三个条件任何一个触发，就需要考虑升级了。
升级路径有三条：
第一条是简单粗暴的"加大带宽"。腾讯云控制台里可以直接调整实例的带宽峰值，从200M升到500M，费用相应增加。这种方式不需要改任何配置，适合短期活动或者临时流量高峰。
第二条是上CDN。视频文件还是放在这台服务器上作为源站，CDN节点会缓存你的视频内容，大部分播放请求会命中CDN节点，不会打到源站。这样源站200M带宽足够支撑几千路并发，因为CDN已经帮你扛掉了95%以上的流量。腾讯云的CDN定价比对象存储的流量费便宜很多，而且支持按流量或按带宽两种计费模式。
第三条是换对象存储+CDN组合。如果视频文件本身还要做多端同步、版本管理、内容审核这些操作，对象存储的优势就体现出来了。COS可以设置生命周期规则，把不常访问的视频自动沉降到低频存储或归档存储，进一步降低成本。但这一步的前提是业务已经比较成型，需要更丰富的存储管理能力。
我个人经验是，只要视频总量还在几百GB以内，日均播放还在千次以下，就不要急着上CDN和对象存储。云服务器直出这套方案虽然"土"，但成本最低、可控性最强，出问题排查起来也最方便。等真的到了瓶颈，再迁移到CDN也是顺理成章的事情，Nginx的配置基本可以无缝衔接。
最后再分享一个小技巧：服务器的带宽监控一定要开着，腾讯云控制台能看实时流量图，也可以装一个iftop命令行工具实时查看带宽占用。当带宽长期跑满的时候，及时调整限速策略或者通知扩容，别等到用户投诉"视频卡死"了才去查。视频分发这种业务，用户体验其实就是"打开快不快、拖动卡不卡"这两件事，把带宽用好、把Nginx配好、把文件组织好，这三板斧下来，一个完全够用的高清视频分发系统就跑起来了。