Reverse proxy access stopped working: where should I start?

Troubleshooting
, , , ,
1

Adapted community discussion: Translated, paraphrased, and condensed from an anonymized public OpenClaw Discord support conversation from August 2026. Technical guidance was reviewed for OpenClaw 2026.9.3.

I can reach my OpenClaw Gateway through its local address, but I also want to connect through the reverse proxy in front of it. What needs to be configured for the proxy route?

2

That depends on whether the proxy runs on the Gateway host or another machine. Please share your OpenClaw version, the proxy software, and that topology.

For a same-host proxy, keep the Gateway on loopback and make the proxy forward both HTTP and WebSocket traffic to the configured Gateway port. The public scheme, host, and port must also appear exactly in gateway.controlUi.allowedOrigins.

For a proxy on another host, the Gateway needs a private network bind that the proxy can reach. Restrict that port at the firewall to the proxy address and keep Gateway token or password authentication enabled. Never expose an unauthenticated Gateway to make the route work.

3

The proxy is Nginx. This used to work and then suddenly stopped, so I would rather diagnose the failing layer before changing the configuration.

4

Good approach. Test one boundary at a time: client to Nginx, then Nginx to the Gateway. Start with read-only checks on the Gateway host:

openclaw gateway status --deep
openclaw health --verbose
openclaw config get gateway.bind
openclaw config get gateway.port
openclaw config get gateway.auth.mode
openclaw config get gateway.controlUi.allowedOrigins
openclaw logs --follow

In another terminal, test the local upstream using the scheme the Gateway actually serves. A response such as 200, 401, or 403 proves that something is listening. Connection refused points to the service, bind, port, firewall, or route. If an HTTP probe gets an empty reply while the Gateway advertises HTTPS or WSS, test HTTPS instead and make the Nginx proxy_pass scheme match.

Then check Nginx configuration and logs. A 502 usually means Nginx cannot reach the upstream. A page that loads but stays disconnected usually points to WebSocket forwarding, an origin mismatch, or device pairing. Nginx must preserve the Upgrade and Connection headers for WebSockets.

If the Gateway log says the origin is not allowed, add the exact public origin rather than a wildcard. Redact tokens, cookies, private addresses, and full proxy configuration before sharing diagnostics.

5

Correction: Nginx is not on this route. The traffic crosses WireGuard into a container, then socat forwards it to the OpenClaw host. I have been connecting to 10.0.0.7:18789.

6

That changes the diagnosis. The route is client to WireGuard container to socat to OpenClaw, so inspect the tunnel address and forwarding process inside the container rather than Nginx. Verify the container’s WireGuard address, route to the OpenClaw host, listener on port 18789, and an HTTPS request from inside the container.

Also make sure socat starts only after its package is installed and remains supervised. A detached install followed immediately by a detached proxy command can race or exit without being noticed.

7

I ran those checks and shared the container’s WireGuard and forwarding results.

8

That identifies the likely fault. 10.0.0.7 is stale or belongs to another peer; the active WireGuard endpoint is 10.0.0.2. Test https://10.0.0.2:18789/. If you receive the Control UI or an HTTP 401 or 403, the network path is working.

For browser access, add the exact https://10.0.0.2:18789 origin to gateway.controlUi.allowedOrigins. A certificate issued only for the local LAN address may still show a hostname warning, which is a separate TLS-name issue.