1Panel可视化部署Open WebUI：接入Ollama与OpenAI兼容API实战

最近大模型本地化部署非常热，但很多朋友卡在第一步：Open WebUI 这个漂亮的聊天天花板界面，到底怎么才能跑起来？网上教程大多让你敲一堆 docker 命令，小白看着就头皮发麻。我自己折腾过几台服务器，踩过不少坑之后发现，用 1Panel 这个可视化运维面板来部署 Open WebUI，基本上就是把复杂操作变成了点鼠标，你要是懂点网页浏览器的操作，就能把大模型接入这件事跑通。

这篇基础篇，我会完整走一遍用 1Panel 部署 Open WebUI 的流程，并讲清楚怎么接入两类最常用的模型来源：本地 Ollama 模型，以及各家大模型平台提供的 OpenAI 兼容 API。你会搞明白 1Panel 在中间到底扮演了什么角色、为什么这么部署最省心、每一步操作背后的逻辑是什么。适合零基础新手，也适合已经在用 Docker 但想提升效率的老手，照着操作基本不会翻车。

1. 为什么是 1Panel + Open WebUI 这个组合

先说 Open WebUI 是什么。它是一个开源的、自托管的 Web 聊天界面，长得像主流商用聊天机器人那样，支持多用户、对话历史、联网搜索、知识库等高级功能。但它本身不提供模型能力，它只是个“壳”，需要你给它接上“大脑”——也就是大模型。这个“大脑”可以是你自己电脑上跑的本地模型，也可以是云端厂商提供的 API。

问题就出在“壳”和“大脑”之间的连接上。直接命令行部署 Open WebUI 不算特别难，但意味着你得处理 Docker 安装、镜像拉取、容器启动参数、端口映射、数据卷挂载、日志排错这一整套东西。对大多数非运维出身的朋友来说，光是理解docker run那一长串参数就得劝退。

1Panel 解决的就是这个痛点。它是一个开源的 Linux 服务器运维管理面板，把 Docker 容器、镜像、网络、存储、防火墙、网站、数据库这些底层资源，全部统一成图形界面里的可视化管理。你可以把它理解成给服务器装了一个“可视化遥控器”，点一下按钮就能完成过去需要在终端里敲几行命令的事情。

两者组合起来的优势很明确：

• Open WebUI 提供模型交互界面，1Panel 负责底层运行环境，分工清楚。
• 1Panel 自带应用商店，部分环境下可以直接安装 Open WebUI，省去手动写配置文件。
• 容器启停、日志查看、资源监控都在一个面板里，排查问题效率高得多。
• 1Panel 的备份功能可以把你整个 Open WebUI 数据目录打包，换服务器迁移非常省事。

我用 1Panel 之前，也试过纯命令行部署。说句实话，命令敲完确实能跑，但过了一段时间想改个端口、想看看日志、想清理旧容器，脑袋里还得回忆当初那串命令具体是啥。后来换到 1Panel，这些操作全部变成可视化按钮，整个人的心智负担小了很多，也敢在服务器上折腾更多东西了。

2. 部署前的准备工作：服务器、系统与网络

这一步非常重要，但往往被教程忽略。准备工作没做好，后面部署出了问题很难判断到底是哪里的锅。

2.1 服务器配置怎么选

先看你的用途。只是自己用、偶尔聊聊天、跑一个 7B 参数的本地模型，2 核 4G 内存的服务器勉强能跑，但别抱太大期望，模型推理速度会明显偏慢，多开几个对话可能内存就不够用了。我自己的经验是，想跑 7B 模型比较流畅，至少 4 核 8G 起步；你要是想跑 14B 以上的模型，那建议直接上 8 核 16G 甚至更高。

有个很容易被忽略的点：Open WebUI 本身启动也吃资源，再加上 Ollama 常驻内存，你的服务器内存会比想象中紧张。建议在部署之前先看一下服务器的 CPU 和内存情况，用free -h和nproc命令就能快速查个大概。

2.2 操作系统与系统环境

1Panel 官方支持的主流 Linux 发行版都能用，我这边实测过 Debian 12 和 Ubuntu 22.04，都没有什么问题。CentOS 7 系列我建议谨慎，因为它的内核对 Docker 新特性的支持不太好，而且官方源维护已经接近尾声，新手容易在依赖安装上卡住。

