html5播放rtsp怎么防盗链_html5rtsp防盗链设置法【安全】

html5无法直接播放RTSP，防盗链必须在服务端协议转换环节实现；因浏览器不解析RTSP URL，前端video标签加属性无效，真正鉴权需在RTSP推流、转协议出口及WebRTC信令阶段完成。

html5 本身不支持 RTSP 协议，所以不存在“HTML5 播放 RTSP 的防盗链设置”这回事——你看到的所谓“HTML5 播 RTSP”，实际是服务端做了协议转换（比如转成 WebRTC、HLS 或 MSE + websocket 封装的 FLV），防盗链必须在转换环节或传输层做，而非在 标签里加属性。

为什么 标签无法直接播 RTSP 且不能防盗链

RTSP 是基于 TCP/udp 的实时流控制协议，依赖 session 状态和复杂信令（如 DESCRIBE、SETUP、PLAY），而 HTML5 只接受 http(S) 上的静态文件（MP4）或标准流协议（HLS、dash）。浏览器根本不解析 RTSP URL，src="rtsp://..." 会静默失败或触发下载行为。因此所有“前端防盗链”尝试（如改 referrerPolicy、加 crossorigin）都无效。

真正有效的防盗链位置：流媒体服务端与信令层

如果你用的是自建流媒体服务（如 SRS、nginx-rtmp、ZLMediaKit、Janus），防盗链逻辑必须落在以下环节：

• 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() 请求播放地址时，带上登录态凭证（如 Authorization header 或 withCredentials: true），让后端能关联用户身份
• 若走 WebRTC，用 RTCPeerConnection 时禁用 iceTransportPolicy: "all"，改用 "relay" 并确保 STUN/TURN 服务器本身也做了访问控制
• 不要在 DevTools console 或 Network 面板中硬编码调试用的 token；生产环境关闭所有 console.log 流地址的行为

最常被忽略的一点：很多团队花精力给 加 controlsList="nodownload"，却放任 WebRTC 的 getStats() 或 FLV 分片 URL 被抓包复用——防盗链成败不在前端标签，而在服务端每次连接是否做原子级鉴权。只要一次 token 复用没拦截，整条链就失效。