openclaw - 💡(How to fix) Fix Interactive runs fail with auth-style 403 when custom OpenAI-compatible provider baseUrl uses Unicode/IDN or punycode hostname, but ASCII hostname/IP works [1 participants]

Summary

OpenClaw interactive runs (Web UI and local TUI / embedded path) fail with:

• 403 Your request was blocked.
• failoverReason: "auth"
• profileFailureReason: "auth"

when a custom OpenAI-compatible provider uses either:

• a Unicode/IDN hostname in baseUrl
• or the punycode form of that same hostname

The same backend works when accessed via:

• ASCII hostname
• public IP + dedicated /v1-only proxy port

This suggests an issue in OpenClaw's handling of non-ASCII-origin hostnames (including punycode forms) in the interactive/embedded run path.

Environment

• OpenClaw version: 2026.4.5
• Host: Linux
• Surface:
  • Web UI
  • local TUI
• Provider type:
  • custom OpenAI-compatible provider
  • api: openai-completions

Affected behavior

With a provider config like this:

{
  "models": {
    "providers": {
      "custom_provider": {
        "baseUrl": "https://<unicode-idn-domain>/v1",
        "api": "openai-completions",
        "apiKey": "<redacted>",
        "models": [
          {
            "id": "gpt-5.4",
            "name": "gpt-5.4",
            "contextWindow": 200000,
            "maxTokens": 8192
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "custom_provider/gpt-5.4"
      }
    }
  }
}

interactive runs fail before a usable assistant reply is produced.

Relevant logs:

error: 403 Your request was blocked.
failoverReason: auth
profileFailureReason: auth
provider: custom_provider
model: gpt-5.4

Key observation

The backend itself is healthy.

Direct manual requests to the same backend succeed:

curl https://<unicode-idn-domain>/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <redacted>' \
  --data '{"model":"gpt-5.4","messages":[{"role":"user","content":"reply with exactly: ok"}],"max_tokens":8}'

This returns HTTP 200 and ok.

The same is true for the punycode hostname and for an ASCII hostname.

So the failure is not simply "backend unavailable".

What was tested

1. Different backends

Two different OpenAI-compatible backends were tested:

• a LiteLLM-based backend
• a different OAuth-backed OpenAI-compatible backend

Manual requests succeeded against both backends.

2. Unicode hostname

Using a Unicode/IDN hostname in baseUrl caused interactive runs to fail with auth-style 403.

Example shape:

• https://<unicode-idn-domain>/v1

3. Punycode hostname

Using the punycode form of the same hostname also failed in interactive runs.

Example shape:

• https://<punycode-domain>/v1

Manual chat/completions requests still succeeded through this hostname.

4. Public IP + /v1-only gateway

A dedicated public proxy port exposing only /v1/* was created:

• http://<public-ip>:<port>/v1

Using that IP-based URL in the provider made Web UI / TUI interactive runs succeed.

5. ASCII hostname

Using an unrelated ASCII-only hostname also worked:

• https://<ascii-domain>/v1

Minimal conclusion

The failure correlates with using a hostname derived from an IDN domain in provider baseUrl.

• Unicode hostname: fails in interactive run path
• punycode hostname: also fails
• unrelated ASCII hostname: works
• public IP + port: works

Expected behavior

OpenClaw should handle provider baseUrl hostnames consistently regardless of whether the configured hostname is:

• Unicode/IDN form
• punycode form
• plain ASCII hostname
• public IP

If manual requests to the backend succeed, the interactive run path should not fail early with a local auth-style 403 purely because the configured hostname is Unicode or punycode.

Actual behavior

When baseUrl contains either a Unicode/IDN hostname or the punycode form of that hostname, interactive runs fail locally with auth-style 403:

403 Your request was blocked.
failoverReason: auth
profileFailureReason: auth

even though the same backend is otherwise reachable and returns valid chat completions.

Workaround

Avoid Unicode/IDN-derived hostname forms in provider baseUrl.

Use either:

• an unrelated ASCII hostname
• or a public IP + dedicated /v1-only proxy

Example working shape:

"baseUrl": "https://<ascii-domain>/v1"

or:

"baseUrl": "http://<public-ip>:<port>/v1"

instead of:

"baseUrl": "https://<unicode-idn-domain>/v1"

or:

"baseUrl": "https://<punycode-domain>/v1"