HTML5无法原生播放RTSP流，鉴权必须在服务端实现；前端仅能安全传递凭证，不可执行鉴权。可行方案包括HLS、WebRTC或MSE+WebSocket，均需服务端完成认证闭环。
HTML5 无法原生播放 RTSP 流，鉴权无从谈起
直接说结论：RTSP 协议本身不被任何主流浏览器支持，HTML5 的 标签只支持 MP4、WebM、Ogg 等基于 HTTP 的媒体格式。所谓“HTML5 播放 RTSP”，本质是绕过浏览器限制，用服务端或 WebAssembly 做协议转换。鉴权必须落在这个转换环节，而非前端 HTML 或 JS 中。
RTSP 鉴权实际发生在流媒体服务器或代理层
RTSP URL 常见形式如 rtsp://user:pass@192.168.1.100:554/stream，但浏览器根本不会发起 RTSP 请求，所以这种 Basic Auth 写法在前端无效。真正起作用的鉴权点有：
- 流媒体服务器（如
Wowza、FFmpeg + nginx-rtmp-module、Mediamtx）对 RTSP 拉流请求做认证 - 中间代理服务（如自建 Node.js/Go 服务）在转发 RTSP 流前校验 token、JWT 或 session
- WebSocket 或 WebRTC 信令阶段完成身份核验，再动态生成带时效的 RTSP 拉流地址（例如
rtsp://token=abc123@.../stream）
注意：Mediamtx 支持 externalAuthenticationHook 配置项，可调用你自己的 HTTP 接口做鉴权；nginx-rtmp-module 则需配合 on_connect 或 on_play 回调脚本。
前端能做的只有“安全传递凭证”，不是“执行鉴权”
前端唯一可控的安全动作，是避免硬编码密码、防止凭证泄露。常见错误包括：
立即学习“前端免费学习笔记（深入）”；
- 在 JS 里拼接
rtsp://admin:12345@...—— 密码明文暴露在源码中 - 把鉴权 token 直接写进 HTML 属性或全局变量，易被调试器读取
- 用 GET 参数传 token（如
/player.html?token=xxx），可能被日志或代理缓存
可行做法：
- 通过
fetch()向后端申请一个短期有效的播放令牌（如 5 分钟有效期），后端返回的是已封装好的 WebRTC offer 或 HLS/MSE 播放地址（如https://api.example.com/stream/abc123.m3u8） - 使用
Secure+HttpOnlyCookie 存储会话，由后端在生成播放页时注入一次性的signedUrl - 若用 WebRTC，用
RTCPeerConnection连接前，先用fetch()向信令服务提交room_id和user_token完成准入校验
替代方案选型：别硬刚 RTSP，优先走标准 Web 路径
真正落地时，几乎没人让浏览器直连 RTSP。更健壮的做法是协议下沉、能力上移：
-
HLS：用
ffmpeg或gstreamer将 RTSP 转为.m3u8+.ts，后端加一层 token 鉴权中间件（如 Nginx 的auth_request模块拦截.m3u8请求） -
WebRTC：用
mediasoup或janus-gateway接入 RTSP 源，所有信令和 ICE 协商都走 HTTPS，天然携带 session 或 JWT -
MSE + WebSocket：用
ffmpeg -f rtsp解码推送到 WebSocket，前端用MediaSource拼帧 —— 鉴权放在 WebSocket 握手阶段（Sec-WebSocket-Protocol或自定义 header）
关键点：所有鉴权逻辑必须在服务端闭环，前端只负责展示和交互。任何试图在浏览器里解析 RTSP 或“模拟”鉴权的行为，都是把密码和逻辑暴露给用户。
