openclaw - 💡(How to fix) Fix [Bug]: api.openai.com blocked by SSRF guard on every LLM request despite public IP and allowedHostnames config

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Every LLM request to api.openai.com is blocked by the internal url-fetch SSRF guard with "Blocked hostname or private/internal/special-use IP address", causing permanent fallback to the configured backup model, even though api.openai.com resolves to public Cloudflare IPs and api.openai.com is already in browser.ssrfPolicy.allowedHostnames.

Steps to reproduce

1. Install OpenClaw on Raspberry Pi 4 (Ubuntu 24.04 arm64) behind a SOCKS5 proxy (sing-box via Tailscale exit nodes)
2. Configure openai/gpt-4o-mini as primary model with API key
3. Set browser.ssrfPolicy.allowedHostnames: ["api.openai.com"]
4. Send any message to the agent via Telegram
5. Observe fallback to backup model every time
6. Confirm with: grep "openai" ~/.openclaw/openclaw-$(date +%Y-%m-%d).log

Expected behavior

LLM requests to api.openai.com should succeed. The hostname is public, non-private, non-reserved, and explicitly listed in allowedHostnames — the SSRF guard should not block it.

Actual behavior

Every request is blocked before reaching the network: [security] blocked URL fetch (url-fetch) targetOrigin=https://api.openai.com reason=Blocked hostname or private/internal/special-use IP address Confirmed via sing-box logs: no connection to api.openai.com ever appears at the network layer. OpenClaw always falls back to the backup model.

OpenClaw version

2026.5.7 (eeef486)

Operating system

Ubuntu 24.04 arm64 (Raspberry Pi 4 8GB)

Install method

npm global

Model

openai/gpt-4o-mini

Provider / routing chain

openclaw (socks-local :2080) -> sing-box -> SOCKS5 exit node (Tailscale, UK) -> api.openai.com

Additional provider/model setup details

Traffic from OpenClaw goes through socks-local inbound (sing-box port 2080), routed via Tailscale SOCKS5 exit nodes. DNS resolves api.openai.com to 172.66.0.243 and 162.159.140.245 (both public Cloudflare IPs, verified is_private=False, is_reserved=False). Config: models.providers.openai with API key, browser.ssrfPolicy.allowedHostnames: ["api.openai.com"], tools.web.fetch.ssrfPolicy.allowRfc2544BenchmarkRange: true.

Logs, screenshots, and evidence

OpenClaw log (repeated pattern per request):
{"subsystem":"security"} blocked URL fetch (url-fetch) targetOrigin=https://api.openai.com reason=Blocked hostname or private/internal/special-use IP address
{"subsystem":"agent/embedded"} embedded run agent end — isError:true, error:"LLM request failed: network connection error.", failoverReason:"timeout", model:"gpt-4o-mini", provider:"openai", rawErrorPreview:"Connection error."

sing-box log (same time window): zero connections to api.openai.com via socks-local. Only api.telegram.org and openrouter.ai connections visible.

DNS resolution on the host:
172.66.0.243 — is_private: False, is_reserved: False
162.159.140.245 — is_private: False, is_reserved: False

Impact and severity

Affected: any OpenClaw instance behind a SOCKS5/tproxy proxy (sing-box, Clash, Surge) Severity: blocks workflow — OpenAI provider is completely unusable, always falls back silently Frequency: 100% reproducible, every single request Consequence: paid OpenAI API key cannot be used, user is unaware of fallback unless checking logs

Additional information

schema shows models.providers.*.request.allowPrivateNetwork but its description states it does not apply to the OpenAI WebSocket path. browser.ssrfPolicy.allowedHostnames is set but has no effect. There appears to be no config option to disable SSRF checking specifically for the LLM transport layer. Workaround: use OpenRouter as proxy to GPT models (openrouter.ai is not blocked).