Android OkHttp3客户端无法接收C# WebSocket服务器消息排查

核心矛盾：你的C#服务器能正常和C#客户端通信，Android客户端也能正常对接在线WebSocket服务器，说明问题出在C#服务器与OkHttp3客户端的交互细节上，而非两端单独的功能问题。以下是针对性排查点：

1. 检查WebSocket帧的标准合规性 #

OkHttp3对WebSocket帧格式的校验比C#自带的WebSocket客户端更严格，常见错误点：

• 服务器向客户端发送的帧不能添加掩码：WebSocket协议规定，只有客户端→服务器的帧需要掩码，服务器→客户端的帧必须无掩码。如果你的C#服务器给所有帧加了掩码，C#客户端可能兼容，但OkHttp3会直接丢弃不符合规范的帧。
• 确认opcode类型正确：文本消息用0x1，二进制消息用0x2，不要混用或用错（比如用0x0续帧但没有初始帧）。
• 负载长度处理：当消息长度超过125字节时，要正确使用16位或64位扩展长度字段，不能直接用1字节长度字段。

建议用Wireshark抓包，对比服务器发给C#客户端和Android客户端的帧格式，一眼就能看出差异。

2. 验证服务器消息发送的有效性 #

• 确认服务器是在WebSocket握手完全完成后发送消息：不要在握手响应还没返回时就发消息，此时OkHttp3还未进入消息接收状态。
• 检查服务器发送消息时使用的WebSocket连接实例：确保是当前已成功握手的活跃连接，而非旧实例或未初始化的对象。
• 查看服务器日志，确认消息发送操作无异常：比如发送方法是否返回成功，有没有抛出IO异常或连接已关闭的错误。

3. 检查OkHttp3客户端的回调实现 #

• 确认WebSocketListener的onMessage方法重写正确：有没有拼写错误（比如写成onMessages），或者方法参数类型不对（文本消息是String，二进制是ByteString）。
• 在所有回调方法中添加日志：包括onOpen、onMessage、onClosing、onClosed、onFailure，排查是否触发了onFailure或意外关闭事件，而你没注意到。
• 避免在onMessage中做耗时操作：如果回调里有阻塞主线程的代码，会导致消息处理不及时，甚至被系统中断。

4. WSS证书的兼容性排查（若使用WSS） #

• 确认OkHttp3正确信任自签名证书：自定义SSLSocketFactory和X509TrustManager时，要确保逻辑正确，没有遗漏证书校验步骤。可以先暂时切换回明文WS测试，排除SSL层面的干扰。
• 抓包检查WSS握手过程：确认SSL握手完全完成，没有出现证书警告或握手失败的情况。部分Android版本对自签名证书的兼容性较差，可以尝试在AndroidManifest中添加android:networkSecurityConfig="@xml/network_security_config"，配置信任自签名证书。

5. 消息编码一致性检查 #

• 服务器发送文本消息时，必须使用UTF-8编码：OkHttp3默认用UTF-8解析文本帧，如果服务器用了GBK等其他编码，会导致解析失败，无法触发onMessage。可以先发送纯ASCII字符的简单消息测试，排除编码问题。

快速排查步骤 #

1. 用Wireshark抓包对比服务器发给两个客户端的帧格式，定位帧差异。
2. 在服务器发送代码处添加日志，记录帧的opcode、长度、是否带掩码等详细信息。
3. 在客户端所有WebSocket回调中添加日志，确认回调触发情况。

内容的提问来源于stack exchange，提问作者Mvltt