origin not allowed (open the Control UI from the gateway host or allow it in gateway.controlUi.allow | Friends of the Crustacean 🦞🤝 | Page 1

glad root Apr 17, 2026, 3:08 PM

#

Hi, I am trying to access my openclaw docker on my LAN network and its not working, I am always receiving this error message when accessing it: origin not allowed (open the Control UI from the gateway host or allow it in gateway.controlUi.allowedOrigins)

I did run openclaw dashboard in my docker shell with the right token and link, it just doesnt want to connect at all. Ollama and searxng are also running without issues.

This is my docker compose file:

openclaw-gateway:
image: ghcr.io/openclaw/openclaw:latest
container_name: openclaw-gateway
restart: unless-stopped
ports:
- 18789:18789
volumes:
- /mnt/ai/pmbeai/appdata/openclaw/config:/home/node/.openclaw
- /mnt/ai/pmbeai/appdata/openclaw/workspace:/home/node/.openclaw/workspace
environment:
- OPENCLAW_GATEWAY_BIND=lan
- OPENCLAW_GATEWAY_MODE=local
- NODE_ENV=production

Thanks!!

elder compassBOT Apr 17, 2026, 3:08 PM

#

rare baneBOT Apr 17, 2026, 3:08 PM

#

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

elder compassBOT Apr 17, 2026, 3:08 PM

#

hidden dragonBOT Apr 17, 2026, 3:10 PM

#

This one is usually not a token problem. It means the browser origin is blocked.

With OPENCLAW_GATEWAY_BIND=lan, you also need to set:

gateway.controlUi.allowedOrigins

to the exact origin(s) you open in the browser, for example:

http://192.168.1.50:18789
http://openclaw.local:18789

Not *, and not just the tokenized dashboard URL.

Example fix in the container:

#

node dist/index.js config set gateway.controlUi.allowedOrigins '["http://192.168.1.50:18789","http://openclaw.local:18789"]' --strict-json

Then restart the container.

A couple important gotchas:

it must match the browser URL exactly: scheme + host + port
if you open by IP sometimes and hostname other times, add both
openclaw dashboard printing the link does not auto-allow LAN origins

Also, what does openclaw --version show inside the container? Version matters a lot here.

Docs:

#

https://docs.openclaw.ai/gateway/troubleshooting

If it still fails after adding allowedOrigins, send:

openclaw --version
the exact browser URL you’re opening
the output of openclaw config get gateway.controlUi.allowedOrigins

glad root Apr 17, 2026, 3:11 PM

#

node@5507d8ff4e82:/app$ openclaw config get gateway.controlUi.allowedOrigins

🦞 OpenClaw 2026.4.15 (unknown) — Somewhere between 'hello world' and 'oh god what have I built.'

[
"http://localhost:18789",
"http://127.0.0.1:18789"
]
node@5507d8ff4e82:/app$

How do I add my other IP origin? like its coming from 10.10.6.1 (desktop)

hidden dragonBOT Apr 17, 2026, 3:12 PM

#

It’s the browser page origin, not usually the desktop’s client IP.

So add the exact URL you open in the browser address bar.

For example, if you open:

http://10.10.6.50:18789

then run:

openclaw config set gateway.controlUi.allowedOrigins '["http://localhost:18789","http://127.0.0.1:18789","http://10.10.6.50:18789"]' --strict-json

Then restart the container.

A couple gotchas:

#

if you open by hostname, add that too, e.g. http://openclaw.local:18789
if you open by IP, add that exact IP
don’t use just 10.10.6.1 unless your browser is literally on http://10.10.6.1:18789

So the rule is:

whatever is in the browser URL bar = what goes into allowedOrigins

Docs: https://docs.openclaw.ai/web/control-ui

If you want, paste the exact URL you’re opening from your desktop and I’ll give you the exact command. Also, if this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

glad root Apr 17, 2026, 3:13 PM

#

Ok let me clarify, I am currently trying to access the openclaw docker which is on 10.10.1.2:18789 from my desktop 10.10.6.1

hidden dragonBOT Apr 17, 2026, 3:13 PM

#

Perfect, then the origin you want is:

http://10.10.1.2:18789

Not the desktop IP.

Run this inside the container:

openclaw config set gateway.controlUi.allowedOrigins '["http://localhost:18789","http://127.0.0.1:18789","http://10.10.1.2:18789"]' --strict-json

Then restart the container and reload the page.

Quick check after setting it:

#

openclaw config get gateway.controlUi.allowedOrigins

It should show all 3 entries.

If you ever access it via a hostname instead of the raw IP, add that hostname as well.

If that fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

glad root Apr 17, 2026, 3:16 PM

#

control ui requires device identity (use HTTPS or localhost secure context)

new issue 😄

I can nginx to my local domain without issue, will it just work like my other docker apps? lets say I nginx to openclaw.mydomain.com (I got many other local domains access like this). Will it work or it requires more configuration than that?

hidden dragonBOT Apr 17, 2026, 3:17 PM

#

Yep, HTTPS via nginx is the normal fix for that error, but it’s not quite zero-config.

For a basic nginx reverse proxy, I’d do this:

Serve OpenClaw at HTTPS
- example: https://openclaw.mydomain.com
Set allowedOrigins to the HTTPS origin
- not the LAN IP if you’re opening the domain in the browser

openclaw config set gateway.controlUi.allowedOrigins '["http://localhost:18789","http://127.0.0.1:18789","https://openclaw.mydomain.com"]' --strict-json

Keep normal token/password auth
- do not switch to gateway.auth.mode: "trusted-proxy" unless nginx is also doing real auth (OAuth/OIDC/etc)
- plain nginx as just a TLS proxy is not trusted-proxy auth

#

Make sure nginx supports WebSocket upgrades
- OpenClaw needs them

Minimum nginx bits:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;

So, short version:

HTTPS nginx proxy? yes, should work
Needs allowedOrigins updated? yes
Needs trusted-proxy mode? no, not for plain nginx

#

Needs websocket headers? yes

Docs:

If you want, paste your nginx server block and I’ll sanity-check it before you wire it up.

glad root Apr 17, 2026, 3:19 PM

#

ok https done and done, now it says pairing required, i guess there is a command for that in openclaw?

hidden dragonBOT Apr 17, 2026, 3:20 PM

#

Yep, that means you’re past the HTTPS issue, nice 😄

Now approve the browser device:

openclaw devices list
openclaw devices approve <requestId>

A couple small gotchas:

use the exact requestId from devices list
openclaw devices approve --latest only previews the newest request, it doesn’t actually approve it
if the browser retried, the request ID may have changed, so run devices list right before approving

Then reload the Control UI.

#

Docs: https://docs.openclaw.ai/cli/devices

If you want, paste the openclaw devices list output and I’ll tell you exactly which command to run.

glad root Apr 17, 2026, 3:22 PM

#

wonderful I am now inside, rocky AI!

Now I need to know how I can configure my local ollama to this and telegram for now, I did it yesterday to test on my desktop but I had a GUI with quickstart helping to do that, can i do it in the control panelk for openclaw or I can type a command to do that in openclaw docker?

hidden dragonBOT Apr 17, 2026, 3:24 PM

#

Yep, you can do either:

guided setup: openclaw onboard
manual config: Control UI → Config tab

For Docker, I’d use openclaw onboard first, since that’s the closest thing to the quickstart flow you saw before.

Easiest path

Inside the container:

openclaw onboard

That can walk you through both:

#

Ollama
Telegram

Important Docker gotcha for Ollama

If Ollama is not inside the same container, do not use 127.0.0.1:11434.

From inside Docker, 127.0.0.1 means the container itself.

So if Ollama is on your desktop, use something like:

http://10.10.6.1:11434

And for OpenClaw + Ollama, use the native Ollama URL, no /v1.

Good:

http://10.10.6.1:11434

#

Bad:

http://10.10.6.1:11434/v1

Telegram quick summary

You’ll need:

a bot token from @BotFather
set channels.telegram.enabled: true
set channels.telegram.botToken
DM the bot once, then approve the pairing code

Typical pairing flow:

openclaw pairing list telegram

#

openclaw pairing approve telegram <CODE>

My recommendation

use openclaw onboard for the first pass
use Control UI Config later for tweaks

Docs:

If you want, tell me where Ollama is running, on 10.10.1.2 or on your desktop 10.10.6.1, and I’ll give you the exact Ollama config to use.

glad root Apr 17, 2026, 3:26 PM

#

Excellent, I will get on that asap. I have a paid service for ollama and access all cloud LLM, which one would you recommend to start with openclaw? I will eventually run many local LLM under this one likee an hybrid setup! I used to like a lot qwen3.5

hidden dragonBOT Apr 17, 2026, 3:26 PM

#

I’d start hybrid, but with a cloud primary.

My recommendation for OpenClaw:

Primary: your strongest hosted model
- best for tool use, planning, and fewer weird failures
Fallback: a cheaper/faster hosted model
- good when the primary is slow or unavailable
Local Ollama model: fallback or low-stakes sessions
- great for experimentation, summaries, cheap background work
- I would not make local-only your main agent at first unless you enjoy debugging tool-calling weirdness 😅

So if you like Qwen-family models, that’s a reasonable local fallback / secondary direction, but for your main OpenClaw driver I’d still use the strongest cloud option you have access to first.

The docs’ general guidance is basically the same:

#

strongest model as primary
fallbacks for cost/latency
weaker/local models for lower-stakes work

For current model-specific recommendations, ask in #models because that changes fast and I don’t want to give you stale advice.

Docs:

If you want, I can help you sketch a good first hybrid config next, like:

primary
fallback
local fallback
heartbeat/background model

glad root Apr 17, 2026, 3:28 PM

#

Yes please, which cloud model from ollama would be the best to start this hybrid setup?

hidden dragonBOT Apr 17, 2026, 3:28 PM

#

I don’t want to give you a specific cloud model name here and accidentally hand you stale advice, that stuff changes too fast.

For your first hybrid OpenClaw setup, I’d choose:

Primary: the strongest Ollama-hosted model currently available with the best reputation for tool calling + instruction following
Fallback: a cheaper/faster hosted Ollama model
Local fallback: the Qwen-family local model you already trust

That’s the safest starting pattern.

So, bluntly, my recommendation is:

don’t start with local-only
don’t start with the cheapest cloud option
start with Ollama’s top-end hosted model, then add Qwen local as fallback

For the exact current best pick, ask in #models and check:

#

If you want, I can help you build the actual hybrid config structure next without hardcoding model names yet, so you can swap in whatever #models recommends.

#origin not allowed (open the Control UI from the gateway host or allow it in gateway.controlUi.allow

Easiest path

Important Docker gotcha for Ollama

Telegram quick summary

My recommendation