Blazor Server对接Azure SignalR Service无原因随机断连问题求助

配置问题排查 #

• 首先排查超时对齐问题：你当前配置的ClientTimeoutInterval为10分钟，但Azure SignalR Service默认的空闲断连超时为300秒（5分钟），会出现Azure SignalR服务端已经主动断开连接，但是你的应用服务端还未判定超时的情况，是最可能的随机断连诱因。
• 其次检查Kubernetes集群粘性会话配置：你设置了ServerStickyMode.Required要求会话必须粘滞到原服务端，但如果K8s的Ingress/Service没有开启粘性会话，或者会话保持时长小于你配置的Circuit保留时间，会导致客户端重连时落到其他Pod上，找不到原有的Circuit状态，就会出现日志中「重连尝试被服务端拒绝」的报错。
• 最后检查依赖版本：.NET 5已经停止官方支持，你使用的Microsoft.Azure.SignalR 1.11.0存在多个已知的连接稳定性bug，后续小版本已经修复相关问题。

获取详细断连日志的方法 #

• 服务端开启SignalR全链路Debug日志，在appsettings.json中添加如下配置：

{
  "Logging": {
    "LogLevel": {
      "Microsoft.AspNetCore.SignalR": "Debug",
      "Microsoft.AspNetCore.Http.Connections": "Debug",
      "Microsoft.Azure.SignalR": "Debug"
    }
  }
}

• 开启Azure SignalR资源日志：在Azure门户中找到对应的SignalR资源，开启资源日志导出功能，勾选ConnectionLogs和MessagingLogs两个日志类别，将日志导出到Log Analytics工作区，即可查看连接断开的底层触发原因，包括是否为限流、网络波动、服务端主动断开等场景。
• 客户端开启Blazor详细日志：修改blazor.server.js的引用方式，手动启动并开启Debug级日志：

<script src="_framework/blazor.server.js" autostart="false"></script>
<script>
  Blazor.start({
    logLevel: "Debug"
  });
</script>

降低断连概率的优化方案 #

• 对齐全链路超时配置：在Azure门户中将SignalR资源的空闲超时调整为不小于10分钟，同时在SignalR配置中添加KeepAliveInterval = TimeSpan.FromMinutes(2)，保证心跳包在空闲超时前发送，避免被中间网络设备主动掐断连接。
• 修正Kubernetes粘性会话配置：如果使用Nginx Ingress，添加如下注解保证会话粘滞时长和Circuit保留时间对齐：

annotations:
  nginx.ingress.kubernetes.io/affinity: cookie
  nginx.ingress.kubernetes.io/affinity-mode: persistent
  nginx.ingress.kubernetes.io/session-cookie-expires: "3600"

• 升级依赖组件：将Microsoft.Azure.SignalR升级到1.11.x的最新稳定版，有条件可将.NET运行时升级到.NET 6/8等LTS版本，修复已知的连接稳定性问题。
• 自定义Blazor重连逻辑：配置自动重连、重连失败自动刷新页面的逻辑，降低用户感知：

Blazor.start({
  reconnectionOptions: {
    maxRetries: 10,
    retryIntervalMilliseconds: 1000
  },
  reconnectionHandler: {
    onReconnectionFailed: (error) => {
      window.location.reload();
    }
  }
});

内容的提问来源于stack exchange，提问作者Sven Boris Bornemann