流媒体服务器怎么配置？配置流媒体服务器需要哪些硬件和软件？

流媒体服务器的配置核心在于编码、存储与分发三者的平衡，没有万能方案，只有根据你的推流场景、观众规模和网络条件做出的最优组合。

流媒体服务器配置，先分清你的使用场景

很多朋友一上来就问“流媒体服务器怎么配”，其实这个问题背后至少有三类完全不同的需求，第一类是个人或小团队做直播推流，比如游戏直播、户外直播，带宽和并发都不大；第二类是公司内部做视频会议或培训录播，对延迟和稳定性要求高；第三类则是面向公众的点播或赛事直播，需要扛住高并发和跨地域分发，这三类场景的硬件选型、软件栈乃至网络部署逻辑截然不同。

如果你连自己属于哪一类都没想清楚，直接照搬网上的“高配方案”大概率浪费钱，而“低配方案”又会在关键时刻卡顿，配置流媒体服务器的第一步不是买硬件，而是量化你的核心指标：同时在线人数、码率上限、延迟容忍度、存储周期,这四个数字决定了后面所有的选择。

个人直播推流场景：低延迟优先，云服务器或家用机均可

个人直播用的是RTMP或SRT协议推流到服务器，再由服务器转码分发给观众，这种场景下，CPU的转码能力比GPU更重要（除非你用NVENC硬编），如果你只是推720P/1080P、码率3-6Mbps的流，一台4核8G的云服务器（带宽按观众数估算）就足够了,具体配置建议：

• CPU：4核以上，推荐Intel Xeon E系列或AMD EPYC入门款
• 内存：8GB起，16GB更稳（因为要跑Nginx和FFmpeg）
• 存储：系统盘40GB SSD，缓存盘建议SSD（临时切片写入）
• 带宽：上行至少10Mbps，每增加100个观看者，至少增加10Mbps带宽

这里有个容易踩的坑：推流码率不等于播放码率，如果服务器只做转存不做转码，那么上行带宽消耗等于所有观众消耗的总和，比如你推6Mbps的流，100个观众同时看，仅出口带宽就需要600Mbps家用宽带绝对扛不住，所以个人直播建议直接使用CDN分发，服务器只做源站,或者开启服务端转码降低码率。

企业级流媒体服务器配置：稳定压倒一切，考虑冗余和切片

企业场景（比如内部培训直播、线上发布会）通常需要多路并发和录制留存，这时候建议采用“主备服务器+存储集群”的架构，软件方面，Nginx-RTMP和SRS（Simple-Rtmp-Server）是主流选择，SRS在国产化环境和复杂协议支持上做得更好，Nginx-RTMP则更轻量、社区资料多。

硬件配置可以参考这个梯度（并发500人以内，720P，2Mbps）：

组件	最低配置	推荐配置
CPU	8核	16核以上
内存	16GB	32GB
系统盘	60GB SSD	120GB SSD
存储盘	500GB HDD	2TB NVMe SSD（用于切片和录制）
网卡	千兆	双千兆或万兆

关键点在于：视频切片（HLS/MPEG-DASH）对磁盘随机读写性能要求很高，HDD在连续写入时没问题，但多个直播流同时切片时，随机写入性能会急剧下降，导致播放卡顿，所以存储盘一定要选SSD，NVMe更佳，另一个容易被忽略的是时间同步流媒体切片需要依赖NTP时钟，如果服务器时间漂移，生成的m3u8索引文件会不匹配,观众端会花屏。

选择合适的流媒体服务器软件与协议

流媒体服务器配置不只是硬件，软件协议的选择直接决定了你能覆盖多少终端设备。 目前最常用的三种协议是RTMP、HLS和WebRTC，RTMP延迟低（1-3秒），但需要分发层转码；HLS延迟高（5-30秒），但兼容性极好（所有浏览器都原生支持）；WebRTC延迟最低（<500ms），但服务器资源消耗大,适合互动直播。

