Gateway Troubleshooting

Use this page when the issue is clearly at the Gateway layer: the service looks loaded but no port is listening, the UI is unauthorized, provider credentials are stale or remote mode is misconfigured. This is more direct than the generic help page.

Help Center Gateway Ops Gateway Configuration

Diagnostic Order

Status and summary

openclaw status
openclaw status --all
openclaw status --deep

Gateway and channel probes

openclaw gateway probe
openclaw gateway status
openclaw channels status --probe

Live logs

openclaw logs --follow

When debugging Gateway issues, logs are almost always more trustworthy than a service manager saying something is running.

Common Failures

No API key found for provider "anthropic"

This usually means the current agent has no Anthropic credentials in its own auth store. Auth is isolated per agent. Re-run onboarding or execute openclaw models auth setup-token --provider anthropic on the Gateway host, then verify with openclaw models status.

Control UI shows device identity required / connect failed over plain HTTP

If the remote Control UI is opened over insecure HTTP, the browser cannot create a device identity. Use Tailscale Serve or HTTPS, or open http://127.0.0.1:18789/ directly on the Gateway host.

The service is installed but not really running

Start with openclaw gateway status and openclaw doctor. A supervisor saying the service is loaded does not prove the process is healthy; inspect live logs and service-manager output.

Gateway start blocked: set gateway.mode=local

Your config exists but gateway.mode is not local. Run openclaw configure again or set it with openclaw config set gateway.mode local.

The service looks alive but the port is not listening

First check whether the CLI and service point at the same config. If the CLI profile and service profile differ, reinstall from the intended profile. If logs say it is refusing to bind without auth, you switched away from loopback without setting gateway.auth.token.

Why does gateway status say running but RPC probe failed

The supervisor sees a live process, but the CLI cannot complete the WebSocket probe. Most often this is the wrong port, config drift, auth failure or a remote URL pointing to the wrong place. Trust the probe target and the logs.