2026.02.25 Update Seemingly Broke My Install? | Friends of the Crustacean 🦞🤝 | Page 1

mild heronBOT Feb 26, 2026, 5:44 AM

#

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

modern swiftBOT Feb 26, 2026, 5:47 AM

#

2026.02.25 tightened the “non-loopback bind” guardrails.

When you set gateway.bind: "lan" (or tailnet/custom), the Gateway will now refuse to bind unless it can see proper local gateway auth (gateway.auth.mode + gateway.auth.token / password). A super common upgrade break is that you think you have “auth tokens”, but they’re under an old/other key (or you only set gateway.remote.token, which is remote CLI auth and does not count for local gateway bind/auth).

Docs (this exact case):

What I’d check first (please paste output; redact tokens):

openclaw --version
openclaw gateway status
openclaw config get gateway.bind
openclaw config get gateway.auth.mode
openclaw config get gateway.auth.token

#

Typical smoking-gun error in logs/status

refusing to bind gateway ... without auth

Fix (example)

{
  gateway: {
    bind: "lan",
    auth: {
      mode: "token",
      token: "replace-me"
    }
  }
}

Then restart:

#

openclaw gateway restart

If gateway.auth.token is empty/missing, generate one:

openclaw doctor --generate-gateway-token

If you paste the openclaw gateway status output (especially the “Last gateway error:” line), I can tell you exactly which of these you’re hitting.

gaunt aurora Feb 26, 2026, 5:54 AM

#

openclaw --version
2026.2.25

openclaw gateway status (i set it temp to loopback to get things working, still want it back to lan)

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-25.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

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 208149, state active, sub running, last exit 0, reason 0)
RPC probe: ok

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

openclaw config get gateway.bind
loopback (expected, i changed it back)

openclaw config get gateway.auth.mode
token

openclaw config get gateway.auth.token
__OPENCLAW_REDACTED__

Again the gateway works normallyh when in loopback but changing it to lan even with a token still makes it not work

modern swiftBOT Feb 26, 2026, 5:56 AM

#

Given your current output, loopback is totally healthy (RPC probe ok, listening on 127.0.0.1).

When you flip back to gateway.bind: "lan" and it “doesn’t work”, there are two common meanings:

1) Gateway is actually running, but the Control UI goes “unauthorized” (most common)

The Control UI stores the gateway token in browser localStorage per origin.

So if you previously authenticated at:

http://127.0.0.1:18789/

…and now you open:

http://192.168.x.y:18789/

…that’s a different origin, so the UI won’t have the token saved anymore and it’ll look “broken” (reconnect/unauthorized).

#

Fix: open the UI on the LAN URL, then Control → Overview → Gateway Access and paste the token again (or run openclaw dashboard, which helps you get the right URL/token flow).

FAQ section that covers this: https://docs.openclaw.ai/help/faq#i-set-gatewaybind-lan-or-tailnet-and-now-nothing-listens-the-ui-says-unauthorized

2) The bind to LAN genuinely fails (usually EADDRINUSE / port conflict)

This happens if something else is already listening on *:18789 or on your LAN IP 192.168.x.y:18789 (loopback bind can still succeed in that case).

To tell which case you’re in, can you:

set gateway.bind back to lan
openclaw gateway restart
paste:

openclaw gateway status
openclaw logs --follow   # just the first error block after restart is enough

#

If you see EADDRINUSE, run:

ss -ltnp | grep 18789

…and we’ll know what’s squatting on the port.

Key thing: your token config looks fine, so the next clue is what openclaw gateway status says in lan mode (especially any “Last gateway error” / “Listening” lines).

gaunt aurora Feb 26, 2026, 6:00 AM

#

I changed it back to lan to test openclaw gateway status and this is what i got (im heavily redacting it after i send it for my safety)

test

modern swiftBOT Feb 26, 2026, 6:07 AM

#

That output is the clue: nothing “mystical” happened to your token — 2026.2.25 added a hard security rule:

ws:// to any non-loopback address is now blocked (CLI refuses to send creds/chat data over plaintext).
And the Control UI/WebChat now effectively needs a secure context (HTTPS/WSS) for the device-identity crypto, so “bind to 0.0.0.0 and open http://<public-ip>:18789” is no longer a supported/safe setup.

