CF Pages WebSocket-only Worker intermittently fails with "Network connection lost" and "hung" after returning 101

Description

I am experiencing a runtime-level issue with a minimal Cloudflare Worker that only establishes a WebSocket connection and returns a 101 Switching Protocols response.

The issue can be reproduced with a minimal Worker containing no application-level networking logic, no streaming logic, and no additional asynchronous processing.

The primary error is:

Error: Network connection lost.

I also intermittently receive:

The Workers runtime canceled this request because it detected that your Worker's code had hung and would never generate a response.

The problem occurs even with the minimal reproduction below.

Environment

• Cloudflare Workers / Pages
• Compatibility date: 2026-09-08
• Wrangler: 4.90.0
• Runtime: current September 2026 runtime
• Reproduces intermittently across multiple test locations
• No application-level networking logic is involved in the reproduction below

Minimal reproduction

export default {
  async fetch(request, env, ctx) {
    if (request.headers.get("Upgrade") !== "websocket") {
      return new Response("WebSocket Runtime Minimal Test", {
        status: 200,
      });
    }

    console.log("[MINIMAL] fetch start");

    const pair = new WebSocketPair();
    const ws = pair[0];
    const client = pair[1];

    ws.accept();

    console.log("[MINIMAL] ws.accept completed");
    console.log("[MINIMAL] returning 101");

    return new Response(null, {
      status: 101,
      webSocket: client,
    });
  },
};

Observed behavior

The Worker consistently reaches:

[MINIMAL] fetch start
[MINIMAL] ws.accept completed
[MINIMAL] returning 101

The 101 response is returned, but the runtime may subsequently report:

Error: Network connection lost.

or:

Error: The Workers runtime canceled this request because it detected that your Worker's code had hung and would never generate a response.

In some cases the same request produces the hung error multiple times, while other requests produce Network connection lost.

Important observation

This reproduction contains no application-level networking or streaming implementation.

The Worker does only three relevant operations:

1. Create a WebSocketPair
2. Call accept()
3. Return a 101 response containing the WebSocket

Therefore, the failure appears to occur after the WebSocket upgrade rather than being caused by application-level data processing.

Example logs

[MINIMAL] fetch start
[MINIMAL] ws.accept completed
[MINIMAL] returning 101

X [ERROR] Error: Network connection lost.

Another occurrence:

[MINIMAL] fetch start
[MINIMAL] ws.accept completed
[MINIMAL] returning 101

X [ERROR] Error: The Workers runtime canceled this request because it detected that your Worker's code had hung and would never generate a response.

The behavior is intermittent rather than occurring on every connection.

Expected behavior

After the Worker returns:

HTTP 101 Switching Protocols

the WebSocket connection should remain valid until the client or server closes it.

A minimal WebSocket Worker should not produce a runtime-level Network connection lost or hung error when there is no additional application logic involved.

Actual behavior

The WebSocket upgrade succeeds from the Worker application's perspective:

ws.accept completed
returning 101

but the Workers runtime subsequently reports either:

Network connection lost

or:

The Workers runtime canceled this request because it detected that your Worker's code had hung and would never generate a response.

Additional observation

The issue appears independent of the application logic.

I initially investigated the problem as an application-level issue, but reducing the Worker to the minimal WebSocket implementation above still reproduces the runtime errors.

This makes me suspect a problem in the WebSocket/runtime lifecycle handling rather than in the Worker application's data-processing logic.

Could you please confirm whether there is a known issue with the current Workers runtime concerning WebSocket connections that have successfully returned 101, particularly cases where the runtime subsequently reports Network connection lost or incorrectly classifies the request as a hung Worker?

If this is a known runtime regression, any information about the affected runtime versions, compatibility-date behavior, or an expected fix would be appreciated.

Thank you.