ChatGPT-Next-Web项目中使用litellm代理时DuckDuckGoLite插件异常问题解析

问题背景

在ChatGPT-Next-Web项目中，当用户通过litellm作为中间层接入多个AI模型服务（如OpenAI和AWS Bedrock）时，发现基础对话功能正常，但DuckDuckGoLite插件会出现调用失败的情况。该问题表现为插件调用时返回500错误，后端日志显示连接超时（UND_ERR_CONNECT_TIMEOUT）。

技术分析

1. 网络架构问题

根本原因在于Docker容器网络配置不当。当litellm服务运行在宿主机（如3005端口），而ChatGPT-Next-Web运行在Docker容器内时，容器内部的127.0.0.1指向的是容器自身而非宿主机。这种网络隔离特性导致容器内应用无法直接访问宿主机的服务。

2. 中间层配置影响

当使用litellm作为中间层时，插件系统的网络请求路径会发生变化：

• 正常情况：插件请求直接通过容器网络出口访问外部API
• 中间层情况：请求需要先经过litellm服务，再由litellm转发

3. DuckDuckGoLite特殊性

该插件需要访问外部搜索引擎API，对网络连通性要求较高。当基础网络配置错误时，会出现连接超时现象，这与普通模型API调用的失败模式不同。

解决方案

1. Docker网络配置修正

推荐以下两种配置方式：

• host模式：启动容器时添加--network=host参数，使容器共享宿主网络栈
• 显式指定宿主机IP：使用宿主机的实际IP（非127.0.0.1）作为BASE_URL

2. 中间层环境检查

确保满足以下条件：

• litellm服务本身可以正常访问外部网络
• 容器到litellm服务的网络连通性正常
• 必要时配置HTTP_PROXY环境变量处理企业网络限制

3. 测试验证步骤

建议按顺序验证：

1. 宿主机直接curl测试litellm服务可用性
2. 容器内测试到litellm的网络连通性
3. 基础对话功能测试
4. 插件功能测试

经验总结

这类问题在混合部署场景中较为常见，关键是要理解：

1. Docker网络隔离机制
2. 中间层服务的请求转发路径
3. 不同功能模块的网络依赖差异

建议在复杂部署场景中建立分层测试策略，先验证基础网络连通性，再逐步测试各功能模块，可以快速定位问题边界。