SRS与Nginx-RTMP的对比：小白选Nginx，高阶用SRS

这里说一下SRS与Nginx-RTMP的对比，行业共识认为，Nginx-RTMP更像一个模块，配置简单，适合单机部署；SRS则是一个完整的流媒体服务器，自带API、集群、转码和回源功能，如果你的需求是“一把梭”既要RTMP又要HLS还要WebRTC，那就直接选SRS 4.0以上版本，它内置了HTTP-FLV和WebRTC支持，配置上只需修改srs.conf文件：

listen              1935;
max_connections     1000;
srs_log_tank        console;
vhost __defaultVhost__ {
    hls {
        enabled         on;
        hls_path        ./objs/nginx/html;
        hls_fragment    6;
        hls_window      60;
    }
}

这段配置的意思是：开启HLS切片，每个切片6秒，保留60秒内的切片作为回看窗口，对于企业场景，建议把hls_fragment设为4秒，切片更小、起播更快，但磁盘写入压力会增大，个人测试的话，Nginx-RTMP的配置文件更直观：

rtmp {
    server {
        listen 1935;
        chunk_size 4096;
        application live {
            live on;
            record off;
            hls on;
            hls_path /tmp/hls;
            hls_fragment 6s;
        }
    }
}

这里要注意，Nginx-RTMP的HLS模块需要额外编译，而且不支持WebRTC，如果你的播放端有大量iOS Safari用户，建议用SRS配合其内置的HTTP服务器,避免单独再部署Nginx静态服务来发HLS。

推流端与播放端参数配置的常见坑

很多人配好了服务器，结果推流画面卡顿或音画不同步，问题往往出在编码参数上，无论是OBS还是FFmpeg推流,以下参数是经过大量实践验证的：

• 视频编码：H.264（兼容性最好），码率可变（CRF=23左右）
• 音频编码：AAC-LC，采样率44100Hz，码率128kbps
• GOP大小：2秒（也就是帧率的两倍,30fps就设60）
• 关键帧间隔：与GOP一致，不要使用自动
• B帧：建议关闭或设为0（B帧会引入额外延迟）

如果音画不同步，检查推流端的video_track和audio_track的time_base是否一致，不要混合使用不同帧率的素材（比如30fps视频配29.97fps音频）。播放端如果使用HLS，延迟主要来自切片时长和播放器缓存，在播放器初始化时，将hlsMinBufferLength（如hls.js）设为3个切片时长,可以显著减少起播卡顿。

公网部署与带宽成本：地域节点怎么选

当你准备把流媒体服务器配置从局域网搬到公网，首先遇到的就是地域选择问题，如果你服务的是国内观众，服务器必须放国内（否则备案和访问速度都是问题）；如果观众主要在海外，新加坡或日本节点是常见选择，国内地域中，华东（上海）、华北（北京）和华南（广州）是三个核心拨测点，距离用户越近,首屏时间越短。

行业专家指出，国内主流云厂商的带宽计费方式分为按固定带宽和按流量两种，直播场景强烈建议选按流量计费，因为峰会活动可能只有1小时峰值，固定带宽会浪费大量成本，以简米云为例，按流量的价格大约在0.8元/GB（具体以官网为准），一场200人、码率2Mbps、时长1小时的直播，流量消耗大约为200人 2Mbps / 8 3600秒 = 180GB，成本约144元,这个估算可以作为预算参考。

如何评估流媒体服务器价格：不只算硬件

很多搜索“流媒体服务器价格”的朋友，其实是在选型阶段。总成本 = 服务器费用 + 带宽费用 + 存储费用 + (可选)转码费用，部分云厂商的转码是按分钟计费的，如果没有高码率兼容需求，建议关闭服务端转码，让观众直接拉流原始码率,这样能省下相当一部分钱。

对于自建机房，额外还要考虑公网IP成本、电力成本和维护人力，以一台中等配置服务器（16核32G）为例，云上价格大约每年5000-8000元，而物理机采购约1.5-2万元，但维护成本更高，对于非核心业务，租用云主机比自建机房更划算。

