Category: OpenWebUI

本文记录一次在自托管环境中使用 OpenWebUI + Ollama 的实际配置与排查过程，重点包括： 全文基于实践总结，不涉及任何具体主机名、端口、路径等敏感信息。 一、模型存在 ≠ 用户可用：OpenWebUI 的权限设计 在 OpenWebUI 中，即使已经完成以下操作： 普通用户依然可能看到： 模型列表为空 这并不是部署错误，而是 OpenWebUI 的权限模型设计所致。 1. 两个容易混淆的概念 OpenWebUI 将模型拆分为两个维度： 维度 含义 Enable 模型在系统中可用 Access / Visibility 哪些用户可以看到并使用 启用模型 并不等于 普通用户可见。 二、正确的模型授权方式（全局放行） 推荐做法是：由管理员统一放行模型给所有用户。 操作路径（管理员账号） 完成后，模型将正常出现在普通用户的模型列表中。 三、为什么会这样设计？ 这种设计对自托管场景其实是合理的： 对于长期运行的私有实例，这是一个偏“企业级”的设计思路。 四、OpenWebUI 是否支持语音对话？ 简短结论 支持，但不是一键式语音助手。 OpenWebUI 的定位是： UI + 编排层，而不是语音模型本体。 五、语音能力的模块化拆分 …

本文记录一次在 Docker + Nginx 反向代理 场景下，部署 Open WebUI + Ollama 时，遇到 WebSocket 400 与前端解析异常的问题，以及完整的定位与修复过程。本文采用工程记录风格，省略与具体环境强绑定的细节（路径、域名、IP 已脱敏），可作为同类问题的参考模板。 一、问题现象 部署完成后，表现为： 直观感受是： 二、初步排查：确认不是服务本身的问题 1. 确认容器状态 2. 直接访问容器端口 通过本机或内网直接访问 WebUI 暴露端口： 说明： 问题不在 Open WebUI 或 Ollama 本身 三、确认问题边界：反代之后才出问题 当通过 Nginx 反代访问时： 结论很明确： 问题发生在 Nginx → Open WebUI 的反向代理层 四、问题本质分析 1. Open WebUI 使用了什么通信机制？ 2. …

本文记录一次从 Ollama 后端模型服务 到 Open WebUI 前端界面 的完整搭建过程，重点放在 Docker Compose 架构、数据卷持久化、模型管理与常见误区。文中已对主机名、IP、端口等私人信息做统一脱敏处理。 一、目标与前提 目标 前提环境 二、关键概念澄清 在开始之前，先澄清几个容易混淆的点。 1️⃣ Ollama 版本 ≠ 模型大小 二者是完全不同的层级，不要混为一谈。 2️⃣ 7B 是什么 3️⃣ WebUI 与 Ollama 的关系 三、Docker Compose 结构设计 设计原则 四、最终 Docker Compose 配置（脱敏版） 五、启动流程 1️⃣ 启动服务 确认两个容器均为 Up 状态。 2️⃣ 下载模型（重点） 模型必须通过运行中的 Ollama 容器下载，否则会报错。 下载完成后验证： …

摘要 本文记录了一套可复制、低风险的 Open WebUI + Ollama 自托管方案，重点讨论二者是否应部署在同一个 Docker Compose 中、认证与管理员模型的设计，以及符合最小权限原则的日常使用方式。本文面向已有 Docker / 反向代理经验的读者，采用工程化视角，避免与具体路径、端口、域名等敏感信息绑定。 1. Open WebUI 的定位 Open WebUI 是为大语言模型交互设计的通用前端（Chat UI 层）： 其职责聚焦在用户交互、会话管理、权限控制与系统配置，而非模型训练或推理本身。 2. 与 Ollama 放在同一个 Compose 中是否合理 2.1 结论 在“单机一体化服务”的使用场景下，将 Open WebUI 与 Ollama 放在同一个 Docker Compose 文件中是高度合理的默认选择。 2.2 合理性依据 生命周期一致 安全边界清晰 运维成本低 故障域符合依赖关系 2.3 何时不建议放在一起 3. Open …