如何诊断Blazor Server端客户端多次意外连接/断开问题

算力阿峰

2026-7-31

Blazor Server 频繁微型断开/重连问题排查方案

一、客户端侧信息收集

浏览器开发者工具日志：让出现问题的用户打开浏览器开发者工具（F12），切换到「Network」标签的「WS」分类，实时监控Blazor的WebSocket连接，记录断开时的帧信息、状态码，以及「Console」标签中Blazor/SignalR相关的错误提示（比如重连触发的原因、错误代码），要求用户保存这些日志文件。
客户端环境排查：收集用户的浏览器版本、是否启用了代理/防火墙、是否安装了广告拦截或隐私类插件（这类插件可能干扰WebSocket长连接），同时记录客户端设备的网络类型（有线/无线）。
增强客户端日志：在Blazor的components-reconnect-modal组件中添加自定义JS逻辑，监听navigator.onLine状态变化，记录网络在线/离线的时间点；同时通过SignalR的客户端onclose事件捕获连接断开的具体原因，将这些日志和服务器端CircuitHandler的日志做时间对比，判断是客户端网络波动还是服务器端触发的断开。

IIS WebSocket配置检查：确保IIS已启用WebSocket协议，并且空闲超时设置大于Blazor的Circuit心跳间隔（默认Blazor心跳为30秒，建议将IIS WebSocket空闲超时设为5分钟以上）。可通过命令行查看当前配置：
```
appcmd list config /section:websocket
```
若需要修改，可执行：
```
appcmd set config /section:websocket /pingInterval:00:05:00 /pingTimeout:00:01:00
```
Windows事件日志分析：查看服务器的「系统日志」中TCP/IP相关的错误（如TCP重置、连接超时），以及「应用程序日志」中IIS、ASP.NET Core的报错信息，重点关注Circuit断开是否由服务器端主动触发（如资源不足、Circuit回收）。
启用Blazor详细日志：在appsettings.json中调整日志级别，获取SignalR和Blazor Server的详细运行日志：
```
{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore.SignalR": "Debug",
      "Microsoft.AspNetCore.Components.Server": "Debug"
    }
  }
}
```
这些日志会记录Circuit的创建、断开、重连的完整流程，包括断开的具体触发源。

基础连通性测试：
- 在客户端执行ping -t your-server-domain，持续测试10-15分钟，记录丢包率和延迟波动情况；
- 用tracert your-server-domain追踪路由，查看是否有节点存在高延迟或丢包；
- 用PowerShell命令测试WebSocket端口连通性：
```
Test-NetConnection your-server-domain -Port 443 -InformationLevel Detailed
```
中间设备配置检查：排查站点的防火墙、负载均衡器、代理服务器，确认是否存在针对长连接的限流、超时或中断策略（部分设备会主动断开空闲时间较短的长连接，即使Blazor有心跳也可能被误判）。
WebSocket连通性测试：使用wscat工具（需安装Node.js）在客户端直接连接Blazor的SignalR端点，模拟用户连接并观察是否会出现断开：
```
wscat -c wss://your-server-domain/_blazor?id=your-circuit-id
```
（注：circuit-id可从浏览器开发者工具的WS连接URL中获取）

浏览器开发者工具：直接捕获WebSocket帧、错误日志，无需额外安装，是最便捷的客户端排查工具；
WireShark：在客户端或服务器端抓取网络包，过滤websocket或tcp流量，分析断开时的包类型（FIN/RST），判断是主动断开还是异常中断；
PerfView：在服务器端收集性能数据，排查是否存在CPU、内存、IO突增导致的Circuit断开，或ASP.NET Core线程池瓶颈；
IIS日志：查看IIS访问日志中WebSocket连接的请求记录，分析断开时的状态码和请求详情。

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