Add an optional fallback signal
You can add a wrapper that tries SearXNG first, then falls back to Brave:
search-with-fallback.sh
#!/bin/bash
# Search with fallback: SearXNG → Brave
QUERY="$1"
LIMIT=${2:-5}
# Try SearXNG first
RESULT=$(~/.openclaw/skills/searxng/search.sh "$QUERY" "$LIMIT" 2>/dev/null)
if [ -n "$RESULT" ] && [ "$RESULT" != "No results or SearXNG unavailable" ]; then
echo "# Results via SearXNG (private)"
echo "$RESULT"
else
echo "# SearXNG unavailable, falling back to Brave..."
# Let OpenClaw's built-in web_search handle it
echo "FALLBACK_TO_BRAVE: $QUERY"
fiUnderstand the request path
The agent calls your script, which queries the local SearXNG service. SearXNG sends the query to configured engines and aggregates their results. Those engines receive the query and your server’s IP.
The fallback wrapper prints a FALLBACK_TO_BRAVE marker. It does not call Brave itself. Your agent must recognize the marker and invoke a configured backup search tool.
Know what you control
- Control: choose engines, logging, and deployment settings.
- Local integration: agents use a single endpoint you operate.
- Clear limits: upstream engines still receive queries and can fail or rate-limit requests.
Troubleshooting
"Connection refused"
SearXNG isn't running. Check: docker ps | grep searxng
"format=json not supported"
Add formats: [html, json] to settings.yml and restart
No results for some queries
Some engines rate-limit. SearXNG rotates through engines automatically. Try again or add more engines in settings.
Extend the setup
- Add more engines — Configure DuckDuckGo, Qwant, Mojeek in settings.yml
- Enable caching — Reduce repeated queries with Redis
- Deploy on VPS — Run SearXNG on a VPS for multi-agent access
It’s working if
Unavailable search produces an explicit error or fallback signal. If you configure a backup tool, verify the agent actually calls it instead of treating the marker as a result.