关闭代码1006是一种特殊代码，表示浏览器实现异常（本地）关闭了连接。

如果您的浏览器客户端报告 close code 1006，那么您应该查看websocket.onerror(evt)事件以获取详细信息。

但是，Chrome 很少会1006向 Javascript 端报告任何关闭代码的原因。这可能是由于 WebSocket 规范中的客户端安全规则可以防止滥用 WebSocket。（例如使用它来扫描目标服务器上的开放端口，或为拒绝服务攻击生成大量连接）。

请注意，1006如果在 HTTP 升级到 Websocket 期间出现错误（这是技术上“连接”WebSocket 之前的步骤），Chrome 通常会报告关闭代码。由于错误的身份验证或授权，或错误的协议使用（例如请求子协议，但服务器本身不支持相同的子协议），甚至尝试与不是 WebSocket 的服务器位置通信（例如尝试连接到ws://images.google.com/)

从根本上说，如果你看到一个关闭的代码1006，你有一个非常低级的 WebSocket 错误（类似于“无法打开文件”或“套接字错误”），并不是真正针对用户的，因为它指向一个低级问题与您的代码和实现。修复您的低级问题，然后当您连接时，您可以包含更合理的错误代码。您可以根据项目的范围或严重性来实现这一点。示例：信息和警告级别是项目特定协议的一部分，不会导致连接终止。对于严重或致命的消息报告，还使用您的项目协议来传达您想要的尽可能多的细节，然后使用 WebSocket 关闭流的有限功能关闭连接。

请注意，WebSocket 关闭代码的定义非常严格，关闭原因短语/消息的长度不能超过 123 个字符（这是一个有意的 WebSocket 限制）。

但并不是所有的都丢失了，如果您只是出于调试原因想要这些信息，那么关闭的详细信息及其根本原因通常会在 Chrome 的 Javascript 控制台中以相当多的详细信息报告。

在我和可能的@BIOHAZARD 案例中，它是nginx proxy timeout. 默认情况60下，套接字中没有活动是秒

我将其更改为 24hnginx并解决了问题

proxy_read_timeout 86400s;
proxy_send_timeout 86400s;

当 Chrome 不符合 WebSocket 标准时，情况似乎就是这种情况。当服务器发起关闭并向客户端发送关闭帧时，Chrome 认为这是一个错误，并向 JS 端报告代码 1006 和无原因消息。在我的测试中，Chrome 从不响应服务器启动的关闭帧（关闭代码 1000），这表明代码 1006 可能意味着 Chrome 正在报告自己的内部错误。

PS Firefox v57.00 正确处理了这种情况，并成功地将服务器的原因消息传递给了 JS 端。

认为这对其他人可能很方便。知道正则表达式很有用，孩子们。呆在学校。

编辑：把它变成了一个方便的花花公子功能！

let specificStatusCodeMappings = {
    '1000': 'Normal Closure',
    '1001': 'Going Away',
    '1002': 'Protocol Error',
    '1003': 'Unsupported Data',
    '1004': '(For future)',
    '1005': 'No Status Received',
    '1006': 'Abnormal Closure',
    '1007': 'Invalid frame payload data',
    '1008': 'Policy Violation',
    '1009': 'Message too big',
    '1010': 'Missing Extension',
    '1011': 'Internal Error',
    '1012': 'Service Restart',
    '1013': 'Try Again Later',
    '1014': 'Bad Gateway',
    '1015': 'TLS Handshake'
};

function getStatusCodeString(code) {
    if (code >= 0 && code <= 999) {
        return '(Unused)';
    } else if (code >= 1016) {
        if (code <= 1999) {
            return '(For WebSocket standard)';
        } else if (code <= 2999) {
            return '(For WebSocket extensions)';
        } else if (code <= 3999) {
            return '(For libraries and frameworks)';
        } else if (code <= 4999) {
            return '(For applications)';
        }
    }
    if (typeof(specificStatusCodeMappings[code]) !== 'undefined') {
        return specificStatusCodeMappings[code];
    }
    return '(Unknown)';
}

用法：

getStatusCodeString(1006); //'Abnormal Closure'

{
    '0-999': '(Unused)',
    '1016-1999': '(For WebSocket standard)',
    '2000-2999': '(For WebSocket extensions)',
    '3000-3999': '(For libraries and frameworks)',
    '4000-4999': '(For applications)'
}

{
    '1000': 'Normal Closure',
    '1001': 'Going Away',
    '1002': 'Protocol Error',
    '1003': 'Unsupported Data',
    '1004': '(For future)',
    '1005': 'No Status Received',
    '1006': 'Abnormal Closure',
    '1007': 'Invalid frame payload data',
    '1008': 'Policy Violation',
    '1009': 'Message too big',
    '1010': 'Missing Extension',
    '1011': 'Internal Error',
    '1012': 'Service Restart',
    '1013': 'Try Again Later',
    '1014': 'Bad Gateway',
    '1015': 'TLS Handshake'
}

来源（为简洁起见略作修改）：https : //developer.mozilla.org/en-US/docs/Web/API/CloseEvent#Status_codes

在 nginx 代理下使用 Chrome 作为客户端并使用 golang gorilla websocket 作为服务器时出现错误

并且每隔 x 秒从服务器向客户端发送一些“ping”消息解决了问题

更新：哦，男孩，我在这个答案之后实现了几十个基于 websocket 的应用程序，每 5 秒从客户端 PINGING是保持与服务器连接的正确方法（我不知道当我建议从服务器 ping 时我在想什么）