1. 离线环境下的Dify与Ollama：为什么你需要这份指南

最近有好几个做企业内部AI应用的朋友跟我吐槽，说他们想把Dify和Ollama这套组合拳搬到内网环境里，结果被网络问题卡得死死的。不是模型下不动，就是依赖装不上，折腾好几天都跑不起来。这场景我太熟了，我自己在给一些对数据安全要求极高的金融和制造业客户做私有化部署时，也踩过不少坑。所以今天，我想跟你详细聊聊，怎么在完全离线的服务器上，把Dify和Ollama这对黄金搭档给稳稳地搭起来。

简单来说，Dify是一个低代码的AI应用开发平台，让你能像搭积木一样快速构建AI应用，比如智能客服、内容生成工具。而Ollama则是一个本地大模型运行工具，能让你在自家服务器上轻松跑起像Llama、DeepSeek这样的开源模型。把它们俩集成在一起，你就能在一个无网络的环境里，拥有一个功能强大且完全自主可控的AI大脑。这特别适合那些业务数据敏感、不允许连接外网，但又迫切需要AI能力的企业或研发团队。

你可能觉得，不就是把两个软件装到一台没网的机器上嘛，能有多难？我一开始也这么想，但实际操作起来，你会发现这里头门道不少。从Dify本身的离线部署，到Ollama镜像和模型文件的“搬运”，再到两者之间的插件配置，每一步都可能遇到依赖缺失、版本冲突、路径不对的“暗礁”。这份指南，就是把我趟过的路、踩过的坑，总结成一套清晰、可复现的操作手册，目标是让你一次成功，少走弯路。

2. 战前准备：梳理你的离线部署清单

在动手敲命令之前，准备工作做得好，能省去后面至少一半的麻烦。离线部署的核心思路，就是“在线准备，离线安装”。你需要一台能联网的机器（比如你自己的开发电脑，或者公司里一台有外网权限的跳板机），和一台最终要运行服务的离线服务器。这两台机器之间，得能通过U盘、移动硬盘或者内部文件服务器来传输数据。

首先，你得明确要部署的版本。我强烈建议你固定版本号，别直接用latest这样的标签，不然今天在线机拉取的镜像，明天可能就和离线环境的其他组件不兼容了。对于Dify，你可以去它的GitHub Release页面，找到稳定版的Docker镜像标签和源码包。对于Ollama，同样去其GitHub Release页面，确定你要用的Docker镜像版本（比如ollama/ollama:0.5.2）以及对应的Linux安装包。

接下来，在联网机器上，你需要准备好以下几样“弹药”：

1. Dify的Docker镜像：通过docker pull拉取。
2. Ollama的Docker镜像：同样用docker pull拉取。
3. Ollama的模型文件：这是最占空间的部分。比如你想用deepseek-r1:1.5b这个模型，就需要在联网环境下用Ollama先下载好。
4. Dify的Ollama插件：这是连接Dify和Ollama的桥梁，需要从Dify的插件市场或GitHub仓库下载。
5. 可能的系统依赖包：如果离线服务器是比较老的操作系统（比如CentOS 7），你可能还需要提前下载好新版glibc、libstdc++等依赖的RPM包。

我建议你在联网机器上创建一个清晰的目录结构，比如：

offline_packages/
├── dify/
│   └── dify_image.tar
├── ollama/
│   ├── ollama_image.tar
│   └── models/ (存放从容器内拷贝出的.ollama目录)
├── plugin/
│   └── dify_plugin_ollama.tar.gz
└── system_libs/ (存放glibc等离线安装包)

这样打包传输时一目了然，不容易乱。

3. 分步攻坚：Dify的离线安装与启动

Dify官方提供了多种部署方式，但在离线环境下，Docker Compose是最省心、依赖隔离最好的选择。我们首先在联网机器上操作。

第一步，获取Dify的部署文件。 在联网机器上，克隆Dify的仓库（或直接下载稳定版的ZIP包）：

git clone https://github.com/langgenius/dify.git --branch stable
cd dify/docker

关键在这里：我们需要把docker-compose.yaml和.env配置文件准备好，尤其是.env文件，它包含了数据库密码、密钥等重要配置。你可以基于.env.example生成一个，并务必记住你设置的密码。

第二步，拉取镜像并导出。 在dify/docker目录下，直接运行docker-compose pull，它会根据docker-compose.yaml文件拉取所有需要的镜像（包括Dify API、Web前端、数据库等）。拉取完成后，使用docker save命令将所有镜像打包：

# 查看拉取到的镜像
docker images | grep dify

# 将关键镜像导出为文件，这里以dify-api和dify-web为例，实际请导出compose文件中所有自定义镜像
docker save -o dify-api.tar langgenius/dify-api:stable
docker save -o dify-web.tar langgenius/dify-web:stable
# 别忘了还有PostgreSQL、Redis等基础镜像
docker save -o postgres.tar postgres:16-alpine
docker save -o redis.tar redis:7-alpine-alpine

第三步，转移并导入到离线服务器。 将打包好的tar文件和整个dify/docker目录（包含docker-compose.yaml和.env）拷贝到离线服务器。在离线服务器上，进入该目录，逐个加载镜像：

docker load -i postgres.tar
docker load -i redis.tar
docker load -i dify-api.tar
docker load -i dify-web.tar

第四步，启动Dify服务。 镜像全部加载成功后，在离线服务器的dify/docker目录下，直接运行：

docker-compose up -d

用docker-compose ps查看所有容器是否都正常启动（状态为Up）。如果一切顺利，访问服务器的IP和端口（默认为http://<服务器IP>:3000），你应该就能看到Dify的登录界面了。首次登录需要创建管理员账号，用刚才在.env里配置的账号密码即可。

注意：离线环境下，Dify的Web界面可能会尝试加载一些在线字体或资源，导致控制台有报错，但这通常不影响核心功能。如果前端容器启动失败，可以检查其日志docker logs dify-web，常见问题是内存不足或端口冲突。

4. 核心难点：Ollama的离线部署与模型“搬运”

这是整个流程中最容易出错的环节。我强烈推荐使用Docker方式安装Ollama，它能完美规避宿主机系统库版本老旧的问题。手动安装看似简单，但一旦遇到glibc版本不对，解决起来极其耗时。

4.1 Docker方式（推荐，一劳永逸）

我们在联网机器上操作，目的是准备好镜像和模型“数据包”。

1. 拉取并导出Ollama镜像：

# 拉取指定版本镜像，避免后续更新导致不兼容
docker pull ollama/ollama:0.5.2
# 运行一个临时容器，目的是为了进去下载模型
docker run --rm -d --name ollama_temp -p 11434:11434 ollama/ollama:0.5.2
# 等待容器完全启动
sleep 10

2. 在容器内下载所需模型：

# 执行pull命令下载模型，这里以deepseek-r1:1.5b为例
docker exec ollama_temp ollama pull deepseek-r1:1.5b
# 这个过程取决于模型大小和网速，请耐心等待。完成后可以列出模型确认
docker exec ollama_temp ollama list

看到deepseek-r1:1.5b出现在列表中，说明下载成功。

3. 提取模型文件： Ollama下载的模型默认存放在容器内的/root/.ollama目录。我们需要把它拷贝出来。

# 在联网机器上创建一个目录存放模型文件
mkdir -p /tmp/offline_ollama/models
# 将容器内的模型目录拷贝到宿主机
docker cp ollama_temp:/root/.ollama /tmp/offline_ollama/models/
# 停止并删除临时容器
docker stop ollama_temp

4. 打包镜像和模型：

# 导出Ollama的Docker镜像
docker save -o ollama_0.5.2.tar ollama/ollama:0.5.2
# 打包模型目录，方便传输
tar -czf ollama_models.tar.gz -C /tmp/offline_ollama/models .ollama

现在你得到了两个关键文件：ollama_0.5.2.tar（镜像）和ollama_models.tar.gz（模型数据）。

5. 在离线服务器上部署： 将上述两个文件传输到离线服务器。假设我们规划将模型数据放在/data/ollama目录下。

# 导入镜像
docker load -i ollama_0.5.2.tar
# 创建模型存储目录并解压模型数据
mkdir -p /data/ollama
tar -xzf ollama_models.tar.gz -C /data/ollama/
# 注意解压后，模型文件应该在 /data/ollama/.ollama 下
# 运行Ollama容器，关键是将宿主机模型目录挂载到容器内
docker run -d \
  --name ollama \
  -p 11434:11434 \
  -v /data/ollama/.ollama:/root/.ollama \
  --restart unless-stopped \
  ollama/ollama:0.5.2

这里-v参数至关重要，它把宿主机上我们准备好的模型目录，挂载到容器内Ollama默认的模型路径，这样容器启动时就能直接读到模型，无需再次下载。

6. 验证Ollama服务：

# 查看容器日志，确认无报错
docker logs ollama
# 列出已加载的模型
docker exec ollama ollama list
# 进行一个简单的对话测试
docker exec ollama ollama run deepseek-r1:1.5b "你好，请用一句话介绍你自己。"

如果测试命令能返回模型的回答，恭喜你，最硬的一块骨头已经啃下来了。

4.2 手动安装方式（及其坑点）

原始文章提到了手动安装可能遇到glibc版本问题，我在这里展开说一下，希望你尽量避开这条路。如果你不得不在没有Docker环境的服务器上安装，步骤是：下载Linux安装包，解压运行。但一旦报错提示需要GLIBC_2.27，而你的系统只有GLIBC_2.17，那就麻烦了。

解决这个问题需要在另一台相同系统版本但能联网的机器上，手动下载高版本glibc、libstdc++的源码或RPM包，然后传到离线服务器上编译安装。这个过程极易引发系统库冲突，可能导致其他依赖旧版本库的软件崩溃。所以，除非你非常清楚自己在做什么，并且有完整的系统备份，否则强烈不建议在离线生产环境手动安装Ollama。Docker方案提供了完美的环境隔离，是离线部署的首选。

5. 最后一步：在Dify中配置Ollama模型

Dify和Ollama都跑起来之后，我们需要让它们认识彼此。这需要通过安装Dify的Ollama插件来完成。同样，这个过程也需要离线操作。

