"agents": {
  "defaults": {
    "imageGenerationModel": {
      "primary": "google/gemini-3.1-flash-image-preview"
    }
  }
}

I also enabled the google and openai provider plugins, so this is no longer a "provider not registered" issue.

### Expected behavior

OpenClaw should ideally handle this more gracefully in common proxy environments.

Possible acceptable behaviors:

Allow requests to known public domains even if local DNS returns Fake-IP addresses.
Resolve/check the final target in a proxy-aware way.
Provide a documented opt-out / allowlist for SSRF checks in this scenario.
At minimum, surface a clearer error explaining that Fake-IP DNS/proxy mode is incompatible.

### Actual behavior

Actual behavior
image_generate fails with:

Blocked: resolves to private/internal/special-use IP address
Relevant log example:

[security] blocked URL fetch (url-fetch) target=https://generativelanguage.googleapis.com/v1beta/models/gemini-3.1-flash-image-preview:generateContent reason=Blocked: resolves to private/internal/special-use IP address
[tools] image_generate failed: Blocked: resolves to private/internal/special-use IP address
DNS resolution on this machine
These public domains resolve to Fake-IP addresses in my current network/proxy setup:

generativelanguage.googleapis.com -> 198.18.67.196
ai.google.dev -> 198.18.82.102
api.openai.com -> 198.18.82.167
chatgpt.com -> 198.18.71.100
openrouter.ai -> 198.18.56.125
api.fal.ai -> 198.18.82.168
scutil --dns shows the active resolver is also going through a 198.18.0.2 resolver on a utun interface.

### OpenClaw version

2026.3.23-2

### Operating system

macOS 26.3

### Install method

_No response_

### Model

GPT 5.4

### Provider / routing chain

openai - GPT 5.4

### Additional provider/model setup details

Why I think this is a bug
The blocked destination is not an actual private service I configured manually. It is a public provider endpoint, but the local proxy/DNS layer rewrites resolution to a special-use range. This makes OpenClaw incompatible with a common networking setup on macOS.

The security check is understandable, but the current behavior seems too strict for proxy/Fake-IP environments and ends up blocking legitimate outbound provider calls.

Workaround
Disabling Surge Enhanced Mode or excluding these domains from Fake-IP resolution appears to help, but that is only a workaround and not ideal.

Request
Could OpenClaw support Fake-IP / proxy-enhanced DNS setups more explicitly, or provide a safe override for trusted public provider domains?

### Logs, screenshots, and evidence

```shell