Docker容器中运行.NET 8 Worker Service的ClientWebSocket一分钟后抛出WebSocketException求助

遇到这种容器内定时断开的问题，我太有共鸣了！大概率是网络层面的空闲超时或者容器环境的默认配置在搞鬼，毕竟本地运行正常、只有容器里出问题，基本可以锁定是容器相关的网络差异。我给你梳理几个常见的排查方向和解决办法：

1. 优先排查：容器网络的空闲超时（最常见原因） #

很多容器编排环境（包括Docker本身、云服务商的负载均衡，甚至是宿主机的防火墙）都会对空闲连接设置默认60秒的超时时间。你的WebSocket如果在一分钟内没有数据传输，中间的网络组件就会强制断开连接，而本地运行时没有这些中间NAT/负载层，所以不会触发这个问题。

解决办法：实现符合WebSocket规范的PING/PONG心跳机制，定时发送心跳包保持连接活跃，代码可以这么改：

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    var ws = new ClientWebSocket();
    await ws.ConnectAsync(new Uri("ws://url.com/stream"), stoppingToken);
    
    // 设置心跳间隔为30秒（比60秒超时短，确保连接不会被判定为空闲）
    var keepAliveInterval = TimeSpan.FromSeconds(30);
    var lastActivityTime = DateTime.UtcNow;

    while (!stoppingToken.IsCancellationRequested)
    {
        // 检查是否需要发送心跳
        if (DateTime.UtcNow - lastActivityTime > keepAliveInterval)
        {
            await ws.SendAsync(Array.Empty<byte>(), WebSocketMessageType.Ping, true, stoppingToken);
            lastActivityTime = DateTime.UtcNow;
            logger.LogInformation("Sent WebSocket ping to keep connection alive");
        }

        var buffer = WebSocket.CreateClientBuffer(1024, 1024);
        var result = await ws.ReceiveAsync(buffer, stoppingToken);
        
        lastActivityTime = DateTime.UtcNow; // 收到任何消息（包括PONG）都更新活动时间

        switch (result.MessageType)
        {
            case WebSocketMessageType.Close:
                logger.LogWarning("Socket closed by remote");
                await ws.CloseAsync(WebSocketCloseStatus.NormalClosure, "Closing", stoppingToken);
                break;
            case WebSocketMessageType.Pong:
                logger.LogInformation("Received WebSocket pong");
                continue;
            case WebSocketMessageType.Text:
                var json = Encoding.UTF8.GetString(buffer.ToArray(), 0, result.Count);
                logger.LogInformation("Message received: {Message}", json);
                break;
        }
    }
}

注意：一定要用WebSocketMessageType.Ping类型发送，而不是自己发个文本消息，这样服务器会自动返回PONG，符合协议规范，兼容性更好。

2. 尝试开启TCP层面的Keep-Alive #

如果应用层的PING/PONG不管用，可以试试开启底层TCP的Keep-Alive，让操作系统自动发送心跳包，不需要应用层处理。不过ClientWebSocket没有直接暴露底层Socket，需要用反射来设置，代码示例：

protected override async Task ExecuteAsync(CancellationToken stoppingToken)
{
    var ws = new ClientWebSocket();
    await ws.ConnectAsync(new Uri("ws://url.com/stream"), stoppingToken);

    // 通过反射获取底层Socket，设置TCP Keep-Alive
    var innerWebSocketField = typeof(ClientWebSocket).GetField("_innerWebSocket", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance);
    if (innerWebSocketField != null)
    {
        var managedWebSocket = innerWebSocketField.GetValue(ws);
        var socketField = managedWebSocket.GetType().GetField("_socket", System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.Instance);
        if (socketField != null)
        {
            var socket = (System.Net.Sockets.Socket)socketField.GetValue(managedWebSocket);
            socket.SetSocketOption(System.Net.Sockets.SocketOptionLevel.Socket, System.Net.Sockets.SocketOptionName.KeepAlive, true);
            // 设置TCP Keep-Alive参数：60秒后开始发送心跳，间隔30秒，重试3次
            socket.SetSocketOption(System.Net.Sockets.SocketOptionLevel.Tcp, System.Net.Sockets.SocketOptionName.TcpKeepAliveTime, 60);
            socket.SetSocketOption(System.Net.Sockets.SocketOptionLevel.Tcp, System.Net.Sockets.SocketOptionName.TcpKeepAliveInterval, 30);
            socket.SetSocketOption(System.Net.Sockets.SocketOptionLevel.Tcp, System.Net.Sockets.SocketOptionName.TcpKeepAliveRetryCount, 3);
            logger.LogInformation("TCP Keep-Alive enabled");
        }
    }

    // 后面的接收逻辑和之前一致即可
}

这种方法更底层，适合那些服务器不支持WebSocket PING/PONG的场景。

3. 排查Docker网络模式 #

如果上面的方法都没用，可以试试切换Docker的网络模式，比如用host模式（仅限Linux容器），让容器直接使用宿主机的网络栈，避免Docker bridge网络的NAT超时。测试命令：

docker run --network=host your-image-name

不过这个方法有安全风险，生产环境不建议随便用，但可以用来快速验证是不是Docker网络层的问题。

4. 最后确认：服务器端是否有特殊配置 #

虽然你说本地运行没问题，但还是可以确认一下服务器端是否对来自容器的连接有不同的超时设置？比如服务器的防火墙、负载均衡是否针对容器IP段设置了更短的超时？不过这个可能性比较小，但可以排查一下服务器的日志。

按照这个顺序排查，应该能解决问题！我之前遇到过几乎一模一样的情况，就是用应用层PING/PONG解决的。

备注：内容来源于stack exchange，提问作者rperwinski