一、关闭WebSocket连接
要断开WebSocket连接，需要一个端点断开底层的TCP连接。端点需要通过某种方式来完全关闭TCP连接，例如TLS会话，并适当的丢弃未接收完毕的数据。端点也在必要时可以通过一些有效的方式断开连接，如在受到攻击时。
在一般情况下，底层TCP连接应先被服务端断开，以便保持TIME_WAIT状态。这是为了防止其在2个最大分节生命期（1~4分钟，Windows操作系统为4分钟）之内重新打开，否则可能会由于接到一个高序列的SYN包而重新打开连接。在一些异常的情况下（如在一段时间内未收到服务器端TCP关闭帧），客户端可以关闭TCP连接。如果服务器发出关闭指令，则它需要立即关闭连接。而客户端发出关闭指令需要等待服务器发送的TCP关闭帧。
二、关闭握手阶段
关闭握手阶段需要一个状态码和一个可选的关闭原因，端点必须发送一个关闭控制帧，并设置状态码和关闭原因。一旦端点发送并接收了关闭帧，就需要按上节中的方法关闭WebSocket连接。
三、关闭握手阶段开始
当接收或发送关闭帧后，代表关闭握手阶段开始，此时WebSocket连接进入到CLOSING状态。
四、关闭WebSocket连接结束
当底层TCP连接关闭时，代表WebSocket连接已关闭，此时WebSocket连接状态改为CLOSED。如果TCP连接在WebSocket关闭握手结束后断开，则此次WebSocket为一次完整的（cleanly）关闭。
如果WebSocket连接未能建立，它仍叫做连接关闭，但不是完整的。
五、关闭码
关闭帧可以包含一个关闭码和一个关闭原因。关闭帧可以由任何一方发起，也可以双方同时发起。若关闭帧没有指明关闭码，则认为关闭码为1005，如果WebSocket连接断开，而没有任何关闭帧（如底层传输时丢帧），则认为关闭码为1006。
注意：双方发送的关闭码可能不一致。例如，对方发送了一个关闭帧，但本地程序还没有将数据及关闭帧从socket接收缓存中读取出来，然后本地程序决定发送一个关闭帧，双方都会发送并接收到一个关闭帧并不会再次发送关闭帧（即只进行一次收发，即使不是发过关闭帧后收到的帧）。
六、关闭原因
关闭原因是可选的，跟在关闭码后面，为UTF-8编码的数据，并未对其内容做详细的定义。如果没有设置关闭原因，则关闭原因是一个空的字符串。
注意：同关闭码一样，双方发送的关闭原因可能不一致。
七、强制关闭连接
一些情况会引起强制关闭连接，当情况发生时，客户端需要关闭连接并将错误返回给用户（如控制台中报错等），同样，服务器需要关闭连接并将问题记录在日志中。
如果WebSocket连接建立在端点需要强制关闭连接之前，端点需要在处理关闭帧之前发送关闭帧并发送正确的关闭码。当强制关闭连接后，端点不能再次尝试向对方发送任何数据（包括关闭帧）。
除了上述情况或指定的应用层协议（如WebSocket API）外，客户端不应该断开连接。
八、关闭码
1000 正常关闭
1001 端点丢失，如服务器宕机或浏览器切换其他页面
1002 协议错误
1003 数据类型错误（例如端点只能处理文本，但传来了二进制消息）
1004 保留
1005 保留，禁止由端点发送此类型关闭帧，它是用来当端点没有表明关闭码时的默认关闭码。
1006 保留，禁止由端点发送此类型关闭帧，它是用来当端点未发送关闭帧，连接异常断开时使用。
1007 数据内容错误（如在text帧中非utf-8编码的数据）
1008 端点已接收消息，但违反其策略。当没有更好的关闭码（1003或1009）的时候用此关闭码或者不希望显示错误细节。
1009 内容过长
1010 客户端期望服务器协商一个或多个扩展，但这些扩展并未在WebSocket握手响应中返回。
1011 遇到未知情况无法执行请求
1015 保留，禁止由端点发送此类型关闭帧，它会在TLS握手失败（如证书验证失败）时返回。
保留关闭码
0-999 尚未使用
1000-2999 协议保留，用于未来版本、扩展等
3000-3999 为库、框架、应用程序保留，这些状态码可在IANA中注册，这些状态码并未在此协议中实现。
4000-4999 私有保留，不可被注册。用于开发者自定义关闭码。