In the WebSocket protocol, which close status codes must never appear in a Close frame on the wire, and why do they exist?

## Two namespaces that look like one WebSocket close status codes are 2-byte unsigned integers, and every example you meet is in the 1000s, so they read like one flat list. They are not. The range splits into codes that travel and codes that never do. - **Wire codes** are put in a Close frame's body by an endpoint that is choosing to close and wants to say why. `1000` normal closure, `1001` going away, `1002` protocol error and `1011` unexpected condition on the server are the general-purpose ones. - **Reserved codes** must not be set as a status code in a Close control frame by any endpoint. They are *report* values: something a local API hands the application to describe a situation in which no status arrived. An endpoint that put a reserved code into a frame would be violating the specification, and a peer would be entitled to treat it as a protocol error. ## The three reserved codes | Code | What it reports | What was on the wire | |---|---|---| | `1005` | No status code was present | A Close frame **did** arrive, with an empty body | | `1006` | The connection closed abnormally | **No Close frame** was sent or received at all | | `1015` | The TLS handshake failed | No WebSocket connection was ever established | The distinction between the first two is the one that separates a candidate who has read the specification from one who has only seen the codes in a log. `1005` means a Close frame arrived and simply said nothing. `1006` means the closing handshake never happened. ## Why 1006 is a trick question Ask "the peer closed with `1006` — what reason did it give?" and a weak answer starts guessing at causes. The correct answer is that the peer gave nothing, because the peer sent no Close frame. `1006` is the application's own record of an absence: 1. Something ended the connection without a closing handshake — a transport reset, a process that died mid-write, an intermediary that dropped the flow's state, a path that went away. 2. There is no Close frame, so there is no body. 3. There is no body, so there is no status code and no reason string. 4. The receiving side still has to tell the application *something*, so it reports the reserved value that means exactly "this ended abnormally". The absence of a reason string is not a gap in the API. It is the honest consequence of there being no frame to read one from. ## What you actually learn from an abnormal close A `1006` is a fact about the *ending*, not a diagnosis of the cause. It tells you the closing handshake did not happen and nothing more, so treat it as the start of an investigation: - It does **not** distinguish a peer that crashed from a path that was cut; both produce the same value. - It does **not** mean the peer is at fault — an intermediary between you may have dropped a connection that both endpoints believed was healthy. - A rising rate of `1006` against a steady rate of `1000` and `1001` is the signal worth alerting on, because clean closes are the ones you can attribute. - If your own endpoint can end connections cleanly during shutdown, every `1006` left in the data is one you did not cause, which makes the number worth far more. ## Reading a close code correctly When you see a close code in a log, ask two questions in order. First: **is this a wire code or a reserved one?** If it is reserved, no peer chose it and there is no point looking for intent behind it. Second: **if it is a wire code, which side sent it?** `1011` from your server and `1011` from the peer are opposite findings, and the code alone does not say which endpoint put it in the frame. Record the direction alongside the code, or half of your close-code data will be unattributable.