Configuring OpenClaw Gateway Bind and Control UI on Azure

Understanding Gateway Bind Modes

One of the first configuration hurdles with OpenClaw on Azure is understanding the --bind parameter. Unlike a simple IP address (e.g., 0.0.0.0), OpenClaw uses named bind modes:

Setting the bind mode

In your .env file on the VM:

# For SSH tunnel access (recommended)
OPENCLAW_GATEWAY_BIND=loopback

# For direct public/LAN access
OPENCLAW_GATEWAY_BIND=lan

Common mistake: Setting OPENCLAW_GATEWAY_BIND=0.0.0.0 will fail with:

Invalid --bind (use "loopback", "lan", "tailnet", "auto", or "custom")

Use lan instead of 0.0.0.0.

The Control UI Origin Enforcement

When you bind to a non-loopback address (e.g., lan), OpenClaw enforces browser-origin checks on the Control UI. This prevents unauthorized browsers from connecting to your dashboard via DNS rebinding or cross-origin attacks.

Without proper origin configuration, you’ll see this crash loop:

Gateway failed to start: Error: non-loopback Control UI requires
gateway.controlUi.allowedOrigins (set explicit origins), or set
gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true
to use Host-header origin fallback mode

You have two options to fix this:

Option A: Explicit Allowed Origins (Recommended)

Set a specific list of trusted origins:

cd ~/openclaw

docker compose run --rm openclaw-cli config set \
  gateway.controlUi.allowedOrigins \
  '["http://<VM_PUBLIC_IP>:18789","http://<VM_PRIVATE_IP>:18789","http://localhost:18789","http://127.0.0.1:18789"]'

Replace <VM_PUBLIC_IP> and <VM_PRIVATE_IP> with your actual IPs:

# Get your public IP
curl -s ifconfig.me; echo

# Get your private IP
hostname -I

Why this is recommended

• Explicitly defines which browser origins can connect
• Protects against DNS rebinding attacks
• No security warnings in the gateway logs
• Works with Azure NSG restrictions for defense in depth

Option B: Host-Header Origin Fallback (Quick but less secure)

If you want to get running immediately:

docker compose run --rm openclaw-cli config set \
  gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback true

This tells OpenClaw to trust the Host header from the browser request instead of checking against an explicit allowlist.

When this is acceptable

• You restrict access via Azure NSG to your IP only
• You’re behind a reverse proxy that sets proper headers
• You’re in a development/testing environment
• You understand the DNS rebinding risk

The security warning

With this flag enabled, you’ll see:

[gateway] security warning: dangerous config flags enabled:
gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true.
Run openclaw security audit.

This is expected and serves as a reminder to lock down access through other means.

Applying Configuration Changes

After any config change, restart the gateway:

docker compose down
docker compose up -d --force-recreate
docker compose ps
docker compose logs --tail=50 openclaw-gateway

Verify the gateway stays Up (not Restarting):

# Check multiple times over ~60 seconds
docker compose ps
# Wait 15 seconds
docker compose ps
# Wait 15 seconds 
docker compose ps

Recommended Configuration for Azure

For SSH tunnel access (most secure)

# .env
OPENCLAW_GATEWAY_BIND=loopback
OPENCLAW_GATEWAY_PORT=18789

No origin configuration needed — loopback mode skips the origin check.

Access via SSH tunnel:

# From your laptop
ssh -L 18789:127.0.0.1:18789 azureuser@<VM_PUBLIC_IP>
# Then open http://127.0.0.1:18789

For direct public access

# .env
OPENCLAW_GATEWAY_BIND=lan
OPENCLAW_GATEWAY_PORT=18789

Plus explicit origins:

docker compose run --rm openclaw-cli config set \
  gateway.controlUi.allowedOrigins \
  '["http://<VM_PUBLIC_IP>:18789"]'

Plus Azure NSG rule restricting TCP 18789 to your IP.

Configuration Reference

View your current configuration:

docker compose run --rm openclaw-cli config get

Key gateway settings:

Next Steps

With the gateway properly configured, let’s connect a Discord bot: Connecting OpenClaw to Discord on Azure.