SRS 生态中的 Oryx：一体化直播与 WebRTC 平台的架构、部署与运维实践

【免费下载链接】srs SRS is a simple, high-performance, AI-driven real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181, with codec support for H.264, H.265, AV1, VP9, AAC, Opus, and G.711. 项目地址: https://gitcode.com/GitHub_Trending/sr/srs

本文基于 SRS 仓库内 skills/srs-support/references/oryx-overview.md 这篇 Oryx 概览文档撰写，覆盖 Oryx 的定位与组件架构、双向协议支持矩阵、最小化 Docker 部署流程、完整环境变量与端口配置、以及单机化设计的边界与限制。读完后你可以独立完成 Oryx 的部署、推流/拉流全链路验证、OpenAPI 自动化接入，并清楚知道它与独立 SRS 的配置差异和能力边界。

一、Oryx 是什么：SRS 之上的"开箱即用"一体化方案

Oryx（前身名为 SRS Stack）是一个一体化、开箱即用的开源视频解决方案，用于在云端或自托管环境中构建直播与 WebRTC 服务。它的核心设计思想是把一整条直播技术栈压进一个单机应用：

• SRS 提供底层媒体服务器能力（接收、转封装、分发）；
• Oryx 在其之上补齐面向最终用户的工作流：认证、自动 HTTPS、录像、多平台再推流、虚拟直播、摄像头推流、转码、HTTP API、回调以及 AI 媒体能力。

一个关键的产品区分：Oryx 基于 SRS，但它不是独立 SRS 的另一个名字。独立 SRS 通过手工编辑 .conf 配置文件（本仓库 trunk/conf/ 下有完整示例，如 full.conf）和 1985 端口的 /api/v1/ API 直接运维；而 Oryx 主要通过 Web 控制台操作，内部由 Go 后端动态生成 SRS 与 NGINX 配置。仓库中 skills/srs-support/SKILL.md 明确将二者划为两个独立产品的支持范围，并强调"不要把 Oryx 控制台工作流翻译成裸 SRS 配置"。

因此选型原则是：如果你需要精细控制媒体服务器（边缘集群、自定义 vhost、直接操作 /api/v1/），用独立 SRS；如果你要快速搭一个"带界面、带 HTTPS、带录像和再推流"的直播站点，用 Oryx。

二、工作流与数据通路：从源到目的地

Oryx 的数据通路可以概括为"多种来源 → Oryx 中枢 → 三类目的地"，原文档给出的架构示意如下：

2.1 支持的输入来源（Sources）

来源	协议/方式	说明
OBS、FFmpeg、vMix	RTMP / SRT / WHIP	传统编码推流工具按各自能力选择协议
浏览器	WHIP	采集摄像头与麦克风推流，前提是已启用 HTTPS（安全上下文）
IP 摄像头、流 URL	RTSP 等	Oryx 通过受管的 FFmpeg 任务拉取源（如 RTSP），再送入 Oryx 或转发到外部平台
视频文件	本地/上传	上传的文件或位于容器 /data 目录下的文件，可用于虚拟直播和 AI 配音

2.2 Oryx 内部集成的服务

组件	职责
Dashboard 与 OpenAPI	通过 Web 界面或 /terraform/v1/ API 配置和运维 Oryx
SRS	通过 RTMP、SRT、WebRTC、HLS、HTTP-FLV 接收、转换并分发直播流
FFmpeg	承担再推流、虚拟直播、摄像头拉流、转码、录像后处理、AI 媒体管线
Redis	存储 Oryx 配置与任务状态，落在持久化的 /data 卷
NGINX	提供 HTTP/HTTPS 访问、反向代理、Web 与媒体资源分发
OpenAI 服务（可选）	由用户自行配置后，为转写、语音助手、配音、OCR 提供能力

2.3 支持的输出目的地（Destinations）

• 浏览器与播放器：通过 WHEP、HLS、HTTP-FLV、RTMP 或 SRT 播放，取决于播放器能力；
• 网站与应用：内嵌浏览器播放器、WordPress 插件（SRS Player）或自研应用；
• 直播平台：将直播源或虚拟直播再推到 YouTube、Twitch、Facebook 等；
• 文件与集成：保存录像、导出配音成品与字幕、通过 HTTP 回调推送推流/录像/OCR 事件。

三、协议支持矩阵：哪些能推、哪些能拉

Oryx 文档将协议明确分为双向协议（既支持推流进 Oryx，也支持从 Oryx 拉流）与单向协议（只在特定场景中作为输入或输出）。

3.1 双向协议（输入 + 输出）