在开始之前，最好确认你的系统是干净的，没有装过旧版 Docker 或其它面板。之前看到有人服务器上已经装了一个宝塔面板，再装 1Panel，结果 Docker 配置互相打架，折腾了半宿。如果你有这种情况，建议先把旧环境梳理干净，或者直接换一台全新服务器，省去不必要的麻烦。

2.3 端口规划与防火墙

Open WebUI 默认容器端口是 8080，1Panel 面板本身默认端口是 8090。你还需要给 Ollama 留一个端口，默认是 11434。

我的习惯是提前规划好端口映射，比如把 Open WebUI 映射到服务器的 3000 端口，访问地址就是http://服务器IP:3000。这样和 1Panel 的 8090 端口区分开，避免混淆。如果你服务器上有防火墙（包括云服务商的安全组规则），记得提前放行这些端口，否则后面打开浏览器会一直超时。这个坑我踩过好几次，每次都是排查了半天才发现是安全组没放行。

3. 第一步：安装 1Panel 并完成初始化

这里直接讲我验证过最快的一条路径。

3.1 安装命令

1Panel 官方提供了一条安装命令，你在终端里执行即可。因为涉及服务器管理，安装过程需要 root 权限。如果当前登录用户不是 root，建议先执行sudo -i切换，这样后面一系列操作都省心。

安装过程中会自动检测系统基础环境，并安装 Docker 和 Docker Compose。这一点很关键，你不需要自己提前装 Docker，1Panel 会一并处理了。安装完成后，终端会输出面板的访问地址、用户名和密码，一定要记下来，或者截图保存。我当初就是没保存好初始密码，后来花了不少时间重置，得不偿失。

3.2 进入面板后的初始化配置

用浏览器打开面板地址，首次登录会让你设置新的管理员密码。这里我建议把密码设置得复杂一点，顺便把两步验证开了，因为 1Panel 管理着服务器上的 Docker 环境，权限很高，如果账号泄露，后果不仅仅是面板本身被控制，所有容器数据都可能暴露。

登录进面板之后，先用几分钟把下面几个基础设置做了：

• 修改面板默认端口。8090 是默认端口，建议改成其它不常用的端口，安全性会好一些。
• 配置 Docker 镜像加速。国内访问 Docker Hub 官方仓库有时很不稳定，拉取镜像容易一直转圈。1Panel 在「设置 - 镜像加速」里面提供了多个加速地址选项，勾选保存之后，后续拉取镜像速度会明显改善。这一步强烈建议做，不然后面拉 Open WebUI 镜像可能会卡到让你怀疑服务器是不是死机了。
• 开启面板的自动备份。1Panel 把备份功能做得很完善，你可以把面板配置甚至整个容器数据定期备份到本地或者远程存储。我建议打开，几分钟的设置换来的安心感非常值。

3.3 理解 1Panel 在部署中扮演的角色

安装完成之后，你会在左侧看到「容器」「镜像」「编排」这些菜单。实际上，1Panel 就是把 Docker 的底层能力做了封装。比如「容器」对应docker ps，「镜像」对应docker images，「编排」对应docker compose。有了这个概念，后续不管是点按钮还是看文档，心里都有个底，不会觉得云里雾里。

4. 第二步：部署 Open WebUI

部署 Open WebUI 有两条路线，我给你都讲一遍，你根据自己的实际情况选一条就行。

4.1 方式一：应用商店一键安装

1Panel 自带应用商店，在「应用商店」里搜索 Open WebUI，如果能看到，点安装就会进入可视化配置界面。你需要设置一个端口，比如 3000，然后确认挂载目录，1Panel 默认会帮你创建好数据目录，安装完成后点「详情 - 端口」就能看到访问地址。

这条路是最省事的，但有一个前提条件：你使用的 1Panel 版本应用商店里确实收录了这个应用。如果搜索不到，不要着急，用方式二同样不复杂。

4.2 方式二：Docker Compose 方式安装（通用方案）

我更推荐你学习一下 Compose 方式，因为它不依赖应用商店是否有收录，只要服务器能拉取镜像，随时都能装。而且 Compose 文件本身就相当于一键部署脚本，换机器、迁移环境的时候非常方便。

进入 1Panel 的「编排」，新建一个编排，把下面的 Compose 内容粘贴进去：

version: '3.8' services: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui ports: - "3000:8080" volumes: - /opt/open-webui:/app/backend/data extra_hosts: - "host.docker.internal:host-gateway" restart: always

