#unstable gateway connection

1 messages · Page 1 of 1 (latest)

viral arrow
#

I installed openclaw using the bash command from the homepage, it's running but sometimes the dashboard giving me 502 bad gateway i have to restart manually, but after couple of hours it happen again 502 gateway. Is there some settings i need to check?

terse hedgeBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

forest fulcrumBOT
viral arrow
#

even on openclaw tui, most of the times it just stopped after finishing a prompt, not showing anything

worldly bridgeBOT
#

502 usually means the dashboard can’t reach the gateway anymore, so I’d check gateway health first, not a dashboard-only setting.

Please paste these when it happens:

openclaw --version
openclaw status --all
openclaw gateway status --deep
openclaw doctor

Then watch logs:

openclaw logs --follow
#

If RPC is fully down, use:

tail -f "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

The common things to look for are:

  • gateway process stopped/crashed
  • service config and CLI config are different
  • port conflict (EADDRINUSE)
  • low memory / OOM on the host
  • a proxy layer in front of OpenClaw (nginx, Caddy, Cloudflare, Tailscale Serve) returning the 502

One quick clue: if openclaw gateway status still shows Runtime: running and RPC probe: ok while the dashboard is broken, it may be the browser/WebSocket side instead of the gateway itself.

Docs:

#

yeah, if both the dashboard and TUI stop behaving, that points much more to the gateway/RPC layer dying than to a dashboard-only issue.

Most important thing: check it while it’s broken, before restarting.

Please grab:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw models status
openclaw logs --follow

A few high-signal things to look for:

  • openclaw gateway status says Runtime: running but RPC probe: failed
#
  • that means the supervisor still sees a process, but the gateway itself is not actually responding
  • Config (cli) and Config (service) are different
    • that means the service may be running a different config than the one you’re editing
  • any EADDRINUSE, crash, auth, or OOM/memory lines in logs

In the TUI, also try:

/status

If it’s just sitting there with no output, docs specifically say to check:

openclaw status
openclaw models status
#

let’s keep it in this thread first.

Before restarting again, please paste:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw models status
openclaw logs --follow

The key is to capture it while it’s broken. If that points to an actual OpenClaw bug, the right escalation path is a GitHub issue here:

https://github.com/openclaw/openclaw/issues

That’ll get it in front of the team with the useful diagnostics attached.

viral arrow
#

08:48:53+00:00 error Gateway failed to start: another gateway instance is already listening on ws://127.0.0.1:18789 | listen EADDRINUSE: address already in use 127.0.0.1:18789
If the gateway is supervised, stop it with: openclaw gateway stop
08:48:53+00:00 error Port 18789 is already in use.
08:48:53+00:00 error - pid 955038 root: openclaw-gateway (127.0.0.1:18789)
08:48:53+00:00 error - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
08:48:53+00:00 error Gateway service appears enabled. Stop it first.
08:48:53+00:00 error Tip: openclaw gateway stop
08:48:53+00:00 error Or: systemctl --user stop openclaw-gateway.service
08:48:55+00:00 warn gateway/ws {"subsystem":"gateway/ws"} Proxy headers detected from untrusted address. Connection will not be treated as local. Configure gateway.trustedProxies to restore local client detection behind your proxy.

worldly bridgeBOT
#

nice, this log is actually very revealing.

You have two separate clues here:

  1. EADDRINUSE / another gateway instance is already listening

    • that means a gateway is already bound to 127.0.0.1:18789
    • so when you “restart manually”, you may be trying to start a second gateway on top of the supervised service

  2. Proxy headers detected from untrusted address

    • that means something is sitting in front of OpenClaw as a proxy
    • OpenClaw is seeing forwarded headers, but does not trust that proxy IP for local-client detection

So I’d avoid changing random settings for now. First normalize the setup:

  • if you installed the service, use only:
# 
  openclaw gateway stop
  openclaw gateway start
  • don’t also launch a separate manual gateway process on the same port

Next, please paste:

openclaw --version
openclaw gateway status

The important lines in openclaw gateway status are:

  • Runtime
  • RPC probe
#
  • Probe target
  • Listening
  • Config (cli)
  • Config (service)

If Config (cli) and Config (service) are different, that’s a very common cause of weird flaky behavior.

Also, are you using nginx, Caddy, Cloudflare, or Tailscale Serve in front of OpenClaw?

Because the proxy warning suggests this may be the real split:

  • if http://127.0.0.1:18789/ works directly, but your proxied URL gives 502, the problem is probably the proxy layer
  • if both break, it’s the gateway/service

Relevant docs:
https://docs.openclaw.ai/help/faq#what-does-another-gateway-instance-is-already-listening-mean
https://docs.openclaw.ai/help/faq#why-does-openclaw-gateway-status-show-config-cli-and-config-service-different

viral arrow
#

🦞 OpenClaw 2026.4.21 (f788c88) — The only open-source project where the mascot could eat the competition.

│
â—‡
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-22.log
Command: /root/.nvm/versions/node/v25.5.0/bin/node /root/.nvm/versions/node/v25.5.0/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Service config looks out of date or non-standard.
Service config issue: Gateway service PATH includes version managers or package managers; recommend a minimal PATH. (/root/.nvm/versions/node/v25.5.0/bin)
Service config issue: Gateway service uses Node from a version manager; it can break after upgrades. (/root/.nvm/versions/node/v25.5.0/bin/node)
Recommendation: run "openclaw doctor" (or "openclaw doctor --repair").
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 957459, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: admin-capable

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

worldly bridgeBOT
#

this narrows it down a lot.

Your gateway itself looks healthy in that snapshot:

  • Config (cli) and Config (service) match
  • Runtime: running
  • Connectivity probe: ok
  • Listening: 127.0.0.1:18789

So the earlier EADDRINUSE was just you trying to start a second gateway while the systemd service was already running.

The more likely issue now is the proxy path, especially because you also got:

Proxy headers detected from untrusted address

And your gateway is loopback-only, so if you are opening the dashboard from anywhere other than the same machine, it has to be going through some proxy/tunnel.

#

What I’d check next

When the 502 happens again, on the server run:

openclaw gateway status
curl -I http://127.0.0.1:18789/

If 127.0.0.1:18789 still works locally, but your normal dashboard URL returns 502, then the problem is almost certainly nginx / Caddy / Cloudflare / Tailscale Serve / whatever is in front, not the OpenClaw gateway.

One more thing

openclaw gateway status is also warning that your systemd service is using nvm-managed Node and looks a bit non-standard. That is worth cleaning up, even if it is not the direct 502 cause.

I’d run: