把Dify部署到内网/局域网环境这事听起来似乎就是把Docker Compose跑起来、改个IP就完事但真正操作过才会发现内网环境下从镜像获取、模型接入到多用户访问每一步都可能踩坑。我今年帮两个团队做过Dify的局域网络部署一个是用在内部知识库问答一个是给产品团队做AI应用原型验证体会最深的一点是内网部署和公网部署完全是两码事思维方式得先切换过来。这篇就把整个过程中的方案选型、实操步骤和排查经验整理出来给同样需要在隔离网络里跑Dify的朋友一个可参考的完整路径。1. 为什么要在局域网里跑Dify场景与需求拆解1.1 内网使用Dify的真实需求需要把Dify部署到内网/局域网通常绕不开这几类诉求。最典型的是数据安全要求。企业内部的知识库、技术文档、业务流程数据很多都带有保密属性不适合传输到外部服务。把这些数据接入AI应用做问答、做分析时企业合规部门会直接要求所有数据链路不经过外网。这种场景下Dify作为应用开发框架跑在内网是唯一合规的选择。另一个常见诉求是稳定性和可控性。公网SaaS服务会受到网络波动、服务商变更、限流策略的影响而局域网部署意味着整套系统都在自己手里访问速度、可用性、版本升级节奏都可以自主掌控。对于需要7×24小时运行的内部工具来说这一点很关键。还有一类场景是成本考量。某些团队只是想做内部原型的快速验证比如测试RAG检索增强生成流程、对比不同模型的效果用Dify可以快速拼出可用的应用配合本地部署的开源模型整个链路的边际成本会低很多。不管属于哪类诉求内网部署Dify的核心目标是一样的在一个不依赖外部服务的网络环境里跑起来一套完整的AI应用开发平台。1.2 内网部署和公网部署的核心差异很多人第一次做内网部署时心态还停留在“照教程敲命令”的阶段但内网环境的约束条件完全不同。公网部署时服务器可以随意访问外部镜像仓库、模型API、软件源所有依赖都能即时拉取内网环境则意味着这些路径全部断裂甚至可能是物理隔离网络唯一可行的信息传递通道就是移动硬盘或离线安装包。另一个差异是模型接入方式。公网部署可以直接配置云端模型服务的API Key开通即用内网环境则必须自己解决模型推理能力要么部署本地开源模型要么对接企业内部已有的模型服务平台要么通过代理网关统一调用。我见过不少内网部署失败的案例最后复盘发现根本不是Dify本身的问题而是环境差异导致的“隐性依赖”没有被提前识别。比如某个组件启动时会默认去拉取字体包、下载向量模型文件在内网环境里这些操作会一直卡住或超时。1.3 部署前的资源盘点清单第一次做内网部署前建议先把下面这几项整理清楚能省下大量排查时间服务器硬件配置CPU核心数、内存容量、磁盘空间。Dify全家桶API服务、Worker、数据库、向量存储、Sandbox等加起来内存占用不小个人使用建议16GB起步团队使用建议32GB以上。网络边界情况是纯物理隔离还是只屏蔽了部分外网域名是否能访问内部镜像仓库这直接决定镜像获取策略。模型资源情况内网是否有可用的模型推理服务有没有开放兼容接口模型文件能否离线获取客户端数量预计有多少用户通过浏览器访问是否需要配置HTTPS是否需要统一入口时间窗口如果需要在限定的迁移窗口内完成部署是否提前准备好所有资源包把这些盘清楚后续的部署方案就有了明确依据。2. 内网部署的核心准备工作2.1 硬件与系统环境要求Dify官方对配置的要求是一个参考底线内网环境中建议适度上调。内存方面Dify默认的Docker Compose配置里包含postgres数据库、redis缓存、weaviate向量库、sandbox运行环境等多个容器。即便没有用户访问整套服务常驻内存占用就在8GB到10GB之间当有并发请求时内存会进一步升高。我给某团队推荐的是32GB内存的服务器跑知识库问答应用日常20个并发用户完全够用。CPU方面Dify本身计算压力不大但如果服务器上同时部署本地模型就需要单独考虑。CPU推理开源模型的效率较低即使只跑7B参数量的量化模型并发超过3个就会明显卡顿有条件的话建议给本地模型准备独立GPU设备。存储方面两件事占用空间容器镜像本身以及向量库中存储的文档切片数据。镜像大约需要10GB空间向量数据则随业务增长持续膨胀。建议系统盘预留100GB以上另外挂载独立数据盘存放docker数据目录。系统环境建议使用Ubuntu 22.04 LTS或Debian 12Docker版本不低于24.xDocker Compose插件版本不低于2.20。这类系统对容器环境的兼容性较好遇到问题也能查到大量参考案例。2.2 镜像获取策略从外网环境打包迁移内网环境最直接的问题Dify的镜像从哪来推荐的做法是在可访问外网的机器上提前拉取所有镜像保存为tar文件再迁移到内网导入。第一步准备一台有外网访问权限的机器安装相同版本的Docker从Dify官方仓库获取对应版本的docker-compose.yaml文件。第二步根据编排文件逐条拉取镜像。以常见版本为例镜像清单大致包括dify-apidify-workerdify-webnginxpostgresredisweaviatesandboxssrf_proxy第三步通过docker save命令将所有镜像打包为一个压缩文件。打包命令类似下面这样docker save \ langgenius/dify-api:0.6.14 \ langgenius/dify-worker:0.6.14 \ langgenius/dify-web:0.6.14 \ nginx:latest \ postgres:15-alpine \ redis:7-alpine \ semitechnologies/weaviate:1.19.0 \ langgenius/dify-sandbox:0.2.1 \ ubuntu:22.04 \ -o dify-kit.tar第四步将tar文件拷贝至内网服务器执行docker load导入。docker load -i dify-kit.tar导入完成后通过docker images确认所有镜像都已存在。强烈建议把镜像清单和版本号记录在案后续需要扩展节点或恢复环境时这个清单就是最重要的参考依据。注意镜像打包迁移时一定在同一台机器上操作docker save和docker load避免出现架构不匹配问题。如果外网机器是MacARM架构而内网服务器是x86的Linux拉取到的镜像就不能直接使用。最稳妥的方式是让外网迁移机和内网服务器使用相同的CPU架构。2.3 版本锁定与配置文件准备内网部署必须锁定Dify版本不能像公网环境那样随意用latest。原因很简单内网没有持续拉取新镜像的条件版本一旦确定后续的配置文件、镜像都围绕它来准备。拿到对应版本的docker-compose.yaml之后建议做这几件事一是把yml文件里所有镜像的tag参数固定写死避免因为“latest”语义变化导致迁移不一致。二是检查环境变量配置段重点看SECRET_KEY、DB_PASSWORD等密钥项提前生成强随机值填入。Dify在首次启动时会用这些密钥初始化数据库后续再改会比较麻烦。三是提前准备好nginx的配置文件。默认配置绑定80端口内网场景建议直接复用如果要改端口或添加HTTPS证书需要同步调整web服务里的相关配置。四是检查sandbox配置。Dify的代码执行功能依赖于沙箱环境有些内网部署出于安全考虑会禁用这部分能力配置文件里可以对应调整启用状态。这些准备工作做完内网部署最容易被“卡脖子”的问题就基本解决了。3. 局域网完整部署实操过程3.1 基础部署步骤内网服务器的部署流程和公网环境在命令层面是相近的核心区别在于所有依赖都已经提前备齐。进入docker-compose.yml所在目录先做一次启动前检查docker compose config这个命令会校验编排文件的语法和配置完整性有错误会直接提示。确认无误后后台启动docker compose up -d启动后查看容器状态docker compose ps正常情况下api、worker、web、db、redis、weaviate这些核心容器都会处于Up状态。接着查看日志确认初始化过程无误docker compose logs -f api看到类似“Application startup complete”之类的日志时说明API服务已经就绪。3.2 离线镜像导入的细节与验证离线导入阶段最关键的一点不只是把镜像load进来还要校验镜像完整性和版本匹配。我在一次迁移中遇到过这样的情况tar包拷贝过程中文件损坏docker load并没有报错但后续启动api容器时反复崩溃日志提示找不到某个依赖文件。后来重新对比了源机器的镜像ID和导入后的镜像ID发现问题出在传输环节。所以建议在导入完成后用下面两步做验证第一步对比镜像REPOSITORY和TAG是否完整。第二步对比关键镜像的ID是否一致。docker images --digests在源机器和目标机器上分别执行比对结果确保镜像的内容完全一致。这一步虽然简单但能避免大量启动阶段的隐藏问题。另一个细节导入完成后不要立刻执行docker compose up。先手工启动一个临时容器做基本验证比如启动postgres、redis这两个基础组件确认能正常运行后再启动整套编排这样问题定位更清晰。3.3 环境变量与关键配置调整Dify的配置主要通过docker-compose.yml里的environment段完成。内网环境下有几个变量的调整需要注意。第一个是强制HTTPS相关设置。如果内网只用HTTP访问需要确保Dify不会强制跳转HTTPS否则用户访问时会一直重定向到不存在的https地址。第二个是域名与端口配置。如果通过IP加端口访问比如 http://192.168.x.x:8080需要同时修改nginx和web容器里的相关配置。第三个是存储路径设置。Dify支持把外部文件存储改为本地存储或内网的MinIO服务如果用默认配置所有上传文件会保存在容器内部容器重建后数据容易丢失。建议在部署时把存储挂载到宿主机目录volumes: - ./volumes/app:/app/api/public第四个是模型密钥配置。如果直接使用本地模型服务需要确保API地址可以被子网内的其他容器访问不要使用localhost或127.0.0.1而应该使用宿主机在容器网络中的网关地址通常是172.17.0.1或配置host模式。3.4 局域网访问与多用户使用配置部署完成后局域网内的其他电脑通过浏览器访问http://服务器IP:端口即可打开Dify控制台。首次访问时系统引导创建管理员账号这个账号拥有全平台管理权限。团队使用时建议做三件事第一在控制台里创建多个成员账号分配不同角色权限。Dify支持工作空间级别的成员管理可以把不同业务线的同事分到不同空间隔离应用和数据。第二配置nginx反向代理。如果服务器有多个应用需要共用80/443端口用nginx做一层代理按路径或子域名转发到Dify容器这样用户入口统一后续也方便加HTTPS证书。第三设置访问范围。如果局域网内存在多个网段但只想允许特定网段访问可以在服务器防火墙层限制入口。例如仅放行办公网段到Dify端口的访问规则sudo ufw allow from 192.168.10.0/24 to any port 8080实操建议如果团队使用人数较多建议在部署时就把Dify的web服务映射到非默认端口比如8080避免和服务器上其他HTTP服务冲突。端口的选择要提前规划好部署完成后轻易不改因为改端口会涉及nginx配置、应用内地址等多处联动调整。4. 内网环境下的模型接入核心方案对比4.1 外网模型API不可用时的替代思路内网部署Dify之后最核心的问题来了应用需要模型能力模型从哪来如果内网无法访问外部模型API那就只有两条路一是部署本地开源模型二是接入公司内部已有的模型服务。两条路并不互斥可以并行。Dify的模型接入层设计得比较灵活支持在“设置 → 模型供应商”里添加多种来源。对于内网部署两种方式最实用接入本地推理框架提供的OpenAI兼容接口或者直接接入Ollama这类轻量级本地模型服务。4.2 以Ollama方式接入本地模型Ollama是目前内网部署中接入门槛最低的方案特别适合快速跑通流程。在局域网内找一台配置较好的机器建议32GB内存以上如果有GPU更好安装Ollama后拉取目标模型。以比较常用的中文场景为例ollama pull qwen2.5:7b模型就绪后让Ollama在局域网内可访问的地址上监听。默认配置下Ollama只监听本机回环地址需要修改监听参数使其监听0.0.0.0这样Dify才能通过网络访问到。接着在Dify的模型供应商页面选择Ollama类型填入API地址http://内网机器IP:11434和模型名称即可完成接入。Dify会自动拉取该模型的能力信息包括上下文长度、支持的参数等。实测中7B级别模型对中文问答、摘要、简单推理任务表现尚可响应速度在纯CPU环境下大约每秒5到10个token在GPU环境下可以提升十倍以上。如果对生成质量有更高要求可以考虑14B或更大参数模型但硬件投入会明显增加。4.3 通过兼容接口接入内部模型网关很多中大型企业内部已经建设了模型服务平台通过统一网关对外提供API服务。这类平台通常兼容OpenAI的接口格式Dify可以直接接入。操作路径是在模型供应商列表中选择“OpenAI-API-compatible”填上网关地址、访问密钥和模型部署名称。关键点在于网关的API路径可能需要拼接例如网关地址加上/v1等前缀Dify的接入表单中都有对应字段。这里有个技巧如果内部网关对某些模型支持Chat模式而Dify设置中识别不到可以先手动填写模型名称Modal name然后在“模型类型”里选择LLM再试着发起一次对话验证。不少内部网关兼容层的识别字段是标准化的填写准了就能直接连通。接入成功后可以在Dify的应用编排页面里选择该模型进行对话测试。建议先在调试对话里发起简单请求确认模型返回正常再开始搭建完整的应用工作流。4.4 评测与选型建议做了几个团队的模型接入对比后我的建议是先跑通Ollama再考虑内部网关最后再考虑更重的专有模型平台。Ollama胜在简单直接一条命令就能启动服务适合验证Dify的编排流程是否正常。内部网关适合生产场景优点是模型能力更强、管理规范、还有统一监控缺点是接入调试可能需要和网关平台的管理方反复确认参数。如果是自己搭着玩或者小团队内部用Ollama配7B或14B模型就足够跑出很可靠的RAG应用。如果是部门级甚至公司级应用务必优先确认内网已有的模型资源避免重复造轮子。5. 常见问题与排查技巧实录5.1 启动失败类问题现象一docker compose up之后api容器反复重启。最常见的诱因是数据库初始化失败。Dify首次启动时api容器会等待数据库就绪并执行迁移脚本如果postgres容器尚未完全初始化api容器就会进入重启循环。排查方法是查看api容器日志docker compose logs -f api如果日志里有“relation does not exist”这类数据库错误最稳妥的解决方式是把数据目录清空、重新执行docker compose down -v再up。内网部署时没有升级包袱重新初始化通常是最快路径。现象二web容器启动后浏览器访问502。这通常是前端容器和nginx容器之间的通信问题。检查web容器和nginx容器是否都处于正常状态确认docker网络是否创建成功。执行docker network ls查看是否存在平台网络如果没有重新执行docker compose up时加上-d参数让Compose自动重建网络。5.2 模型调用失败类问题现象在Dify中测试对话界面提示模型调用超时或connection refused。排查思路分三层。第一层确认目标模型服务本身可用直接在服务器上用curl测试接口连通性。第二层确认Dify容器到模型服务的网络链路容器内执行curl看是否能访问模型服务地址。特别注意不要用localhost因为容器内的localhost指的是容器自己不是宿主机。第三层确认模型供应商页面填写的API地址格式正确没有多余空格或错误前缀。我遇到过最隐蔽的一个问题模型服务监听了IPv6地址Dify容器用IPv4访问失败。解决方式是在模型服务启动参数中明确指定监听IPv4地址。5.3 局域网访问异常类问题现象服务器本机可以访问Dify页面但局域网内其他电脑不行。优先级排查是否防火墙拦截。Ubuntu的ufw如果开启需要放行对应端口。检查方法sudo ufw status如果状态为active增加规则放行sudo ufw allow 8080/tcp另一个常见原因是docker-compose.yml里端口映射配置不正确。如果web服务的ports写的是127.0.0.1:8080:80那只有本机能访问需要改为0.0.0.0:8080:80或直接用8080:80。5.4 性能与稳定性调优建议内网部署跑一段时间后最容易出现两类问题一是向量库体积膨胀导致检索变慢二是所有容器放在同一台服务器上资源竞争导致整体响应变慢。向量库优化的核心是控制索引规模和数据生命周期。建议在知识库管理后台定期清理过期文档同时为每个知识库设置合理的分块大小。块太小会浪费向量空间块太大会降低检索准确率。容器资源限制方面建议在docker-compose.yml里为api、worker、weaviate等核心服务增加mem_limit配置防止单个容器抢占全部内存。例如services: api: mem_limit: 4g worker: mem_limit: 4g weaviate: mem_limit: 2g设置后即使某个服务出现内存泄漏也不会拖垮整台服务器的其他服务。另外一点实操经验内网Dify上线后建议定期手动备份docker数据目录尤其是postgres和weaviate两个子目录。Dify本身的备份机制依赖外部存储配置如果不提前设置容器重建后历史配置和知识库数据都有可能丢失。最简单的备份方式服务停掉后直接拷贝整个数据目录到另一块磁盘恢复时原样放回即可。6. 内网部署的扩展思路与个人体会一个Dify内网部署跑通只是开始真正让它发挥价值还需要在应用层面持续打磨。我个人用过最舒服的路径是先用Dify搭建一个内部知识库问答机器人把团队的技术文档、运维手册、项目总结全部投进去让新同事遇到问题时先问机器人解决基础重复性咨询。跑通之后再逐步添加工作流类应用例如把告警日志通过API接入Dify自动汇总分析并按模板生成处理建议。在实际操作中我的体会是内网部署Dify最大的门槛不在技术而在准备。镜像提前备好、模型提前接入、端口和域名提前规划整套部署跑下来其实半小时就能完成反之如果这些准备工作没有做光是排查镜像缺失和网络不通就可能耗费大半天。最后再分享一个小技巧在内网服务器上给docker配置一个本地镜像仓库服务比如Harbor或Registry把Dify镜像推送进去。后续不管是升级版本还是增加新的部署节点都能直接从内部仓库拉取彻底摆脱依赖外网迁移文件的局面。这个步骤做完内网部署的体系才算真正完整。