多模态模型

AI 语音一直“正在连接”？用 RUM 排查 WebSocket 建连问题

2026 年 9 月 29 日

AI语音总卡在“正在连接”？本文教你一步步排查WebSocket建连疑难问题。核心内容：1. AI语音交互场景下建连问题的背景与排查难点2. 借助RUM记录握手信息定位问题范围的方法3. 通过Trace关联追踪服务端问题根因的流程

AI 语音交互中的

建连问题

Cloud Native

AI 语音一直“正在连接”？用 RUM 排查 WebSocket 建连问题

本图由AI生成

考虑这样一个智能眼镜语音助手场景：眼镜负责采音与播放，配套手机 App 通过 WebSocket 连接云端语音服务。用户按下眼镜上的语音键，问“今天需要带伞吗？”，却迟迟听不到回复；打开配套 App，页面停在“正在连接”，重试后偶尔恢复。模型侧指标看起来正常，常规接口中也找不到与这次操作对应的失败请求，问题该从哪里查？

对采用 WebSocket 的应用，这次等待可能发生在音频发出前的建连阶段。本文通过阿里云 CMS 2.0 用户体验监控（RUM）的自定义资源记录握手，确认连接结果、尝试耗时和受影响的用户环境；具备端云追踪条件后，再通过 Trace 检查对应的服务端处理。

语音助手需要持续上传音频、接收结果，还要处理用户打断，WebSocket 适合这类双向交互。

AI 语音一直“正在连接”？用 RUM 排查 WebSocket 建连问题配图 2

这里以 ASR、Agent、模型和 TTS 组成的级联语音架构为例，实时多模态模型可能合并部分环节。

握手记录：

连接结果与用户现场

Cloud Native

继续用上述示意场景说明。先确认本次语音操作触发了新连接，而不是复用已有连接，再从已采集的用户会话与操作找到对应握手记录。假设记录中有以下结果：

字段	示意值	能说明什么
`success`	`false`	本次握手未成功
`statusCode`	`403`	收到了 HTTP 拒绝响应
`errorMessage`	`auth-rejected`	按本文约定归类，具体拒绝原因仍需核查

这条记录将笼统的“AI 没有响应”收敛到握手拒绝，排查由此转向服务端的握手处理，而非模型推理。仅凭 403 还无法判断是否签名过期，具体原因需要进一步的诊断证据。

单条日志也能记录 403。接入 RUM 的价值，是将这个结果与已采集的用户会话、App 版本、设备和网络环境放在一起分析，判断影响范围，并为回归验证提供方向。按实际可用字段聚合，还可以观察异常是否集中出现：

聚合现象	继续核对
`429/rate-limited` 增多	网关限流规则、连接配额与同期尝试量
蜂窝网络中 `-1/transport-error` 集中	客户端诊断、网络切换与网关记录；分类本身不足以定位 DNS/TLS 根因
某个 App 版本技术失败增多	同口径下的网络、设备分布，以及版本变更和回归结果

Trace 关联：

网关与鉴权处理

Cloud Native

沿着前面的 403，握手资源携带的 Trace Context 可以关联实际采集的网关、鉴权 Span。Span 记录操作的耗时、状态和调用关系，既用于检查拒绝发生在哪个环节，也用于观察握手期间的鉴权、路由或初始化是否变慢。

若脱敏诊断证据指向签名过期，排查再转向凭据刷新、签名有效期和设备时间，并结合受影响的版本或用户环境做回归验证。

▍上下文传播与关联条件

Upgrade 请求的 traceparent 与 RUM 资源保留同一 Context。网关提取入站上下文后创建自己的 Span：入站标识为 trace-id=T, parent-id=A 时，网关使用 trace-id=T, span-id=B, parent=A，其中 A 是父标识，B 是网关自身的 Span ID。以下流程以服务端已接入追踪为前提。

AI 语音一直“正在连接”？用 RUM 排查 WebSocket 建连问题配图 3

这条流程将客户端的握手结果与服务端处理联系起来：端侧在请求和 RUM 资源中保留同一份 Trace Context，网关和鉴权服务则通过各自的 Span 记录处理过程。Context 提供关联标识，Span 提供处理耗时、状态和调用关系。在服务端追踪与后台关联配置生效后，就可以从一条握手记录继续核查对应的拒绝位置和处理耗时。

采集口径：

连接尝试、终态与指标

Cloud Native

前面的分析依赖口径一致的握手记录。将连接存活时间作为握手耗时，难以反映连接建立的快慢；多个回调重复上报，则会放大尝试量和失败数。因此，本文以一次连接尝试为采集单位，只统计发起连接到首个终态的耗时，并通过统一完成函数对回调去重，使每次尝试最多上报一条握手资源。

▍在首个终态结束计时

