简介：本资源为 Dify 1.3.1 版本的纯国内镜像一键部署包，面向需要在 Linux 服务器上快速搭建大模型应用开发平台的开发者与运维人员，解决官方镜像拉取缓慢、环境配置繁琐的问题。压缩包共约 2000 个文件，以 1410 个 Python 源码、370 个 JSON 配置、103 个 CSS 样式及 26 个 JS 脚本为主，另含 23 个 YAML、12 个 Shell 脚本与少量 HTML、SQL、XML 等，整体约 20.31MB，覆盖后端服务、前端界面与容器编排所需模块。包内已预置 .env 环境文件与 dify.yaml 编排文件，Nginx 端口、S3 插件等参数均已写好，解压至 /usr/local 后进入 docker 目录执行 docker-compose 命令即可拉起全部服务，浏览器访问对应 IP 的 17880 端口完成注册即可使用。目前已有 1882 人学习下载，适合希望跳过镜像下载与配置调试、直接体验 Dify 1.3.1 的读者参考使用。

1. dify-1.3.1 部署包：纯国内镜像一键安装到底省掉了哪些事

公司内网机器不能直连外网，但团队想用 Dify 搭一套知识库问答，这个场景我遇到过不止一次。dify-1.3.1 部署包配纯国内镜像一键安装，解决的正是这件事：把 Docker 镜像、npm 依赖、Python 包全部换成国内可访问的源，让一台干净的内网服务器在半小时内跑起 Dify。它适合三类人：没有外网出口的企业内网运维、被镜像拉取超时折磨过的后端、以及想快速验证 Dify 工作流和知识库流水线是否值得投入的技术负责人。这篇不聊概念，只讲部署包怎么拆、参数怎么改、哪几个地方最容易翻车。

2. 部署包拆开看：国内镜像替换了哪些层

2.1 镜像层、依赖层、运行时层的替换逻辑

Dify 的部署本质是 Docker Compose 拉起一组容器：api、worker、web、db、redis、weaviate 或 qdrant、nginx。官方 compose 文件里每个服务的 image 字段指向 Docker Hub，构建阶段还会从 npm registry 和 PyPI 拉包。纯国内镜像部署包做的事情，是在三个层面做替换。

第一层是容器镜像。把 langgenius/dify-api:1.3.1 、 langgenius/dify-web:1.3.1 这类镜像地址换成国内镜像仓库的对应路径。常见做法是使用阿里云容器镜像服务的公开镜像加速，或者企业自建的 Harbor 仓库做一次代理缓存。第二层是构建依赖。web 前端构建时 npm install 会访问 registry.npmjs.org，部署包里会把 .npmrc 的 registry 指向 npmmirror。第三层是 Python 包。api 服务安装依赖时 pip 默认走 pypi.org，部署包会写入 pip.conf 指向清华或阿里云 PyPI 镜像。

这三层缺一层，一键安装就会在某个环节卡住。我见过只换了 Docker 镜像但没换 pip 源的部署包，容器能起来，api 服务启动时装依赖直接超时，日志里全是 Read timed out 。

2.2 一键安装脚本的执行流程与关键参数

部署包通常包含一个 install.sh 和一份 .env 模板。脚本做四件事：检查 Docker 和 Docker Compose 是否就绪、导入离线镜像或配置镜像加速、生成 .env 文件、执行 docker compose up -d 。

#!/bin/bash
# install.sh 核心逻辑节选
set -e

# 1. 检查 Docker 环境
if ! command -v docker &> /dev/null; then
    echo "Docker 未安装，请先安装 Docker 20.10+"
    exit 1
fi

# 2. 配置 Docker 镜像加速（写入 daemon.json）
MIRROR_URL="https://your-mirror.example.com"
mkdir -p /etc/docker
cat > /etc/docker/daemon.json <<EOF
{
  "registry-mirrors": ["${MIRROR_URL}"],
  "insecure-registries": []
}
EOF
systemctl daemon-reload && systemctl restart docker

# 3. 生成 .env
if [ ! -f .env ]; then
    cp .env.example .env
    # 替换关键参数
    sed -i "s|^DIFY_API_BASE_URL=.*|DIFY_API_BASE_URL=http://$(hostname -I | awk '{print $1}')|" .env
fi

# 4. 启动
docker compose -f docker-compose.yaml up -d

脚本里 registry-mirrors 填的是国内镜像加速地址， DIFY_API_BASE_URL 必须改成服务器实际 IP，否则 web 前端调 api 会跨域失败。 .env 里还有几个参数值得注意： DB_PASSWORD 和 REDIS_PASSWORD 不要用默认值， SECRET_KEY 必须重新生成， MIGRATION_ENABLED 在首次启动时设为 true，后续升级再关掉。

