Knowledge base · TOPIC-11

Why WebSocket can fail when HTTPS works

Short answer: ordinary HTTPS and WebSocket share parts of the path, but WebSocket adds an Upgrade handshake and a persistent bidirectional channel. An intermediary can allow short requests while rejecting or terminating that channel.

RFC 6455 defines the opening handshake and 101 Switching Protocols response. OpenAI also documents secure WebSocket considerations for ChatGPT and Codex. These facts establish a cause model, not the cause of one user’s failure.

Begin with the shared layers: DNS, TCP, and certificate-validated TLS. Then use only a provider-approved, bounded WebSocket test when one exists. Record timestamps and avoid arbitrary endpoint probing. A successful handshake still does not prove long-lived stability; a failed handshake does not identify the terminating hop.

Tivor Open Probe V0.1 does not measure WebSocket, SSE, or long-lived connections. Its OpenAI path measures governed DNS, TCP, TLS, anonymous HTTPS, and repeated short-window reliability. The Scanner cannot reproduce a native agent channel. Open Probe can establish the earlier layers and clearly marks the remaining gap. Related: Codex waiting for network.