企业官网建设流程全解析

配置明明在控制台生效了，播放却始终拉不到流——这是直播域名体系里最反直觉的误区，也是域名规划阶段最常见的痛点之一。运维在 PC 运营管理后台看到推流域名和播流域名都显示"已配置成功"，CNAME 也填了，可观众在移动端 App 和微信小程序里就是黑屏。问题往往不在地址，而在域名本身：推流域名和播流域名没有关联到同一直播中心，或者加速区域选成了海外却忘了备案，导致分发链路根本没打通。这类配置错误在直播系统开发早期极容易踩，因为它不报错、不红字，只是静默地不通，而这类痛点恰恰最容易在规划阶段被忽略。

推流域名与播流域名互斥，一个域名只能二选一

推流域名与播流域名是两套互斥的体系，一个域名只能是其中一种，不能兼用。推流域名负责把直播流推送进直播中心，播流域名负责把处理好的流分发到观众端。在功能层面，域名管理是直播系统配置模块的第一道闸门，所有后续模板、回调、鉴权都挂在这两个域名之下；关联的推流域名与播流域名还必须选择同一直播中心，初次配置后不可更改。理解这一前提，才能避免"推上去了却拉不到"的错位。从数据模型看，一个域名被标记为推流域名后，系统不会为它建立播流分发链路，反之亦然，这正是为什么误把同一个域名既当推流又当播流会彻底不通——它不是配置错了，而是链路根本没建。规划时应当把"推流域名池"与"播流域名池"在总管理中心里分开管理，避免运营误选。

四大配置项里，直播中心与业务类型初次配置后不可更改

添加域名时需要填四项：加速域名、直播中心（Region）、业务类型、加速区域（Scope）。其中直播中心与业务类型在初次配置后不可更改，这意味着规划阶段就要想清楚这路流归哪个中心、跑什么业务，后面改不动。控制台一般使用子域名、不支持泛域名，而 API 支持以英文句点开头的泛域名，这在多租户 SaaS 化直播平台里是必用的能力。域名准入要先过标准校验，再验证域名归属权，添加域名，最后做 CNAME，顺序不能乱。把顺序再讲细一点：域名准入标准校验先于一切，它决定这个域名能不能进系统；其后是验证域名归属权，证明你确实拥有这个域名；通过后才添加域名、再做 CNAME，任一步失败都进不到下一步。直播中心（Region）一旦选定就无法更改，意味着这路流的媒体处理与分发物理位置就此锁定，后续若要换中心只能重建域名；业务类型同样初次配置后不可更改，它决定了这套域名承载的是普通直播、转码还是其他业务形态。规划阶段就把"哪个中心、跑什么业务"定死，能省掉后期大量推倒重来的成本。

加速区域决定备案：国内要备案，海外无需备案

加速区域有三选一，直接决定备案要求。中国内地（domestic）需要工信部备案；全球加速（global）同样需要备案；海外及港澳台加速（overseas）无需备案。这是很多出海直播项目的技术方案决策点：如果观众主要在海外，选 overseas 可以绕开备案周期，但国内观众访问质量会下降；如果兼顾国内，就必须先完成备案才能用 domestic 或 global。直播系统开发时应当把备案状态作为域名开通的前置校验，避免运营后台已经建好场次、域名却因未备案被拦截。

域名关联拓扑有两条规则，主子域配置不能错位

域名之间的关联拓扑是整套体系最容易被讲错的部分，它有两条规则。第一条，关联推流和播流域名，可以实现"一个播流域名对应多个推流域名"，而一个推流域名只能配置一个主播流域名——这常用于同一场大型活动从多个机位、多个推流端汇聚到一条播放链接。第二条，关联主、子播流域名，可以实现"一个推流域名对应多个播流域名"，子播流域名继承主播流域名的推流配置与转码配置，而且这些配置在子域名上单独配置无效，例如转码模板必须配在主播流域名。子播流域名之间不允许嵌套。理解这两条拓扑，是设计多平台分发与多清晰度分发方案的基础。

