# Reverse proxy access stopped working: where should I start? **URL:** \ **Category:** Troubleshooting\ **Tags:** remote-access, reverse-proxy, security, tls, troubleshooting\ **Created:** [September 14, 2026, 5:36pm UTC](https://community.openclaw.ai/t/reverse-proxy-access-stopped-working-where-should-i-start/30 "2026-09-14T17:36:29Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![ArchivedMember](https://avatars.discourse-cdn.com/v4/letter/a/e56c9b/32.png) [@ArchivedMember](https://community.openclaw.ai/u/ArchivedMember)\ **Post date:** [September 14, 2026, 5:36pm UTC](https://community.openclaw.ai/t/reverse-proxy-access-stopped-working-where-should-i-start/30/1 "2026-09-14T17:36:29Z")
> **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? ---
**Author:** ![OpenClawSupport](https://avatars.discourse-cdn.com/v4/letter/o/49beb7/32.png) [@OpenClawSupport](https://community.openclaw.ai/u/OpenClawSupport)\ **Post date:** [September 14, 2026, 8:46pm UTC](https://community.openclaw.ai/t/reverse-proxy-access-stopped-working-where-should-i-start/30/2 "2026-09-14T20:46:15Z")
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. ---
**Author:** ![ArchivedMember](https://avatars.discourse-cdn.com/v4/letter/a/e56c9b/32.png) [@ArchivedMember](https://community.openclaw.ai/u/ArchivedMember)\ **Post date:** [September 14, 2026, 8:46pm UTC](https://community.openclaw.ai/t/reverse-proxy-access-stopped-working-where-should-i-start/30/3 "2026-09-14T20:46:15Z")
The proxy is Nginx. This used to work and then suddenly stopped, so I would rather diagnose the failing layer before changing the configuration. ---
**Author:** ![OpenClawSupport](https://avatars.discourse-cdn.com/v4/letter/o/49beb7/32.png) [@OpenClawSupport](https://community.openclaw.ai/u/OpenClawSupport)\ **Post date:** [September 14, 2026, 8:46pm UTC](https://community.openclaw.ai/t/reverse-proxy-access-stopped-working-where-should-i-start/30/4 "2026-09-14T20:46:15Z")
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: ```bash 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. ---
**Author:** ![ArchivedMember](https://avatars.discourse-cdn.com/v4/letter/a/e56c9b/32.png) [@ArchivedMember](https://community.openclaw.ai/u/ArchivedMember)\ **Post date:** [September 14, 2026, 8:46pm UTC](https://community.openclaw.ai/t/reverse-proxy-access-stopped-working-where-should-i-start/30/5 "2026-09-14T20:46:16Z")
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`. ---
**Author:** ![OpenClawSupport](https://avatars.discourse-cdn.com/v4/letter/o/49beb7/32.png) [@OpenClawSupport](https://community.openclaw.ai/u/OpenClawSupport)\ **Post date:** [September 14, 2026, 8:46pm UTC](https://community.openclaw.ai/t/reverse-proxy-access-stopped-working-where-should-i-start/30/6 "2026-09-14T20:46:16Z")
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. ---
**Author:** ![ArchivedMember](https://avatars.discourse-cdn.com/v4/letter/a/e56c9b/32.png) [@ArchivedMember](https://community.openclaw.ai/u/ArchivedMember)\ **Post date:** [September 14, 2026, 8:46pm UTC](https://community.openclaw.ai/t/reverse-proxy-access-stopped-working-where-should-i-start/30/7 "2026-09-14T20:46:16Z")
I ran those checks and shared the container’s WireGuard and forwarding results. ---
**Author:** ![OpenClawSupport](https://avatars.discourse-cdn.com/v4/letter/o/49beb7/32.png) [@OpenClawSupport](https://community.openclaw.ai/u/OpenClawSupport)\ **Post date:** [September 14, 2026, 8:46pm UTC](https://community.openclaw.ai/t/reverse-proxy-access-stopped-working-where-should-i-start/30/8 "2026-09-14T20:46:16Z")
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.