Gateway: service says running but the CLI/UI can't connect (probe fails)

Symptoms

• openclaw gateway status says the service is running, but:
  • the Control UI won’t connect, or
  • openclaw status --deep / openclaw channels status --probe can’t reach the gateway.

Cause

Most common causes:

• You’re probing the wrong gateway (for example, your CLI is in remote mode, or using a different profile/state dir).
• The gateway process is running but not listening on the expected port (bind/auth mismatch, crash loop, refused bind).
• Firewall / network path prevents reachability from your client.

Fix

Work through these in order; jumping straight to service reinstall can hide a wrong-target or auth problem.

1) Confirm what the CLI is trying to reach

Run:

openclaw gateway status

Pay attention to the printed probe target / URL and whether you’re in local vs remote mode.

2) Verify the gateway is actually listening

If the gateway is local to the machine you’re on, try opening the Control UI locally:

• http://127.0.0.1:18789/

If auth is enabled, generate the browser URL with:

openclaw dashboard

If loopback works but remote doesn’t, it’s usually bind/firewall/auth.

3) Check for bind/auth mismatch

If you bind to LAN/tailnet, ensure auth is configured through the current auth/config guide. If you see “refusing to bind … without auth”, fix auth or fall back to loopback/tunnel access and restart.

4) Repair service/profile mismatches

If you changed install method (npm ↔ git), profile, or config location, rewrite the service:

openclaw gateway install --force

Then restart and re-probe.

Verify

• openclaw status --deep succeeds.
• Control UI stays connected and openclaw channels status --probe works.

Related

• Wrong-target/remote-mode branch: /troubleshooting/solutions/gateway-cli-probing-wrong-gateway-remote-mode
• Non-loopback auth branch: /troubleshooting/solutions/gateway-refusing-to-bind-without-auth