本文按 HTTP/1.1 Upgrade 建模：从 connect 开始，到 open、失败或主动终止等首个终态结束，形成一次 attempt（连接尝试）。每个 attempt 最多上报一次；open 后的关闭或失败不补报握手资源，重连另建 attempt。连接存活时间、消息收发和 AI 回合不计入这次握手耗时。

AI 语音一直“正在连接”？用 RUM 排查 WebSocket 建连问题配图 4

取消、超时和系统失败回调可能先后甚至并发到达。本文将终态事件收敛到统一完成函数，避免同一次尝试重复上报。取消底层连接前保存触发原因，可以区分用户退出与业务超时：前者归为主动终止，后者归为 timeout，系统取消回调本身不足以说明用户为何终止连接。replaced 仅表示未完成的旧 attempt 被替换，不代表全部重连。

▍保留能支撑排障的字段

资源类型采用 websocket，核心分析字段如下。

字段	含义与约定
`url`	脱敏后的连接地址，用于按 Endpoint 聚合
`success`	以 `open` 回调确认握手成功
`statusCode`	可用的 HTTP 状态码；无可用响应时，示例记为 `-1`
`errorMessage`	稳定、低基数的分类，如 `auth-rejected`、`timeout`、`cancelled`，不上传异常原文
`duration`	`connect` 到首个终态的毫秒数，使用单调时钟

客户端收到 101 后仍可能因 Upgrade 校验失败进入失败回调，因此本文以 open 确认握手成功。-1 表示没有可用 HTTP 响应，不直接代表网络故障；WebSocket Close Code 不写入该字段。错误分类是本文约定，不是产品固定枚举。

▍按结果分组统计

比较不同版本、网络和时间段的数据时，本文采用以下口径：

成功比例：成功数除以已上报终态的尝试总数，cancelled/replaced 保留在分母中，并单独展示占比。如另算排除主动放弃后的技术成功率，仅剔除已确认的业务主动终止，保留超时和原因不明的取消。
耗时分组：成功、失败和主动终止分别计算分位数，原因不明的事件保留独立分组。混算 P95 可能让快速取消掩盖成功连接变慢。
数据范围：注明采集范围、采样和时间窗口，统计结果仅覆盖已上报记录，不代表全部用户尝试。

接入方式

Cloud Native

以 Android 的 OkHttp 和 iOS 的 URLSessionWebSocketTask 为例，采集逻辑围绕建连过程与终态回调展开，两端遵循相同流程：

发起连接：为本次连接尝试开始计时，在握手请求发出前准备并注入 Trace Context。
处理终态：统一处理握手成功、失败或主动终止，保留首个结果并结束计时，避免后续回调重复上报。
上报资源：将连接结果、耗时及与握手请求一致的 Trace Context，通过 RUM 自定义资源接口上报。

以下为终态去重后的核心上报调用，结果字段、耗时测量对象及上下文由上述流程准备。

Android：

// resourceUrl 为脱敏地址，measuring 记录本次握手耗时（毫秒）。AlibabaCloudRum.reportCustomResource(    "websocket", resourceUrl, "GET", statusCode, errorMessage,    success, "OkHttp3", traceContext, measuring);

iOS：

// resourceURL 为脱敏地址，measure 记录本次握手耗时（毫秒）。_ = AlibabaCloudRUM.setCustomResource(    "websocket", success: success, url: resourceURL, method: "GET",    statusCode: statusCode, errorMessage: errorMessage,    provider: "URLSessionWebSocketTask", tracing: traceContext, measure: measure)

接入时保留原有业务回调、消息收发和连接管理逻辑。具体接口用法与配置说明参见文档中心：

Android：自定义资源：https://help.aliyun.com/zh/cms/cloudmonitor-2-0/monitor-android-applications-in-cms2-0#3a0d0455c6zma
iOS：自定义资源：https://help.aliyun.com/zh/cms/cloudmonitor-2-0/ios-sdk-configuration-reference#55cc64b1b0w9g

总结

Cloud Native

移动端 AI 语音交互停在“正在连接”时，排查可以从 WebSocket 握手开始。以一次连接尝试为单位记录结果和耗时，再结合 App 版本、设备与网络环境，可以逐步确认连接是否建立、异常是否集中出现在某类用户环境中，为这段等待找到更具体的排查方向。

阿里云 CMS 2.0 用户体验监控（RUM）的自定义资源接入方式，可以将握手结果与用户会话关联起来；具备端云关联条件后，再通过 Trace 检查对应的网关与鉴权处理。RUM 提供客户端的连接结果和用户现场，Trace 补充服务端的处理依据。沿着“用户反馈—握手记录—服务端处理”展开分析，可以将笼统的“AI 没有响应”逐步收敛为有明确范围、有具体线索的问题。