浏览器与直播：那些安全策略带来的坑

更新: 5/4/2026 字数: 0 字时长: 0 分钟

适合读者：所有做 Web 直播、被浏览器安全策略"背刺"过的同学。本文不讲协议，只讲浏览器侧那些"标准之外、血泪之中"的坑。

开篇：为什么直播特别容易踩安全策略

普通网页只是加载一堆静态资源，直播却是一头"长尾怪兽"：

长连接持续拉流，任何一次中断都会被用户感知；
音视频数据量大、来源分散，跨域、混合内容、CORS 几乎无法回避；
涉及播放与声音，自动播放、用户手势、硬件解码策略都会插一脚；
终端形态复杂，iOS Safari、Android WebView、小程序 WebView 各有各的魔改。

浏览器的安全模型本来就是"宁可错杀一千"，直播又把所有边界都踩得死死的。下面按"策略 → 症状 → 定位 → 解决"的结构过一遍。

一、Mixed Content：HTTPS 页面里的 HTTP 流

1.1 现象

页面在 https://live.example.com，播放器配置的是 http://cdn.example.com/live/room.flv。Chrome 控制台：

Mixed Content: The page at 'https://live.example.com/' was loaded over HTTPS,
but requested an insecure resource 'http://cdn.example.com/live/room.flv'.
This request has been blocked.

1.2 分类要分清

浏览器把混合内容分两档，策略不一样：

类型	包含资源	现代浏览器行为
Passive（被动）	`<img>` `<video>` `<audio>` 的 `src`	旧版警告，Chrome 80+ 起逐步自动升级到 HTTPS，失败则阻断
Active（主动）	`fetch`、`XHR`、`WebSocket`、`<script>`、`<iframe>`	直接硬阻断，没有商量

直播里几乎所有协议都踩的是 active 这档：FLV 靠 fetch、HLS 靠 fetch、WebRTC 信令靠 WebSocket——全是"必死"档。

1.3 解决思路

根治：CDN/源站上 HTTPS。没有第二条路。务必同时支持 HTTP/2，对 LL-HLS 的多请求场景收益巨大。
过渡：upgrade-insecure-requests：
html
```
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
```
浏览器会把页面内所有 http:// 请求自动升级成 https://。注意前提是 CDN 确实有 HTTPS 端点，否则只是换个姿势挂。
历史文物：Protocol-relative URL（//cdn.example.com/x.flv）：跟随页面协议。现在基本不用了，不如显式写 https://，意图更清晰。
WebSocket 也要升级：ws:// 在 HTTPS 页面下同样算 mixed content，必须 wss://。连麦信令被这个坑过的人不少。
别指望 crossorigin="anonymous" 能绕开：这是 CORS 的事，不是 Mixed Content 的事，两个是独立的坎。

二、CORS：fetch 流与 MSE 最容易"静默失败"的一环

2.1 fetch 拉流的 CORS 要求

用 fetch(flvUrl) 拉流，和拉一个 JSON 接口没有本质区别——同源策略照样生效。CDN 必须回：

Access-Control-Allow-Origin: https://live.example.com
# 或 *，但注意下面与 credentials 的冲突

几个直播特有的坑：

CDN 边缘节点配置不一致：源站配了，边缘没配，表现为"有的用户能播有的不能"。症状：fetch 返回 TypeError: Failed to fetch，Network 面板显示请求是发出去了但 (failed) net::ERR_FAILED。
Access-Control-Allow-Origin: * 与 cookie 鉴权冲突：一旦 fetch(url, { credentials: 'include' })，就不能是 *，必须回显具体 origin 且带 Access-Control-Allow-Credentials: true。
预检（preflight）会被触发：自定义 header（如 X-Token）、非简单方法都会先来一个 OPTIONS。CDN 必须放行 OPTIONS 并回 Access-Control-Allow-Headers。直播最好把鉴权放 query string，避开 preflight。
Range 请求：HLS 切片、fMP4 字节范围加载都会用到。CDN 要回显 Access-Control-Expose-Headers: Content-Length, Content-Range，否则 JS 读不到长度，ABR 会瞎掉。

2.2 `<video>` 元素的 `crossorigin` 属性

这是最容易用错的一个属性：

html

<video src="https://cdn.example.com/x.m3u8" crossorigin="anonymous"></video>

三个取值：

