HTML视频无法真正防投屏，关键在于保护密钥获取链路和播放上下文：需动态校验Referer+JWT、禁用缓存、每分片独立IV、时效性密钥接口，并在HLS.js中动态注入请求头。
HTML 视频本身无法真正“防投屏”，但你可以让投屏行为失去意义——关键不是拦住投屏动作，而是确保投屏出去的内容无法被复用、下载或二次分发。m3u8 地址防不住，也不该指望它被防住；真正要保护的是密钥获取链路和播放上下文。
为什么直接防 m3u8 地址注定失败
m3u8 是纯文本索引文件，浏览器必须完整加载它才能解析出 TS 分片地址。只要用户能打开页面，开发者工具 Network 面板里就能看到 m3u8 请求，连带里面的 #EXT-X-KEY:URI=... 也能直接点开。这不是漏洞，是 HLS 协议的设计前提。
- 任何“隐藏 m3u8 URL”的尝试（比如 base64 编码、JS 拼接）都只是增加一丁点阅读门槛，对抓包工具无效
- 所谓“防投屏”，本质是防“投屏后被人录屏/扒走/批量下载”，而不是防“把当前画面投到电视上”
- Chrome/Firefox 的投屏功能走的是系统级 Cast API，前端 JavaScript 完全无权拦截或感知
HLS.js 播放时如何切断密钥可复用路径
多数盗链脚本靠解析 m3u8 中的 URI 字段直接请求密钥，所以重点不是藏 m3u8，而是让这个 URI 指向一个**每次请求都校验上下文**的接口，且返回内容不可缓存、不可跨会话复用。
- 密钥接口必须校验
Referer+Authorization头（如 JWT），且Referer必须精确匹配你自己的域名，不能只校验子域名 - 响应头强制加
Cache-Control: no-store, no-cache, must-revalidate，禁用 CDN 和浏览器缓存 - 密钥 URI 应包含时效参数，例如
/keys/abc123.key?token=xyz&ts=1729382760，服务端验证ts是否在 5 分钟窗口内 - 不要在 m3u8 里写死密钥地址，而是在 HLS.js 的
Hls.Events.KEY_LOADED事件中动态改写keyLoader，注入额外 header 或重写 URL
投屏场景下最易被忽略的破绽：IV 和密钥复用
很多团队用了 AES-128 加密，却把 IV 写成固定值（如 IV=0x00000000000000000000000000000000），这等于把锁芯换成透明塑料——攻击者拿到一个密钥 + 固定 IV，就能解出所有同密钥的 TS 分片。
立即学习“前端免费学习笔记（深入）”；
- 务必为每个 TS 分片生成独立
IV，格式应为IV=0x<16-byte-hex>，且与分片序号或时间戳强关联 - 避免使用
ffprobe可直接提取的静态密钥方案；改用服务端动态派生，前端 JS 不参与密钥计算，只做 token 透传 - 测试时用
curl -v "https://your.com/keys/xxx.key?token=..."直接请求密钥，确认返回 403 或 401（而非 200）才说明防护生效
真正有效的防护不在 m3u8 文件里，而在你调用密钥接口那一刻——那个请求是否绑定了设备指纹、是否有时效窗口、是否拒绝了非预期 Referer、是否禁止了缓存。这些细节一旦漏掉一环，整个加密就形同虚设。
