HTML5无法直接播放RTSP，防盗链必须在服务端协议转换环节实现；因浏览器不解析RTSP URL，前端video标签加属性无效，真正鉴权需在RTSP推流、转协议出口及WebRTC信令阶段完成。
HTML5 本身不支持 RTSP 协议，所以不存在“HTML5 播放 RTSP 的防盗链设置”这回事——你看到的所谓“HTML5 播 RTSP”，实际是服务端做了协议转换（比如转成 WebRTC、HLS 或 MSE + WebSocket 封装的 FLV），防盗链必须在转换环节或传输层做，而非在 <video> 标签里加属性。
为什么 <video> 标签无法直接播 RTSP 且不能防盗链
RTSP 是基于 TCP/UDP 的实时流控制协议，依赖 Session 状态和复杂信令（如 DESCRIBE、SETUP、PLAY），而 HTML5 <video> 只接受 HTTP(S) 上的静态文件（MP4）或标准流协议（HLS、DASH）。浏览器根本不解析 RTSP URL，src="rtsp://..." 会静默失败或触发下载行为。因此所有“前端防盗链”尝试（如改 referrerPolicy、加 crossorigin）都无效。
真正有效的防盗链位置：流媒体服务端与信令层
如果你用的是自建流媒体服务（如 SRS、Nginx-rtmp、ZLMediaKit、Janus），防盗链逻辑必须落在以下环节：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- RTSP 推流鉴权：在
on_connect或on_publish钩子中校验 token、IP 白名单或时间戳（例如 SRS 的auth_cache+ 自定义 HTTP 回调） - 协议转换出口鉴权：当 RTSP 被转成 WebRTC（
webrtc://）或 HTTP-FLV（http://.../live/xxx.flv）时，URL 中必须携带一次性签名参数，如?t=171xxxxxx&sign=abc123，服务端验证后再允许建立 WebSocket 连接或返回 FLV 头 - WebRTC 的 ICE/SDP 交换阶段插入鉴权：在生成 offer/answer 前，先向后端请求带权限的 SDP，否则拒绝返回 candidate
- 禁止裸露原始 RTSP 地址：确保 Nginx 或 CDN 不反向代理
rtsp://地址（它本就不能被代理），更不要把 RTSP URL 写死在前端 JS 里
前端能配合做的最小必要动作
前端唯一可控点，是避免泄露播放凭证，以及配合服务端完成动态 token 获取：
立即学习“前端免费学习笔记（深入）”；
- 播放 URL 必须由后端 API 动态返回（含时效签名），禁止前端拼接
stream_id+ 固定域名 - 使用
fetch()请求播放地址时，带上登录态凭证（如Authorizationheader 或withCredentials: true），让后端能关联用户身份 - 若走 WebRTC，用
RTCPeerConnection时禁用iceTransportPolicy: "all"，改用"relay"并确保 STUN/TURN 服务器本身也做了访问控制 - 不要在 DevTools Console 或 Network 面板中硬编码调试用的 token；生产环境关闭所有
console.log流地址的行为
最常被忽略的一点：很多团队花精力给 <video> 加 controlsList="nodownload"，却放任 WebRTC 的 getStats() 或 FLV 分片 URL 被抓包复用——防盗链成败不在前端标签，而在服务端每次连接是否做原子级鉴权。只要一次 token 复用没拦截，整条链就失效。
