Mediamtx RTSP 路径排障指南:SETUP 请求报 400/401/404 的 5 种典型症状【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx客户端向 Mediamtx 发出 RTSP SETUP 请求却收到报错时,问题几乎都集中在同一个点上:Mediamtx RTSP 路径没有对上服务器期望的样子。下面先给你一张对号入座的对照表,再按三种会实际撞上的场景拆开展开,最后用一套三步自查流程收尾。先看这张表:30 秒对上号响应码日志关键字最可能的原因400invalid path路径为空,或以/之外的字符开头401挑战-重试循环没带凭证,或用户/IP/权限对不上404no stream available路径本身合法,但上面没有正在发布的流461Unsupported Transport客户端请求的传输协议不在rtspTransports列表里先纠正一个常见误解:在 mediamtx 的 RTSP 实现里,认证失败一律返回 401——internal/servers/rtsp/conn.go 里的handleAuthError只会构造 401 响应,不存在 403 分支。所以看到 401 时,别去猜账户被封,只需要区分没带凭证和凭证错误两种情况。场景一:400 invalid path ,URL 写错了你会看到什么:客户端拿到 400 Bad Request,服务端日志里记着invalid path。为什么会这样:internal/servers/rtsp/session.go 的onSetup处理器第一件事就是检查路径——长度为 0,或者第一个字符不是/,直接返回 400;通过后把开头的斜杠剥掉,用剩下的部分当作路径名去匹配流。注意同样的检查也存在于onDescribe(读流协商)和onAnnounce(发布流)里,所以读写两侧都会以同样方式失败。三种典型错法:rtsp://host:8554/:斜杠后面是空的rtsp://host:8554cam1:路径前漏了斜杠客户端配置里只填了服务器地址,把路径留空了怎么处理:写成rtsp://host:8554/cam1这种形式。斜杠后的部分要和 mediamtx.yml 里paths段的路径名一一对应,默认监听端口是 8554(rtspAddress: :8554);如果开了 RTSPS 加密变体,端口则是 8322。场景二:401 Unauthorized,RTSP 认证配置没对上你会看到什么:客户端先收到一次带挑战信息的 401,补上密码后仍然 401。为什么会这样:这是一个两步协商。第一次请求不带凭证时,服务端发 401 挑战、提示重新携带凭证发起请求——这一步是正常握手,不算错误;第二次请求里凭证如果不对,401 就是最终结果,同样见 conn.go 的handleAuthError。凭证判定逻辑在 internal/auth/manager.go,它依次核对用户名、密码、IP 白名单和权限。怎么处理:核对 mediamtx.yml 中的认证配置:authMethod: internal authInternalUsers: - user: any pass: ips: [] permissions: - action: read path: - action: publish path:逐项检查:客户端提供的用户/密码,是否真的存在于authInternalUsers里;ips限制是否匹配请求来源 IP?前面挂反代时必须配置rtspTrustedProxies,否则服务端看到的是代理 IP 而不是真实客户端,IP 校验必然失败——这就是为什么要改;权限够不够:读流需要action: read,且path字段留空(任意路径)或恰好匹配目标路径;rtspAuthMethods默认就是[basic],digest只是为兼容保留,默认不用动。场景三:404,Mediamtx 404 排查你会看到什么:路径写法完全正确,却收到 404 Not Found。为什么会这样:onSetup的播放分支会调用AddReader,如果该路径当前没有流在发布,就返回PathNoStreamAvailableError,响应码被设为 404(位置同前,见 session.go)。也就是说路径本身是合法的,只是上面没有东西可读。怎么处理:对照发布端的路径名和读流 URL 里的路径名,逐字符一致,大小写敏感,末尾别多字符;如果发布端用的是source:配置的静态源,先确认这个源真的活着,源挂了同样表现为 404;读流成功时日志会记[session xxx] is reading from path cam1, with tcp, H264,用这行日志反查路径是否真的匹配上了。进阶:把路径写得灵活的两种做法正则路径名:在paths段里,路径名可以用~前缀写成正则,比如~^cam会匹配所有以 cam 开头的路径,all_others则兜底所有没被其他条目命中的路径。相当于给一批流套上同一套规则,不用逐个建条目。按需发布:把路径设为source: publisher并配置runOnDemand(一条外部命令),mediamtx 只会在有客户端请求时才启动流,等没有读取者再过runOnDemandCloseAfter时长后释放;配合runOnDemandRestart自动重启、runOnDemandStartTimeout限定启动等待时间,能省下空转的资源。完整用法见 docs/2-features/14-on-demand-publishing.md。三步自查流程对码查表:用开头那张表,把响应码和日志关键字对上,确定属于哪个场景;开 debug 看会话日志:在 mediamtx.yml 里把logLevel调成debug,用logDestinations/logFile把日志落到文件,然后找所有带[session的行,核对请求路径和认证结果;两头路径互查:确认发布端的路径名和读流端 URL 里的路径完全一致,并且发布端确实在线(静态源连接成功,或存在一个 publisher 会话)。三步之后仍定位不到,再对照 docs/2-features/06-authentication.md 检查认证方式选型,并逐一核对rtsp相关全局参数(传输协议、加密方式、地址端口)。【免费下载链接】mediamtxReady-to-use Media-over-QUIC / SRT / WebRTC / RTSP / RTMP / LL-HLS / MPEG-TS / RTP live media server and media proxy that allows to read, publish, proxy, record and playback real-time video and audio streams.项目地址: https://gitcode.com/GitHub_Trending/me/mediamtx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考