fetch faild

[stray gazelle]

Hi, i started to use open claw today but i'm often getting fetch failed with duck duck go. Could someone help me to figure it out ?

[modest temple]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[ionic pendant]

Victorrr, first thing: what does openclaw --version print?

For DuckDuckGo specifically: it’s the key-free fallback, but it’s unofficial/HTML-based, so fetch failed can happen if DDG blocks the request, serves a bot challenge, or changes markup. The docs call this out as experimental.

Two useful checks:

openclaw --version
openclaw configure --section web

In the web config wizard, try switching from duckduckgo to an API-backed provider like Brave/Perplexity/Tavily/etc. if you want reliability. DuckDuckGo is fine as a zero-key fallback, but I wouldn’t use it as the stable option.

Docs:
https://docs.openclaw.ai/tools/duckduckgo-search
https://docs.openclaw.ai/tools/web

[stray gazelle]

OpenClaw 2026.5.12 for the version.
So there is no free and stable provider for web searching ?

[ionic pendant]

Short version: not really in the “zero account, zero setup, always reliable” sense.

Best options:

• Brave Search: probably the best practical choice. It’s API-backed and has a free tier, so it’s much more stable than DuckDuckGo HTML scraping.
• SearXNG: free and can be stable if you self-host or use a reliable instance, but it’s more setup/ops.
• Ollama Web Search: key-free, but requires ollama signin and a reachable Ollama setup.
• DuckDuckGo: free/no key, but experimental because OpenClaw has to scrape DDG’s HTML pages, so blocks/challenges are expected sometimes.

I’d try Brave first via:

openclaw configure --section web

Docs:
https://docs.openclaw.ai/tools/web

[ionic pendant]

https://docs.openclaw.ai/tools/brave-search
https://docs.openclaw.ai/tools/searxng-search

[stray gazelle]

Hmm, the problem doesn't seem to come from the web search provider itself, but js function itself "from web_search failed: fetch failed"

[ionic pendant]

Yep, that wording usually means the lower-level Node fetch() transport failed before OpenClaw got a normal HTTP response. So you’re right: it may be network/TLS/proxy/DNS rather than “DuckDuckGo returned bad results.”

For DuckDuckGo the target is roughly https://html.duckduckgo.com/html?q=.... From the same machine running the gateway, try:

openclaw doctor --deep
curl -I 'https://html.duckduckgo.com/html?q=test'
node -e "fetch('https://html.duckduckgo.com/html?q=test').then(r=>console.log(r.status)).catch(e=>{console.error(e); console.error('cause:', e.cause)})"

If curl works but the node -e fetch fails, that points at Node’s TLS/proxy/runtime environment. Common causes are missing CA certs, proxy env not reaching the gateway service, DNS issues, or flaky IPv6 routing.

One known docs note: nvm-installed Node can hit fetch failed from missing CA roots; the fix is usually starting OpenClaw with:

export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/ca-certificates.crt

[ionic pendant]

openclaw gateway run

Docs: https://docs.openclaw.ai/help/environment#nvm-users-web_fetch-tls-failures

If you can paste the gateway log line that includes the cause: after fetch failed, that’ll narrow it down fast.

[stray gazelle]

curl: (35) Recv failure: Connection reset by peer
TypeError: fetch failed
at Object.processResponse (node:internal/deps/undici/undici:12793:20)
at node:internal/deps/undici/undici:13181:23
at process.processTicksAndRejections (node:internal/process/task_queues:104:5)
at node:internal/deps/undici/undici:17409:7
at process.processTicksAndRejections (node:internal/process/task_queues:104:5) {
[cause]: Error: read ECONNRESET
at TLSWrap.onStreamRead (node:internal/stream_base_commons:216:20) {
errno: -54,
code: 'ECONNRESET',
syscall: 'read'
}
}
cause: Error: read ECONNRESET
at TLSWrap.onStreamRead (node:internal/stream_base_commons:216:20) {
errno: -54,
code: 'ECONNRESET',
syscall: 'read'
}

[ionic pendant]

That confirms it: this is below OpenClaw. Both curl and Node are getting ECONNRESET, so the TLS connection is being closed by the remote side or something in between your machine and DuckDuckGo.

Most likely causes:

• DuckDuckGo is blocking/resetting traffic from your IP/network/VPS/provider.
• A proxy/VPN/firewall/ISP middlebox is interfering.
• Less likely: IPv6 routing weirdness.

Quick tests:

curl -4 -I 'https://html.duckduckgo.com/html?q=test'
curl -6 -I 'https://html.duckduckgo.com/html?q=test'
curl -I 'https://duckduckgo.com/'

If -4 works and normal/-6 fails, it’s IPv6 routing. If all DDG requests reset, DuckDuckGo or the network path is rejecting you.

[ionic pendant]

Practical fix: switch web search to an API-backed provider, usually Brave if you want a free tier:

openclaw configure --section web

