AI摘要：最小 Compose 我先写了一个最小版本：

启动：

第一个坑：容器里的 localhost 不是宿主机 Ollama 跑在宿主机时，WebUI 容器里访问 127.1ms.run/open-webui/open-webui:main容器是否在跑docker psgrep open-webui日志是否异常docker logs -f open-webuiOllama 是否可访问curl http://127.团队内网 AI 入口要长期用，Compose 文件、数据卷和升级路径要比第一次启动更重要。

我这次想在测试机上放一个 Open WebUI，给团队内部连 Ollama 用。镜像本身不复杂，官方主镜像是 ghcr.io/open-webui/open-webui:main，但真正排查时发现问题一般分三层：镜像拉取、容器网络、数据卷。

先把镜像层单独过掉

GHCR 拉取不稳定时，先不要急着写 compose。单独拉镜像：

镜像层先过，后面再看 WebUI 和 Ollama。否则 docker compose up 里所有问题都会混在一起。

最小 Compose

我先写了一个最小版本：

启动：

第一个坑：容器里的 localhost 不是宿主机

Ollama 跑在宿主机时，WebUI 容器里访问 127.0.0.1:11434，访问到的是容器自己。

所以这里用：

如果 Linux 上这个地址不可用，可以考虑：

或者直接把 Ollama 也放进同一个 compose 网络，让 Open WebUI 访问 http://ollama:11434。

第二个坑：数据卷必须提前想好

Open WebUI 的数据路径是：

所以 compose 里要有：

没有这个卷，重建容器后配置可能丢。自托管服务最烦的不是第一次启动，而是升级后发现数据没按预期保留。

第三个坑：端口和安全组

容器启动不代表外部能访问。

如果是云服务器，还要看安全组有没有放开 3000。如果走反向代理，再看 Nginx upstream 指向的是宿主机端口还是容器网络。

排查表

结论

Open WebUI 用 Docker 部署并不难，难的是把“镜像、端口、Ollama 地址、数据卷”这几层分开排。团队内网 AI 入口要长期用，Compose 文件、数据卷和升级路径要比第一次启动更重要。