RTMP 服务器是直播发布者的接收点。编码器或制作应用会发送 RTMP URL 和流密钥；服务器接受该会话、应用访问策略，并为下一个选定任务提供流。它不会自动成为观众播放器、CDN、录制器或制作切换台。
RTMP 服务器的作用
一个有用的心智模型是：发布者 → RTMP 服务器 → 选定的下游模块。发布者可以是 OBS、FFmpeg 或编码器。已发布的 RTMP 规范保存在历史规范镜像中。服务器向发布者提供地址和凭据，然后让操作员确认连接和媒体是否处于活动状态。录制、路由、监看和观众交付各自都需要配置和验收检查。
| 层级 | 需要回答的问题 |
|---|---|
| 接入 | 已分配的发布者是否携带预期密钥到达监听器？ |
| 媒体 | 视频、音频和比特率在接收端是否可用？ |
| 下游 | 应由哪个单独配置的监看、录制、路由或播放器接收它？ |
仔细读取发布地址
RTMP 端点通常将服务器地址或应用路径与流名称或密钥组合。应把密钥当作凭据：从部署中复制，不要放入公开文档，若已暴露则应替换。端口取决于部署；在检查监听器和防火墙策略前，不要假定端口可达。
选择受控访问或访客访问
受控模式为同一已配置流名称分配 Publisher 和 Receiver 角色；因此两个角色可使用相同的 RTMP URL。访客模式没有预先创建的访问规则，而是有意开放端点：发布时选择非空流名称，接收时使用同一名称。
按顺序验证交接
- 在受控模式中，确认该流具有 Publisher 和 Receiver 角色；在访客模式中，确认开放端点是有意设置的。
- 发布已知源，并确认活动发布者状态和传入比特率。
- 从配置的接收端或监看路径检查画面和预期音频。
- 仅在此之后测试选定的录制、路由或浏览器输出工作流。
如果 OBS 显示正在推流但服务器未显示发布者，请比较精确的 URL 和密钥，然后检查 DNS、监听器端口和访问规则。如果发布者可见但下游路径为空，则接入检查已经通过；应排查该下游模块，而不是随意更改编码器。
运行收到的流
Callaba RTMP Server 是已配置的监听器和操作控制点：创建发布者与接收者访问、检查当前活动，并将选定流交给下一个运行任务。浏览器播放是独立的 Web Player 或 HLS 工作流；现代浏览器不能原生播放 RTMP URL。
后续步骤
如需配置接入工作流，请查看 Callaba RTMP Server。发送端测试请使用OBS RTMP 指南；传输边界请参阅RTMP 协议基础；若下一项任务是观看流，请参阅RTMP 播放器与浏览器播放。
