OpenClaw "gateway closed (1006 abnormal closure (no close frame)): no close reason"

Why it happens

A clean shutdown sends a close frame with a code like 1000 or 1012. 1006 means the TCP connection ended with no frame at all, so the client only knows that the line went dead, not why.

1. The gateway process crashed, was killed, or restarted mid-request (for example by launchd, systemd, or an update). Issue #7976 reported intermittent health-check failures with exactly this text on a macOS LaunchAgent gateway.
2. The gateway was alive but starved. On 2026.9.6, users reported event-loop stalls with "[ws] webchat disconnected code=1006" in the log (issue #157545), and config hot reload can block the event loop for 20 to 33 seconds (issue #159698, open).
3. A reverse proxy dropped an idle socket. nginx closes a proxied connection when nothing is read for proxy_read_timeout, which defaults to 60 seconds, and it does so without a WebSocket close frame.
4. Wrong scheme: connecting with ws:// to a wss:// gateway, or the reverse. The CLI lists this as a possible cause next to the error.
5. Some CLI commands closed the socket abnormally after a doctor repair on 2026.6.11 while openclaw gateway health still passed (issue #98753, open).

The fix

1. 1 Check the process: openclaw gateway status. If it is not running or its PID just changed, read openclaw logs --follow for the crash or restart reason before anything else.
2. 2 If the gateway is up, rerun the command. A one-off 1006 during a restart or reload is expected.
3. 3 Behind nginx, keep the WebSocket upgrade headers and raise the read and send timeouts on the gateway location (see the block below), then reload nginx. For Caddy or a cloud load balancer, raise its idle timeout the same way.
4. 4 Match the scheme to the gateway: wss:// when TLS terminates in front of it, ws:// for plain loopback.
5. 5 If it happens under load, check the log for event-loop or heartbeat warnings near the disconnect, and upgrade past the release named in the matching issue.
6. 6 Run openclaw doctor for anything config-shaped.

nginx settings that stop idle 1006 drops

nginx's proxy_read_timeout and proxy_send_timeout both default to 60s. A gateway connection that goes quiet for longer is cut, and the client reports 1006. Keep the upgrade headers and set longer timeouts on the location that proxies the gateway:

location / {
    proxy_pass http://127.0.0.1:18789;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
}

If the handshake itself fails you get a 400, not a 1006. That is the missing upgrade headers case, covered on the WebSocket 400 page.

Did my command run anyway?

Maybe. If the socket dropped after the CLI sent a write, the gateway may already have applied it. Before 2026.9.6 the CLI printed the same message and advised a retry either way (issue #154281). From 2026.9.6 it warns that the outcome is unknown (PR #154282). Check the current state, for example openclaw agents list or openclaw cron list, before repeating a write.

Still failing?

• If the gateway restarts on its own, look for a crash loop or memory pressure in openclaw logs --follow and in your service manager's logs.
• If only certain commands fail while openclaw gateway health passes, capture the exact command and version and compare with issue #98753.
• If it only happens through the proxy, test the same command directly against ws://127.0.0.1:18789 on the host to isolate the proxy.

Related errors

• OpenClaw WebSocket 400 behind nginx / Caddy
• OpenClaw gateway heap leak and OOM