协议	传输层	典型用法
RTMP	TCP	用 OBS、FFmpeg、vMix 或任意 RTMP 编码器推流；用 RTMP 兼容软件拉流。传统直播工作流
SRT	UDP	用 OBS、vMix、FFmpeg、ffplay 等 SRT 兼容工具推流和拉流。为不完美网络设计的可靠低延迟传输
WebRTC	UDP（媒体）	浏览器、OBS 或兼容应用通过 WHIP 推流、WHEP 拉流。Oryx 中延迟最低的工作流；浏览器推流必须有 HTTPS 等安全上下文

3.2 单向协议（文档化场景）

• HLS 与 HTTP-FLV：由已推入的直播流生成的播放输出，在标准 Oryx 工作流中不作为推流输入；
• RTSP：IP 摄像头场景的输入。Oryx 用 FFmpeg 拉取摄像头流再转推/转发，并不把 RTSP 作为通用播放输出暴露。

这里可以与独立 SRS 做一个对照：本仓库 trunk/doc/Resources.md 列出的 SRS 标准端口为 1935/TCP（RTMP）、1985/TCP（HTTP API）、8080/TCP（HTTP-FLV/HLS）、8000/UDP（WebRTC 媒体）。Oryx 沿用了其中的 1935 与 8000/UDP，另加了 10080/UDP（SRT）；而 1985/8080 这类 SRS 原生端口在 Oryx 里被收敛到 NGINX 反代之后的 80/443 上（见下文端口映射）。

四、最小化部署实战：Docker 四步走

Oryx 文档给出的"最简工作流"是：跑起 Docker 镜像 → 从 OBS 推一路 RTMP → 用控制台生成的浏览器链接播放。完整步骤如下。

步骤 1：带持久化存储运行 Oryx

docker run --restart always -d -it --name oryx -v $HOME/data:/data \
  -p 80:2022 -p 443:2443 -p 1935:1935 -p 8000:8000/udp -p 10080:10080/udp \
  ossrs/oryx:5

$HOME/data:/data 挂载是必需的：管理员密码、推流密钥（publish secret）、证书、Redis 数据、录像、上传文件和各项功能配置都保存在 /data 下，容器重建后只有靠这个挂载才能保住。

步骤 2：设置管理员密码

打开 http://localhost，按提示设置管理员密码。远程服务器请换成可达的 IP 或域名，并确保主机防火墙与云安全组放行所需端口。

步骤 3：从控制台获取推流地址

在 Dashboard 中进入 Scenarios > Streaming > RTMP: OBS or vMix，复制生成的 Server 与 Stream Key 填入 OBS 开始推流。注意：Stream Key 中包含了 Oryx 的全局推流密钥，应按敏感信息对待——不要出现在日志或截图里，也不要把它拼进播放 URL。

步骤 4：使用控制台生成的播放链接

通过 HLS、HTTP-FLV、WebRTC/WHEP 或其他方式预览直播。若要启用浏览器 WHIP 推流，需配置 HTTPS，且对外地址要使用可达的内网 IP、公网 IP 或域名，而不是 localhost/127.0.0.1（WebRTC 候选地址与浏览器安全上下文都依赖它）；同时放行 UDP 8000 端口。

默认暴露端口速查

宿主机端口	容器内端口	用途
80/TCP	2022/TCP	HTTP 控制台、OpenAPI 与 HTTP 媒体分发
443/TCP	2443/TCP	HTTPS 控制台、API、信令与加密 HTTP 媒体分发
1935/TCP	1935	RTMP 推流与播放
8000/UDP	8000	WebRTC 媒体传输
10080/UDP	10080	SRT 推流与播放

如果修改了宿主机端口映射，务必使用不冲突的端口，并同步设置 HTTP_PORT、RTMP_PORT、RTC_PORT、SRT_PORT，让控制台生成的 URL 与实际部署一致。

五、核心组件与依赖

Oryx 以一体化应用分发，通常就是 ossrs/oryx Docker 镜像，用户无需单独安装其内部依赖。

核心组件：

• SRS — RTMP、SRT、WebRTC、HLS、HTTP-FLV 的媒体服务器引擎；
• FFmpeg 与 ffprobe — 处理录像、再推流、虚拟直播、摄像头拉流、转码、转写、配音与 OCR 工作流的媒体；
• Redis — 存储配置、认证数据与持久任务状态，数据经 /data 挂载保留；
• NGINX — HTTP/HTTPS 代理与 Web/媒体资源服务，另有一个独立的可选 NGINX HLS CDN 工作流；
• Go — Oryx 后端与 HTTP 服务的实现语言；
• React — Web 控制台，编译后的静态资源打进发布镜像；
• LEGO — Let's Encrypt 证书的自动申请与续期；
• youtube-dl — 为接受远程视频源的工作流下载在线媒体。

按功能启用的外部服务：

