Mediamtx RTSP SETUP 路径问题排查指南400、401、404 快速定位【免费下载链接】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 这一步客户端弹出 400、401 或 404流就是放不出来。Mediamtx 是一款支持 RTSP、RTMP、SRT、WebRTC 等多种协议的多协议媒体服务器而 SETUP 请求的路径处理正是新手最容易踩坑的环节。下面按先对照症状、再看原理的顺序带你把问题一次排清楚。症状速查先对着表格找原因别急着翻源码。客户端返回什么、日志里写了什么基本就能定位方向你看到的现象最可能的原因第一反应动作400 Bad Request日志含invalid path请求路径为空或没以/开头核对完整 URL确认是rtsp://host:8554/stream名这种形式401 Unauthorized没带凭证或用户名/密码错误检查认证配置和客户端填入的凭证是否一致403 Forbidden凭证正确但该用户没有这个路径的读取权限查看用户permissions里read对应的path范围404 Not Found这个路径下当前没有正在发布的流确认发布者正常且路径名和发布端完全一致461 Unsupported TransportSETUP 要求的传输协议如 tcp被禁用了检查 mediamtx.yml 中rtspTransports是否包含tcp客户端发出 SETUP 后服务器依次查了什么Mediamtx 的 SETUP 处理逻辑在 internal/servers/rtsp/session.go 的onSetup函数里顺序是这样的查路径格式路径不能为空且必须以/开头。不满足直接回 400日志写invalid pathif len(ctx.Path) 0 || ctx.Path[0] ! / { return base.Response{StatusCode: base.StatusBadRequest}, nil, fmt.Errorf(invalid path) }查传输协议如果 SETUP 里写的是 TCP而配置里没开 TCP回 461。UDP、组播被禁用的情况则由底层库提前拦截。查权限把用户名、密码、来源 IP 交给认证模块校验不过就回 401/403。查流是否存在播放场景下如果这个路径没有正在发布的流回 404内部对应PathNoStreamAvailableError。全部通过建立 RTP 传输会话返回 200后续进入 PLAY。记住这条顺序后面每个错误码都能对号入座。RTSP 返回 400先核对路径格式看到 400 时先检查请求 URL 本身。最常见的情况是路径段为空或粘连比如rtsp://host:8554没写路径和rtsp://host:8554stream1漏了斜杠。正确的形态是rtsp://host:8554/stream1其中stream1会去掉开头的/后与 Mediamtx 配置里的路径名匹配。再确认路径里有没有奇怪字符空格、中文、多余的问号。如果你用了查询参数问号后面的部分会被当作 Query 单独处理路径本体要在问号之前闭合。最后看一眼服务器日志里是否有invalid path有的话就是格式问题无疑如果日志是其他报错文本再按 400 的其他分支排查比如流拉起来时解码或封装出错那属于流本身的问题而不是路径问题。401 / 403按凭证 → 权限两步走看到 401 时先检查客户端到底有没有把凭证发出去。有些播放器要手动填用户名密码有些会自动处理 Basic 认证先确认这一步没漏。再确认用户名和密码和 Mediamtx 配置里的authInternalUsers完全一致注意区分内部认证、外部 HTTP 认证和 JWT 三种模式不同模式下凭证的含义不一样详细规则见 docs/2-features/06-authentication.md。如果凭证确认无误仍然被拒就是权限问题403 的典型场景。最后去核对用户的permissions配置action: read下面的path字段如果指定了具体路径其他路径一律拒绝留空才表示任意路径。改完配置后等文件监听自动生效再重连即可。404 Not Found流不存在先查发布端看到 404 时先检查发布端是不是真的在推流发布者连的是不是同一台 Mediamtx、发布用的路径名和你拉流用的路径名是否一字不差大小写也算。再确认拉流时机——如果发布者断开了、或者该路径配成了按需启动但命令没跑起来路径上就没有可用流SETUP 自然回 404。最后借助控制面验证调用 docs/5-references/2-control-api.md 里描述的接口查看该路径的 source 是否为none。如果 API 显示有 source 但客户端还是 404多半是发布端刚断连的竞态重连一次即可。进阶路径别名与 on-demand 动态发布两个常用的进阶手段可以覆盖大部分路径对不上的场景。前者是给远程流起一个好记的名字后者是没人看就先不推有人来看再启动paths: cam1: source: rtsp://192.168.1.100:554/stream nvr: runOnDemand: sh start_nvr.shcam1就是一个路径别名客户端用rtsp://host:8554/cam1拉流实际源在远端摄像头上。nvr则配了runOnDemand当第一次有读者包括 RTSP SETUP请求这个路径时Mediamtx 先执行脚本把流拉起来读者在超时时间内等待没人看时再用runOnDemandCloseAfter自动收尾。完整选项说明见 docs/2-features/14-on-demand-publishing.md。日志排查调级别、搜关键词排路径问题离不开日志。在 mediamtx.yml 里把logLevel从info调到debug并让logDestinations同时输出到[stdout, file]logFile指定落盘文件方便事后翻查。恢复现场后重点搜三类关键词invalid path路径格式问题的铁证[RTSP session开头的行每条会话日志都带这个前缀顺着同一个 session 前缀看完整生命周期created by ...到destroyed: ...is reading from path这行出现说明 SETUP、PLAY 全走通了流正常读起。一条典型的成功日志长这样INF: [RTSP session a1b2c3d4] is reading from path cam1, with tcp, H264, MPEG-4 Audio。如果你搜到了 404 对应会话的destroyed: ...后面那段错误文本就是最终结论。发布前自查清单上线前过一遍这五条绝大多数 SETUP 路径问题都能提前避免拉流 URL 形如rtsp://host:8554/路径名路径以/开头且无多余字符发布端和拉流端的路径名完全一致且发布者此刻确实在推流可用控制 API 确认rtspTransports里包含客户端要用的传输协议tcp / udp / 组播开了认证时凭证已填对且用户read权限覆盖目标路径日志级别设为info以上并落盘确认能搜到is reading from path这一行。【免费下载链接】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），仅供参考