CNAME 配完要等约 10 分钟，DNS 缓存不是配置错了

CNAME 解析是域名能真正跑起来的最后一步。推流与播流域名需分别做 CNAME 解析到加速平台，而且因为 Local DNS 缓存的存在，配置 CNAME 后加速平台大约延迟 10 分钟才显示解析成功。很多开发者配完立刻去拉流，发现不通就以为配置错了，其实只是 DNS 还没生效。这里还有一个使用限制：每个账号最多 20 个直播加速域名，需要增加得提工单。把 CNAME 生效延迟写进联调文档，能省掉大量"以为坏了"的误报。还要注意的是，Local DNS 的缓存 TTL 因运营商而异，10 分钟是平台侧观察到的典型延迟，部分地区可能更久，联调时应以播流域名实际出流为准，而不是以控制台状态为准。备案状态同样应当作为域名创建接口的硬性校验项：未备案的 domestic 或 global 域名即便解析成功，加速平台也会在边缘拒绝服务，表现为 CNAME 已生效但播放返回 403 或空响应，这种"半通不通"最容易被误判为代码问题。

功能配置生效表：流处理配主播域，分发安全配子域

功能配置生效表是排查"配了不生效"的终极依据，必须写准在哪个域名配才有效。生效在主播流域名的包括：直播流管理（查看在线流、历史流、禁推流）、文件管理（录制、截图查询与索引剪辑）、转码模板、录制配置、截图配置、审核配置、直播时移、直播延时配置、拉流配置，以及推流路数、转码时长、截图张数用量和添加子播放域名、HLS 回源 HOST。生效在子播流域名的包括：修改加速区域、延迟配置（高/中/低）、HTTP 头配置、安全配置（HTTPS、Referer、URL 鉴权、IP 黑白名单）、带宽峰值监控、IPv6、资源监控（流量带宽下行、回源、HTTPCODE）、实时监控、独立访客数、用户分布、播放带宽流量、时移用量、日志下载、实时日志推送。一句话规则：与"流本身怎么处理"相关的配置落在主播流域名，与"播流分发与访问安全"相关的配置落在子播流域名。落到排查动作上，如果一个域名配了转码模板却始终不生效，第一反应应是去确认模板是配在主播流域名还是子播流域名——子域上单独配的转码模板是无效的，必须回到主播流域名才生效；同理，延迟配置（高/中/低）生效在子播流域名，改在主播域同样不生效。很多团队在直播中途调了某一项期待立刻变化，结果线上毫无反应，根因往往不是配置错了，而是配置落在了不生效的那个域名上。把"配置归属"作为排障第一步，能直接砍掉一大半"配了不生效"的误报工单。

域名体系必须收口在总管理中心，权限与日志监控不能下放

把域名体系放回角色权限与总管理中心的视角，才能确认它不会和别的模块打架。超级管理员拥有域名、密钥、配额、账务的最高权限，负责在总管理中心创建和关联域名；运营管理员按业务域分配加速区域与播流域名，给不同场次排期；主播、观众等角色只通过移动端 App 或微信小程序使用现成播放地址，既看不到域名配置也不该有修改权限。当某个域名下的直播出现合规问题，审核员会触发审核工单，对违规场次做禁推或驳回重提，客服再跟进申诉与补材料。域名作为所有能力的载体，它的归属与权限必须收口在总管理中心，不能下放给普通运营随意改动。

域名配置的健康度同样依赖日志、风控与监控。每个播流域名的日志下载与实时日志推送能反映访问分布与异常请求；当某个域名突发带宽在 1 分钟内增量达 50 Gbps，平台会触发限流到不超过 50 Gbps 的风控规则，既防攻击也防高额成本；监控面板则持续跟踪流量、带宽峰值与 HTTPCODE，帮助运维在播放异常之前就发现域名层面的隐患。当监控发现某域名 HTTPCODE 异常飙高或带宽突增，先回到功能配置生效表确认配置是否落在了正确的域名上，再排查链路，而不是盲目改 CNAME，因为大多数"不通"的根因是配置归属错了而非解析没生效。