This isn’t a 2026.5.12-specific OpenClaw bug from that output; OpenClaw is just surfacing the transport reset.

[stray gazelle]

Got 1 400 error code and 1 200 code

[ionic pendant]

Which command got the 400 vs 200?

Small correction: curl -I uses HEAD, and some endpoints return 400 for HEAD even when GET works, so the 400 alone may not matter. The important part is whether you still see ECONNRESET.

Try this GET test instead:

curl -4 -L -A 'Mozilla/5.0' 'https://html.duckduckgo.com/html?q=test' -o /tmp/ddg.html -w '%{http_code}
'
curl -6 -L -A 'Mozilla/5.0' 'https://html.duckduckgo.com/html?q=test' -o /tmp/ddg6.html -w '%{http_code}
'

If -4 gives 200 and -6 fails/resets, it’s IPv6. If both give 200 but OpenClaw still fails, then we look at the gateway process environment next.

[stray gazelle]

curl -4 -L -A 'Mozilla/5.0' 'https://html.duckduckgo.com/html?q=test' -o /tmp/ddg.html -w '%{http_code}
'
curl -6 -L -A 'Mozilla/5.0' 'https://html.duckduckgo.com/html?q=test' -o /tmp/ddg6.html -w '%{http_code}
'
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 14154 0 14154 0 0 99500 0 --:--:-- --:--:-- --:--:-- 99676
202
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 14160 0 14160 0 0 97971 0 --:--:-- --:--:-- --:--:-- 98333
202
Seem to be ok isn't it ?

[ionic pendant]

Mostly yes: 202 is still an OK-class HTTP status, and both IPv4/IPv6 downloaded a body, so the basic network path now works from your shell.

The remaining difference is probably one of these:

• intermittent DDG resets
• Node/OpenClaw process environment differs from your shell
• the gateway is still using an older failed state/session/log context

Run the Node test again with the same user-agent:

node -e "fetch('https://html.duckduckgo.com/html?q=test',{headers:{'User-Agent':'Mozilla/5.0'}}).then(async r=>console.log(r.status, (await r.text()).length)).catch(e=>{console.error(e); console.error('cause:', e.cause)})"

If that returns something like 202 141xx, restart the gateway and retry OpenClaw web search. If OpenClaw still fails after that, check whether the gateway is launched as a service with different env/proxy/Node than your terminal.

[stray gazelle]

It didn't return anything

[ionic pendant]

If it printed nothing, it may be hanging rather than failing. Stop it with Ctrl+C, then try a timeout-wrapped version:

node --version
node -e "const c=new AbortController(); setTimeout(()=>c.abort(),10000); fetch('https://html.duckduckgo.com/html?q=test',{signal:c.signal,headers:{'User-Agent':'Mozilla/5.0'}}).then(async r=>console.log(r.status,(await r.text()).length)).catch(e=>{console.error(e.name, e.message); console.error('cause:', e.cause)})"

Also try the same against a non-DDG HTTPS site:

node -e "const c=new AbortController(); setTimeout(()=>c.abort(),10000); fetch('https://example.com',{signal:c.signal}).then(r=>console.log(r.status)).catch(e=>{console.error(e.name, e.message); console.error('cause:', e.cause)})"

If curl works but Node hangs/fails, this is specifically the Node/undici networking path, which is the same path OpenClaw uses for web_search. Then I’d check Node version, proxy env, and whether restarting OpenClaw with a fresh terminal environment changes it.

[stray gazelle]

I only got 200 return code

[ionic pendant]

That sounds like the example.com test returned 200, which means Node HTTPS basically works.

The key question is what the DuckDuckGo Node test returned. It should print two values, like:

202 14154

If DDG still prints nothing/hangs but example.com prints 200, then Node works generally but stalls on DDG specifically. At that point I’d stop fighting DuckDuckGo and switch providers, because OpenClaw’s DDG integration depends on that exact Node fetch path.

If the DDG Node test also returns 202 14xxx, restart the gateway and retry:

openclaw gateway restart

If it still fails after the restart, grab the fresh gateway log line around from web_search failed so we can see whether the cause changed.

[stray gazelle]

DDG returned 200 to, maybe it was just bad luck. Is there some incovenient to use searXNG as my search engine ?

[ionic pendant]

Yeah, SearXNG is a reasonable choice. The main inconveniences are operational, not OpenClaw-specific:

• You need a SearXNG instance. Self-hosting is best; random public instances can be slow, rate-limited, disabled, or change behavior.
• It depends on upstream engines, so Google/Bing/DDG can still throttle or block the SearXNG instance if it sends lots of traffic.
• You must enable the JSON API on the SearXNG side: search.formats needs json.
• Result quality can vary depending on which engines/categories your SearXNG instance enables.
• If the instance is public, OpenClaw requires https://; http:// is only accepted for loopback/private-network hosts.

Basic local setup:

docker run -d -p 8888:8080 searxng/searxng
openclaw configure --section web
# select searxng

Or set: