#openclaw fetch failed

1 messages · Page 1 of 1 (latest)

gleaming nymph
#

need help

radiant socketBOT
#

Verification failed: fetch failed is coming from Node’s fetch() during the custom provider verification POST to:

<API Base URL>/chat/completions (OpenAI-compatible)

In practice this almost always means the OpenClaw CLI process can’t reach that URL at the network/TLS level (DNS/proxy/cert/IPv6), even if other apps (SillyTavern) can.

A couple of high-signal things to check:

  1. Version first (important)
    Please paste:
openclaw --version
  1. Proxy: OpenClaw/Node does not automatically use the macOS “System Proxy”
    Node/undici generally only uses proxies when you set proxy env vars in the same shell.
#

In the terminal where you run openclaw configure, run:

env | grep -i proxy

If you only have a system proxy (or only ALL_PROXY), set explicit HTTP(S) proxy env vars and retry:

export HTTPS_PROXY="http://127.0.0.1:7890"
export HTTP_PROXY="http://127.0.0.1:7890"
export NO_PROXY="127.0.0.1,localhost"

openclaw configure

(Replace 127.0.0.1:7890 with whatever your proxy app exposes as an HTTP proxy port.)

#
  1. Get the real underlying error (DNS? timeout? cert?)
    Run this and paste the output (it prints e.cause which often contains the actual reason):
node -e 'fetch("https://test.cfd/v1/chat/completions",{method:"POST",headers:{"Content-Type":"application/json","Authorization":"Bearer sk-REDACTED"},body:JSON.stringify({model:"gpt-5.4",messages:[{role:"user",content:"Hi"}],max_tokens:1,stream:false})}).then(r=>console.log("status",r.status)).catch(e=>{console.error("err",e); console.error("cause",e.cause);})'
  1. Common Mainland-China-specific gotcha: IPv6 routing
    If the cause looks like IPv6 / network unreachable, try forcing IPv4 first:
NODE_OPTIONS="--dns-result-order=ipv4first" openclaw configure

If you paste (a) openclaw --version, (b) your env | grep -i proxy, and (c) the node -e ... error + cause, I can tell you exactly which bucket it’s in (proxy not picked up vs DNS vs TLS cert vs IPv6).

#

That error is super specific now:

cause Error: getaddrinfo ENOTFOUND sub2.547823.cfd

So this is not an API-key / request-format problem. It’s DNS: your Mac (Node) cannot resolve that hostname.

Why SillyTavern can work anyway:

  • SillyTavern/Electron/Chromium often ends up using different DNS behavior (DoH / proxy DNS / system stack),
  • while the OpenClaw configure verification is a plain Node fetch() and (today) it effectively needs your local DNS to resolve the upstream host.

Fix options (pick one)

Option A — Fix DNS so the host resolves locally

In Terminal, check:

dig test.cfd
# 
dig sub2.547823.cfd

If sub2.547823.cfd returns NXDOMAIN/empty, switch your Mac’s DNS to something that can resolve it (common choices: 1.1.1.1, 8.8.8.8, 9.9.9.9) or configure your proxy client to provide DNS for the system.

(Your proxy env vars won’t help if DNS itself says “doesn’t exist”.)

Option B — Use a base URL that doesn’t rely on that unresolvable CNAME

If your provider can give you a different domain (or a “CN domain”) that resolves under your DNS, use that instead of test.cfd.

Option C — Bypass the wizard verification (manual config)

If you know the endpoint works and just want OpenClaw to use it, you can add it directly to ~/.openclaw/openclaw.json (this skips the wizard’s verification step).

From the config reference: https://docs.openclaw.ai/gateway/configuration-reference#custom-providers-and-base-urls

Example (JSON5):

