去年双十一前，一家零售企业做内部订货会直播。技术对接会上，对方的网络工程师抛来一句：你们的观看鉴权到底做在哪一层？他们纠结的是能不能让外部抓不到流、内部员工点开就进。这个问题问到了点子上。
内部观看权限不是一个开关。从采集、推流、平台分发到终端，好几个节点都能插手，插错位置的后果是两头落空：外人没拦住，自己人也进不来。
平台侧鉴权：进门那道闸的三种接法
绝大多数内部直播，鉴权落在分发平台这一层，也就是员工点开链接之后、看到画面之前那道闸。常见三种，各有各的毛病。
报名审核
用户先填信息，运营在后台逐条放行。名单严、人数少的场合好用；几百人以上就得配两个人在后台点，点到开播前还没点完是常事。
口令
一串字符发给全员，谁拿到谁进。轻，但会外流。我们只在内容不敏感、图个省事的内训里用，而且要求口令按场次换，别一整年一个。
白名单导入
把账号或者企业邮箱前缀批量塞进去，不在表里的直接挡在门外。折中方案，我们用得多。常和报名审核叠着用：先导基线名单，临时人员走审核补位。
这一层拦的是"看的人"，它管不了"流"本身。这句话很多甲方要听两遍才接受。
推流侧要不要单独走私有流
有人觉得推流不走公开地址，外人就抓不到。想法没错，代价得算。私有推流意味着整条上行要自建或者租专网，带宽和稳定性自己扛。一般的内部会议没必要走到这一步，把平台侧鉴权做扎实就够。只有当连"这场直播存不存在"都不想暴露时，才值得上。
还有个容易忽略的点：上游私有、下游还是公有平台，中间得做协议转换，延迟和故障点各加一层。这笔账要跟保密级别绑着算，不是越封闭越好。有客户坚持上了私有流，结果那场因为转换节点抖动掉了两次画面，反倒给自己添了麻烦。
动态水印压在导播端、推流端还是分发层
权限拦不住截图，所以内部直播几乎都上动态水印，把观看者标识压在画面上用于溯源。压哪一端有讲究。
压在导播输出、也就是合成后的成品流上，位置和内容可控，但所有分支共用一套，没法按人变。压在推流端，理论上能按账号嵌不同标识，分支一多，节点压力和同步就都是问题。我们更倾向在平台分发层做按人水印，观众各自看到的标识不同，上游一点不用动。前提是平台本身支持，所以选型的时候这条要写进需求清单，别等上线了才问。
直播权限和回放权限，得是两个开关
不少团队图省事，直播关了回放跟着锁。这两者该拆开。一场内部培训，直播时严进严出，结束后把回放开给没赶上的人，价值反而上来了。反过来也有：某些决策会直播能看、回放必删，因为事后内容还要改口径。
拆开的代价是配置要双线核对，漏一处就可能该删的没删。我们交付前会出一张权限对照表，直播态和回放态各列一行，谁配的谁打钩，客户那边再复核一遍。这张表改过五六个版本，现在长成一页纸，勾完拍照留档。
并发把鉴权接口打满，是常见坑
平时几十人测得好好的，开播那一瞬间上千人同时敲门，鉴权接口被打满，正常名单也进不去。原因在于登录校验要走后台查询，瞬时并发全堵在那一跳。缓解办法是提前做名单预热，把白名单缓存到边缘节点，让核验就近完成，少碰中心库。
带宽也要留余量，我们一般按预估峰值上浮三成备着，宁可空着不撑爆。现场留一名工程盯监控面板，接口响应一旦变慢就切降级：先放人进候播页，核验放到后台补跑。这个降级动作要提前跟客户报备，不然对接人看见"排队中"三个字就以为出事了。
大面积进不去时，按这个顺序查
别乱，顺序是固定的。
- 先分清是全员进不去还是部分人进不去，这一下定方向
- 全员进不去，八成是平台侧鉴权服务或者缓存出了问题，查接口状态
- 部分人进不去，先看是不是不在白名单，再看口令有没有过期、报名有没有通过
- 都对得上，再问时间窗。很多内部直播设了固定开放时段，提前点开就是黑屏
时间窗这一条被误判成故障的次数多到离谱。把开放时间写进候播页公告，能省掉一半误报。
我们现在做内部场次，技术方案两页，配置核对表三页。听着有点本末倒置，可回头看，出事的十有八九是核对表那三页里漏了一行，不是方案选错了。
我是摄行影像，做企业活动的现场影像和直播技术支持。链路怎么接、鉴权压在哪一层，拿你们现有平台的参数来对更准。
