在Dify中访问Gemini等模型代理设置指南

原创

已于 2025-03-09 23:33:45 修改 · 9.1k 阅读

27 ·

CC 4.0 BY-SA版权

文章标签：

#ai #docker

于 2025-03-09 22:29:53 首次发布

该文章已生成可运行项目，

问题背景

Google Gemini模型可纯免费使用，且性能也相当不错，一般个人使用或研究足够。但在在国内访问，需设置代理。在Docker部署Dify时，虽然按官方文档介绍设置代理环境变量，但实测发现并不生效。我们通过研究试验解决了这个问题，并探索了可配置化的按需走代理的方法。

说明：本文主要内容不是介绍dify本地部署的内容，可参见Dify官方部署指南。如看官有兴趣，小子可以写一个专门文章。

根因分析

先说结论

Dify中访问Gemini模型使用了Google的generativeai Python SDK，底层通过gRPC进行通信，它要求代理相关的环境变量必须使用小写形式，大写形式不生效。

详细分析过程

Dify官方文档说明
Dify的官方文档中提到可以通过设置环境变量（在.env.example和.env文件中）来配置代理，但没有特别说明大小写问题。文档中通常使用的是大写形式的环境变量，如HTTP_PROXY和HTTPS_PROXY。

 HTTP_PROXY
 HTTP 代理地址，用于解决国内无法访问 OpenAI、HuggingFace 的问题。注意，若代理部署在宿主机 (例如 http://127.0.0.1:7890)，此处代理地址应当和接入本地模型时一样，使用 Docker 容器内部的宿主机地址（例如 http://192.168.1.100:7890 或 http://172.17.0.1:7890）。

 HTTPS_PROXY
 HTTPS 代理地址，用于解决国内无法访问 OpenAI、HuggingFace 的问题。同上。

Gemini模型插件实现
Dify的Gemini模型插件使用了Google的generativeai Python SDK。

底层通信机制
Google的generativeai SDK底层使用gRPC进行通信。根据gRPC官方文档，它支持以下几个代理相关的环境变量：

grpc_proxy, https_proxy, http_proxy The URI of the proxy to use for HTTP CONNECT support. These variables are checked in order, and the first one that has a value is used.
no_grpc_proxy, no_proxy A comma separated list of hostnames to connect to without using a proxy even if a proxy is set. These variables are checked in order, and the first one that has a value is used.

问题确认
对比Dify文档中说明的变量是大写形式（如HTTP_PROXY），而gRPC文档中是小写形式（如http_proxy）。通过实验确认，只有小写形式的环境变量对Gemini模型生效。
版本差异
对于Dify 0.15.x版本（尚未引入插件概念的版本），Gemini模型的源代码位于主仓库中，但代理环境变量的要求相同。

解决方案

同时设置大小写环境变量

最直接的解决方法是同时设置大小写两套环境变量，确保各种组件都能正确识别代理设置。

如果在Docker容器中设置了全局代理环境变量，所有HTTP请求都会走代理，这可能会导致不必要的性能开销。

虽然可能通过no_proxy（NO_PROXY）配置，但黑名单域名多起来就比较麻烦。
也可以让http proxy server那边配置，也不是所有的proxy server都能进行配置。

我们看到，dify本身是有一个ssrf_proxy的容器服务，是使用squid支持的。至于为何dify添加了这个组件，一句话：为了安全，参见官方介绍。
我们借用这个服务，更优雅地实现按需代理。因为squid是一个非常经典的代理服务器，它支持代理链（proxy chain）和域名白名单配置。

实现步骤

确保已有可用的HTTP代理服务器（相信看官都会有，如果没有小子也提供不了）

在dify/docker/.env中配置环境变量
变量名没有使用官方指定，因为原来处理逻辑比较绕，可以简化，另外域名变量是为了使用白名单，而不是黑名单。为何分开主机和端口配置？这个是为了适配squid(ssrf_proxy)，后续说明。


# public http proxy server used in ssrf_proxy service(squid), change for your ip/port
HTTP_PROXY_SERVER_HOST = 192.168.0.1
HTTP_PROXY_SERVER_PORT = 3128
# domains through public http proxy, space separate(if include subdomains, domain wildcard must be begin with comma)
DOMAINS_BY_PROXY = ".googleapis.com .google.com google.dev .openai.com .anthropic.com .github.com .githubusercontent.com .githubassets.com .youtube.com .duckduckgo.com .huggingface.co .dify.ai"

修改dify/docker/ssrf_proxy/squid.conf.template
找到以下行（40多行的位置）：

# cache_dir ufs /var/spool/squid 100 16 256
# upstream proxy, set to your own upstream proxy IP to avoid SSRF attacks
# cache_peer 172.1.1.1 parent 3128 0 no-query no-digest no-netdb-exchange default

替换为（必须要替换在原来的这个位置，因为squid有一序列的规则，有兴趣可参见官方文档）：

# 使用squid的机制实现对指定域名及其子域名走上游代理，
cache_peer ${HTTP_PROXY_SERVER_HOST} parent ${HTTP_PROXY_SERVER_PORT} 0 no-query no-digest no-netdb-exchange default
acl external_domains dstdomain ${DOMAINS_BY_PROXY}
never_direct allow external_domains
cache_peer_access ${HTTP_PROXY_SERVER_HOST} allow external_domains
cache_peer_access ${HTTP_PROXY_SERVER_HOST} deny all

修改dify/docker/docker-compose-template.yaml
尽量不直接修改docker-compose.yaml，但也是可行的，看官自己选择。在api、plugin_daemon、sandbox几个服务的"environment:" 节中增加如下配置

environment:
    ...
    # setting http proxy using ssrf_proxy service
    HTTP_PROXY: ${
     
     SANDBOX_HTTP_PROXY:-http://ssrf_proxy:3128}
    HTTPS_PROXY: ${
     
     SANDBOX_HTTPS_PROXY:-http