WebSocket 1006 Does Not Tell You Which Hop Broke
Read abnormal WebSocket closure as missing close-handshake evidence, then locate whether proxy setup or an established session failed.
WebSocket code 1006 reports abnormal closure without the expected Close frame. It is reserved: an endpoint must not send 1006 as the status in a WebSocket Close frame. Seeing it in an API event is not a server message identifying the proxy as the cause.
If the connection never opened
Follow setup in order: connection to the proxy, proxy negotiation, destination TLS for WSS, then the WebSocket opening handshake. A proxy challenge or tunnel rejection can stop the sequence before the WebSocket stage.
If it opened and carried messages
Record the usable duration and what happened before closure. Transport interruption, application shutdown and an intermediary policy can all leave a receiver without a clean close exchange.
Preserve the endpoint, session identifier, last activity and whether a normal Close frame was observed. Compare the browser or library's network errors with destination logs where you control them. The event code alone cannot identify the ISP, proxy operator or application server as the source.
A normal HTTPS page working through the same proxy checks a short exchange, not the lifetime of this session. Keep browser state and application code steady when changing the route; otherwise a successful retry is hard to interpret.
Repair the boundary supported by the evidence. Proxy authentication, TLS trust and application reconnection are separate jobs, and increasing every timeout cannot make 1006 identify one of them.