#Reverse Proxy headers are not trusted

1 messages · Page 1 of 1 (latest)

thorn charm
#

Hi i am running openclaw in a docker container using docker-compose behind a (nginx) proxy

I ran the security audit and got this output:

OpenClaw security audit
Summary: 0 critical · 2 warn · 1 info
Run deeper: openclaw security audit --deep

WARN
gateway.trusted_proxies_missing Reverse proxy headers are not trusted
  gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client checks cannot be spoofed.
  Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.

according to the wiki there is a proxy config:
https://docs.openclaw.ai/gateway/security#reverse-proxy-configuration
but i dont know where to configure trustedProxies

dawn remnantBOT
#

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

mystic depotBOT
#

You configure it in the Gateway config, not in nginx.

Where

OpenClaw reads a JSON5 config from $OPENCLAW_CONFIG_PATH (default: ~/.openclaw/openclaw.json) inside the container.
Docs: https://docs.openclaw.ai/help/faq#what-format-is-the-config-where-is-it

So you want to add:

{
  gateway: {
    trustedProxies: ["127.0.0.1"], // or your nginx/proxy IP as seen by the gateway
  },
}

How (easiest)

#

If you have the CLI in the container:

openclaw config set gateway.trustedProxies '["127.0.0.1"]'

(Then restart the container / gateway if it doesn’t hot-reload.)

Which IP to put there?

It must be the IP address that the Gateway sees the reverse proxy connection coming from:

  • nginx on the same host network namespace → often 127.0.0.1
  • nginx in another docker container → the nginx container IP (or the docker bridge gateway IP, depending on how you wired it)

Related docs section you linked: https://docs.openclaw.ai/gateway/security#reverse-proxy-configuration

thorn charm
#

Thank you

thorn charm
#

What these settings do:
Setting Purpose
bind: "lan" Allows connections from Docker's internal network (default loopback blocks them)
trustedProxies Tells the gateway to trust proxy headers from Docker's network (172.16.0.0/12)
controlUi.allowInsecureAuth Allows the dashboard to authenticate over HTTP (needed when TLS terminates at the proxy)
Troubleshooting the dashboard

"gateway token mismatch" — The token in your browser URL does not match the token in openclaw.json. Check that gateway.auth.token in ./data/config/openclaw.json matches the OPENCLAW_GATEWAY_TOKEN in your .env file. If they differ, update one to match the other and restart.

"pairing required" — The gateway doesn't trust the proxy connection. Make sure trustedProxies and controlUi.allowInsecureAuth are set as shown above, then restart the gateway.

"Proxy headers detected from untrusted address" — Same cause as above. Add trustedProxies with the Docker network range to your gateway config.

How can I set these settings

mystic depotBOT
#

Those are Gateway config keys (in openclaw.json / JSON5), so you set them either by editing the config file that’s mounted into your container, or by running openclaw config set … inside the container.

Docs:

1) Find where your container reads config from

Inside the container:

docker compose exec openclaw sh -lc 'echo "$OPENCLAW_CONFIG_PATH"; ls -la ~/.openclaw; ls -la ${OPENCLAW_CONFIG_PATH:-~/.openclaw/openclaw.json}'

Default is ~/.openclaw/openclaw.json (unless you set OPENCLAW_CONFIG_PATH).

2) Set the keys (CLI way)

#

If your reverse proxy is a different container, gateway.bind: "loopback" will block it, so you typically want lan:

docker compose exec openclaw openclaw config set gateway.bind lan

Then set trusted proxies. Best is the proxy container’s IP (or a small dedicated docker subnet), not all of 172.16.0.0/12:

docker compose exec openclaw openclaw config set gateway.trustedProxies '["172.20.0.10"]' --strict-json
# or (if you must) a CIDR for your *specific* compose network:
docker compose exec openclaw openclaw config set gateway.trustedProxies '["172.20.0.0/16"]' --strict-json

Restart:

# 
docker compose restart openclaw

About controlUi.allowInsecureAuth

You only need:

openclaw config set gateway.controlUi.allowInsecureAuth true

if you are opening the Control UI over plain HTTP in the browser.
If nginx terminates TLS and you access the UI via https://…, you generally should not enable this (it’s a security downgrade).

3) Make sure nginx is not letting clients spoof X-Forwarded-For

OpenClaw expects your proxy to overwrite forwarded headers (not append). In nginx, prefer:

# 
proxy_set_header X-Real-IP       $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;

(Using $proxy_add_x_forwarded_for can allow spoofing because the first IP might come from the client.)

4) Extra docker-compose safety tip

If you set gateway.bind: "lan", try to not publish the gateway port to the host (ports:). Let only nginx reach it on the internal docker network (expose:), so there’s no “bypass the proxy” path.

If you paste your docker-compose.yml network section (and whether nginx is on-host or in-compose), I can tell you the exact trustedProxies value to use.

thorn charm
#

When i go to the webui to channels and see Channel config schema unavailable.
How to fix it?

mystic depotBOT
#

That UI message usually means: the Gateway did return a config schema, but it doesn’t contain a schema node for channels.<id> — which happens when the channel plugin isn’t loaded/enabled.

In OpenClaw, channels (telegram/discord/whatsapp/…) are implemented as bundled plugins, and most bundled plugins are disabled by default.

Fix

Inside the container, run:

openclaw plugins list

If e.g. telegram / discord / whatsapp show as disabled, enable the one(s) you want:

openclaw plugins enable telegram
# or:
# 
openclaw plugins enable discord
openclaw plugins enable whatsapp

Then restart the gateway/container (plugin config changes require a restart):

docker compose restart openclaw

If it’s still unavailable

Run this and paste the output:

openclaw plugins doctor
#

That will tell us if the channel plugin failed to load (missing deps, blocked by plugins.allow, etc.).

thorn charm
#

How can I use an ollama model from another docker container?

mystic depotBOT
#

To use Ollama that’s running in another Docker container, you just need:

  1. Network reachability (openclaw container can hit ollama:11434)
  2. Tell OpenClaw the Ollama baseUrl (and set an OLLAMA_API_KEY placeholder to “turn it on”)

Docs: https://docs.openclaw.ai/providers/ollama

1) docker-compose: put both services on the same network

Example sketch:

services:
  ollama:
    image: ollama/ollama:latest
    # make sure it listens on the container interface, not 127.0.0.1 only
    environment:
# 
      - OLLAMA_HOST=0.0.0.0:11434
    expose:
      - "11434"
    volumes:
      - ollama:/root/.ollama

  openclaw:
    image: ghcr.io/openclaw/openclaw:latest
    depends_on:
      - ollama
    environment:
      - OLLAMA_API_KEY=ollama-local   # any value is fine; Ollama doesn’t need a real key
    # mount your OpenClaw config as you already do

2) Point OpenClaw at the Ollama container

#

Set the provider base URL to the service name:

openclaw config set models.providers.ollama.baseUrl "http://ollama:11434"
openclaw config set models.providers.ollama.apiKey "ollama-local"

(Then restart the gateway/container if needed.)

Now you can set an agent model like:

{
  agents: { defaults: { model: { primary: "ollama/<model-id-from-ollama-list>" } } }
}