OpenClaw "skills install" Hangs Behind a Corporate Proxy

Published April 17, 2026 · Bug #67770 · Affects: 2026.4.5–2026.4.14 · Platform: Kubernetes / egress-locked networks

You're running OpenClaw inside a Kubernetes cluster (or any network where all external traffic must go through a forward proxy). You've set HTTPS_PROXY correctly — curl through the proxy reaches clawhub.ai just fine. Then you run:

openclaw skills install web-search

And get this after ~10 seconds:

fetch failed | Connect Timeout Error (attempted address: clawhub.ai:443, timeout: 10000ms)

The CLI ignored your proxy entirely and tried to connect directly to clawhub.ai:443 — which your NetworkPolicy blocks.

Root Cause

This is a known Node.js behavior that catches a lot of people off guard. Node's built-in fetch (powered by undici) does not read HTTPS_PROXY or HTTP_PROXY environment variables automatically.

Unlike curl or older http.request-based code, undici's fetch requires the caller to explicitly install a ProxyAgent as the global dispatcher. OpenClaw's ClawHub module uses native fetch without doing this — so it bypasses the proxy entirely regardless of your environment variables.

The affected code is in /app/dist/clawhub-BFjxm1oA.js, using https://clawhub.ai as the endpoint (overridable via OPENCLAW_CLAWHUB_URL).

Workarounds

Option 1: Preload global-agent (Drop-in Shim)

The quickest fix for containers/Kubernetes: inject the global-agent package as a Node preload. It patches http, https, and undici to honor HTTPS_PROXY:

# In your Dockerfile or entrypoint, before openclaw starts:
npm install -g global-agent

# Set environment variables in your pod spec:
# GLOBAL_AGENT_HTTPS_PROXY=http://squid-proxy.openclaw.svc.cluster.local:3128
# NODE_OPTIONS=--require global-agent/bootstrap

With NODE_OPTIONS=--require global-agent/bootstrap set, all subsequent fetch calls in the OpenClaw process will route through the proxy automatically.

Option 2: Set OPENCLAW_CLAWHUB_URL to an Internal Mirror

If you control an internal package mirror or can stand up an nginx reverse proxy inside your cluster that proxies clawhub.ai:

# In your pod/deployment env:
OPENCLAW_CLAWHUB_URL=https://clawhub-mirror.internal.company.com

This routes the ClawHub fetch to an endpoint reachable without going through an external proxy. Works well in air-gapped or highly restricted clusters.

Option 3: Install Skills Manually

Download skill tarballs from a machine with external access and copy them into the container:

# On an external machine with access:
openclaw skills install web-search
# Find the installed skill:
ls ~/.openclaw/skills/

# Copy to your restricted machine/container via your existing artifact pipeline
# Then restart the gateway — OpenClaw scans ~/.openclaw/skills/ on boot

Who This Affects

This primarily hits:

OpenClaw deployed on Kubernetes (EKS, GKE, AKS) with NetworkPolicies restricting egress
Corporate environments where all internet traffic must pass through Squid or a similar forward proxy
Air-gapped or compliance-restricted deployments

Home users and standard VPS/cloud VM setups with open egress are not affected — skills install works fine there.

Status

The upstream fix is straightforward — add a ProxyAgent dispatcher in the ClawHub module when proxy env vars are present:

import { ProxyAgent, setGlobalDispatcher } from 'undici';
const proxy = process.env.HTTPS_PROXY || process.env.https_proxy
           || process.env.HTTP_PROXY  || process.env.http_proxy;
if (proxy) setGlobalDispatcher(new ProxyAgent(proxy));

Track progress at issue #67770. The global-agent preload (Option 1) is the most reliable workaround until this ships.

If you're managing an OpenClaw deployment in a locked-down cluster and need help with proxy configuration or internal routing, ClawReady handles exactly this kind of setup.

← Back to blog