Cloudflare 此前已经让其服务器具备 Media over QUIC（MoQ）中继能力。新的 provisioning API 又向前推进了一步：开发者可以创建自己的隔离中继，并明确控制哪些身份能够发布媒体、哪些身份只能观看。这让 MoQ 从共享基础设施能力，进一步变成可纳入业务权限体系的可编排资源。
隔离中继解决了什么问题
媒体中继不仅负责转发数据，也处在内容生产者和消费者之间的信任边界上。如果发布端与观看端共用一套宽泛凭证，泄露后的影响会非常直接：只应观看直播的客户端，可能获得注入内容的能力；某个项目的凭证，也可能被误用于另一个项目。
隔离中继提供了更清晰的资源边界。可以把每场活动、每个租户或每套环境放进独立中继，例如：
production与staging使用不同中继，测试推流不会进入生产观众链路。- 多租户平台按客户隔离中继，减少配置错误造成的跨租户访问。
- 主播、转码服务持有发布权限，网页播放器和移动客户端只获得观看权限。
- 临时活动结束后，可以直接撤销凭证或删除对应中继，缩短资源暴露时间。
这里最重要的变化不是“多了一个创建接口”，而是中继开始拥有明确的生命周期和权限归属。它可以像对象存储桶、消息主题或数据库实例一样被自动创建、配置和回收。
发布者和观看者必须是两类身份
权限模型应遵循最小权限原则。发布者需要向中继写入媒体对象，观看者只需要订阅和接收，两者不应共享令牌。
一个典型的角色划分可以是：
| 身份 | 发布 | 观看 | 常见对象 |
|---|---|---|---|
| Publisher | 允许 | 按需允许 | 摄像机网关、OBS 接入层、转码器 |
| Viewer | 禁止 | 允许 | Web 播放器、移动客户端、内部监看页面 |
| Operator | 管理配置 | 通常不直接消费媒体 | CI/CD、控制面服务、运维工具 |
即使系统允许一个主体同时发布和观看，也应避免默认授予双向权限。尤其不要把 provisioning API 的管理凭证下发给播放器；管理凭证应只存在于后端控制面或密钥管理系统中。
观看凭证还可以结合业务生命周期设计成短期令牌：用户先通过应用自身的登录与购票校验，再由后端签发只能访问指定中继、指定内容范围的临时凭证。来源摘要没有给出令牌格式和细粒度授权字段，因此具体能力需要以实际 API 文档为准。
可以这样实践：用控制面创建中继并分配角色
下面是一个可改造的 Shell 示例。由于摘要没有提供真实端点、字段名和响应结构，示例中的 URL 与 JSON schema 是假设性的接口形状，用于展示自动化流程；运行前需要替换为实际 provisioning API 的端点和字段。
准备 curl 和 jq，并把管理令牌放入环境变量：
export MOQ_API_BASE="https://api.example.com/client/v4/accounts/YOUR_ACCOUNT_ID/moq"
export MOQ_ADMIN_TOKEN="replace-with-a-secret-from-your-secret-manager"
创建一个隔离中继：
curl --fail-with-body --silent --show-error \
--request POST "${MOQ_API_BASE}/relays" \
--header "Authorization: Bearer ${MOQ_ADMIN_TOKEN}" \
--header "Content-Type: application/json" \
--data '{
"name": "product-launch-2025",
"isolation": "dedicated"
}' | jq .
接着为发布端和观看端分别创建凭证。不要把两个响应写入同一个公开配置文件：
RELAY_ID="replace-with-created-relay-id"
curl --fail-with-body --silent --show-error \
--request POST "${MOQ_API_BASE}/relays/${RELAY_ID}/credentials" \
--header "Authorization: Bearer ${MOQ_ADMIN_TOKEN}" \
--header "Content-Type: application/json" \
--data '{
"name": "production-encoder",
"role": "publisher"
}' | jq .
curl --fail-with-body --silent --show-error \
--request POST "${MOQ_API_BASE}/relays/${RELAY_ID}/credentials" \
--header "Authorization: Bearer ${MOQ_ADMIN_TOKEN}" \
--header "Content-Type: application/json" \
--data '{
"name": "web-viewers",
"role": "viewer"
}' | jq .
在真实项目中，这段流程更适合放进后端控制面或 CI/CD，而不是由开发者长期手工执行。自动化程序至少应保存中继 ID、记录创建者和用途，并把返回的秘密值直接写入密钥管理系统。日志只能记录凭证标识，不能打印完整令牌。
把中继纳入资源生命周期
Provisioning API 的价值会在自动化之后变得更明显。例如，直播活动服务可以在活动创建时申请中继，在推流设备上线前签发发布凭证，在观众通过鉴权后发放观看凭证，并在活动结束后撤销访问。
建议在资源模型中保留以下字段：
# 这是业务控制面的示例模型，不代表实际 API 配置格式。
event_id: launch-2025
relay_id: relay_abc123
environment: production
owner: media-platform
publisher_secret_ref: secret/moq/launch-2025/publisher
viewer_token_policy: short-lived
expires_at: 2025-12-31T23:59:59Z
这份元数据让团队能够回答几个关键问题：谁创建了中继、它服务于哪场活动、哪些凭证仍然有效、何时应该回收。没有这些信息，自动创建资源很容易演变成长期无人管理的基础设施库存。
上线前的检查清单
采用隔离 MoQ 中继时，可以从以下边界开始：
- 为生产、测试和不同租户建立独立中继，不依赖命名约定实现软隔离。
- 分开发行 publisher 与 viewer 凭证，并验证 viewer 无法提交媒体。
- 将 provisioning 管理令牌限制在后端控制面，禁止进入浏览器、移动应用和构建产物。
- 对创建、授权、撤销和删除操作保留审计记录，但对秘密字段做脱敏处理。
- 设计轮换和紧急撤销流程，不把删除整个中继当作唯一止损手段。
- 压测并观察连接数、媒体延迟、丢包恢复和跨区域表现；权限隔离不会自动解决容量与网络质量问题。
- 对照正式 API 文档确认端点、字段、配额、令牌有效期和错误处理语义。
新的 provisioning API 让 MoQ 中继具备了可编排的隔离与授权边界。真正落地时，重点不是调用一次创建接口，而是把中继、角色凭证、业务事件和回收策略连接成完整的控制面流程。