openclaw - 💡(How to fix) Fix Add global provider request proxy/default SSRF policy for model providers [1 comments, 2 participants]

Feature request

Add a global/default provider request policy for model providers, so operators can configure an explicit proxy and fake-IP/private-network allowance once instead of repeating it under every models.providers.<id>.request block.

Version / context

OpenClaw 2026.4.27 (cbc2ba0)

Problem

The documented top-level proxy feature is process-wide and useful in principle, but it currently is not a safe fit for our fleet because of #74809. The working setup is to use owner/provider-specific explicit proxies.

For model providers, the only schema-supported place I found for allowPrivateNetwork is per provider:

"models": {
  "providers": {
    "google": {
      "request": {
        "proxy": {
          "mode": "explicit-proxy",
          "url": "http://127.0.0.1:6152"
        },
        "allowPrivateNetwork": true
      }
    }
  }
}

That works, but it is difficult to maintain. Every remote provider needs the same repeated block. Examples include built-in providers such as:

• google
• openrouter
• other configured remote providers
• future remote providers added later

If one provider is missed, agent replies can fail in non-obvious ways. In our case, Discord messages were received, but a configured default remote model provider was still blocked by SSRF fake-IP handling:

[security] blocked URL fetch (url-fetch) targetOrigin=https://<redacted-provider-host> reason=Blocked hostname or private/internal/special-use IP address
[agent/embedded] ... provider=<redacted-provider> error=Blocked hostname or private/internal/special-use IP address

Adding allowPrivateNetwork: true to that provider's request block fixed replies. But this is easy to miss and hard to audit.

Why this matters

Many desktop/home-lab operators use proxy stacks such as Surge/Clash with fake-IP DNS ranges. In that setup, public hosts may resolve to 198.18.0.0/15 or other special ranges locally, while the proxy itself is the component that resolves and enforces the real upstream route.

The operator may intentionally trust this local proxy environment and want model/provider HTTP traffic to consistently use it.

Proposed config shape

One possible shape:

"models": {
  "defaults": {
    "request": {
      "proxy": {
        "mode": "explicit-proxy",
        "url": "http://127.0.0.1:6152"
      },
      "allowPrivateNetwork": true
    }
  }
}

Alternative shape under top-level proxy:

"proxy": {
  "enabled": true,
  "proxyUrl": "http://127.0.0.1:6152",
  "providerRequestDefaults": {
    "allowPrivateNetwork": true
  }
}

Or a dedicated top-level request policy:

"providerRequest": {
  "proxy": {
    "mode": "explicit-proxy",
    "url": "http://127.0.0.1:6152"
  },
  "allowPrivateNetwork": true
}

Desired behavior

• Apply the global/default request policy to all model providers unless they override it.
• Preserve per-provider override capability.
• Local/self-hosted providers such as ollama should be able to opt out or be excluded by default if appropriate.
• The policy should be visible via openclaw config get / effective config inspection so operators can audit what each provider receives.

Current workaround

Repeat this block under every remote provider:

"request": {
  "proxy": {
    "mode": "explicit-proxy",
    "url": "http://127.0.0.1:6152"
  },
  "allowPrivateNetwork": true
}

This works, but is brittle. It already caused a real outage where Discord bots were connected and receiving messages, but no replies were produced because model calls were blocked.

Related issues

• #74809: top-level proxy breaks Discord TLS with a local HTTP proxy in our environment.
• #74810: LLM-only model runs and inherited tool allowlists.