OpenClaw 代理系列(2)：`web_search` 报 `fetch failed` 的排查与修复指南（2026）
适用场景：你已经给 OpenClaw 配了代理，但
web_search/web_fetch仍频繁报fetch failed。
这篇是可直接照做的排查文档，目标是：
- 先恢复可用（止血）
- 再定位根因
- 最后补上长期稳定策略
一、故障特征（先判断是否同类问题）
你如果遇到以下现象，基本可以按本文处理：
web_search偶发或持续fetch failedweb_fetch也不稳定- Telegram/QQ 等通道看起来在线，但联网检索能力异常
- 同机有些请求能通，有些请求不通（表现“玄学”）
二、5 分钟快速止血
先别深挖，先让检索恢复：
- 保留主路径：
web_search - 增加兜底：失败后自动走浏览器搜索
- 对用户输出统一模板：
- 原因
- 已做恢复动作
- 是否需要人工介入
这样可以避免用户直接看到 fetch failed。
三、标准排查路径（按顺序做）
Step 1：确认服务在线与基础状态
openclaw status
openclaw gateway statusStep 2：区分“API不可达”还是“运行时链路问题”
在同机做对照测试：
- Python
requests请求目标 API（如 Brave） - OpenClaw
web_search请求同目标
如果 Python 可通但 web_search 失败，优先怀疑：
Node fetch/undici + 代理链路。
Step 3：检查 systemd 服务代理环境
查看 gateway service 与 drop-in：
systemctl --user cat openclaw-gateway.service确认至少存在：
HTTP_PROXYHTTPS_PROXYALL_PROXYNO_PROXY
Step 4：关键修复项（高概率根因）
在 drop-in 增加：
Environment="NODE_USE_ENV_PROXY=1"完整示例（~/.config/systemd/user/openclaw-gateway.service.d/proxy.conf）：
[Service]
Environment="HTTP_PROXY=http://192.168.136.1:8016"
Environment="HTTPS_PROXY=http://192.168.136.1:8016"
Environment="ALL_PROXY=http://192.168.136.1:8016"
Environment="NO_PROXY=127.0.0.1,localhost,::1"
Environment="NODE_USE_ENV_PROXY=1"重载并重启：
systemctl --user daemon-reload
systemctl --user restart openclaw-gateway.serviceStep 5：回归验证
openclaw status
# 再实际执行一次 web_search通过标准：
web_search能稳定返回结果- 不再出现连续
fetch failed
四、为什么会这样（根因解释）
该类问题常见根因不是 API Key，也不是 DNS，而是：
如果你想进一步理解 OpenClaw 最近为什么持续在补 Brave 搜索链路、代理兼容和证据型检索能力，可以继续看： OpenClaw 2026.3.8 值得关注什么：Backup CLI 与 Brave LLM Context 两个实用变化
OpenClaw 的联网工具走 Node
fetch（undici），在某些运行方式下仅设置代理环境变量还不够，需要显式启用NODE_USE_ENV_PROXY=1，否则会出现超时/重置并表现为fetch failed。
五、长期稳态建议（避免复发）
- 工具兜底：
web_search失败自动降级浏览器搜索 - 错误规范：禁止直接返回裸错误
- 健康巡检：每天检查一次 gateway 状态与最近错误
- 变更留痕：所有 proxy/systemd 改动写入变更日志
六、FAQ
Q1：我已经配置了 HTTP_PROXY，为什么还是失败？
A：先检查是否启用了 NODE_USE_ENV_PROXY=1，并确认重载重启已生效。
Q2：为什么 Telegram 在线但搜索失败？
A：消息通道在线 ≠ 联网检索链路健康。两条链路要分别验证。
Q3：修复后还偶发失败怎么办？
A：先开 fallback（browser），再做重试+退避策略，不要把瞬时故障直接暴露给用户。