tencent cloud

云直播

动态与公告
公告
新手指南
产品简介
产品概述
子产品简介
基本概念
产品功能
应用场景
产品优势
使用限制
购买指南
计费概述
基础服务费
增值服务费
预付费资源包
购买流程
计费变更
退款说明
账单查询
续费说明
欠费停服说明
计费常见问题
标准直播
概述
应用场景
快速入门
SDK 接入说明
快直播(超低延时直播)
概述
快直播和标准直播区别
应用场景
快速入门
SDK 接入说明
云导播台
概述
应用场景
功能区介绍
云导播台管理
通用云导播
配置节目单和自动导播
控制台指南
控制台介绍
概览
域名管理
流管理
资源包管理
AI 智能
功能配置
拉流转推
计费用量
业务监控
常用工具
无忧直播
CAM 访问控制
功能实践
直播推流与播放
直播增值功能
典型场景实践
云端原生录制
直播安全
海外直播
回调事件消息通知
常见第三方工具指南
SDK 实践
0. SDK 接入引导
1. 推流
2. 播放
3. 高级功能
API 文档
History
Introduction
API Category
Making API Requests
Live Pad APIs
Live Stream Mix APIs
Time Shifting APIs
Monitoring Data Query APIs
Billing Data Query APIs
Live Transcoding APIs
Delayed Playback Management APIs
Domain Name Management APIs
Watermark Management APIs
Certificate Management APIs
Stream Pulling APIs
Recording Management APIs
Live Callback APIs
Screencapturing and Porn Detection APIs
Authentication Management APIs
Live Stream Management APIs
Data Types
Error Codes
运维指南
优化视频卡顿
推流失败问题排查
播放失败问题排查
CLS 协助直播问题排查
直播延迟问题排查
拉流视频质量不清晰问题排查
COS bucket 授权给直播实现截图存储
故障处理
直播混流报错:InvalidParameter.OtherError
常见问题
服务地区相关
直播基础相关
推流播放相关
直播计费相关
直播海外相关
直播录制相关
云端混流相关
域名配置相关
云导播台相关
适配苹果 ATS 相关
服务等级协议
云直播服务等级协议
CSS 政策
隐私协议
数据处理和安全协议
词汇表
文档云直播运维指南CLS 协助直播问题排查

CLS 协助直播问题排查

PDF
聚焦模式
字号
最后更新时间: 2026-03-16 11:32:50

准备工作

请先参考 文档,将日志投递到腾讯云日志服务(CLS)。

目的

通过腾讯云日志服务(CLS)实时采集并分析 CSS 播放访问日志,帮助您快速缩小直播问题的排查范围,定位客户端、网络、CDN、源站及推流端编码配置等链路中的根因,从而提升故障排查效率与运维效率。

推荐看板

使用方法

运行前,请先替换以下参数:
{start_time}{end_time}:通常通过 CLS 时间选择器设置;仅在确有需要时再补充显式时间戳过滤条件。
{host} :域名
{streamname}
{client_ip}
{interval}(例如 1 minute / 5 minute,请与您的 CLS SQL 语法保持一致。)

播放—概览/错误

HttpCode 趋势(200 vs 4xx vs 5xx)

目标:确认错误是否出现突增,并区分4xx与5xx。
输出:时间分桶 + 200/4xx/5xx 数量。
type:"lvb"
and host:"{host}"
and streamname:"{streamname}"
| select
histogram(cast(__TIMESTAMP__ as timestamp), interval 1 minute) as analytic_time,
sum(case when http_code = 200 then 1 else 0 end) as http_code200,
sum(case when http_code >= 400 and http_code < 500 then 1 else 0 end) as http_code4XX,
sum(case when http_code >= 500 then 1 else 0 end) as http_code5XX
group by analytic_time
order by analytic_time
limit 1000


按域名统计错误数(req_4xx/req_5xx)

目标:找出异常域名。
输出:host + 总请求数 + 4xx/5xx 数量。
type:"lvb"
| SELECT
host,
COUNT(*) AS req_total,
COUNT_IF(http_code >= 400 AND http_code < 500) AS req_4xx,
COUNT_IF(http_code >= 500 AND http_code < 600) AS req_5xx
GROUP BY host
ORDER BY req_5xx DESC, req_4xx DESC
LIMIT 200


播放—时延/丢包

平均处理耗时

目标:识别处理时延是否出现突增。
输出:时间分桶 + process_time 平均值/最大值(秒)。
type:"lvb" and host:"{host}" and http_code=200 and streamname:"{streamname}"
| select histogram( cast(__TIMESTAMP__ as timestamp),interval 1 minute) as analytic_time,
avg(process_time)/1000.0 as process_time_sec
group by analytic_time
order by analytic_time
limit 1000