1. 在联网机器上准备插件包： Dify的Ollama插件通常以Python包的形式存在。我们需要在联网环境下下载它及其所有依赖。

# 创建一个干净的虚拟环境（可选，但推荐）
python -m venv dify_plugin_env
source dify_plugin_env/bin/activate

# 使用pip download下载插件包及其所有依赖
pip download dify-plugin-tool-ollama -d ./dify_plugin_offline_packages

执行完后，dify_plugin_offline_packages目录下会有一堆.whl或.tar.gz文件，这就是插件和它的离线安装包。

2. 在离线Dify环境中安装插件： 将整个dify_plugin_offline_packages目录传输到离线服务器上，并放置在一个Dify服务能访问到的路径。安装方式取决于你部署Dify的模式。如果你用的是Docker Compose，需要进入Dify的后端API容器内进行安装。

# 进入dify-api容器
docker exec -it dify-api bash

# 在容器内，切换到存放离线包的目录（假设你已挂载到容器内）
cd /path/to/dify_plugin_offline_packages

# 使用pip离线安装
pip install --no-index --find-links=/path/to/dify_plugin_offline_packages dify-plugin-tool-ollama

# 退出容器
exit

安装完成后，需要重启Dify的后端服务以使插件生效。

docker-compose restart dify-api

3. 在Dify界面中配置模型： 重启后，刷新Dify工作台。创建一个新的“助手”应用，当进入配置LLM模型的环节时，你应该能在模型供应商列表里看到“Ollama”的选项。

• 基础配置：在API URL中填写你离线服务器上Ollama的访问地址，通常是http://<离线服务器内网IP>:11434。
• 模型选择：在Model Name下拉框或输入框中，填写你在Ollama中已经加载的模型名称，例如deepseek-r1:1.5b。
• 测试连接：点击测试按钮，如果配置正确，Dify会显示连接成功，并可能展示出该模型支持的上下文长度等信息。

保存配置后，你就可以在这个助手应用里，使用本地的Ollama模型进行对话或构建工作流了。至此，整个离线集成工作全部完成。

6. 避坑指南：常见问题与解决思路

即便按照步骤操作，也可能遇到一些意外情况。这里分享几个我遇到过的典型问题及排查思路。

问题一：Dify中测试Ollama连接失败。

• 排查网络：首先确保Dify的API容器(dify-api)能访问到Ollama容器的11434端口。可以在dify-api容器内执行curl http://ollama-container-ip:11434/api/tags试试，看Ollama的API是否正常响应。
• 检查模型名：确认在Dify中填写的模型名称，与docker exec ollama ollama list列出的名称完全一致，大小写敏感。
• 查看日志：分别查看dify-api和ollama容器的日志(docker logs <容器名>)，寻找错误信息。Ollama的日志可能会提示模型加载失败的具体原因。

问题二：Ollama容器启动后，模型列表为空。

• 检查挂载卷：这是最常见的原因。确认运行Ollama容器的-v参数中，宿主机路径是否正确，并且解压的.ollama目录就在该路径下。进入容器检查ls -la /root/.ollama/models，看里面是否有模型文件。
• 权限问题：确保Ollama容器有权限读取挂载的目录。可以尝试在运行容器时加上-u root参数（仅用于测试排查），或者调整宿主机目录的权限为755。

问题三：Dify插件安装后，在界面中找不到Ollama选项。

• 确认安装成功：在dify-api容器内，运行pip list | grep dify-plugin，确认插件已安装。
• 重启生效：插件安装后，必须重启dify-api服务。有时候需要重启整个Dify的docker-compose套件。
• 版本兼容性：这是一个深坑。确实如原始文章末尾提到的，某些版本的Dify与插件存在兼容性问题。如果你使用的是较新的Dify版本（如0.6.x），而插件版本较旧，就可能不显示。如果尝试各种方法无效，可以考虑适度降级Dify版本。例如，回退到经过更多人验证的稳定版本，如0.15.3或与插件发布说明中兼容的版本。降级前，请备份好你的数据库和配置。

问题四：模型推理速度慢或内存不足。

• 资源监控：在离线服务器上使用htop或docker stats命令，观察CPU和内存使用情况。Ollama在加载和运行模型时比较吃内存。
• 模型量化：如果使用的是7B、13B甚至更大的模型，可以考虑在联网机器拉取时，就选择量化版本（如q4_0、q8_0），模型文件更小，运行所需内存也更少。例如ollama pull llama2:7b-q4_0。
• 调整参数：在Dify的模型配置界面，可以适当调整Max Tokens等参数，控制单次生成的文本长度，以减轻负载。

离线集成的过程，就像是在组装一个精密的仪器，每一步的严丝合缝都决定了最终能否成功点亮。我的经验是，保持耐心，仔细核对每一步的命令和路径，尤其是文件传输和目录挂载这种容易出错的环节。一旦跑通，你会发现这一切的折腾都是值得的，因为你获得的是一个在完全内部环境里、数据不出域、自主可控的AI能力中台，这对于很多企业场景来说，其价值远超部署时遇到的这些技术挑战。