Workers WebSockets automatically reply to Close frames
The Workers runtime now automatically sends reciprocal Close frames when receiving Close frames from peers, with readyState transitioning to CLOSED before the close event fires, matching the WebSocket specification and standard browser behavior. A new allowHalfOpen option is available for use cases like WebSocket proxying that require independent close coordination.
The Workers runtime now automatically sends a reciprocal Close frame when it receives a Close frame from the peer. The readyState transitions to CLOSED before the close event fires. This matches the WebSocket specification ↗ and standard browser behavior.
This change is enabled by default for Workers using compatibility dates on or after 2026-04-07 (via the web_socket_auto_reply_to_close compatibility flag). Existing code that manually calls close() inside the close event handler will continue to work — the call is silently ignored when the WebSocket is already closed.
const [client, server] = Object.values(new WebSocketPair());
server.accept();
server.addEventListener("close", (event) => {
// readyState is already CLOSED — no need to call server.close().
console.log(server.readyState); // WebSocket.CLOSED
console.log(event.code); // 1000
console.log(event.wasClean); // true
});
Half-open mode for WebSocket proxying
The automatic close behavior can interfere with WebSocket proxying, where a Worker sits between a client and a backend and needs to coordinate the close on both sides independently. To support this use case, pass { allowHalfOpen: true } to accept():
const [client, server] = Object.values(new WebSocketPair());
server.accept({ allowHalfOpen: true });
server.addEventListener("close", (event) => {
// readyState is still CLOSING here, giving you time
// to coordinate the close on the other side.
console.log(server.readyState); // WebSocket.CLOSING
// Manually close when ready.
server.close(event.code, "done");
});
For more information, refer to WebSockets Close behavior.
Source: original entry ↗
More from Cloudflare
Follow Cloudflare to get its new changes in your feed and email digest.
Cloudflare One Client for macOS 2026.8.2100.0
GA release for macOS Cloudflare One Client with improved split tunnel handling that no longer briefly blocks traffic during reconnects, support for non-RFC 1918 local IPv4 networks, faster connects with lower memory use, and numerous reliability fixes across DNS, reauthentication, and client stability.
Cloudflare One Client for Windows 2026.8.2100.0
This GA release improves split tunnel reliability, adds support for non-RFC 1918 local networks, optimizes connection performance with faster reconnections and lower memory usage, and includes numerous bug fixes for DNS, registration, and network handling. The client now features a service recovery mechanism that automatically restarts on system unlock and better handles large hosts files without blocking traffic.
Cloudflare One Client for Linux 2026.8.2100.0
New GA release for Linux with improved split tunnel handling that no longer briefly blocks traffic during reconnects, support for non-RFC 1918 local IPv4 networks, faster tunnel reconnections, and lower memory usage. Includes numerous stability and reliability fixes for DNS, reconnection behavior, and crash issues.