简介这份资源是面向AI应用开发者的Dify 1.3.1本地化部署包针对国内网络环境做了镜像优化解决官方镜像拉取缓慢、配置繁琐的问题适合需要在内网或私有服务器上快速搭建大模型应用平台的开发者与运维人员。压缩包共约2000个文件以1410个Python源码、370个JSON配置、103个CSS样式及少量JS、YAML、Shell脚本为主整体仅20.31MB涵盖后端服务、前端界面与容器编排等完整模块。资源已预置好.env环境变量与dify.yaml编排文件Nginx端口、S3插件等参数均已填写解压至Linux服务器后即可通过docker-compose一键启动浏览器访问对应IP与端口完成注册即可使用后续也可按需自行调整配置。目前已有1882人学习下载对于希望跳过环境折腾、直接体验Dify工作流与插件能力的读者是一份开箱即用的部署参考。1. 为什么“纯国内镜像”才是 dify-1.3.1 部署包能不能落地的分水岭如果你在国内机房或公司内网拉过 dify 的镜像大概率经历过这种场面docker compose up -d敲下去终端卡在Pulling十几分钟最后甩出一行net/http: TLS handshake timeout或者dial tcp ... i/o timeout。这不是你网络坏了是默认的 Docker Hub、npm、pip 源在境内访问不稳定。dify-1.3.1 部署包 纯国内镜像 一键安装 这个标题讲的正是把这件事一次性解决把 dify 社区版 1.3.1 所需的镜像、依赖、前端构建产物全部换成国内可达的源再用一个脚本把安装、启动、初始化串起来。它解决的不是“dify 是什么”的问题而是“我能不能在半小时内把它跑起来”的问题。适合三类人想在内网做 AI 应用编排的运维、要快速验证 dify 工作流和知识库流水线的开发者、以及被 ssl 错误和 credentials validation 报错折腾过的二次开发人员。读完你应该能自己判断这套包值不值得用、哪些参数必须改、翻车点在哪。2. 拆开一键安装dify-1.3.1 的组件清单与国内镜像替换逻辑2.1 先看清 dify 1.3.1 到底拉了哪些东西dify 社区版本质是一组容器加一个前端。1.3.1 这个版本的核心组件大致是api后端Python、worker异步任务、web前端Next.js、dbPostgreSQL、redis、nginx或 Caddy 做反代、sandbox代码执行沙箱、ssrf_proxy。如果你启用了知识库的向量检索还会涉及weaviate或qdrant接 Neo4j 做图谱的会多一个neo4j容器社区里常提的 dify neo4j 0.0.7 就是这类插件版本。一键安装包要做的是把这些镜像的image:字段从 Docker Hub 换成国内镜像站把前端npm install的 registry 换成 npm 国内镜像源把 Python 依赖的 index-url 换成 pip 国内源。这三件事任何一件没换安装就会在某个环节卡死。组件默认来源国内替换对象是否必须换api / workerDocker Hub国内容器镜像加速地址必须web 构建依赖registry.npmjs.orgnpm 国内镜像源必须Python 依赖pypi.orgpip 国内源必须db / redisDocker Hub国内容器镜像加速地址必须向量库Docker Hub国内容器镜像加速地址按需提示镜像加速地址各云厂商都有提供选你所在机房同区域的跨区拉取照样慢。2.2 镜像替换的三种做法哪种适合一键包第一种是改docker-compose.yaml里的image字段把langgenius/dify-api:1.3.1改成你的镜像站/langgenius/dify-api:1.3.1。这是最直接、最可控的方式一键包通常用这种。第二种是配 Docker daemon 的registry-mirrors全局生效但遇到镜像站没缓存的 tag 还是会回源。第三种是提前docker pull再docker tag适合完全离线环境。一键安装脚本一般走第一种加第三种组合先尝试从国内站拉拉不到就提示你手动导入离线 tar 包。下面是一段典型的镜像替换脚本片段逻辑是遍历 compose 文件里的镜像名统一加前缀。#!/usr/bin/env bash # 将 compose 文件中的镜像统一替换为国内镜像站前缀 MIRRORyour-mirror.example.com # 换成你实际可用的镜像站域名 COMPOSE_FILEdocker-compose.yaml # 备份原文件出问题能回滚 cp $COMPOSE_FILE ${COMPOSE_FILE}.bak # 匹配 image: 开头的行跳过已经带前缀的 sed -i -E s|^(\s*image:\s*)([^/])/(.)|\1${MIRROR}/\2/\3| $COMPOSE_FILE echo 替换完成检查 diff diff ${COMPOSE_FILE}.bak $COMPOSE_FILE这段脚本的关键在sed的正则^(\s*image:\s*)匹配缩进和image:([^/])/(.)把组织名/镜像名拆开再拼上镜像站前缀。参数MIRROR必须换成你实测能通的地址别照抄。跑完一定看diff确认没有把image: postgres:15这种官方镜像误伤成mirror/postgres:15——官方镜像的路径规则和带组织名的不一样误伤后拉取会 404。2.3 npm 与 pip 源替换前端构建不换源必卡dify 的web容器在构建阶段会跑npm install。默认走 registry.npmjs.org国内经常卡在sill fetch或者直接ETIMEDOUT。一键包会在web/Dockerfile或构建参数里注入 registry。常见做法是加一个.npmrc# 在 web 目录下生成 .npmrc指定国内 registry cat web/.npmrc EOF registryhttps://registry.npmmirror.com strict-sslfalse fetch-timeout120000 EOFregistry指向 npmmirror 这类国内源strict-sslfalse是为了绕过部分内网自签证书导致的 ssl 错误——这也是热词里 dify ssl错误 的高频来源。fetch-timeout调大避免大包下载中途超时。Python 侧同理在api的构建或pip install前加-i https://pypi.tuna.tsinghua.edu.cn/simple或者写进pip.conf。注意strict-sslfalse只建议在内网自签证书环境用公网环境关掉它等于放弃校验别长期留着。3. 从零跑通dify-1.3.1 一键安装的完整命令与参数3.1 环境前置检查别跳过一键安装再省事也依赖宿主机有 Docker 和 Compose。先确认版本dify 1.3.1 对 Compose 的version字段和docker composev2语法有要求用老的docker-composev1可能报unsupported config option。# 检查 docker 与 compose 版本 docker version --format {{.Server.Version}} docker compose version # 确认内核参数Elasticsearch/向量库对 vm.max_map_count 有要求 sysctl vm.max_map_count # 若小于 262144临时调大 sudo sysctl -w vm.max_map_count262144vm.max_map_count这个参数是血泪经验不调向量库容器起来就退出日志里只写max virtual memory areas vm.max_map_count [65530] is too low新手很容易以为是镜像问题。内存建议至少 8GBapi加worker加向量库一起跑4GB 机器会 OOM。3.2 一键脚本的执行顺序与关键参数一个靠谱的一键安装脚本顺序应该是检查环境 → 替换镜像源 → 生成.env→ 拉镜像 → 启动 → 健康检查。下面这段是核心启动逻辑重点看.env的生成。#!/usr/bin/env bash set -euo pipefail # 任一命令失败即退出避免半成品状态 # 1. 从模板生成 .env密钥必须随机 if [ ! -f .env ]; then cp .env.example .env # 生成随机密钥别用默认值 SECRET$(openssl rand -base64 42) sed -i s|^SECRET_KEY.*|SECRET_KEY${SECRET}| .env fi # 2. 拉取镜像国内源已在 compose 中替换 docker compose pull # 3. 启动-d 后台运行 docker compose up -d # 4. 等待 api 健康最多 120 秒 for i in $(seq 1 24); do if curl -sf http://localhost:5001/health /dev/null 21; then echo api 已就绪 break fi sleep 5 doneSECRET_KEY必须改默认值会导致会话和加密数据不安全也是credentials validation类报错的诱因之一。set -euo pipefail保证脚本遇到错误立刻停不会出现“一半容器起来了”的玄学状态。健康检查打的是api的/health端口按你.env里EXPOSE_API_PORT实际值改。3.3 首次启动后必须做的三件事容器全绿不代表能用。第一进http://你的IP/install走初始化设置管理员账号这一步会写数据库如果db容器没完全就绪会报 500等 30 秒重试即可。第二检查worker日志有没有celery连接 redis 失败有的话是REDIS_HOST配错。第三如果要接本地大模型在「设置 → 模型供应商」里填 Ollama 或本地推理服务的地址注意容器内访问宿主机要用host.docker.internal或宿主机内网 IP写localhost一定连不上。# 查看各容器状态与最近日志 docker compose ps docker compose logs --tail50 api workerdocker compose ps里STATUS显示healthy才算真就绪running只是进程活着。logs里如果看到OperationalError: could not connect to server是 db 还没起来等看到Connection refused指向 redis是 host 配错。4. 避坑与排查dify 国内镜像部署最常见的 5 个翻车点4.1 镜像拉取报 TLS handshake timeout现象docker compose pull卡住最终net/http: TLS handshake timeout。原因镜像站地址不可达或者 daemon 配的registry-mirrors和 compose 里的前缀冲突。解决先用curl -I https://你的镜像站/v2/确认可达再检查/etc/docker/daemon.json里的 mirrors 是否和 compose 前缀重复重复会导致解析混乱二选一即可。4.2 前端构建报 ssl 错误或证书校验失败现象web容器构建时npm ERR! code CERT_HAS_EXPIRED或UNABLE_TO_VERIFY_LEAF_SIGNATURE。原因内网代理替换了证书npm 默认严格校验。解决在.npmrc里加strict-sslfalse或把内网 CA 证书挂进容器并设NODE_EXTRA_CA_CERTS。前者快后者正规生产环境用后者。4.3 初始化页面报 credentials validation 错误现象填完管理员账号点下一步提示an error occurred during credentials validation。原因多半是SECRET_KEY或数据库连接串有问题也可能是db容器数据卷权限不对导致写不进去。解决docker compose logs db看有没有permission denied有就修数据卷属主确认.env里SECRET_KEY非默认且DB_*参数和 compose 一致。4.4 工作流上下文超长导致任务失败现象跑 dify 工作流时长对话或大知识库检索报上下文超长。原因模型上下文窗口有限知识库流水线召回片段过多。解决在知识库设置里调小top_k和分段大小工作流里加「上下文裁剪」节点。这不是部署问题但国内镜像部署后大家第一件事就是灌知识库很容易撞上。4.5 升级或迁移时数据丢失现象想从 1.3.1 升到更新版本直接换镜像重启数据没了。原因db和向量库的数据在 Docker volume 里换 compose 时 volume 名变了或没挂载。解决升级前docker compose down不加-v别删卷备份volumes目录和.env再换新版本 compose 启动。dify 迁移 的核心就是保住 db 卷和.env里的密钥。5. 进阶把一键安装包改造成可复用、可验证的内网部署模板一键安装跑通只是起点真正省事的是把它变成团队可复用的模板。我一般会做三件事。第一把镜像前缀、端口、密钥全部抽到.envcompose 里只引用变量这样换环境只改一个文件。第二加一个verify.sh启动后自动检查 api 健康、db 连通、redis 连通、web 可访问四项全过才返回 0方便接 CI。#!/usr/bin/env bash # verify.sh 部署后自检四项全过才算成功 set -e curl -sf http://localhost:5001/health /dev/null echo api OK docker compose exec -T db pg_isready -U postgres /dev/null echo db OK docker compose exec -T redis redis-cli ping | grep -q PONG echo redis OK curl -sf http://localhost/ /dev/null echo web OK第三把离线 tar 包和脚本放一起内网机器直接docker load再跑脚本彻底不依赖外网。验证方法上除了自检脚本我习惯在初始化后立刻建一个最小工作流一个开始节点接一个大模型节点跑通一次确认模型供应商配置正确。这一步能提前暴露 90% 的配置问题。说个我自己的教训早期图省事.env里SECRET_KEY没改迁移时新旧环境密钥不一致加密的模型 API Key 全部解不开只能重配。从那以后任何 dify 部署我第一件事就是生成随机密钥并单独备份.env。希望帮到你。本文还有配套的精品资源点击获取