值	发送 cookie?	需要服务端 CORS 头?
不写	不发	不需要（但 `captureStream`、canvas 绘制会被"污染"）
`anonymous`	不发	需要 `Access-Control-Allow-Origin`
`use-credentials`	发	需要且 ACAO 不能是 `*`

关键认知：

不写 crossorigin 也能播放：只是 canvas 绘制会被判定为跨域污染，toDataURL() 会抛 SecurityError。录屏/截图/美颜需求会踩。
加了 crossorigin 但 CDN 没配 CORS：直接加载失败，<video> 报 MEDIA_ERR_SRC_NOT_SUPPORTED。比不加还惨。
MSE 场景属性可以不加：因为数据是 fetch 拉完再 appendBuffer 的，<video>.src 是 blob: URL，不存在跨域概念。但 fetch 本身要过 CORS。
HLS.js 内部走的也是 fetch：crossorigin 属性对它没直接作用，CORS 要配在 m3u8 和 ts/fmp4 分片上。

2.3 实战定位流程

症状：视频不播
 ├─ Network 看 flv/m3u8 请求 → (failed)
 │    ├─ 红叉 "CORS error" 字样 → 缺 ACAO 头
 │    ├─ 状态码 0 + ERR_BLOCKED_BY_RESPONSE → preflight 没过
 │    └─ 状态码 200 但 JS fetch 还是失败 → ACAO 值不匹配 origin
 └─ Console 报 "tainted canvas" → 是 crossorigin 属性问题，不是网络层

三、Autoplay Policy：静音才能自动播

3.1 规则一览（Chrome 主导，其它浏览器趋同）

自动播放能成，需满足任一条件：

视频静音（muted 属性）或无音频轨；
用户在该站点有足够"媒体参与度"（MEI，Chrome 内部评分）；
页面已被用户交互过（click/tap/keydown 触发过 user gesture）；
移动端 PWA 加到主屏后打开。

最保险的策略只有两条：要么 muted 自动播，要么等用户点一下。

3.2 直播场景的典型代码

html

<video id="v" autoplay muted playsinline></video>

const v = document.getElementById('v')
try {
  await v.play()
} catch (e) {
  // NotAllowedError → 被自动播放策略拦了
  showUnmuteButton()
}

3.3 "先静音自动播，用户点一下再开声音"

这是直播落地页最常见的套路：

v.muted = true
await v.play()                      // 一定能成
document.addEventListener('click', () => {
  v.muted = false                    // 用户手势后解除静音
}, { once: true })

要点：

playsinline 是 iOS 必备：否则 iPhone Safari 会进入全屏播放器，把你的 UI 全盖掉。
muted 必须是 HTML 属性或在 play() 之前设置 v.muted = true：有些版本的 WebKit 会在 play() 时用序列化的初始状态判断，JS 异步设 muted = true 可能仍被拦。
play() 的返回值要 catch：早期版本不是 Promise，现代浏览器是；被拦截时抛 NotAllowedError。不 catch 会污染 Sentry。
WebView 里 muted 也可能失败：某些定制浏览器把 autoplay 完全关了（小程序、广告 SDK 的 WebView 常见），必须用户点一下才能播。

3.4 "用户手势"的有效期

单次手势只授权一次 play()/AudioContext.resume() 这类调用，不是"永久白名单"；
跨 await 后手势可能失效：click → await fetch(...) → video.play() 在某些浏览器上会被判定"离开了手势上下文"。解决方案：手势里先 play() 一个静音占位 video，再异步加载真实流。
AudioContext 同样需要手势 resume()，WebCodecs 自研音频通道的同学会碰到。

四、Service Worker / CSP 对流媒体的限制

4.1 Service Worker：帮倒忙的常客

SW 的 fetch 事件会拦截页面的所有请求，直播流也不例外。常见翻车：

SW 把流请求 event.respondWith(caches.match(req)) 了：长连接被 SW 拿去翻缓存，要么找不到、要么返回过期数据、要么直接 hang 死。
SW 复制 body 导致内存炸：req.clone() 或 res.clone() 在长连接上会一直攒 buffer，几分钟后 tab OOM。
SW 升级导致流中断：SW 换版本时会关闭旧实例，fetch stream 会被 abort，表现为用户"看了一会儿突然黑屏"。

最佳实践：

