★ FEATURED ARTICLE 前言在数据安全日益重要的今天企业核心数据无法直接上传公有云大模型。为了兼顾 AI 的便利性与数据隐私私有化 RAG检索增强生成成为了最佳方案。本文将基于Ollama本地大模型推理 DifyRAG 应用平台 Qdrant向量数据库 Nginx反向代理的架构记录一次从零搭建企业级私有化 RAG 平台的实战过程。更重要的是本文详细记录了部署过程中遇到的“拉取卡死”、“DNS 解析失败”、“502 报错”等真实踩坑经验与解决方案希望能帮大家少走弯路。️ 架构设计底层硬件VMware 虚拟机4核 8G 内存纯 CPU 推理基础环境RHEL 10 Docker模型引擎Ollama (运行 Qwen2:1.5b 小模型)应用平台Dify 1.17.1 (全家桶 12 个容器)数据存储PostgreSQL Redis Qdrant (替换默认的 Weaviate)反向代理Nginx (处理长连接与 SSE 流式输出)️ 阶段一宿主机环境与 Docker 优化1. 配置 Docker 镜像加速与数据目录为了防止拉取镜像超时以及容器撑爆系统盘提前配置daemon.jsonbashmkdir -p /data/docker cat /etc/docker/daemon.json EOF { data-root: /data/docker, exec-opts: [native.cgroupdriversystemd], log-opts: { max-size: 100m, max-file: 3 }, registry-mirrors: [ https://docker.xuanyuan.me, https://docker.1ms.run, https://docker.m.daocloud.io ], live-restore: true } EOF systemctl daemon-reload systemctl restart docker 踩坑记录 1拉取镜像遇到magic number mismatch在拉取 Ollama 镜像时遇到此报错说明网络传输不稳定导致镜像层校验失败。解决方法是执行docker system prune -af清理损坏的缓存层换用更稳定的加速源后重新拉取即可。 阶段二部署 Ollama 推理引擎由于宿主机只有 8G 内存必须对 Ollama 容器进行硬性的资源限制防止 OOM内存溢出死机。bash# 1. 创建自定义网络方便后续容器内部通信 docker network create ai-net # 2. 启动 Ollama 容器限制 4G 内存2.5 核 CPU docker run -d \ --name ollama \ --restart always \ --network ai-net \ -p 11434:11434 \ -v /data/ollama:/root/.ollama \ --memory4g \ --cpus2.5 \ ollama/ollama:latest # 3. 拉取轻量级模型 Qwen2:1.5b docker exec -it ollama ollama run qwen2:1.5b测试确认模型可用后输入/bye退出交互界面。️ 阶段三部署 Dify RAG 平台排雷重灾区Dify 官方提供了一键部署脚本但由于国内外网络差异这是踩坑最多的地方。bash# 1. 使用国内镜像源克隆代码 git clone https://gitcode.com/GitHub_Trending/di/dify.git cd dify/docker # 2. 复制环境变量文件 cp .env.example .env # 3. 修改默认端口为宿主机的 Nginx 让路 sed -i s/EXPOSE_NGINX_PORT80/EXPOSE_NGINX_PORT8080/ .env 踩坑记录 2Weaviate 向量库拉取失败默认配置会拉取 Weaviate 向量库但cr.weaviate.io域名在国内常被阻断connection refused。解决改用轻量且容易拉取的Qdrant。bash# 修改向量库类型 sed -i s/^VECTOR_STORE.*/VECTOR_STOREqdrant/ .env # 启动时明确指定 qdrant profile docker compose --profile qdrant up -d 踩坑记录 3Dify-API 镜像拉取极慢/卡死在docker compose进度卡在70/71时不要死等。解决按CtrlC中断Docker 会保存已下载的层。再次执行docker compose --profile qdrant up -d即可断点续传。或者直接新开一个终端执行docker pull langgenius/dify-api:1.17.1单兵突破下完后再次up。 阶段四Nginx 反向代理与 SSE 流式输出优化由于 Dify 容器映射到宿主机的 8080 端口我们需要用 Nginx 做代理并解决大模型输出“卡顿”的问题。bashvi /etc/nginx/conf.d/dify.conf写入以下配置注意替换server_name为你的虚拟机 IPnginxserver { listen 80; server_name 192.168.127.140; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; # --- 核心优化解决大模型打字机效果SSE被缓冲阻断的问题 --- proxy_http_version 1.1; proxy_set_header Connection ; proxy_buffering off; # 关闭缓冲 proxy_cache off; proxy_read_timeout 600s; # 超时拉长 } } 踩坑记录 4访问 IP 却看到红帽测试页执行ss -tulnp | grep :80发现 Nginx 已经在监听。出现测试页是因为 Nginx 的默认server块抢占了请求。解决编辑/etc/nginx/nginx.conf将默认的server { listen 80 default_server; ... }整段注释掉然后重载nginx -t systemctl reload nginx。 阶段五接口联调与终极排雷当所有容器启动后浏览器访问http://192.168.127.140本以为大功告成结果迎来了最折磨的连环报错。 踩坑记录 5React error #441前端白屏/渲染错误页面提示“渲染此组件时发生了意外错误”。通过 F12 查看控制台是 Dify 1.17.1 版本的一个已知 Bug。解决不要用hotfix标签Docker 无法解析。直接执行docker compose pull更新镜像或升级到更新的稳定版。 踩坑记录 6502 Bad Gateway 与db_postgresDNS 解析失败前端一直报system-features 502查看api容器日志报错could not translate host name db_postgres to address。说明 API 找不到数据库容器。排查过程检查docker-compose.yaml发现数据库服务名为db_postgres。但检查.env文件发现DB_HOST配置错误或者旧版本的.env里写的是DB_HOSTdb。解决保持docker-compose.yaml默认不变严格在.env中配置DB_HOSTdb_postgres然后执行强制重建docker compose up -d --force-recreate db_postgres api 踩坑记录 7API 一直显示(unhealthy)这个状态骗了人很久。查看日志发现Database migration successful!Listening at: http://0.0.0.0:5001真相在 8G 内存的机器上Dify 容器极多健康检查脚本因 CPU 繁忙偶尔超时导致误报unhealthy。其实后端早已就绪。解决直接无视刷新浏览器即可访问。 阶段六见证奇迹注册管理员账号并登录 Dify。右上角设置 - 模型供应商 -Ollama基础 URLhttp://192.168.127.140:11434(填宿主机 IP 最稳)模型名称qwen2:1.5b创建知识库上传一份 PDF 文档。创建聊天助手关联知识库开始提问。最终效果看着大模型一个字一个字地流式输出得益于 Nginx 的proxy_buffering off并且精准回答基于文档的内容那一刻之前所有的排雷都是值得的 项目总结与简历素材沉淀通过这次实战我不仅跑通了一个 RAG 平台更在简历上积累了极具分量的经验容器编排与故障排查熟练掌握了 Docker Compose 多容器联动能通过查看日志logs定位并解决网络阻断、DNS 解析、数据卷冲突等真实生产问题。流式传输原理深刻理解了 Nginx 缓冲机制对 SSEServer-Sent Events的破坏并掌握了通过调整proxy_buffering等参数优化大模型打字机体验的技术。资源隔离通过--memory和--cpus对 AI 推理引擎进行硬限制保障了宿主机的稳定性。
阅读完成 · 觉得有帮助？
 性能瓶颈)