• OpenAI 服务 — 可选，仅当配置了转写、语音助手、配音或 OCR 时必需；
• 直播平台 — 仅再推流、虚拟直播或摄像头转发场景需要（YouTube、Twitch、Facebook 或同类目标）；
• 云存储 — 仅当录像配置为云端目标而非本地 /data 时需要。

部署与开发：

• Docker — 推荐部署方式，也是运行完整 Oryx 技术栈的最简途径；
• Helm — 面向 Kubernetes 的另一种文档化部署方式；
• Go 与 Node.js 工具链 — 仅从源码构建后端和 React 控制台时需要，运行官方 Docker 镜像不需要。

六、功能全景

6.1 直播与分发

• 多协议直播 — RTMP、SRT 或 WHIP/WebRTC 推入，RTMP、SRT、WHEP/WebRTC、HLS、HTTP-FLV 拉出；
• Web 控制台 — 生成推流/播放 URL，提供面向场景的配置与状态视图，无需手写 SRS 配置；
• 网站集成 — 浏览器播放、自研应用，以及 WordPress 的 SRS Player 插件；
• HLS 分发 — 生成兼容性好的 HLS，并提供可选的 NGINX HLS CDN 工作流应对更大量级的分发。

6.2 安全与运维

• 管理员认证 — 保护 Oryx 控制台与管理功能；
• 推流认证 — 生成一个全局推流密钥，校验 RTMP、SRT、WHIP 推流端；文档化标准工作流不把密钥加到播放 URL 上；
• 自动 HTTPS — 通过 LEGO 申请与续期 Let's Encrypt 证书，支撑安全控制台访问与浏览器摄像头/麦克风使用；
• 持久化状态 — 配置、证书、Redis 数据、录像、上传与生成媒体全部落 /data；
• HTTP OpenAPI — 暴露文档化的 /terraform/v1/ API，并以 Oryx 认证代理部分 SRS API（/api/ 前缀）；
• HTTP 回调 — 把推流、停止推流、录像、OCR 事件推送到外部应用。

6.3 媒体工作流

• 录像 — 录制指定直播流，支持流过滤器与合并推流会话，产出 MP4，可保存到本地磁盘或文档化的云存储目标；
• 多平台再推流 — 把直播转发到 YouTube、Twitch、Facebook 等目标；当前源停止时可选切换到另一个可用输入；
• 虚拟直播 — 把预录文件等其他媒体源循环/直播化输出，支持 7×24 连续工作流；
• IP 摄像头直播 — 拉 RTSP 摄像头流并转发到 Oryx 或外部平台；纯视频摄像头可按需附加静音音轨；
• 直播转码 — 用受管 FFmpeg 任务修改码率、分辨率或加滤镜，再把处理后的流推回 Oryx。

6.4 AI 能力

• 直播转写 — 语音识别生成字幕，支持烧录字幕与 HLS WebVTT 输出；
• 语音助手 — 面向直播间的浏览器语音/文字助手，可做语言陪练、翻译等提示词驱动的对话；
• 视频配音 — 转写、翻译、语音合成、音段调整并导出多语种视频；
• 直播 OCR — 用可配置的指令从直播画面中抽取文字、物体或场景描述，结果经控制台或 HTTP 回调送达。

注意：AI 能力依赖用户自行配置支持的 OpenAI 服务；语音助手、配音、OCR 文档标注为 beta 功能，且不同 Oryx 版本可用性可能不同。

七、配置体系：以 /data 为核心的持久化与环境变量

Oryx 主要通过 Web 控制台配置（各场景页与系统页），不要把它当作一台可以随意手改配置的独立 SRS 来对待。

7.1 持久化配置要点

• 宿主机目录挂载到 /data，标准 Docker 命令即 $HOME/data:/data；
• Oryx 的环境文件、生成的 SRS/NGINX 配置、SSL 文件、Redis 数据与功能状态都存放在 /data 下；
• 主环境文件是 /data/config/.env，修改后需重启 Oryx 才生效；
• /data/config/.env 可能包含管理员密码等敏感值，必须加以保护；
• 不要用独立 SRS 的示例配置直接替换 Oryx 生成的文件，除非版本匹配的 Oryx 文档明确指引你这么做。

7.2 常用环境变量

