Path: /base-chain/api-reference/rpc-overview
Summary
All four public Base WebSocket endpoints are rejecting connections since the April 21 RPC migration (incident kd90bdz37xw5). WebSocket handshakes never reach the backend — they are being blocked at the Cloudflare layer.
Affected endpoints
- wss://mainnet.base.org
- wss://mainnet-preconf.base.org
- wss://sepolia.base.org
- wss://sepolia-preconf.base.org
Reproduction
Reproduced independently using wscat from a MacBook on a residential/client IP:
$ wscat -c wss://mainnet.base.org
error: Unexpected server response: 405
Also confirmed via curl with a full RFC 6455-compliant WebSocket upgrade request (GET + Upgrade: websocket + Sec-WebSocket-Key headers) — all four endpoints return 405.
Additional testing from a server/datacenter IP returns:
HTTP/2 403
x-deny-reason: host_not_allowed
Root cause hypothesis
Per RFC 6455 §4.1, the WebSocket opening handshake must be an HTTP GET request. The 405 response is being returned before the JSON-RPC layer is reached and before a WebSocket connection is established. The x-deny-reason: host_not_allowed header on the 403 variant points to a Cloudflare proxy misconfiguration — WebSocket upgrade passthrough appears to have been dropped during the April 21 node migration.
HTTP RPC (POST) requests to https://mainnet.base.org are unaffected.
Impact
- eth_subscribe is completely unavailable on all public endpoints
- The WebSocket code examples in the official docs (e.g. newFlashblocks) are non-functional
- Users are being silently broken with no changelog or deprecation notice
Expected behavior
WebSocket connections should complete the upgrade handshake and return HTTP 101 Switching Protocols.
Request
Please either restore WebSocket support on the public endpoints or update the docs to reflect that these endpoints are HTTP-only, so users can plan accordingly.
Path: /base-chain/api-reference/rpc-overview
Summary
All four public Base WebSocket endpoints are rejecting connections since the April 21 RPC migration (incident kd90bdz37xw5). WebSocket handshakes never reach the backend — they are being blocked at the Cloudflare layer.
Affected endpoints
Reproduction
Reproduced independently using wscat from a MacBook on a residential/client IP:
Also confirmed via curl with a full RFC 6455-compliant WebSocket upgrade request (GET + Upgrade: websocket + Sec-WebSocket-Key headers) — all four endpoints return 405.
Additional testing from a server/datacenter IP returns:
Root cause hypothesis
Per RFC 6455 §4.1, the WebSocket opening handshake must be an HTTP GET request. The 405 response is being returned before the JSON-RPC layer is reached and before a WebSocket connection is established. The
x-deny-reason: host_not_allowedheader on the 403 variant points to a Cloudflare proxy misconfiguration — WebSocket upgrade passthrough appears to have been dropped during the April 21 node migration.HTTP RPC (POST) requests to https://mainnet.base.org are unaffected.
Impact
Expected behavior
WebSocket connections should complete the upgrade handshake and return HTTP 101 Switching Protocols.
Request
Please either restore WebSocket support on the public endpoints or update the docs to reflect that these endpoints are HTTP-only, so users can plan accordingly.