So when you set gateway.bind: "lan", openclaw gateway status tries to probe via your public IP (104…) and then bails with:

SECURITY ERROR: … plaintext ws:// to a non-loopback address

Quick confirmations

On the gateway host, run the probe against loopback explicitly (this is still allowed even if you bind to lan):

openclaw gateway status --url ws://127.0.0.1:18789

How to get “remote access” back (recommended options)

Pick one:

#

SSH tunnel (fastest, works everywhere)

ssh -N -L 18789:127.0.0.1:18789 user@104.131.103.21

Then open http://127.0.0.1:18789/ locally (and CLI targets ws://127.0.0.1:18789).

Tailscale Serve/Funnel (HTTPS/WSS)
This is the “nice UX” path for remote Control UI. Docs: https://docs.openclaw.ai/gateway/remote (and the Tailscale page linked from there).
Put it behind real TLS (reverse proxy)
Caddy/Nginx in front, proxy to loopback. (This is the “public internet” way—don’t expose the raw gateway port without TLS.)

If you tell me whether you’re trying to access this from (a) another machine on your home LAN, or (b) over the public internet (it looks like public), I’ll point you at the cleanest of the three.

gaunt aurora Feb 26, 2026, 6:08 AM

#

openclaw gateway status --url ws://127.0.0.1:18789

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-26.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://104.131.103.21:18789/