变量	作用与默认值
MGMT_PASSWORD	设置管理员密码，按机密对待
REACT_APP_LOCALE	控制台语言，en 或 zh，默认 en
HTTP_PORT / RTMP_PORT / RTC_PORT / SRT_PORT	Docker 端口映射与默认不一致时，告知 Oryx 对外端口，保证生成的 URL 正确
MGMT_LISTEN / PLATFORM_LISTEN / HTTPS_LISTEN	内部控制 HTTP 服务监听端口，文档化默认分别为 2022、2024、2443
CANDIDATE	自动按请求主机解析 WebRTC 候选地址不适用时，手动覆盖候选地址
NAME_LOOKUP	是否按 HTTP 请求主机解析候选地址，默认 on
AUTO_SELF_SIGNED_CERTIFICATE	是否自动创建自签名证书，默认 on
SRS_FORWARD_LIMIT / SRS_VLIVE_LIMIT	并发再推流任务数与虚拟直播任务数上限，默认均为 10
REDIS_PASSWORD / REDIS_PORT	不使用默认内置 Redis 时，配置 Oryx 的 Redis 连接

开发期变量（NODE_ENV、LOCAL_RELEASE、PLATFORM_DOCKER、PUBLIC_URL、BUILD_PATH、GO_PPROF）在生产 Docker 部署中不应改动。

7.3 OpenAPI 自动化

• 在 System > OpenAPI 中获取 Bearer Token，用于调用受保护的 /terraform/v1/ API；
• 公开的版本与健康检查端点不需要管理 Token。仓库内 skills/srs-support/SKILL.md 的运维排障章节列出的诊断命令即走这条路径，例如 curl http://localhost/terraform/v1/mgmt/versions（版本）与 curl http://localhost/terraform/v1/mgmt/check（健康检查）；
• 绝不把 Bearer Token、推流密钥、目标平台 Stream Key 或 OpenAI Key 写进公开脚本、日志、截图或文档。

八、边界与限制：单机一体化设计的代价

理解 Oryx 的以下限制，才能在容量规划与多实例部署时避坑：

1. 单机设计 — Oryx 是一体化单机应用，不是内置媒体集群。可以在一台或多台机器上跑多个 Docker 实例，但实例彼此隔离，需要各自独立的端口、/data 目录和外部协调机制（对比：独立 SRS 可通过 origin/edge 集群原生扩展，如本仓库 origin-for-edge.conf 所示的集群模式）；
2. 共享推流密钥 — 文档化认证模型是一条流共享一个全局推流密钥，不提供逐流独立密钥；
3. 手动升级 — Oryx 不会从控制台自升级；Docker、Helm、脚本、aaPanel 部署各走各自的平台升级流程；
4. 持久存储是运维硬性要求 — 不带持久 /data 挂载运行，容器被替换时密码、推流密钥、证书、Redis 数据、录像、上传与功能配置全部可能丢失；
5. 容量受单台主机约束 — 并发直播流、FFmpeg 任务、录像、转码、AI 处理与对外分发共享同一台机器的 CPU、内存、磁盘与带宽；
6. AI 服务是外部依赖且部分为 beta — 受外部 OpenAI 服务的可用性、延迟、配额与成本影响；语音助手、配音、OCR 标注为 beta，版本间可能有差异。

此外，Oryx 5 的 README 将 GB28181、WebRTC 面对面聊天、WebRTC 视频房间、集成 Prometheus/node-exporter 监控列为未完成工作。需要这些能力前先核对实际部署版本的文档，不要默认它们仍然存在缺口（注意 GB28181 在独立 SRS 中已是完整功能，本仓库 trunk/conf/gb28181.conf 与 3rdparty/srs-bench/gb28181 中都有相应支持，两个产品的能力边界要分清）。

九、结语：SRS 与 Oryx 的分工与选择

维度	独立 SRS	Oryx
定位	简单、高性能的实时媒体服务器	基于 SRS 的一体化视频应用平台
配置方式	手工 .conf（参考 full.conf）+ /api/v1/	Web 控制台 + /terraform/v1/ OpenAPI
端口模型	1935 / 1985 / 8080 / 8000(UDP) / 10080(UDP)	80→2022、443→2443、1935、8000(UDP)、10080(UDP)
扩展方式	origin/edge 集群	多实例隔离部署 + 外部协调
附加能力	由集成方自行实现	内置录像、再推流、虚拟直播、摄像头、转码、AI 工作流

Oryx 的价值在于把"媒体服务器 + 应用平台"这一整层工作压缩成一个容器：一条 Docker 命令、一个控制台、一个 /data 卷。而独立 SRS 的价值在于给需要深度定制与集群化分发的团队留下完整的底层控制面。两者同源于本仓库维护的 SRS 内核，按业务场景二选一或组合使用，是 SRS 生态最常见的两种落地姿势。

【免费下载链接】srs SRS is a simple, high-performance, AI-driven real-time media server supporting RTMP, WebRTC, HLS, HTTP-FLV, HTTP-TS, SRT, MPEG-DASH, and GB28181, with codec support for H.264, H.265, AV1, VP9, AAC, Opus, and G.711. 项目地址: https://gitcode.com/GitHub_Trending/sr/srs