Flutter/Dart客户端连接Google Cloud Run部署服务的WebSocket通信失败求助

当前场景的异常排除边界 #

结合已验证的连通性结果：

• 本地部署的同服务端可被Dart客户端正常连接
• 部署在Cloud Run的同服务端可被其他类型客户端正常访问
• Dart客户端连接Cloud Run服务时，握手成功（连接状态进入OPEN/readyState=1），但发送首条消息后立即异常关闭，返回closeCode=1005

以上结果可排除服务端WebSocket逻辑错误、Cloud Run基础网络连通性故障两类基础问题。

高概率成因与解决方案 #

• permessage-deflate 压缩扩展协商不兼容（最常见触发原因）
  Dart 内置WebSocket实现、及官方web_socket_channel库，默认在握手阶段向服务端请求启用permessage-deflate帧压缩扩展。当服务部署在Google Cloud Run后，边缘代理与后端服务的压缩配置未完全对齐时，代理层在收到客户端发送的首个压缩数据帧时，会直接终止连接且不返回标准WebSocket关闭帧，最终导致Dart客户端捕获到无原因的1005关闭码。
  解决方法：建立连接时显式禁用压缩扩展：

  // 纯Dart环境WebSocket连接初始化
  final ws = await WebSocket.connect(
    '你的wss连接地址',
    compression: CompressionOptions.disabled,
  );
  

  若使用web_socket_channel包，需在构造IOWebSocketChannel时传入上述禁用压缩的配置项。

• 首条消息发送时序不兼容
  部分轻量WebSocket服务实现（如Quarkus原生WebSocket、aiohttp WebSocket）在连接握手完成后，需要数百毫秒的时间完成会话上下文初始化，若Dart客户端在连接状态变为OPEN后立即发送首条消息，会触发服务端解析错误断连。
  解决方法：连接建立后增加100~200ms的延迟，再发送首条测试消息验证连通性；同时手动设置Dart客户端的消息分片阈值为1MB以上，避免小消息被强制分片触发服务端解析异常。

• Cloud Run 代理层协议校验规则触发的断连
  Google Cloud Run 边缘代理对WebSocket帧的协议合规性要求高于本地直连场景，若Dart客户端发送的帧未严格遵循WebSocket RFC 6455规范（如附带非标准的预留扩展位），会被代理层直接拦截断连。
  验证方式：使用Python websockets测试客户端连接同一Cloud Run服务，对比Dart客户端发送的握手请求头与帧结构差异，修正不符合规范的配置项。

验证闭环 #

按上述方式禁用Dart客户端的压缩扩展后重新连接，若可正常完成消息收发，即可确认异常根因为压缩扩展协商不兼容。若仍存在断连问题，可开启Cloud Run服务端的请求日志，定位断连发生在代理层还是后端服务层，进一步缩小排查范围。

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