斜杠的注释我给你逐行拆一下：

• image：镜像来源，ghcr.io/open-webui/open-webui是 Open WebUI 的官方镜像仓库。注意它不在 docker hub 上，这也是为什么前面说要配好镜像加速。
• ports：把宿主机的 3000 端口映射到容器的 8080 端口。这一段是按宿主机端口:容器端口的顺序写的。
• volumes：数据卷挂载。/opt/open-webui是宿主机上的目录，它会对应到容器内 Open WebUI 的数据目录。这意味着你的用户信息、聊天记录都保存在宿主机上，就算容器删了重来，数据也还在。
• extra_hosts：这行是为了让容器能够访问宿主机上运行的其它服务。比如你宿主机上跑了 Ollama，容器里想让host.docker.internal指向宿主机，就必须加这段配置。我在部署时如果不加这一行，Open WebUI 就找不到同机器上的 Ollama，折腾了将近一个小时才查到这个原因。
• restart: always：容器崩了或者服务器重启了，Docker 会自动把容器拉起来，省得你手动操作。

点「创建并启动」之后，1Panel 会自动拉取镜像并创建容器。第一次拉镜像可能要几分钟，取决于网络状况。你可以在「容器 - 容器」里看到 open-webui 这个容器，状态是 Running 就说明启动成功了。

4.3 浏览器访问验证

打开浏览器访问http://服务器IP:3000，进入 Open WebUI 首页。首次打开会要求你注册一个管理员账号，这个账号就是该实例的管理员，一定要记好邮箱和密码。

到这里，Open WebUI 本身已经部署完成了。但这个时候它是“空壳”，你还没有接入任何模型，聊天页面打开什么都用不了。别急，下一步就是很多人最容易卡住的部分——模型接入。

5. 第三步：全模型接入实战

Open WebUI 支持接入的模型来源非常多，基础篇我把最主流的两种讲透，足够你日常使用了。

5.1 接入本地 Ollama 模型

Ollama 是目前在本地跑大模型最主流的工具，它提供简单的命令行接口，支持 Llama 3、Qwen 2.5、DeepSeek 在内的众多开源模型。Open WebUI 对 Ollama 的集成度最高，几乎是开箱即用。

5.1.1 部署 Ollama

在 1Panel 的应用商店里搜索 Ollama，如果有直接安装即可。如果没有，你可以在终端里用官方命令安装，或者再写一个 Compose 编排。和部署 Open WebUI 类似，Ollama 的 Compose 内容大致如下：

version: '3.8' services: ollama: image: ollama/ollama:latest container_name: ollama ports: - "11434:11434" volumes: - /opt/ollama:/root/.ollama restart: always

这里面 11434 是 Ollama 默认的 API 端口，Open WebUI 就是通过这个端口和 Ollama 通信的。数据卷一定要挂载，不然你拉下来的模型文件全在容器内部，容器一删模型就没了，重新下载非常痛苦。

5.1.2 下载一个本地模型

部署好 Ollama 之后，进入 1Panel 的「终端」，或者你直接用自己的 SSH 工具连到服务器，执行：

ollama pull qwen2.5:7b

这行命令的意思是不管你 Ollama 是容器部署还是独立部署，都需要在宿主机上执行，让 Ollama 下载 Qwen2.5 的 7B 参数版本模型。模型文件一般好几个 GB，具体大小视模型规格而定，下载时间取决于网络速度。你也可以换成其它模型，比如llama3:8b、deepseek-r1:7b，格式都是模型名:参数规模。

下载期间你会在终端看到进度条，别中断进程，等它显示 success 就完成了。模型下载后在「容器 - 编排」里查看 Ollama 容器的日志，如果正常，会看到类似listening on [::]:11434的日志。

5.1.3 在 Open WebUI 中连接 Ollama

登录 Open WebUI，点击右上角头像，进入「管理面板 - 设置 - 外部连接 - Ollama API 连接」。

这里会要求填一个 Ollama 的 API 地址。我填的是：

http://host.docker.internal:11434

为什么是这样？还记得刚才在 Compose 里加的extra_hosts配置吗？host.docker.internal这个域名在容器里会被解析到宿主机，所以 Open WebUI 容器可以通过它访问到你同一个服务器上的 Ollama。如果你没加extra_hosts，这里就得填你的服务器内网 IP，比如http://192.168.1.100:11434。

