尧图网站建设 
SRS 的 WHIP WebRTC 推流连不上怎么排查【免费下载链接】srsSRS 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用 OBS 或浏览器 WHIP 推流到远程 SRS 时经常遇到连不上信令请求发出去了但推流始终建不起来。根据 SRS 官方文档webrtc.md 的 Connection Failures 一节这类失败通常由两类原因造成HTTPS API 配置问题线上服务器必须用 HTTPS和UDP 端口不通防火墙/端口未放行导致媒体连不上。排查思路就是分两步验证先用 curl 打 WHIP 信令接口再用 nc 验证 UDP 媒体端口把问题定位到信令层还是媒体层。前提知道 WHIP 请求应该长什么样SRS 的 WHIP 推流接口定义如下见 http-api.md 的 WebRTC Publish 一节POST /rtc/v1/whip/?applivestreamlivestream Body in SDP, the Content-type is application/sdpSRS 会把 SDP answer 作为 HTTP 响应返回并且按 WHIP 规范返回的 HTTP 状态码是 201 而不是 200。answer 中会带一行 candidate指明客户端要连的 UDP 媒体端点例如文档示例acandidate:1 1 udp 2130706431 172.18.0.4 8000 typ host generation 0172.18.0.4 8000就是客户端实际要连的 UDP 地址和端口。记住这一行后面排查要同时检查信令接口是否通和candidate 指向的 UDP 端口是否通。第一步用 curl 测试 WHIP 信令接口是否可达文档给出的标准测试命令如下$(date %s)用于让每次 stream 名不重复curl http://localhost:1985/rtc/v1/whip/?ice-ufrag6pk11386ice-pwdl91z529147ri9163933p51c4applivestreamlivestream-$(date %s) \ -H Origin: http://localhost -H Referer: http://localhost \ -H Accept: */* -H Content-type: application/sdp \ -H User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) \ --data-raw $v0\r\nagroup:BUNDLE 0 1\r\nmaudio 9 UDP/TLS/RTP/SAVPF 111\r\ncIN IP4 0.0.0.0\r\nartcp:9 IN IP4 0.0.0.0\r\naice-ufrag:J8X7\r\naice-pwd:Dpq7/fW/osYcPeLsCW2Ek1JH\r\nasetup:actpass\r\namid:0\r\nasendonly\r\namsid:- audio\r\nartcp-mux\r\nartpmap:111 opus/48000/2\r\nassrc:3184534672 cname:stream\r\nmvideo 9 UDP/TLS/RTP/SAVPF 106\r\ncIN IP4 0.0.0.0\r\nartcp:9 IN IP4 0.0.0.0\r\naice-ufrag:J8X7\r\naice-pwd:Dpq7/fW/osYcPeLsCW2Ek1JH\r\nasetup:actpass\r\namid:1\r\nasendonly\r\namsid:- video\r\nartcp-mux\r\nartpmap:106 H264/90000\r\nassrc:512761356 cname:stream \ -v -k替换说明localhost:1985换成你的 SRS HTTP API 地址http_api默认监听 1985。文档同时说明测试 HTTPS 时把http://localhost替换为https://yourdomain.com即可。如果你用eipip或eipip:port查询参数强制指定 candidate也可以加在这个 URL 后面配合 CANDIDATE 一节 使用。如果对接的是 Oryx需要在 URL 中指定 secret文档示例为把/rtc/v1/whip?ice-ufrag改为/rtc/v1/whip?secretxxxice-ufrag。判断标准响应成功时HTTP 状态码应为 201body 中的 SDP answer 里应能看到acandidate:0 1 udp 2130706431 127.0.0.1 8000 typ host generation 0这样的 candidate 行文档示例为127.0.0.1你的环境里是 SRS 实际暴露的 IP 和 UDP 端口。如果这一步就失败连接被拒、TLS 握手失败、401 等问题在信令层检查 HTTPS 证书配置、API 端口是否可达。如果你给 WHIP/WHEP 开启了 RTC Bearer 认证SRS_HTTP_API_AUTH_RTC_BEARER_ENABLEDon则 curl 必须带Authorization: Bearer token头否则收到 401——这一点见 http-api.md 的认证一节。candidate 错误是大多数推流失败的根因信令通了但媒体连不上最常见的原因是candidate 不对。文档原话Please note thatcandidateis essential important, and most failure is caused by wrongcandidate, so be careful.candidate 必须是客户端能连得通的 SRS 侧 IP 地址它会写进 SDP answer 的 candidate 行里。可用的配置方式见 webrtc.md Config: Candidate配置里写固定 IP如candidate 192.168.3.6;用环境变量传入如candidate $CANDIDATE;配合CANDIDATE$(ifconfig en0 inet | grep inet | awk {print $2})macOS或CANDIDATE$(ifconfig eth0 | grep inet | awk {print $2})CentOS取值然后env CANDIDATE192.168.3.10 ./objs/srs -c conf/rtc.confcandidate *;或candidate 0.0.0.0;表示自动检测网卡 IP配合use_auto_detect_network_ip on;URL 上加?eipx如webrtc://192.168.3.6/live/livestream?eip192.168.3.6使用 HTTP API 的主机名作为 candidate需要api_as_candidates on;若主机名是域名还要resolve_api_domain on;注意文档标注 Firefox 不支持域名 candidate其中最快的办法是用eip参数同时修正 IP 和端口特别是 SRS 在负载均衡或代理后面时。文档给出的示例修正 IPhttp://localhost:1985/rtc/v1/whip/?applivestreamlivestreameip192.168.3.10修正 UDP 端口例如实际 UDP 是 18000http://localhost:1985/rtc/v1/whip/?applivestreamlivestreameip192.168.3.10:18000第二步用 nc 验证 UDP 媒体端口是否可达信令通了、candidate 也确认正确之后如果还是连不上下一步验证 candidate 指向的 UDP 端口。文档给出的测试命令是用 nc 向 SRS WHIP 服务器的 UDP 端口发送一个包echo -en \x00\x01\x00\x50\x21\x12\xa4\x42\x74\x79\x6d\x7a\x41\x51\x2b\x2f\x4a\x4b\x77\x52\x00\x06\x00\x0d\x36\x70\x6b\x31\x31\x33\x38\x36\x3a\x4a\x38\x58\x37\x00\x00\x00\xc0\x57\x00\x04\x00\x01\x00\x0a\x80\x2a\x00\x08\xda\xad\x1d\xce\xe8\x95\x5a\x83\x00\x24\x00\x04\x6e\x7f\x1e\xff\x00\x08\x00\x14\x56\x8f\x1e\x1e\x4f\x5f\x17\xf9\x2e\xa1\xec\xbd\x51\xd9\xa2\x27\xe4\xfd\xda\xb1\x80\x28\x00\x04\x84\xd3\x5a\x79 \ |nc -w 3 -u 127.0.0.1 8000 |od -Ax -c -t x1 |grep 000 \ echo Success || echo Failed执行前提这条命令需要在能访问到 SRS UDP 端口的机器上执行本地测试即 SRS 所在机器127.0.0.1 8000换成第一步 answer 中 candidate 行里的实际 IP 和端口。它只发送一个 UDP 包并等待应答不修改任何环境无副作用。SRS 5.0.191 会对此应答文档给出的预期输出示例标注为文档示例字节内容随环境不同会有差异判断依据是最后打印Success0000000 001 001 \0 ! 022 244 B t y m z A Q / 0000010 J K w R \0 006 \0 \r 6 p k 1 1 3 8 6 0000020 : J 8 X 7 \0 \0 \0 \0 \0 \b \0 001 376 0000030 ầ ** ** 027 \0 \b \0 024 206 263 ʼn ** 025 G 215 0000040 I 335 P ^ 7 } N ? 017 037 224 200 ( \0 004 0000050 303 250 272 0000054 Success输出SuccessUDP 端口通媒体链路层面 SRS 有响应。如果推流仍失败回头核对 candidate IP/端口与客户端实际网络路径是否一致。输出FailedUDP 包没有被应答通常是防火墙未放行 UDP 端口、端口映射错误或 SRS 的rtc_server未启用。网络不允许 UDP 时改用 WebRTC over TCP如果排查结果是客户端网络根本不通 UDPSRS 支持不依赖 TURN 的直接 TCP 传输webrtc.md WebRTC over TCP。相关配置项rtc_server.tcp.enabled、rtc_server.tcp.listen默认 8000文档建议用 80/443/8000/8080 这类常用端口便于过防火墙和负载均衡、rtc_server.protocoludp/tcp/all默认udp。用环境变量启动的示例把CANDIDATE换成服务器 IPdocker run --rm -it -p 8080:8080 -p 1985:1985 -p 8000:8000 \ -e CANDIDATE192.168.3.82 \ -e SRS_RTC_SERVER_TCP_ENABLEDon \ -e SRS_RTC_SERVER_PROTOCOLtcp \ -e SRS_RTC_SERVER_TCP_LISTEN8000 \ ossrs/srs:v5注意protocol tcp要求rtc_server.tcp.enabled on否则配置不生效。别忘了 HTTPS 这个前提文档明确本地localhost可以用 HTTP 测试但如果你用的是 Windows、远程 Linux 服务器或其他设备测试WHIP 推流必须使用 HTTPSWHEP 拉流仍可用 HTTP。启用 SRS 自带 HTTPS 见 http-api.md 的 HTTPS API 一节https_api配置或按同文 HTTP and HTTPS Proxy 一节用 Nginx 等反代终结 TLS。自签名证书在 Chrome 里输入thisisunsafe可以继续访问文档在 SFU 示例中给出的操作提示。验证整条链路排查完成后用文档自带的测试页做端到端确认conf/rtc.conf启用rtc_server和 vhost 的rtchttp_server目录默认指向./objs/nginx/html测试页源码在 whip.htmlWHIP 推流页http://localhost:1985/rtc/v1/whip/?applivestreamlivestream页面地址 whip.htmlWHEP 拉流页http://localhost:1985/rtc/v1/whep/?applivestreamlivestream页面地址 whep.html推流端在 WHIP 页发起推流、拉流端在 WHEP 页能看到画面即整条链路通了。另有一个已知限制需要知晓WebRTC 推流后开头 4-6 秒的音频可能缺失DVR/RTMP/HTTP-FLV 侧这是 RTCP Sender Report 建立音视频时间基准所需的已知机制限制文档标注为 known limitation 而非 bug见 webrtc.md Known Limitation: Initial Audio Loss。排查连不上时不要把现象误判成连接问题先确认推流是否其实已经建立。【免费下载链接】srsSRS 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 SRS 的 WHIP WebRTC 推流连不上怎么排查
SRS 的 WHIP WebRTC 推流连不上怎么排查【免费下载链接】srsSRS 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用 OBS 或浏览器 WHIP 推流到远程 SRS 时经常遇到连不上信令请求发出去了但推流始终建不起来。根据 SRS 官方文档webrtc.md 的 Connection Failures 一节这类失败通常由两类原因造成HTTPS API 配置问题线上服务器必须用 HTTPS和UDP 端口不通防火墙/端口未放行导致媒体连不上。排查思路就是分两步验证先用 curl 打 WHIP 信令接口再用 nc 验证 UDP 媒体端口把问题定位到信令层还是媒体层。前提知道 WHIP 请求应该长什么样SRS 的 WHIP 推流接口定义如下见 http-api.md 的 WebRTC Publish 一节POST /rtc/v1/whip/?applivestreamlivestream Body in SDP, the Content-type is application/sdpSRS 会把 SDP answer 作为 HTTP 响应返回并且按 WHIP 规范返回的 HTTP 状态码是 201 而不是 200。answer 中会带一行 candidate指明客户端要连的 UDP 媒体端点例如文档示例acandidate:1 1 udp 2130706431 172.18.0.4 8000 typ host generation 0172.18.0.4 8000就是客户端实际要连的 UDP 地址和端口。记住这一行后面排查要同时检查信令接口是否通和candidate 指向的 UDP 端口是否通。第一步用 curl 测试 WHIP 信令接口是否可达文档给出的标准测试命令如下$(date %s)用于让每次 stream 名不重复curl http://localhost:1985/rtc/v1/whip/?ice-ufrag6pk11386ice-pwdl91z529147ri9163933p51c4applivestreamlivestream-$(date %s) \ -H Origin: http://localhost -H Referer: http://localhost \ -H Accept: */* -H Content-type: application/sdp \ -H User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) \ --data-raw $v0\r\nagroup:BUNDLE 0 1\r\nmaudio 9 UDP/TLS/RTP/SAVPF 111\r\ncIN IP4 0.0.0.0\r\nartcp:9 IN IP4 0.0.0.0\r\naice-ufrag:J8X7\r\naice-pwd:Dpq7/fW/osYcPeLsCW2Ek1JH\r\nasetup:actpass\r\namid:0\r\nasendonly\r\namsid:- audio\r\nartcp-mux\r\nartpmap:111 opus/48000/2\r\nassrc:3184534672 cname:stream\r\nmvideo 9 UDP/TLS/RTP/SAVPF 106\r\ncIN IP4 0.0.0.0\r\nartcp:9 IN IP4 0.0.0.0\r\naice-ufrag:J8X7\r\naice-pwd:Dpq7/fW/osYcPeLsCW2Ek1JH\r\nasetup:actpass\r\namid:1\r\nasendonly\r\namsid:- video\r\nartcp-mux\r\nartpmap:106 H264/90000\r\nassrc:512761356 cname:stream \ -v -k替换说明localhost:1985换成你的 SRS HTTP API 地址http_api默认监听 1985。文档同时说明测试 HTTPS 时把http://localhost替换为https://yourdomain.com即可。如果你用eipip或eipip:port查询参数强制指定 candidate也可以加在这个 URL 后面配合 CANDIDATE 一节 使用。如果对接的是 Oryx需要在 URL 中指定 secret文档示例为把/rtc/v1/whip?ice-ufrag改为/rtc/v1/whip?secretxxxice-ufrag。判断标准响应成功时HTTP 状态码应为 201body 中的 SDP answer 里应能看到acandidate:0 1 udp 2130706431 127.0.0.1 8000 typ host generation 0这样的 candidate 行文档示例为127.0.0.1你的环境里是 SRS 实际暴露的 IP 和 UDP 端口。如果这一步就失败连接被拒、TLS 握手失败、401 等问题在信令层检查 HTTPS 证书配置、API 端口是否可达。如果你给 WHIP/WHEP 开启了 RTC Bearer 认证SRS_HTTP_API_AUTH_RTC_BEARER_ENABLEDon则 curl 必须带Authorization: Bearer token头否则收到 401——这一点见 http-api.md 的认证一节。candidate 错误是大多数推流失败的根因信令通了但媒体连不上最常见的原因是candidate 不对。文档原话Please note thatcandidateis essential important, and most failure is caused by wrongcandidate, so be careful.candidate 必须是客户端能连得通的 SRS 侧 IP 地址它会写进 SDP answer 的 candidate 行里。可用的配置方式见 webrtc.md Config: Candidate配置里写固定 IP如candidate 192.168.3.6;用环境变量传入如candidate $CANDIDATE;配合CANDIDATE$(ifconfig en0 inet | grep inet | awk {print $2})macOS或CANDIDATE$(ifconfig eth0 | grep inet | awk {print $2})CentOS取值然后env CANDIDATE192.168.3.10 ./objs/srs -c conf/rtc.confcandidate *;或candidate 0.0.0.0;表示自动检测网卡 IP配合use_auto_detect_network_ip on;URL 上加?eipx如webrtc://192.168.3.6/live/livestream?eip192.168.3.6使用 HTTP API 的主机名作为 candidate需要api_as_candidates on;若主机名是域名还要resolve_api_domain on;注意文档标注 Firefox 不支持域名 candidate其中最快的办法是用eip参数同时修正 IP 和端口特别是 SRS 在负载均衡或代理后面时。文档给出的示例修正 IPhttp://localhost:1985/rtc/v1/whip/?applivestreamlivestreameip192.168.3.10修正 UDP 端口例如实际 UDP 是 18000http://localhost:1985/rtc/v1/whip/?applivestreamlivestreameip192.168.3.10:18000第二步用 nc 验证 UDP 媒体端口是否可达信令通了、candidate 也确认正确之后如果还是连不上下一步验证 candidate 指向的 UDP 端口。文档给出的测试命令是用 nc 向 SRS WHIP 服务器的 UDP 端口发送一个包echo -en \x00\x01\x00\x50\x21\x12\xa4\x42\x74\x79\x6d\x7a\x41\x51\x2b\x2f\x4a\x4b\x77\x52\x00\x06\x00\x0d\x36\x70\x6b\x31\x31\x33\x38\x36\x3a\x4a\x38\x58\x37\x00\x00\x00\xc0\x57\x00\x04\x00\x01\x00\x0a\x80\x2a\x00\x08\xda\xad\x1d\xce\xe8\x95\x5a\x83\x00\x24\x00\x04\x6e\x7f\x1e\xff\x00\x08\x00\x14\x56\x8f\x1e\x1e\x4f\x5f\x17\xf9\x2e\xa1\xec\xbd\x51\xd9\xa2\x27\xe4\xfd\xda\xb1\x80\x28\x00\x04\x84\xd3\x5a\x79 \ |nc -w 3 -u 127.0.0.1 8000 |od -Ax -c -t x1 |grep 000 \ echo Success || echo Failed执行前提这条命令需要在能访问到 SRS UDP 端口的机器上执行本地测试即 SRS 所在机器127.0.0.1 8000换成第一步 answer 中 candidate 行里的实际 IP 和端口。它只发送一个 UDP 包并等待应答不修改任何环境无副作用。SRS 5.0.191 会对此应答文档给出的预期输出示例标注为文档示例字节内容随环境不同会有差异判断依据是最后打印Success0000000 001 001 \0 ! 022 244 B t y m z A Q / 0000010 J K w R \0 006 \0 \r 6 p k 1 1 3 8 6 0000020 : J 8 X 7 \0 \0 \0 \0 \0 \b \0 001 376 0000030 ầ ** ** 027 \0 \b \0 024 206 263 ʼn ** 025 G 215 0000040 I 335 P ^ 7 } N ? 017 037 224 200 ( \0 004 0000050 303 250 272 0000054 Success输出SuccessUDP 端口通媒体链路层面 SRS 有响应。如果推流仍失败回头核对 candidate IP/端口与客户端实际网络路径是否一致。输出FailedUDP 包没有被应答通常是防火墙未放行 UDP 端口、端口映射错误或 SRS 的rtc_server未启用。网络不允许 UDP 时改用 WebRTC over TCP如果排查结果是客户端网络根本不通 UDPSRS 支持不依赖 TURN 的直接 TCP 传输webrtc.md WebRTC over TCP。相关配置项rtc_server.tcp.enabled、rtc_server.tcp.listen默认 8000文档建议用 80/443/8000/8080 这类常用端口便于过防火墙和负载均衡、rtc_server.protocoludp/tcp/all默认udp。用环境变量启动的示例把CANDIDATE换成服务器 IPdocker run --rm -it -p 8080:8080 -p 1985:1985 -p 8000:8000 \ -e CANDIDATE192.168.3.82 \ -e SRS_RTC_SERVER_TCP_ENABLEDon \ -e SRS_RTC_SERVER_PROTOCOLtcp \ -e SRS_RTC_SERVER_TCP_LISTEN8000 \ ossrs/srs:v5注意protocol tcp要求rtc_server.tcp.enabled on否则配置不生效。别忘了 HTTPS 这个前提文档明确本地localhost可以用 HTTP 测试但如果你用的是 Windows、远程 Linux 服务器或其他设备测试WHIP 推流必须使用 HTTPSWHEP 拉流仍可用 HTTP。启用 SRS 自带 HTTPS 见 http-api.md 的 HTTPS API 一节https_api配置或按同文 HTTP and HTTPS Proxy 一节用 Nginx 等反代终结 TLS。自签名证书在 Chrome 里输入thisisunsafe可以继续访问文档在 SFU 示例中给出的操作提示。验证整条链路排查完成后用文档自带的测试页做端到端确认conf/rtc.conf启用rtc_server和 vhost 的rtchttp_server目录默认指向./objs/nginx/html测试页源码在 whip.htmlWHIP 推流页http://localhost:1985/rtc/v1/whip/?applivestreamlivestream页面地址 whip.htmlWHEP 拉流页http://localhost:1985/rtc/v1/whep/?applivestreamlivestream页面地址 whep.html推流端在 WHIP 页发起推流、拉流端在 WHEP 页能看到画面即整条链路通了。另有一个已知限制需要知晓WebRTC 推流后开头 4-6 秒的音频可能缺失DVR/RTMP/HTTP-FLV 侧这是 RTCP Sender Report 建立音视频时间基准所需的已知机制限制文档标注为 known limitation 而非 bug见 webrtc.md Known Limitation: Initial Audio Loss。排查连不上时不要把现象误判成连接问题先确认推流是否其实已经建立。【免费下载链接】srsSRS 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考