HTML视频无法真正防投屏，但可通过动态生成带签名、时效和会话绑定的代理地址，使投屏端因鉴权失败而黑屏或403；禁用右键等前端手段无效，核心在于服务端严格校验签名、时间戳与用户身份，并禁止缓存、校验Referer辅助防护。
HTML 视频无法真正“防投屏”，但你可以让投屏行为失效或受限——关键不是阻止用户点 Cast 按钮，而是确保被投出去的内容无法播放。核心思路是：投屏时 Chrome 默认投整个标签页或桌面，但如果视频源是动态代理地址（带签名、短时效、绑定会话），那么电视端加载该地址时会因鉴权失败而黑屏或 403。
为什么直接给 <video src="xxx.mp4"> 会导致投屏失控
Chrome 浏览器的 Cast 功能在投屏时，会把当前页面中 <video> 标签的 src 属性值原样发给 Chromecast 设备。如果这个 URL 是公开可访问的 S3 预签名链接、CDN 直链或本地文件路径，电视端就能独立请求并播放；一旦链接泄露或过期策略宽松，投屏就等于变相外泄。
- 用户右键“投射到设备” → Chromecast 向
/video/abc123.mp4?token=xxx发起 GET 请求 - 若该 URL 不校验 referer、不绑定 session、有效期长达 1 小时，电视端必然能播
- 前端禁用右键、隐藏 DOM、混淆 JS 变量名，对 Cast 行为完全无效
Node.js 必须生成带上下文的代理地址，而非直出视频路径
你不能把 S3 或本地视频路径拼进 HTML 里返回给前端，而应在 Node.js 中提供一个受控接口（如 /api/play/:id），由它动态生成仅本次会话有效的流式代理地址。这个地址必须包含：videoId、userId、timestamp、signature，且服务端需在每次请求时实时校验。
- 前端调用
fetch("/api/play/vid_001")，携带 JWT 或 session cookie - 后端验证用户权限后，生成类似
/proxy/stream?vid=vid_001&t=1734645600&s=abc123def456&u=user_xyz的地址 -
/proxy/stream路由必须做三件事：检查t是否在 5 分钟内、s是否匹配hmac(videoId+userId+t, secret)、u是否与当前会话一致 - 校验失败直接
res.status(403).end()；成功则用pipe()流式转发 S3 响应，不重定向
投屏失败的关键配置：禁止缓存 + 强制校验 Referer（辅助手段）
即使做了签名校验，Chrome 投屏有时会复用已缓存的响应头或跳过部分鉴权逻辑。为堵住这个缝隙，你需要在代理响应中明确禁止中间缓存，并在 Nginx 或 Node 层加 Referer 白名单（仅允许你的域名）。
立即学习“前端免费学习笔记（深入）”；
- Node.js 中设置：
res.setHeader("Cache-Control", "no-store, must-revalidate") - Nginx 配置示例（针对
/proxy/stream）：valid_referers yourdomain.com; if ($invalid_referer) { return 403; } - 注意：
Referer可伪造，仅作辅助；主防线仍是签名+时效+session 绑定 - 不要依赖
X-Forwarded-For或 IP 限流——NAT 环境下大量用户共享出口 IP
真正防不住的场景和你该接受的事实
如果你的服务需要支持 Chrome 投屏，又希望内容绝对不外泄，目前没有银弹。以下情况你无法拦截：
- 用户开启“投射整个桌面” → 电视端看到的是你网页的实时画面，和视频地址无关
- 用户用手机录屏投屏画面 → 这属于物理层截取，任何 Web 防护都无效
- 用户在电脑上用 OBS 截取浏览器窗口再推流 → 同理，服务端无感知
能做的只有让“投单个视频链接”这条路走不通：签名过期快（建议 ≤ 120 秒）、绑定用户 ID、拒绝重复 token、日志记录异常请求频率。剩下的，交给业务侧权衡——比如教育类视频可接受有限投屏，而付费课程必须关闭 Cast 按钮提示。