填好保存之后，在 Open WebUI 里刷新一下页面的模型列表，如果一切顺利，刚才下载的qwen2.5:7b就会出现在模型选择下拉框里。选上它，直接开始对话，就说明本地模型接入了。

5.2 接入 OpenAI 兼容 API

除了本地模型，很多人也想用国内外的各家大模型平台提供的 API 服务。这些平台绝大多数都提供了 OpenAI 兼容接口，意味着 Open WebUI 只要填一个 Base URL 和一个 API Key，就能无缝接入。

先普及一个基本概念：

• Base URL：API 服务的访问地址，一般是一个域名加上/v1。
• API Key：平台给你发的专属密钥，相当于你的访问凭证。

不同平台的 Base URL 不同，你需要以平台开发者文档为准。例如某主流通用接口平台一般是https://api.openai.com/v1，国内一些聚合平台则是https://api.xxx.cn/v1格式，具体需要看官方文档。

在 Open WebUI 管理后台找到「设置 - 外部连接 - OpenAI API 连接」：

• 填入 Base URL。
• 填入 API Key。
• 点击「保存」之后，Open WebUI 会自动拉取该接口下可用的模型列表。我实测过，有的平台会把一批模型列出来，有的平台则需要你手动添加。如果需要手动添加，就把模型 ID 填进去，比如gpt-4o-mini、glm-4-flash这类字符串。
• 保存后模型列表里就会出现对应模型名称。

需要留意的是，各个厂商的模型命名规则差异很大，有些是纯字母加数字，有些还带日期后缀。建议先在平台控制台确认你要用的模型 ID 是不是准确，免得填了之后对话时报错。

5.3 本地模型和 API 模型混用的协作体验

接入两种来源之后，Open WebUI 的模型下拉框里会同时出现本地模型和云端模型。你可以随时切换：本地模型响应速度快、免费、数据不出服务器，但模型能力受限于你机器性能；云端 API 模型能力更强，但每次对话都要按量付费，且数据会经过第三方。

我个人的用法是：日常用本地 Qwen 2.5 处理一些隐私性比较高的文本，比如个人笔记整理；需要更强推理能力的时候，再切到云端 API 模型。混用模式不仅节省成本，还能保证对话体验，这个灵活性是 Open WebUI 非常好用的一个特性。

5.4 如果希望接入更多平台

国内很多平台都兼容 OpenAI 接口，你可以在外部连接里新建多个连接，给每个连接起一个容易识别的名称，比如「厂商A」「厂商B」。Open WebUI 支持同时保存多套 OpenAI 兼容配置，并不冲突。不过基础篇我不建议过度贪多，先接入一两个，把基础流程跑熟练，后面再加不迟。

6. 常见问题与排查技巧实录

下面这些问题都是我实际部署过程中亲测遇到的，整理成速查表，你可以直接对着排查。

下面挑几个重点问题展开讲讲。

6.1 端口访问不通时怎么快速定位

这是新手最头疼的问题。我的排查顺序固定是：先在服务器本地执行curl -I http://localhost:3000，如果能返回内容，说明服务本身没毛病，问题出在防火墙或安全组；如果连接被拒绝，说明容器可能没有起来，或端口映射不对，去 1Panel 容器详情页看日志最直接。

云服务器的安全组规则和服务器内部防火墙是两回事，很多新手只查了服务器里的防火墙，忽略了控制台上的安全组。我也干过这种事，后来形成一个习惯：只要是端口访问不通，先查安全组，再查内部防火墙。

6.2 镜像拉取失败的对策

Open WebUI 镜像仓库是在 ghcr.io 上，国内直连经常受限。如果你遇到拉取超时，建议先试镜像加速（在 1Panel 设置-镜像加速中），如果你所在网络环境仍然无法正常拉取，还有一个办法：在终端里手动使用docker pull ghcr.io/open-webui/open-webui:main重试几次，有时网络波动导致第一次失败，但重试往往能成功。实在不行，就只能找一台与 ghcr.io 连通更好的服务器来拉取并导出了镜像包，再传到目标服务器导入。

这属于基础篇不太推荐的方案，但如果你的网络环境特殊，可以作为兜底手段。

6.3 Open WebUI 找不到 Ollama 模型

