disableRemotePlayback 对 DLNA 无效，因其仅影响 AirPlay/Chromecast 等浏览器投屏 API，而 DLNA 基于 UPnP/SSDP 协议由设备直连拉流；真正防护需动态设置混淆 src + 服务端 Referer/签名/UA/会话校验。
disableRemotePlayback 对 DLNA 无效，HTML5 <video></video> 标签本身不支持、也无法禁止 DLNA 投屏——DLNA 是设备间基于 UPnP/SSDP 的发现与控制协议，浏览器不参与也不拦截该过程。
为什么 disableRemotePlayback 不影响 DLNA
该属性仅向浏览器提示“不希望启用 AirPlay 或 Chromecast”，底层调用的是 WebKit 和 Chromium 的投屏 API 接口，与 DLNA 协议栈（UPnP 发现 + HTTP GET 流拉取）完全无关。电视或音箱作为 DLNA 渲染器（MR），直接从你网页中暴露的 src URL 拉流，不经过浏览器投屏逻辑。
-
disableRemotePlayback在 Safari/Chrome 中对 AirPlay/Chromecast 有可见抑制效果（如右键菜单移除投屏项），但对 DLNA UI（如手机端“投射到电视”按钮）零影响 - 即使你写
<video disableremoteplayback src="https://cdn.example.com/video.mp4"></video>，DLNA 客户端仍能提取并请求该 URL - Firefox 完全忽略该属性；Android WebView 行为不一致，部分版本直接跳过解析
真正能干扰 DLNA 投屏的前端操作只有隐藏或混淆 src
DLNA 控制点（如手机 App）通常通过 DOM 扫描或 JS 注入方式提取 <video></video> 的 src 或 currentSrc。阻止它，关键不是“禁协议”，而是不让真实地址轻易暴露。
- 避免在 HTML 源码中硬编码
src：改用 JS 动态设置，且 URL 经过简单混淆（如 base64 编码后解码再赋值） - 禁用
video.currentSrc可读性：在播放前执行Object.defineProperty(video, 'currentSrc', { get() { return ''; } });（注意：部分浏览器会静默忽略） - 监听
loadstart后立即清空src，改用MediaSource进行 MSE 播放——此时currentSrc为空字符串，DLNA 工具无法提取有效 URL - 慎用 CSS 隐藏：
##video { display: none !important; }可能导致播放器初始化失败或触发 fallback 错误，不如用visibility: hidden; position: absolute; left: -9999px;降低副作用
服务端才是 DLNA 防护的核心防线
前端所有手段都只是增加提取成本，无法真正阻止。DLNA 客户端拿到 URL 后发起的是一次标准 HTTP GET 请求，防护必须落在服务端校验环节。
立即学习“前端免费学习笔记（深入）”；
- 拒绝无 Referer 或非法 Referer 的请求：Nginx 中配置
valid_referers none blocked server_names *.yourdomain.com; - 强制带签名 token：
/video/abc123.mp4?t=1734692580&s=abcd1234，服务端校验时间戳和 HMAC 签名，过期即 403 - 限制 User-Agent：对已知 DLNA 客户端 UA（如
Linux/3.14.0 UPnP/1.0 DLNADOC/1.50）返回 403 或空响应体 - 结合播放会话绑定：前端获取视频地址时，后端生成一次性的 session_id，并要求后续所有分片请求携带该 ID，服务端校验其活跃状态
DLNA 的本质是“推 URL”，不是“推画面”。只要真实媒体地址被拿到，任何 DLNA 渲染器都能播——所以别纠结浏览器能不能“禁 DLNA”，重点检查你的 src 是不是裸露在 HTML 里、服务端有没有对 HTTP 请求做身份和上下文校验。
