Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Since #54536, it seems that a localhost trusted-proxy is no longer trusted at all. This seems to have even been explicit in the design, since a test was written that states "rejects trusted-proxy identity headers from loopback sources".

It's unclear what the new configuration should be to allow authentication via a local proxy that's performing authn/authz.

Steps to reproduce

1. Start the latest openclaw (2026.3.31) with the following in the config:

    "port": 18789,
    "mode": "local",
    "bind": "loopback",
    "trustedProxies": ["127.0.0.1", "::1"],
    "auth": {
      "mode": "trusted-proxy",
      "trustedProxy": {
              "userHeader": "Remote-User",
              "allowUsers": ["foo"]
      }
    },

2. Configure a local proxy that performs authentication (i.e., Caddy + authelia) and injects a Remote-User header.
3. Receive unauthorized error

Expected behavior

User is authorized based on trusted proxy header.

Actual behavior

User is not authenticated, logs indicate reason=trusted_proxy_loopback_source

OpenClaw version

2026.3.31

Operating system

Debian 13 (trixie)

Install method

openclaw installer script

Model

openrouter/minimax/minimax-m2.5

Provider / routing chain

openclaw -> openrouter -> minimax-m2.5

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: anyone using a local authentication proxy
Severity: completely blocks gateway access

Additional information

No response