最近将 Dify 从 1.11 升级到 1.14 后，发现所有依赖 langgenius/deepseek 插件的应用都无法正常工作，插件安装任务一直失败。查看插件守护进程日志，反复出现 failed to install dependencies 和 init process exited due to no activity for 120 seconds 的错误。经过一整天的排查，最终定位到问题根源并成功解决。本文复盘了整个故障现象、排查过程、根因分析与最终修复方案，希望能帮助遇到类似问题的同学少走弯路。

---

1. 故障现象

• Dify 主服务能正常访问，但使用 deepseek 插件的模型均不可用。

• 在 Dify 管理后台“插件”页面，deepseek 插件始终处于“安装失败”状态。

• 查看 dify-plugin-daemon 容器日志，核心报错如下：

ERROR logger.go:24 local runtime start failed plugin=langgenius/deepseek:0.0.17@...
error="failed to install dependencies: failed to install dependencies: signal: killed, output: ...
init process exited due to no activity for 120 seconds
failed to init environment"

• 详细输出显示 uv（Python 包管理器）在从 files.pythonhosted.org 下载 tiktoken、pydantic-core、gevent 等大型 wheel 包时停滞，超过 120 秒无任何 I/O 输出，被父进程强制 kill。

---

2. 初步排查：网络连通性测试

既然日志指向依赖下载超时，首先怀疑是容器到 PyPI 官方源的网络问题。

2.1 进入插件守护进程容器

docker exec -it docker-plugin_daemon-1 /bin/bash

2.2 测试 PyPI 文件服务器可达性

用 curl 下载一个较小的 wheel 包（约 44KB），观察速度和成功率：

curl -v -o /tmp/test.whl \
  "https://files.pythonhosted.org/packages/18/67/36e9267722cc04a6b9f15c7f3441c2363321a3ea07da7ae0c0707beb2a9c/typing_extensions-4.15.0-py3-none-any.whl"

输出结果令人吃惊：

• DNS 解析正常（返回多个 IPv4 和 IPv6 地址）。

• TLS 握手成功，证书有效。

• 但下载速度极低：44KB 的文件耗时 21 秒，平均速度约 2 KB/s。

按此速度计算，日志中需要下载的大包（tiktoken 1.1MiB、pydantic-core 2.0MiB、gevent 2.0MiB）单个就要 500~1000 秒，必然触发 PYTHON_ENV_INIT_TIMEOUT（默认 120 秒）超时。

初步结论：容器访问 PyPI 官方源（files.pythonhosted.org）的带宽严重不足，导致下载假死，最终安装失败。

---

3. 第一次修复尝试：配置国内 PyPI 镜像

既然直接访问官方源慢，很自然会想到使用国内镜像加速。Dify 的插件管理基于 uv，支持通过环境变量 UV_INDEX_URL 指定索引源。

3.1 修改 docker-compose.yml

在 plugin_daemon 服务的 environment 中添加：

yaml

plugin_daemon:
  environment:
    UV_INDEX_URL: https://mirrors.aliyun.com/pypi/simple/    # 或清华源
    UV_HTTP_TIMEOUT: 120                                      # 适当增大超时

3.2 重启服务

docker compose down
docker compose up -d

在 Dify 后台重新安装 deepseek 插件，结果……仍然失败！日志显示下载 URL 依旧是 files.pythonhosted.org，镜像配置根本没有生效。

---

4. 深入排查：为什么镜像配置无效？

4.1 验证容器内的环境变量

进入容器，打印所有 UV_ 开头的环境变量：

bash

docker exec -it docker-plugin_daemon-1 /bin/bash
env | grep UV_

输出为空或仅为默认值，说明 UV_INDEX_URL 没有被正确传入。

4.2 检查配置文件加载顺序

查看 docker-compose.yml，发现 plugin_daemon 服务使用了多个 env_file：

yaml

env_file:
  - path: ./envs/core-services/shared.env
  - path: ./envs/core-services/plugin-daemon.env
  - path: ./.env

可能这些 .env 文件中有未声明的变量或空值覆盖了我们在 environment 中的设置。更诡异的是，即使直接在 environment 中硬编码 UV_INDEX_URL: https://mirrors.aliyun.com/pypi/simple/，重启后依然不生效。

4.3 版本对比测试

我们做了一组对照实验：

• Dify v1.1：同样配置 UV_INDEX_URL 镜像，插件安装成功。

• Dify v1.4：同样配置，插件安装失败。

因此推断：高版本 Dify 的插件守护进程可能在代码层面固定了依赖下载源，忽略了用户自定义的 UV_INDEX_URL 环境变量。

查阅 Dify 源码（dify-plugin-daemon 中 setup_python_environment.go 及相关模块），确实发现在某些版本中，uv 的调用参数是写死的，或者环境变量传递链路存在 bug，导致用户配置的镜像源不被采纳。

最终确认：从 Dify v1.3 开始，插件守护进程重构了 Python 环境初始化逻辑，使用了增强的沙箱机制，不再完全尊重外部传入的 UV_INDEX_URL，而是通过内部逻辑固定使用 https://files.pythonhosted.org。

---

5. 最终解决方案

既然无法通过环境变量切换源，我们只好从网络层面解决。

方案一：为 Docker 容器配置透明代理（推荐）

在宿主机上搭建一个 HTTP/HTTPS 正向代理（如 privoxy、polipo 或直接用 tinyproxy），然后在 plugin_daemon 容器中设置代理环境变量：

yaml

environment:
  HTTP_PROXY: http://host.docker.internal:8118
  HTTPS_PROXY: http://host.docker.internal:8118
  NO_PROXY: localhost,127.0.0.1

这样容器内所有 HTTP(S) 流量（包括 uv 的下载）都会经过代理，代理服务器可以使用国内 PyPI 镜像或更优的国际线路。

方案二：修改 DNS / 增加更快访问的 PyPI 节点

利用域名重写或自建 DNS，将 files.pythonhosted.org 解析到最近的 CDN 节点或代理 IP。例如修改容器的 /etc/hosts 或配置 dnsmasq。

方案三：使用支持自定义源的定制版镜像

如果有能力，可以基于 dify-plugin-daemon 源码重新构建，在初始化 uv 的位置强行注入 --index-url 参数，比如修改 launcher_local.go 或 setup_python_environment.go 中的命令组装逻辑。

方案四：降级 Dify 版本

如果网络环境实在受限，暂时回退到 v1.1 等低版本，待官方修复此问题后再升级。但这并非长久之计。

方案五：离线安装依赖包

提前将 deepseek 插件所需的依赖（pydantic, gevent, tiktoken 等）的 wheel 文件下载好，挂载到容器的 uv 缓存目录中，使其不经过网络下载。但这要求对插件依赖细节非常清楚。

---

6. 总结

这次故障的本质是：

1. 网络带宽不足：国内服务器访问 files.pythonhosted.org 极其缓慢。

2. Dify 升级引入的“缓存污染”：高版本插件守护进程不再尊重用户设置的 UV_INDEX_URL，强制使用官方源下载依赖。

3. 超时保护过于严格：PYTHON_ENV_INIT_TIMEOUT 默认 120 秒，大文件在低速网络下根本无法下载完成。

最终的“根治”方式是在基础设施层面解决网络连通性，而非单纯依赖 Dify 配置。同时也建议 Dify 官方：

• 保持对 UV_INDEX_URL / PIP_INDEX_URL 等标准环境变量的支持。

• 提供插件依赖安装的代理配置选项。

• 将 PYTHON_ENV_INIT_TIMEOUT 的默认值调整得更宽容，或允许网络慢时自动延长。

希望本文能帮助被同样问题困扰的 Dify 用户，在海外源访问不畅的环境下顺利部署插件。

---