Cloudflare Tunnel · WebSocket · Help

Cloudflare Tunnel: WebSocket 1006 while the page loads

Trace the WebSocket handshake to the origin when live updates fail but ordinary HTTP requests still work.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

WebSocket code 1006 describes an abnormal closure but does not identify its cause. First determine whether the handshake fails or an established connection closes later. HTTP 400, access denial and a login redirect require different checks. Compare the browser request with origin logs at the same time; the reported successful HTTP/2 comparison concerns connector transport and is not a universal repair.

Source basis: Q1 · Q2 · Q3

Applies to
Covers WebSockets through Cloudflare Tunnel. The original Home Assistant add-on report does not establish an exact cloudflared version, and its transport workaround remains case specific.
How to verify the result
The WebSocket handshake succeeds, a harmless live update reaches the application, and the connection remains stable through the previously problematic period with access controls retained.
Your first check

What response does the first WebSocket handshake receive?

Inspect the specific browser request and origin log. HTTP 400 for a missing Upgrade differs from sign-in, 403 rejection or a later disconnect.

The interface loads, but status information stops updating or the application repeatedly reconnects. The browser reports WebSocket code 1006; the origin may log HTTP 400 with a missing Upgrade header. A Home Assistant report describes this combination behind Cloudflare Tunnel. Its reported transport comparison is a case-specific lead, not a universal repair. Q1

1006 does not identify the cause

Start with connection establishment. A sign-in redirect, access denial, malformed upgrade and later disconnect are different situations. Cloudflare applies the relevant HTTP request controls to the initial WebSocket handshake. Q2 Establish what happened at that stage before changing connection-lifetime settings.

Separate establishment from ongoing operation

  1. Find the affected request. In browser network tools, identify the WebSocket path. Record status, time and how long the connection remained open. Do not copy full URLs containing session tokens into a support enquiry.
  2. Classify the first response. A redirect to sign-in points initially towards authentication handling. A 403 calls for correlation with access rules. HTTP 400 specifically naming a missing upgrade leads instead towards request headers and proxy forwarding.
  3. Compare the origin evidence. Determine which request arrived at the origin at the same time. Compare it with an authorised direct test using an appropriate hostname. A working home page does not replace a test of this particular WebSocket endpoint.
  4. List intermediate components. Include additional reverse proxies, access layers and relevant header rules. Look for the first point where the expected request changes or receives a different response. Avoid changing several layers simultaneously.
  5. Test the transport hypothesis narrowly. If the observations match the original report, a controlled connector-transport comparison may be useful. --protocol http2 controls the Cloudflare-facing connection; it does not automatically enable HTTP/2 to the origin. Q3 Review effects on other routes and required UDP services.

Verify a useful connection

After a correction, confirm more than a successful first handshake. Observe a harmless live update and check that the connection remains usable. A subsequent idle disconnect is a separate finding and should not automatically be treated as evidence that the original header problem remains.

For handoff, prepare the browser response, sanitised endpoint path, origin error, tunnel version and proxy chain. State clearly whether failure occurs before or after establishment. Preserve intended access controls during the comparison so that a seemingly successful test does not merely bypass the application's real sign-in path.

Frequently asked questions

Does 1006 prove a Cloudflare fault?

No. The establishment response and correlated logs are needed to locate the failing stage.

Should I add an Upgrade header to every request?

That is not a useful general repair. Establish whether and where an actual WebSocket request is being mishandled first.

Describe your case

Support with this issue

We can trace the handshake through access controls, the tunnel and the origin.

Describe your case →Related service: Data & improvements

Sources