前提是 Ollama 已经下载好了模型，并且 API 端口正常监听。打开 1Panel 的「容器」，分别查看 ollama 和 open-webui 这两个容器是否都在运行。如果都在运行，再去 Open WebUI 的设置页面核对 Ollama API 地址。

有个容易忽略的点：如果你 Ollama 是通过 1Panel 应用商店安装的，部分版本会自动帮你做端口映射，但如果是通过纯容器方式运行，注意看端口有没有映射到宿主机。没有端口映射，宿主机上的 Open WebUI 容器自然访问不到它。

6.4 磁盘空间为什么很快满了

大模型动辄几个 GB，Open WebUI 的聊天记录也可能积累出大量数据。建议在 1Panel 面板里看下「主机 - 磁盘」，确认空间使用情况。还有一个进阶做法：在 Ollama 设置环境变量OLLAMA_KEEP_ALIVE=0，这样模型不用时就会立即释放内存，避免长期占用显存或内存资源，对低配置服务器非常友好。

7. 日常使用沉淀与后续扩展

到了这一步，整个部署链路已经跑通了：1Panel 管理底层，Open WebUI 提供聊天界面，Ollama 和云端 API 提供模型能力。你可以开始日常使用了，但还有几个值得养成的习惯和后续可做的事项，基础篇里一并说一下。

先说日常习惯。

第一，数据备份是个一定要做的事。1Panel 的「计划任务」功能可以定期把/opt/open-webui目录打包备份。我个人的频率是每天凌晨自动备份一次，保留最近 7 份。你想象一下，如果搭建了一个月之后聊天记录积累了很多重要内容，结果服务器数据盘故障，没有备份就等于全部清零，那种打击感是比较难受的。

第二，镜像和容器版本要适当关注。Open WebUI 项目迭代很快，几乎每周都有新版本发布。当你某天发现 Web 界面上有一些异常，或者无法打开时，可以先看一下 1Panel 容器详情里启动时间，拉起的镜像版本是什么，有时候问题在项目的新版本里已经修复了。升级方式也很简单，在 1Panel 编排里把镜像版本改成新的 tag，重建容器即可，数据因为挂载在宿主机目录不会丢失。

再说后续扩展。

基础篇你已经有了一套完整的本地对话系统。接下来如果你还有精力，这几个方向值得延伸：

• 加 HTTPS 域名访问：1Panel 自带网站功能，可以配置反向代理，再把域名解析过来，申请 SSL 证书，这样你就能用https://ai.yourdomain.com这种方式访问，比 IP 加端口的方式优雅得多，也适合分享给别人用。
• 多用户管理：Open WebUI 内置用户系统，你可以给家人或同事开账号，每个人拥有独立的对话记录和设置。在管理面板里可以设置用户权限，避免非管理员误删全局配置。
• 知识库功能：Open WebUI 支持把文档上传进来做向量检索，让模型基于你的私有文档回答问题。这个功能在管理面板里的「知识库」模块，接入需要配置嵌入模型。基础篇不展开，但你在界面里浏览一下就能看到入口。
• 观察资源使用：1Panel 面板首页默认就有 CPU、内存、网络流量的实时监控，你可以跑两个模型对话试试，观察资源占用情况，对理解大模型推理的资源消耗会有直观感受。

8. 写在最后的经验体会

我在实际使用中发现，如果你只接一个本地模型，整个系统的架构其实非常轻：一台云服务器、1Panel、Open WebUI、Ollama，四个组件就能组成一套完整的高质量对话服务，而且全部都是开源软件，没有额外授权费用。这套方案特别适合有隐私需求、想在私有环境里长期使用大模型的人。

还有一个小技巧分享给你：部署完成之后，别急着追求多模型全家桶，先把一个本地模型和一个 API 模型跑通，把对话、切换、数据备份这些都试一遍，熟悉之后再逐步增加。我见过不少人一上来就往 Ollama 里塞五六个模型，结果磁盘满了，也不知道每个模型之间的区别，反而体验很差。

本文整体是一个基础篇的落地记录，后续如果你有域名和 HTTPS 化、知识库接入、团队多人使用这些需求，可以顺着这个基础继续延伸。我踩过的那些坑，大多数是端口不通、镜像拉取失败、host.docker.internal 配置漏掉导致的，你在部署时提前避开这些雷点，整个流程用不了吃一顿饭的时间就能跑完。