# 
{
  agents: {
    defaults: {
      model: { primary: "custom-proxy/gpt-5.4" },
    },
  },
  models: {
    providers: {
      "custom-proxy": {
        baseUrl: "https://test.cfd/v1",
        apiKey: "${CUSTOM_API_KEY}",
        api: "openai-completions",
        models: [{ id: "gpt-5.4", name: "gpt-5.4" }],
      },
    },
# 
  },
}

And put secrets/proxy env in ~/.openclaw/.env (so the Gateway service also gets them):

CUSTOM_API_KEY=sk-...
HTTPS_PROXY=http://127.0.0.1:17890
HTTP_PROXY=http://127.0.0.1:17890

Then restart the gateway and test via the dashboard.

If you paste the output of the two dig commands, I can tell you immediately whether it’s a DNS server issue vs the domain genuinely not resolving from your network.

#

That dig output explains everything:

  • You’re querying 223.6.6.6 (AliDNS)
  • It returns SERVFAIL
  • And WARNING: recursion requested but not available (i.e. it’s not acting like a normal recursive resolver for you right now)

So your Mac’s DNS resolver simply can’t resolve sub2.547823.cfd → Node gets ENOTFOUND → OpenClaw “fetch failed”.

1) Quick confirmation: does any public resolver work?

Try these three (paste results):

dig sub2.547823.cfd @1.1.1.1
dig sub2.547823.cfd @8.8.8.8
dig sub2.547823.cfd @9.9.9.9
#
  • If one of them returns an IP, then your current DNS (223.6.6.6) / network DNS path is the problem → switch your macOS DNS to that working resolver (or configure your proxy app to provide DNS).
  • If all of them fail from your network, then that domain/TLD is being blocked/poisoned → you must use proxy DNS / DoH (or change to a different base domain that resolves).

2) Important OpenClaw detail (why proxy env vars didn’t save you here)

Right now the openclaw configure custom-provider verification uses plain Node fetch + system DNS. It does not reliably “tunnel DNS via your proxy env vars”.

So in Mainland China setups, the usual ways to make the wizard succeed are:

  • Enable your proxy client’s TUN / enhanced mode (so all apps + DNS go through it), or
  • Bypass the wizard verification and manually add the provider in ~/.openclaw/openclaw.json (and put HTTPS_PROXY/HTTP_PROXY + API key in ~/.openclaw/.env for the Gateway runtime).

If you paste the three dig ... @... results, I’ll tell you which path is best for your network.

#

Yep — that result basically proves DNS interception / DNS poisoning on your network.

dig ... @8.8.8.8 returning SERVFAIL + recursion requested but not available with 0ms is not normal Google DNS behavior. It usually means your ISP/router is hijacking UDP/53 and answering locally (so you can’t reach real 8.8.8.8 DNS at all).

What this means for OpenClaw

openclaw configure → custom provider verification does a Node fetch() → Node uses system DNS → DNS can’t resolve sub2.547823.cfd → ENOTFOUND → fetch failed.

Your proxy helps SillyTavern because it’s likely doing proxy DNS / DoH, but Node (during the wizard) is still stuck with the broken DNS path.

Two practical ways forward

Option 1 (recommended): bypass the wizard verification and configure manually

This avoids the DNS step entirely.

  1. Put your proxy + key into ~/.openclaw/.env (so the Gateway runtime can use the proxy):
# 
  },
  models: {
    providers: {
      "custom-proxy": {
        baseUrl: "https://test.cfd/v1",
        apiKey: "${CUSTOM_API_KEY}",
        api: "openai-completions",
        models: [{ id: "gpt-5.4", name: "gpt-5.4" }],
      },
    },
  },
}
  1. Restart and test:
# 
openclaw gateway restart
openclaw status

Option 2: fix DNS properly (so Node can resolve that domain)

You need DNS over HTTPS / proxy DNS / TUN mode so DNS queries aren’t hijacked.

In your proxy app, look for settings like:

  • TUN mode
  • Enhanced mode
  • Proxy DNS
  • DNS over HTTPS (DoH)

Once that’s enabled, dig sub2.547823.cfd should start returning an IP.