Cannot connect using CLI when using trustedProxy | Friends of the Crustacean 🦞🤝 | Page 1

faint lava Apr 9, 2026, 1:52 PM

#

I am running openclaw in a docker container and this is my error in the logs:
[ws] unauthorized conn=03c04667-9344-4726-a96d-02899ac16164 remote=127.0.0.1 client=cli cli v2026.4.10 reason=trusted_proxy_loopback_source

this is my config:
"gateway": {
"mode": "local",
"trustedProxies": [
"192.168.1.25",
"127.0.0.1"
],
"auth": {
"mode": "trusted-proxy",
"trustedProxy": {
"userHeader": "x-forwarded-user",
"requiredHeaders": [
"x-forwarded-proto",
"x-forwarded-host"
],
"allowUsers": [],

  },
  "password": "redacted"
},
"port": 18789,
"bind": "lan",
"tailscale": {
  "mode": "off",
  "resetOnExit": false
},

Are there any alternatives to the CLI? I looked trough some other posts and it seems that the CLI auth when using a proxy isn't possible(from what i understand)

mortal lilyBOT Apr 9, 2026, 1:52 PM

#

spark walrusBOT Apr 9, 2026, 1:52 PM

#

⚠️ Missing API key for provider "openai". Configure the gateway auth for that provider, then try again.

faint lava Apr 9, 2026, 3:19 PM

#

@spark walrus ?

#

Cannot connect using CLI when using trustedProxy

spark walrusBOT Apr 9, 2026, 3:21 PM

#

Yep, your read is basically right.

trusted_proxy_loopback_source means OpenClaw saw the request as coming from 127.0.0.1, and gateway.auth.mode: "trusted-proxy" fails closed on loopback by design.

So in your setup:

127.0.0.1 in gateway.trustedProxies is not enough to make loopback valid for trusted-proxy auth
the CLI is not a good fit for direct auth against a trusted-proxy gateway
your configured password does not help while auth.mode is explicitly "trusted-proxy"

Practical options:

Use Dashboard / Control UI through the reverse proxy
- this is the main browser-based alternative
- docs: https://docs.openclaw.ai/web/dashboard
- trusted proxy docs: https://docs.openclaw.ai/gateway/trusted-proxy-auth

#

If you need the CLI, switch gateway auth to token or password
- that is the supported path for CLI access
If you want to keep trusted-proxy, make sure OpenClaw sees a non-loopback proxy source
- for Docker, that usually means the proxy reaches the container over a bridge/container IP like 172.x.x.x, not 127.0.0.1

So short version: CLI + trusted-proxy + loopback source is not supported.

If you want, paste openclaw --version plus how your proxy/container networking is wired up, and I can tell you which of the 3 options is the cleanest fix.

#

Short answer: yes, but not the CLI in that auth mode.

With gateway.auth.mode: "trusted-proxy":

OpenClaw expects requests to arrive from a non-loopback trusted proxy IP
127.0.0.1 is rejected for trusted-proxy auth, even if listed in trustedProxies
the CLI does not come in with the proxy identity flow, so it hits trusted_proxy_loopback_source

So your alternatives are:

Dashboard / Control UI via the reverse proxy for interactive use
https://docs.openclaw.ai/web/dashboard
https://docs.openclaw.ai/web/control-ui
HTTP APIs via the reverse proxy for programmatic use
https://docs.openclaw.ai/gateway/openai-http-api
https://docs.openclaw.ai/gateway/tools-invoke-http-api

#

Switch auth mode to token or password if you specifically need the CLI

Also, in Docker, if you want to keep trusted-proxy, OpenClaw needs to see the proxy coming from something like the proxy/container network IP, not 127.0.0.1.

Relevant docs: https://docs.openclaw.ai/gateway/trusted-proxy-auth

If you paste openclaw --version and how your proxy reaches the container, I can tell you whether to fix the networking or just swap to token/password for CLI access.

faint lava Apr 9, 2026, 3:24 PM

#

I want to use this command to check if the browser is working:
openclaw browser --browser-profile remote status

I am currently running:
brave.exe --remote-debugging-port=9222
On my main PC, and this is the config for the server:
"browser":{
"enabled": true,
"profiles":{
"remote": { "cdpUrl": "http://192.168.1.7:9222", "color": "#00AA00" }
}

spark walrusBOT Apr 9, 2026, 3:25 PM

#

Yep, that command is a good test, with one important catch:

openclaw browser --browser-profile remote status is still local CLI, but it talks to the loopback browser control service, not your trusted-proxy auth path.

So:

run it on the machine/container where OpenClaw is running
it is not a remote-through-the-proxy replacement for the normal CLI
if you run it from your PC against the proxied gateway, you’re back in the same auth problem

Your browser profile looks basically right. I’d just make it explicit that Brave is externally managed:

"browser": {
  "enabled": true,
  "profiles": {

#

    "remote": {
      "cdpUrl": "http://192.168.1.7:9222",
      "attachOnly": true,
      "color": "#00AA00"
    }
  }
}

Best test order, from the OpenClaw container/server:

curl http://192.168.1.7:9222/json/version
curl http://192.168.1.7:9222/json/list
openclaw browser --browser-profile remote status

#

openclaw browser open https://example.com --browser-profile remote
openclaw browser tabs --browser-profile remote

If the curl calls fail, it’s a network / firewall / CDP exposure problem between the container and your PC, not a trusted-proxy problem.

Docs:

Browser: https://docs.openclaw.ai/tools/browser
Remote CDP troubleshooting: https://docs.openclaw.ai/tools/browser-wsl2-windows-remote-cdp-troubleshooting
Trusted proxy: https://docs.openclaw.ai/gateway/trusted-proxy-auth

If you want, paste:

openclaw --version
output of curl http://192.168.1.7:9222/json/version from inside the container

and I can tell you exactly which layer is failing.

faint lava Apr 9, 2026, 3:35 PM

#

C:\Program Files (x86)\BraveSoftware\Brave-Browser\Application>curl http://127.0.0.1:9222/json/version

C:\Program Files (x86)\BraveSoftware\Brave-Browser\Application>

it has no output in windows

spark walrusBOT Apr 9, 2026, 3:36 PM

#

That means layer 1 is failing before OpenClaw is even involved.

curl http://127.0.0.1:9222/json/version on Windows should return JSON.
If it returns nothing, Brave is not actually serving CDP yet.

So I’d pause the OpenClaw side for a sec and fix this first:

Fully quit Brave
- make sure no Brave processes are left running

Start a fresh Brave with remote debugging enabled

then re-test:

curl -v http://127.0.0.1:9222/json/version
curl -v http://127.0.0.1:9222/json/list

#

Also check in Brave:
- brave://inspect/#remote-debugging

Once Windows local CDP works, then test from the OpenClaw container:

curl http://192.168.1.7:9222/json/version

If that fails, the problem becomes:

Brave is only listening locally, or
Windows/network/firewall is blocking the container from reaching it

And only after both of those work should you try:

#

openclaw browser --browser-profile remote status
openclaw browser open https://example.com --browser-profile remote

One small config tweak I’d still make:

"remote": {
  "cdpUrl": "http://192.168.1.7:9222",
  "attachOnly": true,
  "color": "#00AA00"
}

Docs:

https://docs.openclaw.ai/tools/browser

#

https://docs.openclaw.ai/tools/browser-wsl2-windows-remote-cdp-troubleshooting

If you want, paste the output of:

curl -v http://127.0.0.1:9222/json/version

and I’ll help narrow down whether Brave isn’t exposing CDP at all, or just not exposing it to the network.

faint lava Apr 9, 2026, 3:41 PM

#

I switched to chrome and now: Server running at: starting…

spark walrusBOT Apr 9, 2026, 3:42 PM

#

That sounds like progress 👍

If you’re seeing starting…, the next thing I’d check is still the raw CDP endpoint, not OpenClaw yet.

On the Windows box running Chrome:

curl -v http://127.0.0.1:9222/json/version
curl -v http://127.0.0.1:9222/json/list

You want JSON back there.

Then from the OpenClaw container/server:

#

curl http://192.168.1.7:9222/json/version

So the flow is:

Windows local works
Container can reach the same endpoint

Then try:

openclaw browser --browser-profile remote status
openclaw browser open https://example.com --browser-profile remote
openclaw browser tabs --browser-profile remote

If openclaw browser ... status is the thing showing starting…, give it a few seconds once, but the real truth is whether /json/version returns JSON.

#

If you paste the output of the Windows curl -v command, I can tell pretty quickly which layer is still broken.

faint lava Apr 9, 2026, 3:59 PM

#

now it is accesible from the openclaw docker container, but I still dont have access to the CLI to check the status

{
"Browser": "Chrome/146.0.7680.178",
"Protocol-Version": "1.3",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0 Safari/537.36",
"V8-Version": "14.6.202.31",
"WebKit-Version": "537.36 (@19ad7ae2ac645174d8fbf01dfde5f19a6c54f641)",
"webSocketDebuggerUrl": "ws://192.168.1.7:9222/devtools/browser/fed385ff-b496-49d6-9caf-9c251e76fd48"
}

spark walrusBOT Apr 9, 2026, 4:00 PM

#

Nice, that JSON is the big milestone. It proves the remote Chrome CDP endpoint is reachable from the OpenClaw container.

So at this point, the browser side looks good.

What’s still blocked is the normal gateway CLI auth:

openclaw status
other gateway CLI commands from outside the container

Those still won’t work with gateway.auth.mode: "trusted-proxy" over loopback/direct CLI, which is why you keep hitting the auth wall.

What should work now

If you run this inside the OpenClaw container:

#

openclaw browser --browser-profile remote status
openclaw browser open https://example.com --browser-profile remote
openclaw browser tabs --browser-profile remote

that is the right next test.

Important distinction

Gateway CLI → still blocked by trusted-proxy design
openclaw browser ... local browser CLI inside the container → should be testable now

If you need remote operator access from your PC

Use one of these:

#

Dashboard / Control UI through the proxy
https://docs.openclaw.ai/web/dashboard
https://docs.openclaw.ai/web/control-ui
Switch gateway auth to token or password if you specifically want CLI access from outside

Also, I’d keep this in config for the remote browser profile:

"remote": {
  "cdpUrl": "http://192.168.1.7:9222",
  "attachOnly": true,
  "color": "#00AA00"
}

If openclaw browser --browser-profile remote status fails inside the container, paste that exact error, because that would be a different issue now, and I think we’re close.

faint lava Apr 9, 2026, 4:01 PM

#

$ node@d2959d1b0f94:/app$ openclaw browser --browser-profile remote status

🦞 OpenClaw 2026.4.10 (unknown)
I can grep it, git blame it, and gently roast it—pick your coping mechanism.

│
gateway connect failed: GatewayClientRequestError: unauthorized
◇
Error: gateway closed (1008): unauthorized
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/node/.openclaw/openclaw.json
Bind: lan

spark walrusBOT Apr 9, 2026, 4:03 PM

#

Ah, that clears it up. openclaw browser ... is still hopping through the gateway, so it hits the same trusted-proxy auth wall.

So the picture now is:

Chrome CDP is working ✅
Remote CDP is reachable from the container ✅
CLI is still blocked by gateway.auth.mode: "trusted-proxy" ✅ unfortunately expected

If you just want to check the browser from inside the container, use the loopback browser control API directly instead of the CLI.

With gateway.port: 18789, the browser control port is usually 18791.

Try:

curl -H 'x-openclaw-password: <your-password>' \

#

  'http://127.0.0.1:18791/?profile=remote'

curl -H 'x-openclaw-password: <your-password>' \
  'http://127.0.0.1:18791/tabs?profile=remote'

If you want to open a page:

curl -X POST \
  -H 'x-openclaw-password: <your-password>' \
  -H 'content-type: application/json' \
  -d '{"url":"https://example.com"}' \
  'http://127.0.0.1:18791/tabs/open?profile=remote'

#

A couple notes:

the standalone browser API is loopback-only
it uses shared-secret auth only (x-openclaw-password / bearer token), not trusted-proxy headers
so this is good for local container-side testing, not remote CLI from your PC

I’d also set:

"remote": {
  "cdpUrl": "http://192.168.1.7:9222",
  "attachOnly": true,
  "color": "#00AA00"
}

Docs:

#

If you want true CLI access from outside, you’ll need to switch the gateway to token or password auth. Otherwise, for remote use, stick to Dashboard / Control UI through the proxy.

Glad we caught the real boundary here. If you want, paste the output of the curl http://127.0.0.1:18791/... call and I’ll help interpret it.

faint lava Apr 9, 2026, 4:06 PM

#

can the agent test if the connection is ok? like ask him to search for something?

spark walrusBOT Apr 9, 2026, 4:06 PM

#

Yes, and that’s actually the best end-to-end test.

Just make sure you ask it to use the browser, not plain web search, because web_search would bypass the whole browser/CDP path.

Good test prompts:

Use the browser tool to open https://example.com and tell me the page title
Use the browser tool to open google.com, search for OpenClaw docs, and tell me the first result
Open https://news.ycombinator.com in the browser and give me a snapshot

What that tests:

agent can call the browser tool
OpenClaw can reach your remote Chrome CDP
page open / tab control / snapshot all work

If it succeeds, your browser connection is basically good.

#

If it fails, the tool error will tell you which layer is still broken.

Small but important detail: say “use the browser tool” explicitly, otherwise the agent may choose web_search instead.

If you want, I can help you write a minimal test prompt that proves the full stack in one shot.

faint lava Apr 9, 2026, 4:10 PM

#

this is his output:

Sori, but we're back to that unauthorized (1008) glitch. 💀

Because your Gateway is in trusted-proxy mode, it's blocking the openclaw browser command since it's trying to connect via the local loopback (127.0.0.1). It's the same "security wall" that blocked the status command earlier.

To make the browser tool (and other CLI tools) work, you've got to switch the auth mode from trusted-proxy to token. The proxy will still handle the UI and external access, but the Gateway will stop treating the local machine like a stranger.

Want me to try and switch it for you, or do you want to handle the config? 🌀

spark walrusBOT Apr 9, 2026, 4:11 PM

#

Yep, the root cause in that output is right.

Small correction though: the fix is not specifically “switch to token”, it’s:

stay on trusted-proxy and accept that local CLI-style commands won’t work, or
switch to a shared-secret auth mode (token or password) so CLI can work

Important nuance: if you switch away from trusted-proxy, your proxy can still sit in front of OpenClaw, but it stops being the auth boundary. You’d be using token/password auth instead of proxy-identity auth.

So the tradeoff is basically:

Trusted-proxy
- good for proxy-authenticated browser/UI access
- bad for local/direct CLI commands like openclaw status / openclaw browser ...
Token/password
- good for CLI

#

browser/UI also works, but now with shared-secret auth instead of trusted-proxy identity

So yeah, the agent’s diagnosis is solid. The only oversimplification is that it’s not “token or bust”, and changing auth mode changes the whole auth model.

Docs:

If you want, I can help you choose between:

keep trusted-proxy + use UI/browser only, or
switch to token/password + keep CLI access

faint lava Apr 9, 2026, 4:13 PM

#

it says that it does not have a browser tool

spark walrusBOT Apr 9, 2026, 4:14 PM

#

Yep, that usually means one of these is true:

browser.enabled is off
the bundled browser plugin is disabled
plugins.allow is restrictive and does not include browser
tools.allow is restrictive and does not include browser

The docs call out plugins.allow missing browser as the most common cause.

What to check in your config:

{
  browser: {
    enabled: true
  },

#

  plugins: {
    entries: {
      browser: {
        enabled: true
      }
    }
  }
}

If you use a plugin allowlist, make sure it includes browser:

{
  plugins: {

#

    allow: ["browser", "..."]
  }
}

If you use a tool allowlist, include browser there too:

{
  tools: {
    allow: ["browser", "..."]
  }
}

Then restart the gateway. Browser/plugin config changes do not fully apply until restart.

#

Docs:

https://docs.openclaw.ai/tools/browser#missing-browser-command-or-tool

If you paste just these config sections, I can spot it fast:

browser
plugins
tools

faint lava Apr 9, 2026, 4:17 PM

#

"browser": {
"enabled": true,
"profiles": {
"remote": {
"cdpUrl": "http://192.168.1.7:9222",
"color": "#00AA00",
"driver": "openclaw",
"attachOnly": true
}
}
}
}

"plugins": {
"entries": {
"browser": {
"enabled": true
},
"ollama": {
"enabled": true
},
"google": {
"enabled": true
},
"memory-core": {
"config": {
"dreaming": {
"enabled": true
}
}
}
}
},

"tools": {
"profile": "coding",
"web": {
"search": {
"provider": "ollama",
"enabled": true,
"openaiCodex": {}
},
"fetch": {
"enabled": true
}
}
},

spark walrusBOT Apr 9, 2026, 4:17 PM

#

Aha, found it.

Your browser plugin is enabled, but this line is the blocker:

"tools": {
  "profile": "coding"
}

coding does not include the browser tool. It includes group:web, but browser is in group:ui, not group:web.

So the agent saying “I don’t have a browser tool” is expected with that config.

Fix

Keep coding, but add browser access explicitly:

#

"tools": {
  "profile": "coding",
  "allow": ["group:ui"],
  "web": {
    "search": {
      "provider": "ollama",
      "enabled": true,
      "openaiCodex": {}
    },
    "fetch": {
      "enabled": true
    }
  }
}

#

or more narrowly:

"tools": {
  "profile": "coding",
  "allow": ["browser"]
}

Then restart the gateway.

Why

From the docs:

coding = fs + runtime + web + sessions + memory + media + cron
browser lives in group:ui

#

Docs:

So, good news: this one is not your trusted-proxy issue. It’s just tool policy. 🎉

If you add browser or group:ui and restart, the agent should be able to test the browser. Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

faint lava Apr 9, 2026, 4:23 PM

#

"tools": {
"profile": "coding",
"allow": ["group:ui"],
"web": {
"search": {
"provider": "ollama",
"enabled": true,
"openaiCodex": {}
},
"fetch": {
"enabled": true
}
}
},

I restarted, and it still doesn't have the tool

spark walrusBOT Apr 9, 2026, 4:24 PM

#

Your global config looks right now. So if it still says no browser tool, the next 2 likely causes are:

You’re still in an old session
- tool/catalog changes often don’t show up mid-session
- start a brand new session after the gateway restart (/new, new thread, or fresh chat)
There’s an agent-specific override
- check for any of these:
- agents.list[].tools.profile
- agents.list[].tools.allow / deny / alsoAllow
- tools.byProvider

The important bit is: with

"tools": {

#

  "profile": "coding",
  "allow": ["group:ui"]
}

the global policy should allow browser.

So if it still doesn’t, I’d strongly suspect old session state or a per-agent override.

What I’d do next:

restart gateway
start a new session
ask: Use the browser tool to open https://example.com and tell me the page title

If it still says missing, paste these sections too:

#

agents
tools.byProvider (if present)
whether this is a new session or the same old one

Docs:

I think you’re very close, this now looks more like tool policy/session caching than browser transport.

faint lava Apr 9, 2026, 4:32 PM

#

now this is his output:

Comanda a fost: browser(action="open", url="https://www.google.com")

Output-ul complet:

{
"status": "error",
"tool": "browser",
"error": "gateway closed (1008): unauthorized\nGateway target: ws://127.0.0.1:18789\nSource: local loopback\nConfig: /home/node/.openclaw/openclaw.json\nBind: lan"
}

spark walrusBOT Apr 9, 2026, 4:33 PM

#

Perfect, that output is actually very helpful.

It means:

the browser tool is present now ✅
but the tool runtime still connects to the local gateway at ws://127.0.0.1:18789
and trusted-proxy is rejecting that loopback connection with the same 1008 unauthorized wall as before

So we’ve narrowed it down a lot:

not a browser transport problem
not a missing tool anymore
it’s the auth mode

Practical takeaway

In your 2026.4.10 setup, browser tool calls are still blocked by gateway.auth.mode: "trusted-proxy" when they go through the local loopback gateway path.

#

So your real options are:

Keep trusted-proxy
- use Dashboard / Control UI through the proxy
- don’t expect CLI / browser tool / local gateway-style calls to work
Switch to token or password
- then CLI + browser tool + agent browser actions should work
- this is what I’d recommend if your main goal is browser automation
Treat this as a bug / limitation
- because it’s a pretty reasonable expectation that server-side browser actions should work
- file it here with that exact error output:
  https://github.com/openclaw/openclaw/issues

Honestly, I think you’ve hit a real limitation in this auth combination, not a bad config at this point.

#Cannot connect using CLI when using trustedProxy

What should work now

Important distinction

If you need remote operator access from your PC

Fix

Why

Practical takeaway