openclaw-network-troubleshooting

Diagnose OpenClaw provider call failures caused by DNS, proxy, fake-IP, and SSRF blocking.

Updated May 4, 2026
One-click install
npx skills add https://github.com/Junkfooooood/hermes-governance --skill openclaw-network-troubleshooting-junkfooooood
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openclaw-network-troubleshooting
Source: https://github.com/Junkfooooood/hermes-governance/tree/main/skills/autonomous-ai-agents/openclaw-network-troubleshooting
Command: npx skills add https://github.com/Junkfooooood/hermes-governance --skill openclaw-network-troubleshooting-junkfooooood

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? OpenClaw provider calls (image, video, web, LLM APIs) can fail with "resolves to private/internal/special-use IP address" errors even when the same API works in curl or a browser. This Skill pinpoints whether the root cause is fake-IP DNS from a proxy/VPN client, /etc/hosts pollution, proxy misconfiguration, or OpenClaw's SSRF guard, and fixes it without weakening security. ## Core Features & Use Cases - Log and Error Analysis: Search OpenClaw gateway logs for SSRF blocks and identify the exact blocked provider origin. - Resolver Comparison: Compare system resolver results against public DNS (1.1.1.1, 223.5.5.5) to detect fake-IP answers like 198.18.0.0/15 from TUN/proxy tools such as Shadowrocket, Clash, Surge, or sing-box. - Safe Fix Patterns: Configure proxy app DNS rules or inject HTTP_PROXY/HTTPS_PROXY via launchd, then verify with guarded request tests and real capability calls. - Use Case: MiniMax image generation fails inside OpenClaw on macOS while curl succeeds; this Skill traces the failure to fake-IP DNS, applies a proxy env fix, restarts the gateway, and verifies the block is gone. ## Quick Start Diagnose why my OpenClaw MiniMax image generation call fails with a private/internal IP error on macOS and fix it without disabling SSRF protection.

Frequently Asked Questions about openclaw-network-troubleshooting

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
Why does OpenClaw fail with "resolves to private/internal/special-use IP address"?

This error means OpenClaw's SSRF guard blocked a provider request because the domain resolved to a private or special-use IP. On macOS, proxy/VPN tools using fake-IP DNS often return 198.18.0.0/15 addresses for public domains, triggering the block even though the API is reachable.

How do I fix OpenClaw API calls that work in curl but fail in the gateway?

Compare the system resolver against public DNS with dig to detect fake-IP answers, then either add the provider domains to your proxy app's fake-IP filter or inject HTTP_PROXY/HTTPS_PROXY into the launchd environment and restart the OpenClaw gateway.

Does this work with Shadowrocket, Clash, Surge, or sing-box on macOS?

Yes, the workflow covers TUN/fake-IP proxy tools including Shadowrocket, Clash, Surge, Loon, sing-box, and Tailscale. It checks scutil DNS state, proxy processes, and local listener ports to identify which tool is intercepting DNS.

Should I set allowPrivateNetwork to true to fix OpenClaw SSRF blocks?

No, enabling allowPrivateNetwork for public providers weakens an intentional SSRF security boundary and only masks fake-IP DNS symptoms. The recommended fixes adjust DNS/proxy routing or use OpenClaw's trusted environment proxy mode instead.

Why does OpenClaw still fail after setting proxy environment variables?

Launchd environment changes only affect newly started processes, so the OpenClaw gateway must be restarted after setting variables. Also verify the provider domain is not in NO_PROXY, which would bypass the trusted proxy path and re-trigger fake-IP DNS pinning.