1. 为什么本地 Ollama 明明跑着Open-WebUI 却连不上很多人第一次在 Linux 上折腾 Open-WebUI Docker 部署连接本地 Ollama都会卡在同一个地方浏览器能打开 Open-WebUI 的界面模型列表却空空如也或者点开设置里的连接状态一直转圈。Ollama 在宿主机上ollama run qwen2.5跑得好好的curl http://localhost:11434/api/tags也能返回 JSON可一旦把 Open-WebUI 塞进容器两边就像隔了一堵墙。这堵墙的本质是网络命名空间。Docker 容器默认有自己的网络栈容器里的localhost指向容器自己而不是宿主机。Ollama 默认又只监听127.0.0.1:11434等于只对宿主机本机开放。容器从自己的localhost去敲 11434自然敲了个寂寞。理解这一点后面所有配置都是在解决「容器怎么找到宿主机上的 Ollama」这一个问题。这篇面向的是本地大模型自托管场景你有一台 Linux 机器物理机或云主机都行Ollama 直接装在系统里而非 Docker 里现在想用 Open-WebUI 给它套一个顺手的 Web 界面。我会把 docker-compose 配置、Ollama 监听地址、端口映射、容器内连通性验证这几件事一次讲透并给出三种网络方案的取舍最后附上真实会撞到的报错和排查路径。整套流程实测下来从零到模型列表正常拉取大概十分钟。需要说明的是Open-WebUI 本身只是前端壳子它不生产模型只负责把请求转发给后端推理服务。所以部署的核心从来不是 Open-WebUI 装没装上而是它和后端之间的那条链路通不通。把链路打通界面自然就活了。2. 部署前把 Ollama 和 Docker 环境对齐动手之前先确认两件事Ollama 装在哪、Docker 能不能正常拉镜像。这两步没对齐后面全是玄学问题。先看 Ollama 的状态和监听地址。执行systemctl status ollama ss -tlnp | grep 11434如果输出是LISTEN 0 4096 127.0.0.1:11434说明 Ollama 只监听本地回环。这时候容器无论怎么配都够不着它必须先放开监听。用 systemd 的 override 方式改别直接动原始 unit 文件sudo systemctl edit ollama.service在打开的编辑器里写入[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434保存后重载并重启sudo systemctl daemon-reload sudo systemctl restart ollama ss -tlnp | grep 11434这次应该看到0.0.0.0:11434。注意放开到0.0.0.0意味着同网段其他机器也能访问你的 Ollama如果这台机器有公网 IP记得用防火墙限制 11434 只对可信来源开放别裸奔。接着确认 Docker 可用docker version docker compose versiondocker compose带空格V2 插件形式现在是主流本文配置都用它。如果只有老的docker-compose带横杠命令换成对应写法即可YAML 内容不变。再确认 Ollama 里至少有一个模型否则 Open-WebUI 连上了也是空列表ollama list没有的话先拉一个比如ollama pull qwen2.5:7b。模型文件不小提前拉好别等界面配好了才发现没模型可聊。最后记下宿主机的内网 IP方案三会用到hostname -I | awk {print $1}假设输出192.168.1.100后面配置里按实际替换。环境对齐后我们进入正式的部署环节。3. 三种网络方案与可复制 docker-compose 配置Open-WebUI 连本地 Ollama本质就三种思路让容器共享宿主机网络、让容器通过特殊域名找到宿主机、让容器直接走宿主机内网 IP。三种都能用适用场景不同。方案一host 网络模式。容器直接复用宿主机网络命名空间容器里的localhost就是宿主机的localhostOllama 哪怕只监听127.0.0.1也能被访问到。这是最省心的方案缺点是端口直接暴露在宿主机上Open-WebUI 监听 8080不是 3000。适合开发调试和单机自用。方案二端口映射 host.docker.internal。容器用自己的网络通过--add-host把host.docker.internal解析到宿主机网关再用环境变量告诉 Open-WebUI 去哪找 Ollama。端口映射干净适合想控制暴露端口的场景。方案三端口映射 宿主机内网 IP。最直白直接把宿主机 IP 写进OLLAMA_BASE_URL。缺点是宿主机 IP 变了配置就得改适合 IP 固定的内网环境。下面给出 docker-compose 版本比一长串docker run好维护。新建目录并写入docker-compose.ymlservices: open-webui: image: ghcr.io/open-webui/open-webui:main container_name: open-webui ports: - 3000:8080 extra_hosts: - host.docker.internal:host-gateway environment: - OLLAMA_BASE_URLhttp://host.docker.internal:11434 - WEBUI_SECRET_KEYchange-this-to-a-random-string volumes: - open-webui:/app/backend/data restart: unless-stopped volumes: open-webui:这是方案二的配置。几个关键点extra_hosts里的host-gateway是 Docker 提供的特殊值会自动解析成宿主机网关地址比手写 IP 稳OLLAMA_BASE_URL必须指向host.docker.internal:11434不能写localhostWEBUI_SECRET_KEY用于会话加密生产环境务必换成随机串别用默认值。如果你选方案一host 网络把ports和extra_hosts去掉加一行network_mode: host同时删掉OLLAMA_BASE_URLhost 模式下容器直接访问localhost:11434即可Open-WebUI 默认就会找它。此时访问端口是 8080。如果你选方案三把extra_hosts去掉OLLAMA_BASE_URL改成http://192.168.1.100:11434换成你的实际 IP。启动docker compose up -d docker compose logs -f open-webui日志里看到服务启动完成的字样后浏览器访问http://localhost:3000方案二/三或http://localhost:8080方案一。首次进入会让你注册管理员账号这个账号只存在本地数据卷里随便设但要记住。配置写完后别急着庆祝端口和地址对不上是新手最常见的坑下一节专门验证链路。4. 验证请求链路与模型列表拉取结果界面能打开不代表链路通了。按从外到内的顺序验证哪一层断了立刻能定位。第一层宿主机上 Ollama 是否可访问curl http://localhost:11434/api/tags应返回包含模型列表的 JSON形如{models:[{name:qwen2.5:7b,...}]}。如果这里就失败回去检查 Ollama 服务状态和监听地址。第二层容器内能否访问到 Ollama。这一步是排查的核心很多人跳过它直接看界面结果无从下手docker exec -it open-webui sh -c curl http://host.docker.internal:11434/api/tags方案二下这条命令应返回同样的模型 JSON。如果报Could not resolve host或连接被拒说明extra_hosts没生效或 Ollama 监听没放开。方案一的话把地址换成http://localhost:11434/api/tags方案三换成宿主机 IP。第三层Open-WebUI 自身健康检查curl http://localhost:3000/health应返回{status:ok}。方案一则是 8080 端口。三层都通之后进 Web 界面右上角头像 → Settings → ConnectionsOllama 那一栏的地址应显示为你在环境变量里配的值状态为绿色。回到主界面左上角模型下拉框里应该能看到ollama list里的所有模型。选一个发条消息能正常流式返回就说明整条链路彻底打通。如果模型列表是空的但连接状态是绿的多半是 Ollama 里确实没模型或者模型名带特殊字符导致解析异常回宿主机ollama list确认一下。实测下来方案二在大多数 Linux 发行版上最稳host-gateway这个机制省去了手算网关的麻烦。方案一虽然简单但端口冲突时排查起来反而绕因为你看不到映射关系。5. 常见报错对照与排查路径部署过程中会撞到的报错就那么几个逐个对照处理。报错一docker: Error response from daemon: Conflict. The container name /open-webui is already in use。同名容器已存在。先删旧的再起新的docker rm -f open-webui docker compose up -d数据在命名卷open-webui里删容器不影响别手滑去docker volume rm。报错二容器内curl报Could not resolve host: host.docker.internal。extra_hosts没写或写错。检查 compose 文件里extra_hosts的缩进YAML 对缩进敏感。确认后docker compose down docker compose up -d重建容器光 restart 不会重新应用extra_hosts。报错三local proxy failed或连接超时。这是 Open-WebUI 转发请求到 Ollama 失败。先按上一节第二层命令在容器内测连通性。如果容器内能通但界面报这个错检查OLLAMA_BASE_URL是否带了多余斜杠或路径正确写法就是http://host.docker.internal:11434结尾不要加/api。报错四401 Unauthorized。如果你在 Ollama 前面挂了鉴权或者 Open-WebUI 的WEBUI_SECRET_KEY变更导致旧会话失效。前者需要在OLLAMA_BASE_URL里带上凭据或改用无鉴权内网访问后者清掉浏览器缓存重新登录即可。报错五日志里出现reading choices相关解析错误。通常是后端返回的不是标准 OpenAI 格式或者模型名对不上。确认 Open-WebUI 里选的模型名和ollama list完全一致大小写和标签都不能差。报错六500 Internal Error。信息太少按顺序查docker logs open-webui --tail 100看堆栈docker ps -a | grep open-webui确认容器没反复重启curl http://localhost:11434/api/tags确认后端活着再进容器测网络。四步走完基本能定位。排查时有个习惯值得养成每改一次配置用docker compose down docker compose up -d完整重建而不是restart。环境变量和extra_hosts这类配置只在创建容器时生效restart 不会重新读取。6. 把本地模型接进统一入口的延伸思路本地 Ollama 跑通之后你手里就有了一套完全自托管、数据不出内网的对话环境。Open-WebUI 负责界面和多用户管理Ollama 负责推理两者通过一条清晰的网络链路连接。这套组合适合对数据隐私敏感、又想有接近云端体验的场景。不过本地部署也有它的边界模型能力受限于你的显卡和内存想用更大的模型就得加硬件多机协作、跨设备调用时每台机器都要单独配一遍 Ollama 和 Open-WebUI维护成本会上去。这时候不少人会考虑把本地模型和云端 API 放在同一个入口里管理让 Open-WebUI 既能连本地 Ollama也能连远程的兼容接口按任务轻重分流。如果你有这类需求可以在 Open-WebUI 的 Connections 里再加一个 OpenAI 兼容的连接项把 Base URL 指向远程服务、填上对应的 Key 和 Model ID 即可。TaoToken 提供的就是这种 OpenAI 兼容的接入方式Base URL 用https://taotoken.net/api在 API Keys 页面 生成 Key 后填进 Open-WebUI就能和本地 Ollama 并存界面上切换模型即可。想先看看有哪些模型可用可以直接在 模型对话 里试跑接入细节参考 接入文档。如果长期跑编码类任务、需要更稳定的额度Coding Plan 是更合适的选择。回到本地部署本身最后留一个实用技巧把docker-compose.yml和 Ollama 的 systemd override 一起放进版本管理换机器时直接拉下来改个 IP 就能复现整套环境。数据卷记得定期备份docker run --rm -v open-webui:/data -v $(pwd):/backup alpine tar czf /backup/open-webui-backup.tar.gz -C /data .一条命令就能打包比重新注册账号省事得多。