[BUG]: Proxy Connection Issues: AnythingLLM Fails with HTTP/SOCKS5 Proxies Due to Missing Explicit Proxy Agent Handling

快速结论：该问题通常出现在 AnythingLLM 桌面版通过 HTTP/SOCKS5 代理访问外部 LLM 提供商（如 OpenAI、Gemini）时，应用未显式使用代理 Agent，而是尝试直连目标 IP，最终返回 “Connection error”。优先排查 Node.js 侧是否正确识别并使用了 HTTP_PROXY/HTTPS_PROXY，以及相关请求库是否配置了代理 Agent。

适用环境：AnythingLLM desktop app；Windows 环境；需要 HTTP 或 SOCKS5 代理才能访问外网；涉及外部 LLM 提供商（OpenAI、Gemini）及模型列表拉取。Issue 中未确认具体的 AnythingLLM 版本、Node.js 版本、Python、CUDA 或显卡信息。

最快修复方案：暂无确认的一步修复方案。Issue 中仅验证了独立 Node.js 脚本使用 https-proxy-agent（HTTP 代理）或 socks-proxy-agent（SOCKS5 代理）可以成功连接，但未验证 AnythingLLM 应用内可直接修改配置解决。

注意事项：设置 NODE_TLS_REJECT_UNAUTHORIZED=0 会关闭 TLS 证书校验，存在安全风险；评论中还有用户反馈在 Docker 镜像 mintplexlabs/anythingllm:1.19.0 中设置 NODE_USE_ENV_PROXY、HTTP_PROXY、HTTPS_PROXY 等变量后，下载 embedder 模型等出站 HTTP 请求仍未走代理。该问题后续被指出可能与 #4868 重复，是否已在主程序修复尚无明确结论。

问题场景

用户在 Windows 环境下运行 AnythingLLM 桌面应用，系统必须通过本地代理（例如 V2RayN 监听 127.0.0.1:10808）访问外网。用户在启动 AnythingLLM 前设置了 HTTP_PROXY、HTTPS_PROXY 和 NODE_TLS_REJECT_UNAUTHORIZED=0，然后配置 OpenAI 或 Gemini 等外部 LLM 提供商。结果在拉取可用模型列表时失败，或选择模型后聊天时报 “Connection error”。日志显示应用尝试直连 LLM 提供商的 IP 地址，绕过了代理。

报错原文

[BUG]: Proxy Connection Issues: AnythingLLM Fails with HTTP/SOCKS5 Proxies Due to Missing Explicit Proxy Agent Handling

Connection error

ETIMEDOUT

原因分析

Issue 作者的排查结果表明：在同一 Node.js 环境中，原生 https.request 即使设置了 HTTPS_PROXY，也无法通过 HTTP 或 SOCKS5 代理连接目标地址，会出现 ETIMEDOUT 并尝试直连目标 IP；而改用 https-proxy-agent 或 socks-proxy-agent 后，请求 api.openai.com 可以成功返回 HTTP 200 或 401。

因此可能原因是：AnythingLLM 或其底层 HTTP/HTTPS 客户端（包括可能使用的 openai npm 包）没有显式配置代理 Agent，仅依赖环境变量不足以让请求走代理。该问题在特定 Windows 代理环境中更容易暴露。Issue 中 Gemini 报错有时来自 OpenAI.makeRequest 函数，也说明请求可能由统一的 OpenAI 客户端发起，但未附带代理 Agent。

环境排查

确认 AnythingLLM 是否为桌面应用，以及实际启动时继承的环境变量是否包含 HTTP_PROXY、HTTPS_PROXY。
确认代理地址与协议是否正确：HTTP 代理应使用 http://127.0.0.1:10808，SOCKS5 代理应使用 socks5://127.0.0.1:10808。
确认代理本身可访问外网，例如使用独立 Node.js 脚本配合 https-proxy-agent 或 socks-proxy-agent 请求 https://api.openai.com/v1/models 进行验证。
如果使用 Docker 镜像 mintplexlabs/anythingllm:1.19.0，需确认容器内是否设置了 HTTP_PROXY、HTTPS_PROXY、NO_PROXY、NODE_USE_ENV_PROXY 等变量，并注意评论反馈该方式仍未解决代理未生效的问题。
Issue 未提供 Python、CUDA、PyTorch、显卡或节点版本信息，这些项目无需作为首要排查项。

解决步骤

先按 Issue 中的复现方式，在启动 AnythingLLM 的同一命令行窗口中设置代理环境变量。HTTP 代理示例：set HTTP_PROXY=http://127.0.0.1:10808、set HTTPS_PROXY=http://127.0.0.1:10808、set NODE_TLS_REJECT_UNAUTHORIZED=0。SOCKS5 代理则将地址改为 socks5://127.0.0.1:10808。
从同一命令行启动 AnythingLLM 桌面应用，确保进程继承上述环境变量。
配置一个外部 LLM 提供商并尝试刷新模型列表。如果仍然报 “Connection error”，说明环境变量未被底层请求库正确使用。
可优先尝试用独立 Node.js 脚本验证代理链路：分别使用原生 https.request、https-proxy-agent、socks-proxy-agent 请求 https://api.openai.com/v1/models。若只有后者成功，则问题定位在 AnythingLLM 未显式使用代理 Agent。
在应用侧暂无确认的一步配置修复方案。Issue 中作者建议 AnythingLLM 引入代理 Agent 库，但该建议是否已合并、是否可通过配置项启用，Issue 讨论中未给出验证结果。
如果使用 Docker 部署，可优先尝试在容器环境中补充 HTTP_PROXY、HTTPS_PROXY、NO_PROXY、NODE_USE_ENV_PROXY，但需注意评论中已有用户在 1.19.0 镜像上反馈仍未生效。

验证方法

在 AnythingLLM 中重新拉取外部 LLM 提供商的模型列表，或发起一次聊天请求。如果不再出现 “Connection error”，且能正常返回模型列表或对话结果，说明代理已生效。也可同时观察代理软件的连接日志，确认 AnythingLLM 的请求确实经过代理而非直连目标 IP。若应用内仍失败，但独立 Node.js 脚本使用代理 Agent 成功，则可确认问题仍在 AnythingLLM 的代理处理逻辑侧。