The reconnect callback runs and the new socket opens. That is transport recovery. It does not necessarily mean your subscriptions, message acknowledgements, or application session continued where the previous connection stopped.

Even the same proxy endpoint can produce a new outward connection. A changed exit IP can also trigger the destination's own session policy. Treat the new socket as a new connection and follow the application's documented recovery exchange. Decide whether the workflow should retain its proxy route when reconnecting.

Keep a little more than the last URL

Useful recovery state can include an authorized session identity, desired subscriptions, the last confirmed event identifier, and operations still awaiting acknowledgement. Those fields belong to the application protocol; WebSocket does not define a universal resume token.

Decide whether to resume from a cursor, obtain a fresh snapshot, or accept a gap. If an event source offers no replay interface, reconnecting faster cannot prove that no messages were missed.

Sending twice can mean doing twice

A message queued locally before a disconnect may never have left the client. Another may have reached the server while its acknowledgement was lost. Blindly resending every unconfirmed command treats those two cases as identical.

Use the service's request identifiers, idempotency support, or reconciliation mechanism where available. A transport reconnect cannot make an application action reversible or automatically deduplicate it.

Keep reconnect attempts bounded and paced according to the application's policy. RFC 6455 recommends backoff after abnormal closure; a fleet of clients retrying immediately can increase the outage's load.

Record which proxy route each attempt selected, but keep route recovery separate from application recovery. “Connected again” is useful evidence. “Caught up and ready to submit more work” needs the additional application exchange that establishes it.

ХӀокхунах тера йаззамаш