Skip to content
Notifications
Clear all

Help: OpenClaw's Docker container won't pass our network proxy

3 Posts
3 Users
0 Reactions
2 Views
(@diego_h)
Reputable Member
Joined: 4 months ago
Posts: 122
Topic starter   [#15542]

I'm trying to integrate OpenClaw's new local inference container into our dev pipeline. Their Docker image runs fine on my local machine, but our corporate environment requires all outbound traffic to go through an authenticated network proxy.

The container fails to pull external models. I've set the standard `HTTP_PROXY` and `HTTPS_PROXY` environment variables in the `docker run` command, and even added them to a custom Dockerfile, but no luck. Their docs don't mention proxy config.

Has anyone gotten OpenClaw's container to work behind a proxy? Is there a config file inside the container I need to modify, or a specific way they handle network calls that bypasses the usual env vars? Our security stack won't allow a direct connection.


Still learning.


   
Quote
(@emma23)
Estimable Member
Joined: 1 week ago
Posts: 68
 

Ugh, proxies are the worst. Been there with a few SaaS tools.

OpenClaw's container might be ignoring the env vars if it's using a non-HTTP client for model downloads. Some of these inference engines use custom gRPC or raw TCP streams that don't respect HTTP_PROXY.

Two things to try:
- Set proxy vars in ALL_CAPS and lower_case. Docker can be picky. I do both.
- Build a custom image and set the proxy at the OS level. For their base image (often Debian), add `ENV` in your Dockerfile AND also `RUN echo 'Acquire::http::Proxy "http://your-proxy:port";' >> /etc/apt/apt.conf.d/proxy.conf`. This catches package managers too.

If that fails, you might need to trace the outbound calls. `docker run --network host` (just for testing!) then watch with `netstat`. Annoying, but it reveals the protocol.


Trial first, ask later.


   
ReplyQuote
(@coffeelover)
Estimable Member
Joined: 1 week ago
Posts: 111
 

Their docs don't mention it because they likely didn't test it. Classic vendor move - works on their clean-slate dev machine, fails in any real environment.

Those proxy env vars are only good for libs that actually check for them. If they're using something like a hardcoded Python `requests` session or a compiled binary, you're out of luck.

Could be they baked the model download into the entrypoint script. You'll probably have to hack the container or push back on your security team for a temp bypass, which is its own nightmare. Fun times.


Just my two cents.


   
ReplyQuote