2.3 离线镜像导入与在线加速的选型差异

部署包分两种形态：离线 tar 包和在线加速脚本。离线包把 docker save 出来的镜像打成 tar，安装时 docker load 导入，适合完全断网的环境。在线加速脚本只配镜像源，镜像还是从国内仓库拉，适合有外网但直连 Docker Hub 慢的机器。

选哪种看两个指标：内网是否有 DNS 能解析国内镜像仓库、磁盘剩余空间是否大于 20GB。离线包体积通常在 3 到 5GB，导入后镜像层占用的空间会翻倍。在线加速对磁盘友好，但首次拉取仍受网络波动影响。我一般建议：能通外网就用在线加速，完全隔离才用离线包，因为离线包的镜像更新需要重新制作，维护成本高。

3. 从零跑通：dify-1.3.1 一键安装的完整步骤

3.1 环境预检：Docker、Compose、端口、磁盘

在跑安装脚本之前，先确认四件事。Docker 版本不低于 20.10，Docker Compose 版本不低于 v2.0，80 和 443 端口没有被 nginx 或其他服务占用，根分区剩余空间大于 20GB。

# 环境预检命令
docker --version
docker compose version
ss -tlnp | grep -E ':80|:443'
df -h / | tail -1

如果 80 端口被占用，改 .env 里的 EXPOSE_NGINX_PORT 为 8080 或其他端口。磁盘不够的话，Docker 的默认数据目录在 /var/lib/docker ，可以通过 daemon.json 的 data-root 迁移到更大的分区。这几步看起来简单，但端口冲突和磁盘满是一键安装失败里排名前两位的原因。

3.2 配置 .env：数据库密码、密钥、镜像地址

.env 文件是 Dify 部署的核心配置。以下是一份经过脱敏的关键参数表。

参数名	作用	建议值
DB_PASSWORD	PostgreSQL 密码	16 位随机字符串
REDIS_PASSWORD	Redis 密码	16 位随机字符串
SECRET_KEY	会话加密密钥	openssl rand -base64 42 生成
DIFY_API_BASE_URL	前端调 API 的地址	http://服务器IP
MIGRATION_ENABLED	首次启动执行数据库迁移	true
EXPOSE_NGINX_PORT	nginx 暴露端口	80 或自定义

生成密钥的命令：

# 生成 SECRET_KEY
openssl rand -base64 42
# 生成数据库密码
openssl rand -hex 16

SECRET_KEY 一旦设定就不要改，改了之后已登录用户的会话全部失效。 MIGRATION_ENABLED 只在首次启动或版本升级时设为 true，日常运行设为 false 可以加快启动速度。

3.3 执行安装并验证容器健康状态

配置完成后执行安装脚本，然后观察容器状态。

# 执行安装
bash install.sh

# 查看容器状态
docker compose ps

# 查看 api 服务日志
docker compose logs -f api --tail=100

正常情况下， docker compose ps 里所有服务状态应该是 running 或 healthy 。api 服务启动较慢，因为要等数据库迁移完成，通常需要 1 到 3 分钟。如果 api 反复重启，看日志里有没有 Connection refused 指向 db 或 redis，那说明密码不匹配或服务没起来。

验证 web 是否可用：

# 检查 nginx 响应
curl -I http://localhost:80

# 检查 api 健康端点
curl http://localhost:80/console/api/health

返回 200 就说明基础服务通了。接下来浏览器访问服务器 IP，应该能看到 Dify 的初始化页面，设置管理员账号密码即可进入。

3.4 接入本地大模型与知识库流水线初验

Dify 跑起来之后，第一件事是接入模型。进入「设置」→「模型供应商」，如果用的是本地 Ollama，填 http://宿主机IP:11434 ，模型名称填 Ollama 里已拉取的模型。如果用的是国内大模型 API，填对应的 Base URL 和 API Key。

知识库流水线验证：新建一个知识库，上传一份 PDF，观察索引状态。如果卡在「索引中」，看 worker 容器日志，常见原因是 embedding 模型没配好或向量数据库连接失败。dify-1.3.1 默认用 weaviate，如果换成 qdrant，需要改 .env 里的 VECTOR_STORE 参数并重启。

4. 避坑排查：一键安装最容易翻车的五个地方

4.1 现象：docker compose up 卡在 pulling 不动

原因：Docker 镜像加速没生效，或者加速地址本身不可达。 daemon.json 写完后没有重启 Docker，配置不会加载。

解决： systemctl restart docker 后执行 docker info 查看 Registry Mirrors 是否包含配置的地址。如果加速地址不通，换一个可用的国内镜像源。离线包场景下检查 docker load 是否成功， docker images 里有没有对应 tag。

