fetchWithSsrFGuard strict mode resolves DNS locally before managed proxy #98925

Summary

fetchWithSsrFGuard still performs local DNS pinning for STRICT fetches when OpenClaw's managed proxy lifecycle is active. In proxy-only sandboxes, local DNS can fail or disagree with the managed proxy resolver, so strict/default guarded fetches fail before the proxy can resolve the target and enforce its egress policy.

This is showing up as repeated downstream patches in NemoClaw/OpenShell integrations. The common shape is not one plugin-specific bug: many OpenClaw call paths either call withStrictGuardedFetchMode(...) directly or omit mode, which defaults to STRICT.

Current behavior

resolveGuardedFetchMode() defaults missing mode to STRICT.

In STRICT mode, fetchWithSsrFGuard() currently does this even when OPENCLAW_PROXY_ACTIVE=1 and proxy env vars are configured:

1. Call resolvePinnedHostnameWithPolicy(...).
2. That helper uses local dns.lookup(..., { all: true }).
3. Only after local DNS succeeds does the fetch use the env proxy dispatcher.

That means proxy-only environments can fail with local DNS errors such as EAI_AGAIN / ENOTFOUND, or can reject fake/sentinel DNS results, before the managed proxy has a chance to resolve and apply policy.

Affected call paths observed downstream

Examples in current OpenClaw source:

• src/cron/isolated-agent/model-preflight.runtime.ts: probeLocalProviderEndpoint() calls fetchWithSsrFGuard() for managed inference preflight with a policy but no mode, so it defaults to STRICT.
• extensions/googlechat/src/auth.ts: fetchChatCerts() fetches Google Chat JWT verification certs with no mode or policy.
• extensions/googlechat/src/api.ts: withGoogleChatResponse() is used by outbound sends, edits, uploads, media fetches, and reactions; it passes no mode or policy.
• extensions/mattermost/src/mattermost/client.ts: the Mattermost guarded client wrapper passes a policy but no mode.
• extensions/mattermost/src/mattermost/probe.ts: the Mattermost reachability probe passes a policy but no mode.
• src/media/fetch.ts: media fetch can explicitly choose withStrictGuardedFetchMode(...).
• src/agents/tools/web-guarded-fetch.ts: web tools explicitly choose strict mode unless useEnvProxy is enabled.

Downstream references

NemoClaw has had to patch or work around this repeatedly:

• @openclaw/googlechat cert fetch fails: SSRF guard's per-request dispatcher bypasses NemoClaw's nemoclaw-http-proxy-fix.js global-agent hook NVIDIA/NemoClaw#4687: Google Chat cert fetch fails because strict guarded fetch bypasses the sandbox proxy path.
• fix(sandbox): cron preflight inference.local uses trusted env-proxy mode NVIDIA/NemoClaw#5129: cron preflight for inference.local had to inject mode: "trusted_env_proxy".
• feat(messaging): onboard Mattermost for OpenClaw NVIDIA/NemoClaw#5592: Mattermost onboarding exposes more strict-by-default call paths.
• feat(messaging): add Google Chat channel for OpenClaw NVIDIA/NemoClaw#6120: Google Chat channel adds a preload rewrite so inbound cert verification and outbound Google Chat calls use trusted proxy modes.

Related OpenClaw issue history shows the same class in individual call paths:

• web_fetch tool bypasses env proxy in proxy-only environments (SSRF guard DNS pinning) #63565: web_fetch bypasses env proxy in proxy-only environments due to SSRF guard DNS pinning.
• [Bug]: memory_search remote embeddings fail with ENOTFOUND when env proxy is configured — withRemoteHttpResponse skips TRUSTED_ENV_PROXY mode #52162: memory search remote embeddings fail with ENOTFOUND because a call path skips TRUSTED_ENV_PROXY.
• google-gemini-cli-auth: OAuth token exchange fails behind proxy (fetchWithSsrFGuard uses createPinnedDispatcher instead of EnvHttpProxyAgent) #34401: Google OAuth token exchange fails behind proxy because guarded fetch uses pinned direct dispatch instead of env proxy dispatch.

Expected behavior

When OpenClaw's managed proxy lifecycle is active (OPENCLAW_PROXY_ACTIVE=1) and the env HTTP proxy applies to the target URL, STRICT fetches should keep the pre-DNS SSRF checks that do not require local resolution:

• URL parsing and scheme checks
• hostname allowlist checks
• blocked hostname checks
• IP literal/private/internal/special-use checks
• redirect revalidation

Then the request should use the managed env proxy dispatcher without local DNS pinning. The managed proxy should own DNS resolution and private-IP enforcement for the final target in this mode.

This matches the trust boundary already implied by the managed proxy lifecycle and avoids requiring every plugin/call path to remember to opt into TRUSTED_ENV_PROXY.

Security notes

The fix should not make ordinary STRICT mode proxy-aware just because HTTP_PROXY is present. It should be limited to the managed proxy lifecycle signal. It should also preserve direct-mode DNS pinning outside managed proxy mode.

Tests should prove:

• default strict mode still ignores env proxy and pins local DNS
• strict mode with OPENCLAW_PROXY_ACTIVE=1 and env proxy configured uses the env proxy without local lookup
• blocked hostnames and private IP literals are still rejected before fetch
• redirects still re-run the pre-DNS policy checks