实战验证：从零配置一台可用的流媒体服务器

为了让你不困惑，这里给出一个基于CentOS 7/Ubuntu 22.04的最小化操作路径，假设你已经在云厂商开通了一台2核4G的服务器（测试用）,系统为Ubuntu。

1. 安装依赖：apt update && apt install -y build-essential git ffmpeg
2. 下载SRS源码：git clone -b develop https://github.com/ossrs/srs.git
3. 编译：cd srs && ./configure --prefix=/usr/local/srs && make
4. 配置：修改上文示例的srs.conf，监听1935端口
5. 启动：./objs/srs -c conf/srs.conf
6. 推流验证：在OBS中设置服务器地址为rtmp://你的IP/live/，推流码为test
7. 拉流验证：在浏览器中访问http://你的IP:8080/live/test.m3u8（SRS自带HTTP端口8080）

如果以上步骤顺利完成，说明你的流媒体服务器已经基本可用了，接下来要做的，是打开防火墙的1935端口（RTMP）、8080端口（HTTP-HLS），以及可能需要开启的1985端口（SRS HTTP API），注意，

云服务器还需要在安全组中放行这些端口,否则外部无法访问。

性能调优与故障排查：流量上来后怎么办

当并发观众从几十涨到几千，你会发现CPU和带宽都吃紧，此时不建议盲目加服务器,先做三层优化：

• 应用层：开启SRS的gop_cache选项（默认开启），它允许播放端不通过服务器中转直接获取关键帧
• 网络层：启用TCP BBR拥塞控制算法（修改/etc/sysctl.conf），可以显著提升高延迟下的带宽利用率
• 部署层：将源站的HLS输出挂载到CDN，让CDN节点负责边缘播放，源站只回源一次

如果出现视频卡顿，优先查看服务器日志中的dropped和stall字段，SRS的控制台输出中，stall表示发送队列已满，说明出站带宽不够或客户端拉流速度跟不上，此时应该降低码率或增加部署节点,而不是升级CPU。

流媒体服务器配置常见问题解答

问：直播推流到服务器后，播放一直卡在缓冲状态，但服务器CPU占用不高，是什么原因？

答：这通常是网络链路问题，首先用ping和mtr工具检查客户端到服务器的延迟与丢包率，如果延迟大于100ms或丢包率超过1%，RTMP传输会频繁重传，导致播放器等待关键帧，解决方案是改用HTTP-FLV或WebRTC协议，两种协议对弱网的抗性更强，如果客户端与服务器在同一局域网内,检查是否开启了流控或QoS策略。

问：流媒体服务器配置中，内存和SSD哪个对并发性能影响更大？

答：内存决定的是并发连接数的上限每个RTMP连接大约需要10-20MB内存，所以16GB内存可以支撑几百到上千并发，但SSD决定的是切片写入能力和回看存储速度，如果观众数少但录制时间长，SSD更重要；如果观众多且同时看直播，内存更容易成为瓶颈，建议常规配置下两者都不要短板，SSD至少预留1GB/s的随机写入带宽。

问：如何降低流媒体服务器带宽成本又不牺牲清晰度？

答：最简单的方式是使用自适应码率（ABR），在服务端转码出多个码率档位（例如1080P@6Mbps、720P@3Mbps、480P@1.2Mbps），播放器根据网络状况自动切换，这样大多数观众会在低码率档位消耗带宽，只有网络好的用户享受高码率，据行业统计数据，启用了ABR后，平均带宽消耗可降低30%-50%，而观看体验基本不受影响，具体操作在SRS中通过transcode块配置FFmpeg过滤器即可实现。

流媒体服务器配置的最终目标，不是追求参数上的极致，而是让观众在不可控的网络环境下获得稳定流畅的观看体验，从明确场景出发，选对协议，控制好编码参数，把预算花在带宽和存储上,这套思路比任何现成的配置模板都更可靠。