Runtime: running (pid 210803, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
RPC probe: failed
RPC target: ws://127.0.0.1:18789
  gateway closed (1006 abnormal closure (no close frame)): no close reason
  Gateway target: ws://127.0.0.1:18789
  Source: cli --url
  Config: /root/.openclaw/openclaw.json

Gateway port 18789 is not listening (service appears running).
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager

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

So Lan is a no-go anymore? I'd like to stick with Lan

modern swiftBOT Feb 26, 2026, 6:20 AM

#

Short answer: Lan wasn’t removed — 2026.02.25 tightened security (plaintext ws:// to non-loopback is blocked and non-loopback binds require correct auth/TLS). Your status output, though, shows the gateway process is running but not listening on 0.0.0.0:18789 — that means the service failed during startup (so the CLI probe gets a 1006/“not listening”), not that OpenClaw refuses LAN forever.

Most likely causes (ordered by how often I see them):

Service failed to start because it rejected the config at startup (common: auth not visible to the service or TLS misconfiguration). The server will exit before opening the port.
gateway.tls was enabled but certs failed to load (gateway refuses to start if TLS enabled and cert missing).
Port conflict (EADDRINUSE) or permission error.
You ran CLI as root (or a different user) and ended up probing with a different config than the service is using — this hides the real cause.

What I need from you to be specific: the gateway service logs around the start attempt. Please run these and paste the first error block (redact tokens/passwords):

Show the service logs (run as the same user that runs the service):

journalctl --user -u openclaw-gateway.service -n 200 --no-pager

If your service is system-wide:

sudo journalctl -u openclaw-gateway.service -n 200 --no-pager

(Alternative if you want the file logs)

#

ls -ltr /tmp/openclaw && tail -n 200 /tmp/openclaw/$(ls -1t /tmp/openclaw | head -1)

Also paste these quick checks (they help narrow it immediately):

openclaw config get gateway.bind gateway.mode gateway.auth.mode
ss -ltnp | grep :18789 || true
openclaw --version

Important things to look for in the logs (what I’ll be looking for):

"refusing to bind gateway to 0.0.0.0 ... without auth" → service didn’t see the token/password. Fix: ensure gateway.auth.token/password is present in the config the service reads (run openclaw config get gateway.auth.token as the same user the service runs under). If you used sudo when checking config earlier, don’t — that can read /root/.openclaw instead of the real user's config.
"gateway tls: cert/key missing" or "gateway tls: failed to enable" → TLS was enabled but cert/key absent or failed to load. Fix: either disable gateway.tls or enable autoGenerate or install cert+key. Example to auto-generate and enable TLS (JSON5):
{
gateway: {
bind: "lan",
auth: { mode: "token", token: "REDACTED" },
tls: { enabled: true, autoGenerate: true }
}
}

#

Then restart the gateway.

EADDRINUSE / another process listening → identify process with ss (above) and stop it or pick another port.

Short tips / reminders

The CLI refuses to probe ws:// to non-loopback addresses for safety — that’s why you saw the “SECURITY ERROR” earlier. That’s only the probe: it does not mean lan is banned. Once the gateway is actually listening with proper auth/TLS, you should probe with wss:// or use an SSH tunnel.
Avoid running the CLI as root (sudo) — the status output you showed contained Config: /root/.openclaw/... which often causes confusion between the config seen by the CLI and the config used by the service.
Easiest secure patterns:
- keep gateway.bind=loopback + use SSH tunnel (ssh -N -L 18789:127.0.0.1:18789 user@host)
- or enable TLS (gateway.tls.enabled + autoGenerate or real certs) and use wss://<lan-ip>:18789
- or use Tailscale Serve

If you paste the first ~50−100 lines from journalctl (or the /tmp/openclaw log) I’ll read them and tell you exactly which of the above is happening and the exact edit/command to get LAN working again.

#

Cool — sounds like you’ve got it sorted now.

If this thread is resolved, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person who hits the same 2026.2.25 LAN/ws security change.

gaunt aurora Feb 26, 2026, 6:28 AM

#

that was meant for the console, sorry

modern swiftBOT Feb 26, 2026, 6:28 AM

#

All good 🙂

If you still want to keep digging and get LAN mode working again, paste the outputs of these (run them without sudo, unless your service truly runs as root):

openclaw config get gateway.bind gateway.mode gateway.auth.mode
openclaw gateway restart
journalctl --user -u openclaw-gateway.service -n 200 --no-pager
ss -ltnp | grep :18789 || true

The journal output will usually contain the exact one-liner cause (auth missing, TLS cert/key missing, EADDRINUSE, etc.).

gaunt aurora Feb 26, 2026, 6:31 AM

#

How do i setup wss:// assuming im already using nginx reverse proxy to manage my ssl certs?

currently i have nginx reverse proxy pointing towards my digitalocean dropley ip w/ a ssl cert, using a sub domain.. seems like to me this all points down to the gateway thinking im using http instead of https but i am not

modern swiftBOT Feb 26, 2026, 6:35 AM

#

If you already have nginx terminating TLS for https://your-subdomain, then “getting wss://” is just: make nginx proxy WebSockets correctly and (ideally) keep the OpenClaw Gateway bound to loopback.

Recommended setup (VPS + nginx)

1) OpenClaw config (on the droplet)
Keep the gateway private on the box and let nginx be the only public entrypoint:

{
  gateway: {
    bind: "loopback",
    port: 18789,
    auth: { mode: "token", token: "..." }
  }
}

Then firewall 18789 from the internet (only allow 80/443 to nginx). On a droplet, bind: "lan" effectively exposes it publicly, which you don’t want anymore.

#

2) nginx config (TLS + WS upgrade)
This is the critical part for wss://:

map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

server {
  listen 80;
  server_name openclaw.example.com;
  return 301 https://$host$request_uri;
}

server {

#

  listen 443 ssl http2;
  server_name openclaw.example.com;

  ssl_certificate     /etc/letsencrypt/live/openclaw.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/openclaw.example.com/privkey.pem;

  # optional but often needed for uploads
  client_max_body_size 50m;

  location / {
    proxy_pass http://127.0.0.1:18789;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

#


    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
  }
}

Now:

Browser loads the UI at https://openclaw.example.com/
The UI will connect to the gateway via wss://openclaw.example.com/ automatically (same origin, secure context)

#2026.02.25 Update Seemingly Broke My Install?

1) Gateway is actually running, but the Control UI goes “unauthorized” (most common)

2) The bind to LAN genuinely fails (usually EADDRINUSE / port conflict)

Quick confirmations

How to get “remote access” back (recommended options)

Recommended setup (VPS + nginx)

Two gotchas that match what you’re seeing