RTT 趋势

目标:识别网络时延是否出现突增。
输出:时间分桶 + 平均 rtt
说明:
请根据您的字段单位保留或调整单位换算逻辑(部分环境中的 rtt 字段本身已是 ms)。
type:"lvb" and host:"{host}" and http_code=200 and streamname:"{streamname}"
| select histogram( cast(__TIMESTAMP__ as timestamp),interval 1 minute) as analytic_time,
avg( if(rtt='-', NULL, cast(rtt as double)) )/1000.0 as avg_rtt_ms
group by analytic_time
order by analytic_time
limit 1000

丢包率趋势

目标:识别丢包是否出现突增。
输出:时间分桶 + 平均 lost_rate
type:"lvb"
| SELECT
histogram(CAST(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
host,
AVG(IF(lost_rate = '-', NULL, CAST(lost_rate AS double))) AS avg_lost_rate
GROUP BY time, host
ORDER BY time
LIMIT 1000

播放—对比/异常点

按域名统计请求数

目标:对比各域名的流量情况。
输出:host + request_count
type:"lvb"
| select
histogram(CAST(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
host,
count(*) as req_count
group by time, host
order by time
limit 1000


按协议-域名统计请求数

目标:识别某个域名下是否存在协议维度异常。
输出:时间分桶 + host + protocol + request_count
HLS 并发用户可参考 文档
说明:
如果您的字段名不是 url,请替换为实际字段名(例如 request_urluripath)。
type:"lvb"
| select
histogram(CAST(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
host,
case
when url like '%.flv%' then 'flv'
when url like '%rtmp%' then 'rtmp'
else 'other'
end as protocol,
count(*) as req_count
group by time, host, protocol
order by time
limit 1000


按域名统计处理耗时

目标:对比各域名的处理时延。
输出:时间分桶 + host + avg/max process_time
*
| SELECT
histogram(CAST(__TIMESTAMP__ AS timestamp), interval {interval}) AS time,
host,
AVG(process_time) AS avg_process_time,
MAX(process_time) AS max_process_time
GROUP BY time, host
ORDER BY time
LIMIT 1000


按域名统计错误率

目标:查看各域名错误情况。
输出:时间分桶 + host + 成功/错误 + 平均 rtt/loss
type:"lvb"
| SELECT
histogram(cast(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
host,
SUM(IF(http_code >= 400 AND http_code < 600, 1, 0)) AS err_count,
SUM(IF(http_code >= 400 AND http_code < 600, 1, 0)) * 1.0 / COUNT(*) AS err_rate
GROUP BY time, host
ORDER BY time
LIMIT 1000


播放—单用户

单用户质量(成功率/时延/丢包/错误)

目标:评估单个用户的播放质量。
输出:时间分桶 + 成功率 + 平均 rtt/loss + 4xx/5xx 数量
type:"lvb"
AND host:"{host}"
AND streamname:"{streamname}"
AND client_ip:"{client_ip}"
| SELECT
histogram(CAST(__TIMESTAMP__ AS timestamp), interval {interval}) AS time,
client_ip,
COUNT(*) AS req_count,
ROUND(COUNT_IF(http_code = 200) * 100.0 / COUNT(*), 2) AS success_rate_pct,
COUNT_IF(http_code >= 400 AND http_code < 500) AS err_4xx,
COUNT_IF(http_code >= 500 AND http_code < 600) AS err_5xx,
AVG(IF(rtt = '-', NULL, CAST(rtt AS DOUBLE))) / 1000.0 AS avg_rtt_ms,
AVG(IF(lost_rate = '-', NULL, CAST(lost_rate AS DOUBLE))) AS avg_lost_rate
GROUP BY time, client_ip
ORDER BY time
LIMIT 1000

推流—质量

说明:
以下码率公式默认 {interval} = 1m(60 秒)。
如果将 {interval} 改为 5m,请将除数从 60 调整为 300。

按流统计推流码率

目标:识别推流码率下降/不稳定问题。
输出:时间分桶 + bitrate_kbps
*
| SELECT
histogram(CAST(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
CONCAT(host, ' | ', streamname) AS host_stream,
ROUND(SUM(size) * 8 / 60.0 / 1000, 2) AS bitrate_kbps
GROUP BY time, host_stream
ORDER BY time
LIMIT 1000

平均带宽(mbps)

目标:识别上行带宽下降/不稳定问题。
输出:时间分桶 + avg_bandwidth_mbps
*
| SELECT
histogram(CAST(__TIMESTAMP__ AS timestamp), interval 1 minute) AS time,
host,
ROUND(SUM(size) * 8 / 60.0 / 1000 / 1000, 3) AS avg_bandwidth_mbps
GROUP BY time, host
ORDER BY time
LIMIT 1000

HTTP 状态码趋势(2xx vs 4xx vs 5xx)

为什么 4xx 响应会突增?

如果403占比最高:建议重点检查以下内容

1. 播放鉴权或签名 URL 不匹配。
403 通常表示播放 URL 无效、已过期,或与当前播放鉴权策略不匹配。
检查 txSecret / txTime。
检查过期时间和服务器时钟。
检查该域名的播放鉴权配置。
如使用拼接直播,请检查 URL 签名规则和 URL 格式。
推流与播放(包含 txSecret / txTime 用法):参考 文档说明
拼接直播 URL 规则(URL 签名规则/示例):参考 文档说明
播放鉴权配置:参考 文档说明
2. 高级内容保护(如已开启)。
如果已启用额外保护能力(例如远程 Token 校验),请确认相关能力未拦截正常请求。
视频内容保护:参考 文档说明
3. Referer 或 IP 访问控制(如已开启)。
这类配置在启用或变更后,较容易引发 403 突增。
Referer 配置:参考 文档说明
IP 白名单 / 黑名单配置:参考 文档说明
4. 地域访问控制(如已开启)。
如果开启了播放地域管理,请确认异常用户所在地域是否在允许范围内。地域策略可能导致特定地区用户返回 403。
按地域访问控制配置:参考 文档说明

如果 404 占比最高:建议重点检查以下内容(CSS)

1. 确认播放 URL 是否正确(domain / app / stream / suffix)。
很多 404 本质上是播放 URL 配置错误导致,例如域名错误、AppName/StreamName 错误,或后缀错误(如 .flv / .m3u8)。
播放 URL 格式 / 示例:参考 文档说明
2. 确认流是否确实在 CSS 上处于直播中(推流状态)。
如果流没有推上来,或推流已经停止,即使播放 URL 正确,也会返回 404。
可在控制台(流管理 > 直播流)中查看,或调用 DescribeLiveStreamState 确认该流当前状态是否为 active / inactive / disabled:参考 文档说明
3. 检查流是否曾中断或结束
推流中断或停止后,播放侧可能立即或延迟一段时间后出现 404。
断流记录(控制台):参考 文档说明
流事件 API(推流/断流事件):参考 文档说明
4. 针对 HLS:确认 404 发生在 .m3u8 还是 .ts 分片上。
这一点非常关键,因为两类问题的根因通常不同:
.m3u8 返回 404,大概率说明流不存在、未在直播中,或路径错误。
.ts 返回 404,通常表示客户端请求了当前播放位置下不存在的分片(常见原因包括播放列表陈旧、代理缓存问题,或 seek 到可用分片窗口之外)。
HLS 会将流切分为5秒–10秒的小分片,并通过 M3U8 播放列表进行管理:参考 文档说明
如有回看/回放需求,请使用时移功能(CSS 会保存 TS 分片,并支持通过 M3U8 参数指定播放时间,时间范围最长可达 6 小时)。参考 文档说明
5. 如果已开启源站模式(origin-pull mode)
如果播放域名配置了回源,404 也可能表示源站侧对应流/资源不存在。
源站配置:参考 文档说明

为什么 5xx 响应会突增?

1. 先确认是否开启了源站模式(origin-pull mode)。在开启回源的情况下,播放 5xx 突增多数与上游/源站异常有关。
源站配置:参考 文档说明
2. 确认是哪个 5xx 状态码占比最高(500 / 502 / 503 / 504)。
不同的 5xx 状态码通常对应不同的上游故障模式。
数据类型(合法的播放错误码):参考 文档说明
3. 结合时延和影响范围分析 5xx(blast radius)。
可按 host / streamname / url 拆分 5xx,并检查是否与更高的处理耗时相关(例如上游变慢通常会先表现为 process_time 升高,再出现 504/5xx)。
实时日志分析(CSS-CLS 播放日志):参考 文档说明
4. 如果 503/504 与流量突增时间一致,请确认容量与资源准备情况。
遇到大流量场景建议提前评估和协调,否则容易一直在处理表象问题。
使用限制 / 流量突增保障说明:参考 文档说明

时延(大多数为 HTTP 200)

为什么大多数请求都返回 HTTP 200,但播放时延仍然很高?

如果协议选择是主要原因,很可能当前使用的是 HLS(M3U8)协议,该协议天然具有较高的延迟(通常约为10秒-30秒)。
如需低时延播放,建议切换为 LL-HLS / WebRTC(需结合平台支持情况)。
如必须使用 HLS,可适当调整分片设置(但可能增加卡顿风险):参考 文档说明

我们已经在使用 HTTP-FLV/RTMP,但时延仍然很高,还需要调整什么?

高时延排查参考 文档说明

丢包(大多数为 HTTP 200)

为什么大多数请求都返回 HTTP 200,但播放仍然会卡顿/冻结?

1. 如果 lost_rate 是主要异常指标,很可能是观众侧丢包或下行网络不稳定(lost_rate 仅在 type=leb 时有效)。
2. 在 CLS 播放日志中筛选 type=leb,观察 lost_ratertt 的趋势。
3. prov / isp / server_region 拆分,确认丢包是否集中在特定地域/运营商。
如果问题集中在特定地域/运营商:建议将受影响用户切换至 LEB(WebRTC),以获得更好的弱网抗性。参考 文档说明
如果需要在带宽波动场景下获得更平滑的播放体验:可开启自适应码率(仅支持 HLS/WebRTC)。参考 文档说明
如果所有观众都出现卡顿(而非集中在某个地域):更应按上游问题处理,例如上游 FPS 过低、上行拥塞等;建议降低码率/分辨率,或优先稳定上行网络。参考 文档说明

对比/异常点

只有一个地域异常,其他地域都正常,应该重点检查什么?

如果某个地域明显异常(错误/时延/卡顿)而其他地域正常,常见原因包括:
播放域名加速地域与实际访问地域不匹配。
开启了地域允许/封禁策略(播放地域管理)。
协议问题仅在该地域生效(协议被屏蔽 / 回退行为异常)。
1. 加速地域不匹配(域名级配置)。
检查播放域名的“加速区域”配置。
如果异常用户所在地域不在加速覆盖范围内,播放可能失败,或表现异常。
地域配置:参考 文档说明
服务地域:参考 文档说明
2. 地域允许/封禁(“仅某一地域异常”最常见的配置原因)。
检查是否开启了“按地域访问控制”(播放地域管理)。
确认异常地域未被封禁,且已被纳入允许范围。
按地域访问控制配置:参考 文档说明
3. 协议维度影响。
如果异常仅与某个协议相关(例如仅 HLS 或仅 FLV 异常),请重点验证该协议的开启状态及播放器行为:
该域名是否屏蔽了此协议。
播放器在该地域/设备上是否自动回退到了其他协议。
按协议屏蔽播放:参考 文档说明

单用户

只有一个用户反馈卡顿/高时延/报错,但整体看板正常,如何验证并隔离问题?

1. 先确认是否为单点问题:
对比同一时间窗内的全局指标(请求/错误/时延),参考 文档说明
2. 在 CLS 实时日志分析中,按 client_ip 和精确时间范围筛选,重点查看 http_code
如使用 LEB,还应同时查看 rttlost_rate(仅 LEB 有效字段;type=leb)。
3. 判断逻辑
rtt / lost_rate 高,但大多数请求为 200,更可能是客户端网络质量问题(Wi-Fi / ISP / 路由)。
持续出现 4xx/5xx,仍按主 RCA 逻辑排查,但范围收敛到该用户(增加 client_ip 过滤条件)。

推流

推流码率下降/断流/上游表现不稳定,如何判断是上行网络问题还是推流端编码配置问题?

1. 如果推流不稳定是主要现象,常见原因是上行拥塞/丢包,或推流设备/推流软件编码参数不合理、资源负载过高,导致码率/FPS 波动。
2. 检查项:确认故障时间窗附近该流状态是否为 active / inactive / forbidden。参考 文档说明
3. 按流拉取推流侧指标并观察趋势:视频码率/视频 FPS/音频码率/编码格式/客户端 IP。参考 文档说明,字段参考 文档说明
4. 如果怀疑是上行网络问题(码率下降 + 重连 / 不稳定):建议降低推流码率并优先稳定上行网络;上行带宽不足容易导致拥塞。参考 文档说明
5. 如果怀疑是推流端编码配置问题(带宽看起来稳定,但码率 / FPS 不稳定):建议调整推流设备 / 推流软件的编码参数,并控制在合理码率范围内(腾讯建议 < 4 Mbps,以避免推流卡顿)。参考 文档说明
6. 如果上行链路存在高丢包或长距离传输场景:建议切换推流协议为 SRT 或 RTMP over SRT,以提升抗丢包能力。
RTMP over SRT 说明与配置参考:文档说明
SRT 抗弱网示例:文档说明

帮助和支持

本页内容是否解决了您的问题?

填写满意度调查问卷,共创更好文档体验。

文档反馈