issue: fetch_url loops indefinitely with no log output

快速结论：在 Open WebUI 中大量并发调用 fetch_url（例如让模型连续抓取十个以上网页）时，部分或全部抓取会无限期挂起、控制台没有任何输出。优先排查 DNS 解析或连接阶段是否缺少超时，并通过提高日志级别定位卡在哪一步。

适用环境：Docker 部署；Debian 12.5；Open WebUI dev 分支（commit 45f680f2bb11）。Issue 未确认 Ollama 版本、浏览器、CUDA、显卡或具体 Python 依赖版本。

最快修复方案：暂无确认的一步修复方案。Issue 中唯一被验证有诊断价值的方法是设置 GLOBAL_LOG_LEVEL=DEBUG 重新复现，日志会显示卡在 urllib3.connectionpool 建立连接或 SafeWebBaseLoader 加载阶段。

注意事项：该问题并非必现，有时正常、有时部分挂起、有时全部挂起，因此单次测试未必能复现。Issue 猜测与“域名解析或连接尝试时未处理的超时”有关，但未给出最终修复或确认根因，相关的 Playwright、超时类改动仍需在对应 Issue 中跟进。

问题场景

用户在 Open WebUI 中使用模型发起联网任务，先调用 web_search（DuckDuckGo 搜索引擎聚合）完成若干次搜索，再让模型对搜索结果逐页调用 fetch_url 抓取正文。使用的测试提示要求“至少抓取十个不同页面以压测后端”。搜索阶段已正常返回（包括 Wikipedia、Google、Yandex、Brave 等，其中 Brave 返回 429），随后十个 fetch_url 调用直接挂起，日志没有任何后续输出。作者强调这不是模型层面的循环调用，而是 fetch_url 工具本身的问题。

报错原文

issue: fetch_url loops indefinitely with no log output

Some fetch_url calls hang indefinitely -- no log output whatsoever.

2026-10-03 13:28:21.263 | INFO     | ddgs.base:search:117 - response: https://grokipedia.com/api/typeahead?query=test&limit=1 200
2026-10-03 13:28:21.544 | INFO     | ddgs.base:search:117 - response: https://en.wikipedia.org/w/api.php?action=opensearch&profile=fuzzy&limit=1&search=test 200
2026-10-03 13:28:21.961 | INFO     | ddgs.base:search:117 - response: https://search.brave.com/search?q=test&source=web 429
...

原因分析

作者在 Issue 中提出的可能原因：fetch_url 在域名解析（domain resolution）或建立连接（connection attempts）阶段存在未处理的超时，导致请求既不返回结果也不抛错，从而无限挂起。Issue 未确认这是否为唯一根因，也未给出修复提交。

自动关联的 Issue 提示还可能存在同一子系统的其他诱因：在远程 Playwright 模式下浏览器与网络都空闲时 fetch_url 停留在 executing 状态（#29773）；页面媒体资源过多导致 Playwright 加载极慢或看似卡死（#29741）；以及长耗时工具超过代理/请求超时后从客户端看像“卡住”（#16747）。这些属于相关背景，并不能直接证明是本 Issue 的根因。

环境排查

确认 Open WebUI 版本：本 Issue 在 dev（45f680f2bb11）上复现，同时也应确认当前运行镜像的标签或 commit。
确认部署方式为 Docker，并确认容器内出网（DNS、443 端口）正常。
确认使用的网页抓取引擎，例如是否为 WEB_LOADER_ENGINE=SafeWebBaseLoader，或启用了 Playwright。
确认日志级别：默认 INFO 下看不到连接层细节，需要开启 DEBUG。
检查是否存在代理、防火墙或 DNS 解析慢的中间层，因为日志显示阻塞发生在 urllib3 建立 HTTPS 连接前后。

解决步骤

按作者验证有效的方式，在 Docker 环境中设置 GLOBAL_LOG_LEVEL=DEBUG 后重启 Open WebUI 容器。
用同样的测试提示复现：先让模型执行多次 web_search，再连续调用 fetch_url 抓取十个以上页面。
观察日志停在什么位置。作者的 DEBUG 日志显示每个 URL 都经历 Starting new HTTPS connection → _make_request → get_web_loader: Using WEB_LOADER_ENGINE SafeWebBaseLoader for 1 URLs 的循环；若某个 URL 在 Starting new HTTPS connection 之后再无输出，即说明卡在解析或连接阶段。
注意日志中 403、429 等状态：部分站点（Wikipedia、Collins Dictionary、Brave）返回 403/429，仍会继续重试或再次加载，可作为判断是否卡死与站点反爬共同作用的参考。
如果卡死集中在 Playwright 相关路径，请对照关联 Issue #29773、#29741 的排查方向（远程 Playwright 空闲挂起、媒体资源过多拖慢加载）。
若确认只是个别域名或个别反爬站点导致，可临时降低单次抓取页面数量或调整模型提示，避免一次触发大量抓取。

验证方法

复现同一批抓取任务，观察是否每个 fetch_url 最终都能给出明确的成功结果、失败返回或超时，而不是长时间停在 fetch_url executing... 且日志无新增输出。若在 GLOBAL_LOG_LEVEL=DEBUG 下所有请求都能走完 urllib3 连接与 get_web_loader 流程，则说明挂起现象不再出现。