企业官网建设流程全解析

简介：这份资源是面向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）、db（PostgreSQL）、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 国内源。这三件事任何一件没换，安装就会在某个环节卡死。

提示：镜像加速地址各云厂商都有提供，选你所在机房同区域的，跨区拉取照样慢。

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 文件中的镜像统一替换为国内镜像站前缀 MIRROR="your-mirror.example.com" # 换成你实际可用的镜像站域名 COMPOSE_FILE="docker-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' registry=https://registry.npmmirror.com strict-ssl=false fetch-timeout=120000 EOF

registry指向 npmmirror 这类国内源，strict-ssl=false是为了绕过部分内网自签证书导致的 ssl 错误——这也是热词里 dify ssl错误 的高频来源。fetch-timeout调大，避免大包下载中途超时。Python 侧同理，在api的构建或pip install前加-i https://pypi.tuna.tsinghua.edu.cn/simple，或者写进pip.conf。

注意：strict-ssl=false只建议在内网自签证书环境用，公网环境关掉它等于放弃校验，别长期留着。

3. 从零跑通：dify-1.3.1 一键安装的完整命令与参数

3.1 环境前置检查，别跳过

一键安装再省事，也依赖宿主机有 Docker 和 Compose。先确认版本，dify 1.3.1 对 Compose 的version字段和docker compose（v2）语法有要求，用老的docker-compose（v1）可能报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_count=262144

vm.max_map_count这个参数是血泪经验：不调，向量库容器起来就退出，日志里只写max virtual memory areas vm.max_map_count [65530] is too low，新手很容易以为是镜像问题。内存建议至少 8GB，api加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 2>&1; then echo "api 已就绪" break fi sleep 5 done

SECRET_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 --tail=50 api worker

docker 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-ssl=false，或把内网 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. 进阶：把一键安装包改造成可复用、可验证的内网部署模板

一键安装跑通只是起点，真正省事的是把它变成团队可复用的模板。我一般会做三件事。第一，把镜像前缀、端口、密钥全部抽到.env，compose 里只引用变量，这样换环境只改一个文件。第二，加一个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。希望帮到你。

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