CLOUDFLARE ERROR 1042

Error 1042 — Bad WebSocket upgrade

Cloudflare Error 1042 means a WebSocket upgrade request failed. This typically happens when your Worker doesn't properly handle the WebSocket upgrade headers, or when a Durable Object's WebSocket hibernation API is misconfigured.

Common causes

  • Not returning a WebSocket pair from your fetch handler for upgrade requests
  • Missing the 'Upgrade: websocket' header check in your handler
  • Durable Object hibernation API misconfigured (acceptWebSocket vs accept)
  • Calling response.body without creating a WebSocketPair first
  • Cross-origin WebSocket requests blocked by CORS or CSP
  • WebSocket server closed before the client finished connecting

Symptoms

  • Client WebSocket connections fail with 'Error during WebSocket handshake'
  • Cloudflare dashboard shows 'Error 1042' on WebSocket upgrade requests
  • Durable Object is created but WebSocket never connects
  • Real-time features (chat, notifications) stop working intermittently

How to fix it

  • Check for upgrade headers: if (request.headers.get('Upgrade') !== 'websocket') return new Response('Expected WebSocket', { status: 426 })
  • Create a WebSocketPair and return the server side: const pair = new WebSocketPair(); return new Response(null, { status: 101, webSocket: pair[1] })
  • For Durable Objects, use the hibernation API: this.ctx.acceptWebSocket(webSocket) instead of webSocket.accept()
  • Handle WebSocket close events to clean up state: webSocket.addEventListener('close', () => { ... })
  • Deploy FlareLog's Tail Worker to capture WebSocket upgrade failures — you'll see the exact request headers that caused the 1042

How FlareLog helps

FlareLog's Tail Worker captures the full request context for Error 1042, including the upgrade headers. You can see which clients are failing, whether it's a CORS issue or a missing header, and correlate WebSocket failures with Durable Object state. For Durable Object WebSocket events, FlareLog's SDK captures open/close/message/error events with full context.

Catch Error 1042 with FlareLog →

FAQ

Why does my WebSocket work in dev but fail with Error 1042 in production?

wrangler dev handles WebSocket upgrades differently than the production runtime. In production, Cloudflare requires you to return a Response with status 101 and the webSocket property set. In dev, the upgrade may work without this. Always test WebSocket endpoints in production-like conditions (wrangler deploy to a preview URL).

Should I use Durable Object WebSocket hibernation?

Yes, if you have many idle WebSocket connections. The hibernation API (acceptWebSocket + serializeState) lets Cloudflare evict idle DOs from memory while keeping the WebSocket alive. This reduces memory usage and cost. Without hibernation, each open WebSocket keeps the DO in memory — 10k connections = 10k DOs = significant cost.

How do I debug WebSocket failures in production?

Without a Tail Worker, you're blind — Cloudflare's dashboard shows Error 1042 but not the request details. FlareLog's Tail Worker captures the upgrade request headers, the Durable Object ID, and the exact failure reason. You can search by client IP or DO ID to find patterns.

Related error codes