SRS 连接失败怎么修Metahuman-Stream 三层排障完整指南【免费下载链接】metahuman-streamReal time interactive streaming digital human项目地址: https://gitcode.com/GitHub_Trending/me/metahuman-stream部署数字人流式项目 Metahuman-Stream 时SRS 连接失败是最常见的坑WHIP 推流没有响应或者播放端拉不到画面。本文按服务、网络、配置一致性三层拆开数据流并给出可验证的命令读完你能自己定位断点。先看懂数据流SRS 是链路里的流媒体中继可以理解为中转站数字人服务把生成的音视频经 WHIPWebRTC 推流协议相当于寄包裹推给它播放端再从 SRS 的播放入口/rtc/v1/whep/取流。端口好比门牌号1985 是 SRS WebRTC API 的协商门牌媒体数据本身走 UDP 大端口段这条传输通道。所以连接只有三处会断项目服务器到 SRS、中间网络、SRS 到播放页。 三层定位法第一层服务层——SRS 是否真正启动SRS 进程在推流入口却不通现象进程存在但 1985 连不上。原因SRS 配置文件未启用 webrtc 段1985 API 根本没开。修复检查 SRS 配置的 webrtc 段与启动日志。如何确认 1985 端口真的在监听现象服务起来了推流仍失败。原因端口冲突或监听地址写成了 127.0.0.1。修复用 netstat 确认 1985 的监听状态与绑定地址。第二层网络层——端口能不能通UDP 媒体端口段一次配齐现象推流握手通过播放端却黑屏或卡住。原因信令走 1985音视频数据却依赖 UDP 1-65535 这段传输通道防火墙只放 1985 通道就是关着的。修复在 SRS 所在服务器放行 UDP 1-65535。防火墙、NAT 与 HTTPS 场景项目自身 Web 服务默认监听 8010TCPSRS API 是 1985跨机部署时两个都要放行。NAT 场景可配合--stun参数STUN 帮助定位公网地址。SRS WebRTC 端口配置若启用 HTTPS还要核对证书路径与有效期测试环境先走 HTTP 更省事。第三层配置一致性层——两端是否一致push_url 路径与 SDK 是否对得上项目默认推流地址是http://localhost:1985/rtc/v1/whip/?applivestreamlivestream。改端口时config.yaml 与前端 web/srs.sdk.js 必须同步修改push_url: http://SRS地址:1985/rtc/v1/whip/?applivestreamlivestreamapp、stream、协议一一对应applive与streamlivestream要和播放页使用的完全一致两端的 http/https 协议也要相同差一个字符都找不到流。 一次验证命令在 SRS 所在服务器依次执行三条curl -X POST http://localhost:1985/rtc/v1/whip/?applivestreamtest——验证 WHIP 推流入口是否可达正常输出是以v0开头的 SDP 应答connection refused 说明服务未监听。netstat -tlnp | grep 1985——验证 1985 是否被监听及归属进程正常输出一行0.0.0.0:1985且进程为 srs。ss -ulnp | grep srs——验证 SRS 是否绑定了 UDP 媒体端口段正常输出多条属于 srs 的 UDP 端口记录。小结最高频的坑是配置不一致改了push_url忘了前端或前端漏改——两端 API 路径、app、stream、协议必须完全一致。放行了 TCP 1985 不等于完事UDP 1-65535 媒体段才是真实传输通道信令通了没它照样黑屏。先确认 SRS 的 webrtc 配置已启用否则 1985 API 根本不存在。把 SRS 地址集中在push_url统一维护排障时开启详细日志。建议先单独打通一条 WebRTC 流curl 推流、播放端验证再接入数字人仍不通时可查阅项目文档与社区讨论。【免费下载链接】metahuman-streamReal time interactive streaming digital human项目地址: https://gitcode.com/GitHub_Trending/me/metahuman-stream创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SRS 连接失败怎么修？Metahuman-Stream 三层排障完整指南
SRS 连接失败怎么修Metahuman-Stream 三层排障完整指南【免费下载链接】metahuman-streamReal time interactive streaming digital human项目地址: https://gitcode.com/GitHub_Trending/me/metahuman-stream部署数字人流式项目 Metahuman-Stream 时SRS 连接失败是最常见的坑WHIP 推流没有响应或者播放端拉不到画面。本文按服务、网络、配置一致性三层拆开数据流并给出可验证的命令读完你能自己定位断点。先看懂数据流SRS 是链路里的流媒体中继可以理解为中转站数字人服务把生成的音视频经 WHIPWebRTC 推流协议相当于寄包裹推给它播放端再从 SRS 的播放入口/rtc/v1/whep/取流。端口好比门牌号1985 是 SRS WebRTC API 的协商门牌媒体数据本身走 UDP 大端口段这条传输通道。所以连接只有三处会断项目服务器到 SRS、中间网络、SRS 到播放页。 三层定位法第一层服务层——SRS 是否真正启动SRS 进程在推流入口却不通现象进程存在但 1985 连不上。原因SRS 配置文件未启用 webrtc 段1985 API 根本没开。修复检查 SRS 配置的 webrtc 段与启动日志。如何确认 1985 端口真的在监听现象服务起来了推流仍失败。原因端口冲突或监听地址写成了 127.0.0.1。修复用 netstat 确认 1985 的监听状态与绑定地址。第二层网络层——端口能不能通UDP 媒体端口段一次配齐现象推流握手通过播放端却黑屏或卡住。原因信令走 1985音视频数据却依赖 UDP 1-65535 这段传输通道防火墙只放 1985 通道就是关着的。修复在 SRS 所在服务器放行 UDP 1-65535。防火墙、NAT 与 HTTPS 场景项目自身 Web 服务默认监听 8010TCPSRS API 是 1985跨机部署时两个都要放行。NAT 场景可配合--stun参数STUN 帮助定位公网地址。SRS WebRTC 端口配置若启用 HTTPS还要核对证书路径与有效期测试环境先走 HTTP 更省事。第三层配置一致性层——两端是否一致push_url 路径与 SDK 是否对得上项目默认推流地址是http://localhost:1985/rtc/v1/whip/?applivestreamlivestream。改端口时config.yaml 与前端 web/srs.sdk.js 必须同步修改push_url: http://SRS地址:1985/rtc/v1/whip/?applivestreamlivestreamapp、stream、协议一一对应applive与streamlivestream要和播放页使用的完全一致两端的 http/https 协议也要相同差一个字符都找不到流。 一次验证命令在 SRS 所在服务器依次执行三条curl -X POST http://localhost:1985/rtc/v1/whip/?applivestreamtest——验证 WHIP 推流入口是否可达正常输出是以v0开头的 SDP 应答connection refused 说明服务未监听。netstat -tlnp | grep 1985——验证 1985 是否被监听及归属进程正常输出一行0.0.0.0:1985且进程为 srs。ss -ulnp | grep srs——验证 SRS 是否绑定了 UDP 媒体端口段正常输出多条属于 srs 的 UDP 端口记录。小结最高频的坑是配置不一致改了push_url忘了前端或前端漏改——两端 API 路径、app、stream、协议必须完全一致。放行了 TCP 1985 不等于完事UDP 1-65535 媒体段才是真实传输通道信令通了没它照样黑屏。先确认 SRS 的 webrtc 配置已启用否则 1985 API 根本不存在。把 SRS 地址集中在push_url统一维护排障时开启详细日志。建议先单独打通一条 WebRTC 流curl 推流、播放端验证再接入数字人仍不通时可查阅项目文档与社区讨论。【免费下载链接】metahuman-streamReal time interactive streaming digital human项目地址: https://gitcode.com/GitHub_Trending/me/metahuman-stream创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考