self.addEventListener('fetch', event => {
  const url = new URL(event.request.url)
  // 直接放行流媒体请求，不进入 SW 缓存逻辑
  if (/\.(flv|m3u8|mpd|ts|m4s)$/.test(url.pathname) ||
      url.pathname.startsWith('/live/')) {
    return   // 不调用 respondWith = 走浏览器默认网络栈
  }
  // 其它请求才走缓存策略
})

4.2 CSP（Content Security Policy）

页面有 Content-Security-Policy 时，流媒体的相关指令：

指令	管什么
`media-src`	`<video>` `<audio>` 的 `src`（包括 `blob:`）
`connect-src`	`fetch`、`XHR`、`WebSocket`、`EventSource`
`img-src`	视频封面、缩略图
`worker-src`	解码 Worker
`frame-src`	iframe 嵌入的第三方播放器

踩坑清单：

media-src 'self' 会挡住 blob URL：MSE 必用 blob:，要显式写 media-src 'self' blob:。
connect-src 要包含 CDN 域名：flv/m3u8 拉流走 fetch，WebRTC 信令走 wss://，都要列进去。

default-src 'none' 很硬核：什么都得显式开白。直播页建议最小集：

Content-Security-Policy:
  default-src 'self';
  media-src 'self' blob: https://cdn.example.com;
  connect-src 'self' https://cdn.example.com wss://rtc.example.com;
  worker-src 'self' blob:;
  img-src 'self' data: https:;

Report-Only 先跑一轮：上线前用 Content-Security-Policy-Report-Only 收集违规，别直接硬拉开关。

五、移动端 WebView：各家魔改最致命的地方

5.1 iOS Safari / WKWebView

必须 playsinline：不写就强制全屏，任何自定义 UI 都被覆盖。
MSE 在 iPhone 上不支持：iPadOS 14+ 才放开。iPhone 的 FLV 永远播不了，必须回退 HLS。
<video> 的同屏数量有限制：旧 iOS 同屏最多 1 个能真正解码，其它变成"黑块"。连麦九宫格要特别注意。
低功耗模式会阻塞自动播：iOS 低电量模式下所有 autoplay 都被拦，静音也不行，必须用户点。
-webkit-playsinline 是祖传兼容：iOS 10 之前要加，现在 playsinline 即可。
AudioContext 采样率固定：iOS 常把 AudioContext 锁在 48000，自研音频链路要重采样。
后台播放：默认一进后台暂停。需要 PWA + <video> 的 PiP 模式，或 hack 住 visibilitychange。

5.2 Android WebView

厂商魔改硬解码器：同是 H.264，某些机型解不了 baseline 但能解 high；某些机型 avc1.64001f 正常但 avc1.640028 黑屏。要做 codecs 级别的设备黑名单。
MediaSource.isTypeSupported 会骗你：返回 true 不代表真能解，只是容器层支持。真机跑才知道。
H.265 全看厂商：国产机近两年基本都带硬解，但 hev1. 和 hvc1. 的 codecs 字符串写错一个就黑屏。
同屏多 <video>：Android WebView 对同屏硬解实例数有限制（常见 4–6），超过会降级软解甚至直接失败。
小程序 WebView（微信/抖音）又是另一套：
- 微信 X5 内核对 FLV 支持较好，但 flv.js 的 worker 可能被禁；
- 微信 iOS 用 WKWebView，iPhone 限制全继承；
- 小程序可能屏蔽 fetch 的 stream API，必须降级为分片拉取或用小程序原生 <live-player>。
Autoplay：Chromium for Android 的策略和桌面一致（静音可自动播），但不少定制浏览器（UC、QQ 浏览器）把 autoplay 彻底关了。

5.3 能力探测清单

上线前至少做这些运行时探测并上报：

const probe = {
  mse: 'MediaSource' in window,
  mseOnVideo: !!document.createElement('video').canPlayType &&
              !!window.MediaSource,
  webrtc: !!window.RTCPeerConnection,
  webcodecs: 'VideoDecoder' in window,
  hlsNative: document.createElement('video')
             .canPlayType('application/vnd.apple.mpegurl') !== '',
  h264High: MediaSource?.isTypeSupported(
    'video/mp4; codecs="avc1.640028"'),
  h265: MediaSource?.isTypeSupported(
    'video/mp4; codecs="hvc1.1.6.L93.B0"'),
  autoplayMuted: null,  // 需要异步 probe video.play()
}