4.2 现象：api 容器启动后立即退出，日志显示数据库连接失败

原因： .env 里 DB_PASSWORD 和 docker-compose.yaml 里 db 服务的 POSTGRES_PASSWORD 不一致，或者 db 容器还没初始化完 api 就启动了。

解决：确认 .env 和 compose 文件里的密码变量引用一致。如果是首次启动，给 api 加 depends_on 的 condition: service_healthy ，等 db 健康检查通过再启动。手动排查可以 docker compose exec db psql -U postgres 看能否登录。

4.3 现象：web 页面打开空白，控制台报跨域错误

原因： DIFY_API_BASE_URL 填的是 localhost 或 127.0.0.1 ，浏览器从其他机器访问时，前端请求发到了用户自己的机器上。

解决：把 DIFY_API_BASE_URL 改成服务器实际 IP 或域名，重启 web 和 nginx 容器。如果用了反向代理，确认 CONSOLE_API_URL 和 APP_API_URL 也指向正确地址。

4.4 现象：知识库上传文件后一直显示索引中

原因：worker 容器没有正常运行，或者 embedding 模型配置有误。dify-1.3.1 的索引任务由 worker 消费队列执行，worker 挂了任务就堆积。

解决： docker compose logs worker --tail=200 查看报错。常见的是 embedding 模型 API Key 无效或额度耗尽。如果是本地模型，确认 Ollama 服务可达且模型已拉取。

4.5 现象：升级或迁移后数据丢失

原因：直接删除了 db 容器或 volume，或者迁移时只备份了 .env 没备份数据库 volume。

解决：升级前执行 docker compose exec db pg_dump -U postgres dify > backup.sql 。迁移时把 volumes 目录整体打包，包括 db 、 redis 、 weaviate 的数据卷。恢复时先起 db，导入 sql，再起其他服务。

5. 进阶技巧：让 dify-1.3.1 在内网长期稳定跑

5.1 用反向代理加 HTTPS 并保留国内镜像加速

内网长期运行建议在前面加一层 nginx 做 HTTPS 终止。证书可以用内部 CA 签发，重点是 proxy_pass 指向 Dify 的 nginx 容器端口，并设置 client_max_body_size 至少 100M，否则知识库上传大文件会 413。

server {
    listen 443 ssl;
    server_name dify.internal;
    ssl_certificate /etc/nginx/certs/dify.crt;
    ssl_certificate_key /etc/nginx/certs/dify.key;
    client_max_body_size 100M;

    location / {
        proxy_pass http://127.0.0.1:80;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 300s;
    }
}

proxy_read_timeout 设大是因为工作流执行和知识库索引可能耗时较长，默认 60 秒会断。

5.2 定期备份数据库与向量库的脚本化

我习惯写一个 cron 脚本，每天凌晨备份 db 和 weaviate 的数据卷。

#!/bin/bash
# backup_dify.sh
BACKUP_DIR=/data/backup/dify/$(date +%Y%m%d)
mkdir -p ${BACKUP_DIR}

# 备份 PostgreSQL
docker compose exec -T db pg_dump -U postgres dify > ${BACKUP_DIR}/dify.sql

# 备份 weaviate 数据卷
docker run --rm -v dify_weaviate_data:/data -v ${BACKUP_DIR}:/backup \
  alpine tar czf /backup/weaviate_data.tar.gz -C /data .

# 保留最近 7 天
find /data/backup/dify -maxdepth 1 -type d -mtime +7 -exec rm -rf {} \;

这个脚本的关键是 docker compose exec -T 的 -T 参数，不加的话 cron 环境下会报 TTY 错误。向量库备份用临时容器挂载 volume 打包，比直接 cp 安全。

5.3 监控容器资源与日志轮转

Dify 跑久了，日志会撑满磁盘。在 docker-compose.yaml 里给每个服务加日志轮转配置：

services:
  api:
    logging:
      driver: json-file
      options:
        max-size: "50m"
        max-file: "3"

max-size 控制单个日志文件大小， max-file 控制保留数量。加上之后，单服务日志最多占 150MB。监控方面， docker stats 可以快速看 CPU 和内存占用，api 和 worker 是内存大户，建议给宿主机至少 8GB 内存。

我自己的习惯是每次部署完先跑一遍知识库上传和对话测试，确认索引和推理链路都通，再把地址交给团队。这套 dify-1.3.1 纯国内镜像部署方案在内网环境跑了几个月，最深的教训是： .env 里的 SECRET_KEY 和数据库密码一定要在首次启动前就设好，启动后再改，要么会话失效，要么数据库连不上，后悔药没地方买。希望帮到你。

本文还有配套的精品资源，点击获取