What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
WebSocket close code 1006 means the connection ended abnormally without a completed close handshake. It does not identify whether FastAPI, the client, the ASGI server, a proxy, or the upstream model connection caused the drop. Diagnose the layer by comparing the last successful traffic with client events, application errors, server logs, intermediary events, and provider timing.
What WebSocket close code 1006 means
RFC 6455 reserves 1006 for applications to report an abnormal closure, such as a connection ending without a Close control frame being sent or received. An endpoint must not transmit 1006 as the status in a WebSocket Close frame. It is therefore a symptom of an unclean connection ending, not a diagnosis of its cause. RFC 6455
![Computer Networking Bible: [3 in 1] The Complete Crash Course to Effectively Design, Implement and Manage Networks. Including Sections on Security, Performance and Scalability](https://m.media-amazon.com/images/I/41H4YJnxKgL._SL160_.jpg)
This differs from explicit close statuses such as 1000, which indicates normal closure, and 1001, which indicates that an endpoint is going away. Those codes can be carried in a Close frame; 1006 is reserved for reporting that the handshake did not complete.
Why it can happen during LLM streaming
A streaming route depends on several pieces staying responsive: the client connection, application code, ASGI server, any intermediary network equipment, and the upstream model request. If one fails before a close handshake completes, the client may report 1006. The code itself cannot distinguish among those layers.
#1 Best Overall
A quiet connection or intermediary policy
If disconnects recur after a similar period with no messages, inspect WebSocket ping/pong behavior and the idle-connection policies of any proxy, load balancer, or CDN in the path. The timing is a clue to investigate, not proof of a particular timeout or vendor default. Confirm the configuration actually deployed in your environment.
Blocking work in the application
If failures coincide with synchronous model calls or CPU-heavy work, check whether that work prevents the ASGI event loop from servicing the socket. Under concurrency, also examine event-loop lag and backpressure. These are possible mechanisms to test against telemetry; a 1006 report alone does not establish that blocking occurred.
Upstream or infrastructure interruption
An upstream request may stop producing data, be cancelled, or fail while the client connection is still open. A server or intermediary may also end the transport. Compare timestamps for the last token or upstream response, application exceptions or cancellation, ASGI server messages, and intermediary events to see where the sequence first changes.
Free tools Windows power users keep installed
One-click scans. No signup required.
How to investigate a 1006 disconnect
- Record the client event. Capture the close code, any reason reported by the client, connection state, timestamp, and time of the last received message. A 1006 report is consistent with no Close frame being received, but does not show which participant or network component failed first.
- Handle disconnects in the route. FastAPI documents that receiving from a socket that has closed raises
WebSocketDisconnect. Catch it around the receive or stream loop so an ordinary client departure is handled cleanly rather than surfacing as a misleading unhandled application error. FastAPI WebSockets documentation - Compare quiet intervals. Note how long the connection was idle before each drop and whether the pattern recurs. Use that observation to check transport liveness and intermediary idle policies; do not infer a specific timeout setting from timing alone.
- Check application responsiveness. Correlate the drop with synchronous model work, CPU-heavy code, event-loop lag, and concurrency. If the socket stops being serviced during blocking work, investigate scheduling and backpressure in the relevant code path.
- Correlate logs across layers. Compare browser close and error events with application exceptions, ASGI server logs, proxy or load-balancer events, and upstream provider timing. The earliest correlated failure points to the next layer to inspect; a client-side 1006 by itself does not.
- Change one implicated behavior at a time. Adjust the code or configuration at the layer supported by the evidence, then check whether the disconnect timing or pattern changes. Record the deployed FastAPI, Starlette, Uvicorn, WebSocket implementation, proxy, and provider versions and configuration when comparing results.
Handle intentional closes correctly in FastAPI and Starlette
FastAPI exposes Starlette’s WebSocket implementation. Routes can accept a connection, receive messages, and send text, bytes, or JSON; a receive on a closed connection can raise WebSocketDisconnect. Catch that exception where the route reads from the socket. FastAPI WebSockets documentation
When the application intentionally closes a connection, use a valid close status rather than 1006. Starlette documents close(code=1000, reason=None); its iterator helpers stop when WebSocketDisconnect is raised. For raw ASGI message handling, Starlette recommends its wrapped send() and receive() methods so WebSocket state stays updated. Starlette WebSockets documentation
Choose a fix based on the evidence
There is no single timeout or keepalive value established as a universal fix. Match the remedy to the layer implicated by correlated logs:
- Application scheduling: If evidence points to blocked socket servicing, address the blocking work or scheduling path and observe event-loop responsiveness.
- Transport liveness: If a repeatable quiet interval is implicated, verify the actual ping/pong behavior and connection handling in the deployed stack.
- Intermediary idle policy: If intermediary logs or configuration point to an idle connection being ended, inspect that specific intermediary’s policy and how it applies to the route.
- Upstream request or cancellation: If provider timing or application cancellation aligns with the disconnect, inspect the stream lifecycle and ensure cancellation and resource limits remain timely.
Do not copy a timeout value from an unrelated deployment. The useful test is whether a targeted change at the implicated layer changes the failure pattern, while preserving cancellation and resource controls.
Quick Recap
Best Value
- Used Book in Good Condition
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