根据结果做协议与编码降级，比"先上再修"成本低一个数量级。

六、过渡技巧与冷知识

Protocol-relative URL（//host/path）：老办法，让资源跟随页面协议。缺点是脚本里、Worker 里不可用（没有"页面协议"概念），CSP 也更难写。不推荐新项目使用。
upgrade-insecure-requests：适合存量系统过渡，但对第三方 CDN 无 HTTPS 的情况无能为力——它只升级协议，不帮你变出证书。
Referrer-Policy: no-referrer-when-downgrade：直播防盗链经常依赖 Referer，升级到 HTTPS 后默认不降级发送，要确认 CDN 白名单匹配规则。
Permissions-Policy（旧 Feature-Policy）：iframe 嵌播放器时，父页要开 autoplay=*、camera=*、microphone=*、encrypted-media=*，否则内嵌播放器的自动播、连麦、DRM 全挂。
Cross-Origin-Isolated：如果你要用 SharedArrayBuffer 加速 wasm 解码（H.265 软解常见），必须开 COOP+COEP，而 COEP 要求所有子资源带 Cross-Origin-Resource-Policy 或 CORS 头——CDN 又得再配一轮。
User Activation API：navigator.userActivation.hasBeenActive 可以查询当前是否有手势上下文，异步流程里判断是否需要弹"点一下解除静音"的蒙层。

七、一张速查表

症状	八成是哪块	第一优先级检查
HTTPS 页面控制台 "Mixed Content"	Mixed Content	CDN 是否有 HTTPS 端点
Network 红叉 + CORS 字样	CORS	响应头 `Access-Control-Allow-Origin`
canvas `toDataURL` 报 SecurityError	CORS / crossorigin	`<video crossorigin="anonymous">` + 服务端 CORS
`play()` Promise reject NotAllowedError	Autoplay	`muted + playsinline`
自动播 OK 但没声音	Autoplay	正常，等用户手势解 mute
流播几秒突然断	SW / CDN	Service Worker 是否拦截了流
blob URL 加载失败	CSP	`media-src` 是否包含 `blob:`
iOS 自动进全屏	iOS Safari	加 `playsinline`
Android 某些机型黑屏	硬解码	codecs 字符串 + 设备白名单
WebSocket 连不上（HTTPS 页面）	Mixed Content	改 `wss://`
小程序 WebView 不能播 FLV	WebView 魔改	降级 HLS 或原生 `<live-player>`

八、结语

直播前端这行，真正的难点从来不是协议和解码——那些翻翻 RFC 就能搞懂。真正让线上稳定率上不去 99.9% 的，是浏览器这一层层看不见的安全策略：HTTPS 升级、CORS、自动播放、SW 拦截、WebView 魔改、CSP 误伤……每一个都够写半天事故复盘。

这份文档不追求穷尽，而是给你建一张**"出问题时该去哪一层看"的地图**。真遇到事故时，先对着速查表排一遍，能省掉 80% 的无效尝试。剩下那 20%，就是直播前端工程师真正的经验值。

浏览器与直播：那些安全策略带来的坑 ​

开篇：为什么直播特别容易踩安全策略 ​

一、Mixed Content：HTTPS 页面里的 HTTP 流 ​

1.1 现象 ​

1.2 分类要分清 ​

1.3 解决思路 ​

二、CORS：fetch 流与 MSE 最容易"静默失败"的一环 ​

2.1 fetch 拉流的 CORS 要求 ​

2.2 <video> 元素的 crossorigin 属性 ​

2.3 实战定位流程 ​

三、Autoplay Policy：静音才能自动播 ​

3.1 规则一览（Chrome 主导，其它浏览器趋同） ​

3.2 直播场景的典型代码 ​

3.3 "先静音自动播，用户点一下再开声音" ​

3.4 "用户手势"的有效期 ​

四、Service Worker / CSP 对流媒体的限制 ​

4.1 Service Worker：帮倒忙的常客 ​

4.2 CSP（Content Security Policy） ​

五、移动端 WebView：各家魔改最致命的地方 ​

5.1 iOS Safari / WKWebView ​

5.2 Android WebView ​

5.3 能力探测清单 ​

六、过渡技巧与冷知识 ​

七、一张速查表 ​

八、结语 ​