[UX] Warn when env proxy is detected but provider requests are not using it

Summary

OpenClaw already supports provider-level request proxy configuration via models.providers.<provider>.request.proxy.mode = "env-proxy", but this is currently hard to discover.

In proxy-required environments such as WSL + Clash/Mihomo or corporate networks, this creates a misleading failure mode: the gateway starts normally, the UI loads, but chat requests silently timeout because provider requests do not automatically use HTTP_PROXY / HTTPS_PROXY unless explicitly configured.

This proposal does not suggest changing the default behavior. It only suggests adding a startup warning to improve observability and reduce debugging friction.

Reproduction

Environment

• WSL2 (Ubuntu)
• Local proxy such as Clash / Mihomo, or a corporate proxy environment
• HTTP_PROXY / HTTPS_PROXY correctly set
• Remote model provider (for example OpenAI)

Steps

1. Start OpenClaw normally
2. Configure a remote provider
3. Send a chat request from the UI

Observed result

• Gateway starts successfully
• UI loads normally
• Chat requests timeout or fail with a network connection error
• No clear warning indicates that proxy configuration is the likely cause

Confirmed workaround

After explicitly enabling provider request proxy, requests work immediately:

{
  "models": {
    "providers": {
      "openai": {
        "baseUrl": "https://api.openai.com/v1",
        "models": [
          { "id": "gpt-5.4", "name": "gpt-5.4" },
          { "id": "gpt-5.4-mini", "name": "gpt-5.4-mini" }
        ],
        "request": {
          "proxy": {
            "mode": "env-proxy"
          }
        }
      }
    }
  }
}

Root cause

This is not a missing capability. OpenClaw already supports provider-level env proxy configuration.

The problem is that the current behavior is difficult to discover in common proxy-required setups:

• environment proxy variables may already be present
• the system service may inherit them correctly
• curl may work as expected
• but provider requests still bypass env proxy unless request.proxy.mode is explicitly configured for that provider

As a result, the app can appear healthy while core chat functionality is broken.

Proposed improvement

Add a non-breaking startup warning when all of the following are true:

• HTTP_PROXY or HTTPS_PROXY is detected
• the provider target is clearly remote rather than local
• provider request proxy is not explicitly configured

Example warning:

Detected HTTP_PROXY/HTTPS_PROXY but provider requests are not using env proxy.
This may cause request timeouts.
Consider setting:
models.providers.<provider>.request.proxy.mode = "env-proxy"

Non-goals

This proposal does not:

• auto-enable env proxy for all providers
• change existing proxy semantics
• route local or LAN providers through a proxy by default

The goal is only to improve discoverability and observability.

Why this matters

This issue is easy to hit in real-world setups:

• WSL + local proxy tools such as Clash / Mihomo
• corporate or restricted network environments
• users accessing remote model providers for the first time

Current behavior is misleading because:

• the gateway appears healthy
• the UI appears healthy
• only model requests fail
• users are pushed into low-signal debugging across gateway, service, and network layers

This makes first-run experience unnecessarily fragile for a common environment class.

Alternatives considered

1. Automatically use env proxy by default

Rejected for now.

That would reduce explicitness and could unintentionally route local, LAN, or otherwise non-remote providers through a proxy.

2. Documentation only

Helpful, but insufficient on its own.

The current failure mode is silent enough that many users will not know where to look.

3. Manual debugging by users

High friction and poor UX for a setup that is common and reproducible.

Additional note

In practice, enabling env proxy for a remote provider may require editing a larger explicit provider block than some users expect.

That makes the capability even less discoverable for users who only want provider requests to respect already-configured HTTP_PROXY / HTTPS_PROXY values.