openclaw - 💡(How to fix) Fix [Bug]: Custom OpenAI-compatible provider works via direct /v1/chat/completions, but OpenClaw 2026.3.28 always fails with "Connection error" [4 comments, 5 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

OpenClaw 2026.3.28 fails on every chat turn for a custom OpenAI-compatible provider with “LLM request failed: network connection error”, even though direct /v1/models and /v1/chat/completions calls to the same endpoint succeed from the same Windows machine.

Steps to reproduce

1. Configure a custom provider in openclaw.json with:
   • baseUrl: https://claw.xclawxx.top/v1
   • api: openai-completions
   • a valid API key
   • model id MiniMax-M2.7-highspeed
2. Set the default model to my-gateway/MiniMax-M2.7-highspeed.
3. Run the gateway in the foreground with openclaw gateway run.
4. Open the dashboard / webchat.
5. Send hello.
6. Observe that OpenClaw fails with LLM request failed: network connection error / rawError=Connection error, while direct requests to /v1/models and /v1/chat/completions against the same endpoint succeed.

Expected behavior

OpenClaw should successfully call the custom provider and return a normal assistant response, matching the successful direct /v1/chat/completions result from the same machine.

Actual behavior

OpenClaw fails every turn with “LLM request failed: network connection error” and “rawError=Connection error”, even though the upstream endpoint works correctly via direct HTTP requests.

OpenClaw version

2026.3.28

Operating system

Windows 11

Install method

npm global

Model

my-gateway/MiniMax-M2.7-highspeed

Provider / routing chain

openclaw -> custom OpenAI-compatible provider (my-gateway) -> https://claw.xclawxx.top/v1 -> MiniMax-M2.7-highspeed

Additional provider/model setup details

Custom provider configured via models.providers.my-gateway with:

• baseUrl: https://claw.xclawxx.top/v1
• api: openai-completions
• valid API key (redacted)
• model id: MiniMax-M2.7-highspeed

I also tested:

• direct GET /v1/models from the same Windows machine → 200 OK
• direct POST /v1/chat/completions from the same Windows machine → 200 OK with a valid assistant response

I forced the OpenClaw model transport to "sse" via:

"agents": {
  "defaults": {
    "models": {
      "my-gateway/MiniMax-M2.7-highspeed": {
        "params": {
          "transport": "sse"
        }
      }
    }
  }
}

### Logs, screenshots, and evidence

```shell
### Direct API checks from the same Windows machine

`GET /v1/models` returns `200 OK`.

`POST /v1/chat/completions` also returns `200 OK` with a valid assistant response for model `MiniMax-M2.7-highspeed`.

This confirms that:

- the upstream endpoint is reachable
- the API key is valid
- the model id is valid
- direct chat completions work outside OpenClaw

### Foreground OpenClaw gateway logs

Running `openclaw gateway run` shows the gateway itself starting normally and webchat connecting successfully:


[gateway] agent model: my-gateway/MiniMax-M2.7-highspeed
[ws] webchat connected ...

But actual assistant turns fail repeatedly with:
[agent/embedded] embedded run agent end: ... isError=true model=MiniMax-M2.7-highspeed provider=my-gateway error=LLM request failed: network connection error. rawError=Connection error.
[agent/embedded] embedded run failover decision: ... decision=surface_error reason=timeout provider=my-gateway/MiniMax-M2.7-highspeed
Representative log excerpt:

13:54:20 [gateway] agent model: my-gateway/MiniMax-M2.7-highspeed
13:55:20 [ws] webchat connected conn=...
13:56:32 [agent/embedded] embedded run agent end: runId=... isError=true model=MiniMax-M2.7-highspeed provider=my-gateway error=LLM request failed: network connection error. rawError=Connection error.
13:56:36 [agent/embedded] embedded run agent end: ...
13:56:42 [agent/embedded] embedded run agent end: ...
13:56:51 [agent/embedded] embedded run failover decision: runId=... stage=assistant decision=surface_error reason=timeout provider=my-gateway/MiniMax-M2.7-highspeed

This reproduces after:

fixing config syntax
separating gateway auth token vs provider API key
restoring baseUrl to https://claw.xclawxx.top/v1
restoring api to openai-completions
forcing transport: "sse"
upgrading from 2026.3.24 to 2026.3.28
running in foreground mode instead of Scheduled Task mode

Impact and severity

Affected: Users configuring a custom OpenAI-compatible provider via models.providers in local webchat sessions. Severity: High (blocks normal chat usage for the affected provider path). Frequency: Always reproduced in my environment after successful setup. Consequence: OpenClaw cannot complete assistant turns through the custom provider even though direct /v1/models and /v1/chat/completions calls succeed from the same machine.

Additional information

This does not appear to be a basic connectivity or credential problem, because the same Windows machine can successfully call both /v1/models and /v1/chat/completions directly against the same endpoint with the same API key.

It also does not appear to be only a Windows Scheduled Task issue, because the same failure reproduces in foreground mode with openclaw gateway run.

At this point the problem seems isolated to OpenClaw's actual embedded agent request path for this custom OpenAI-compatible provider.