Open WebUI не видит Ollama: причины и решение

MAATRIX

Интерфейс открывается, форма чата на месте, а список моделей пуст — и в углу висит ошибка соединения. Причина почти никогда не в самом Open WebUI: он лишь фронтенд и честно сообщает, что не достучался до Ollama по прописанному адресу. Ниже — все причины, по которым Open WebUI не подключается к Ollama, и способ за пять команд понять, какая из них ваша.

Три разных «не видит» — и лечатся они по-разному

Первый шаг — не лезть в конфиги, а понять, какой симптом у вас.

Симптом A — явная ошибка соединения. В логе бэкенда (docker logs --tail 50 open-webui) лежит строка вида:

ERROR [open_webui.routers.ollama] Connection error: Cannot connect to host host.docker.internal:11434 ssl:default [Name or service not known]

Самое ценное — текст в квадратных скобках. Name or service not known: имя не резолвится, DNS контейнера его не знает. Connect call failed ('127.0.0.1', 11434): имя разрешилось, но TCP-соединение не установилось. Две разные болезни.

Симптом B — ошибки нет, а моделей нет. Список пуст, красных плашек не появляется: соединение установилось, а ответ пришёл пустой.

Симптом C — модели видны, но генерация падает. Это не связь: список приходит по тому же соединению. Ищите память и таймауты прокси — почему Open WebUI медленно отвечает разобрано отдельно. Дальше про A и B.

Диагностика: пять команд от хоста к контейнеру

Двигаемся слоями, на каждом шаге отсекая половину вариантов.

1. Жива ли Ollama на хосте. curl -s http://127.0.0.1:11434 должен вернуть ровно строку Ollama is running. Ответ curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused значит, что сервис не поднят — смотрите, почему Ollama не запускается.

2. На каком адресе она слушает.

ss -tlnp | grep 11434
LISTEN 0 4096 127.0.0.1:11434 0.0.0.0:* users:(("ollama",pid=1893,fd=3))

127.0.0.1:11434 — порт открыт только для самого хоста, ни один контейнер до него не дотянется. Нужен *:11434 или адрес шлюза Docker.

3. Есть ли вообще модели. Ответ {"models":[]} на curl -s http://127.0.0.1:11434/api/tags — соединение отличное, а показывать нечего: это симптом B.

4. Дотягивается ли до Ollama сам контейнер. Ключевая команда: она проверяет ровно тот путь, которым ходит Open WebUI.

docker exec -it open-webui curl -s -m 5 -o /dev/null -w '%{http_code} %{time_total}\n' http://host.docker.internal:11434/api/tags

Здоровый ответ — 200 0.004, четыре миллисекунды. Мгновенный 000 — соединение отвергнуто: адрес неверный или сервис не слушает. 000 ровно на пятой секунде (сработал -m 5) — пакет молча дропает фаервол. Разница между «отказ» и «тишина» экономит час.

5. Какой адрес Open WebUI использует на самом деле — не из compose, а из базы:

docker exec open-webui python3 -c "import sqlite3,json; c=sqlite3.connect('/app/backend/data/webui.db'); d=json.loads(c.execute('select data from config order by id desc limit 1').fetchone()[0]); print(json.dumps(d.get('ollama'), indent=2))"

Вывод {"base_urls": ["http://localhost:11434"], "enable": true} часто и есть ответ: в compose давно другое значение, а сервис ходит по старому.

Причина 1. localhost внутри контейнера — это не хост

Примерно две трети случаев. У контейнера свой сетевой неймспейс: 127.0.0.1 внутри него — это сам контейнер Open WebUI, где никакой Ollama нет. Отсюда Connect call failed ('127.0.0.1', 11434): соединение уходит в пустоту и мгновенно отбивается.

Имя host.docker.internal в Linux не существует само по себе, его надо создать: флагом --add-host=host.docker.internal:host-gateway в docker run или блоком extra_hosts: ["host.docker.internal:host-gateway"] в compose. Проверка:

docker exec open-webui getent hosts host.docker.internal
172.17.0.1      host.docker.internal

Пустой вывод — то самое Name or service not known. Добавьте extra_hosts и обязательно пересоздайте контейнер (docker compose up -d --force-recreate): /etc/hosts при простом рестарте не обновляется.

Вторая ловушка — адрес 172.17.0.1 из чужого мануала. Это шлюз дефолтной сети docker0, но compose создаёт для проекта свой бридж со своей подсетью:

docker network inspect openwebui_default --format '{{(index .IPAM.Config 0).Gateway}}'
172.18.0.1

При нескольких проектах будет 172.19.0.1 и дальше, а после docker compose down подсеть может смениться — поэтому host.docker.internal надёжнее. Вариант --network=host решает вопрос одной строкой, но ломает изоляцию контейнера.

Причина 2. Ollama слушает только 127.0.0.1

Отлично сочетается с первой: адрес вы исправили, а Ollama молчит. По умолчанию демон биндится на петлю, и контейнеру он недоступен физически.

Правится через override юнита, а не правкой /etc/systemd/system/ollama.service — установщик перезаписывает этот файл при каждом обновлении. sudo systemctl edit ollama.service открывает редактор, куда добавляются три строки:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Файл ляжет в /etc/systemd/system/ollama.service.d/override.conf. Дальше обязательны оба шага — sudo systemctl daemon-reload и sudo systemctl restart ollama. В ss -tlnp | grep 11434 должно появиться *:11434; если петля осталась, проверьте systemctl show ollama -p Environment.

Здесь же прячется редкий, но выматывающий случай — IPv6:

Cannot connect to host localhost:11434 ssl:default [Connect call failed ('::1', 11434, 0, 0)]

Обратите внимание на ::1: резолвер контейнера отдал сначала IPv6-адрес, а Ollama с OLLAMA_HOST=0.0.0.0 слушает только IPv4. Лечение — не писать localhost в базовом URL либо перевести демон на двойной стек: Environment="OLLAMA_HOST=[::]:11434".

Важное предупреждение: 0.0.0.0 — это все интерфейсы, включая публичный IP. Аутентификации у Ollama нет, открытые инстансы находят сканированием за часы, так что порт 11434 не должен появляться в правилах ufw. Узкий вариант — привязать демон к шлюзу Docker: Environment="OLLAMA_HOST=172.17.0.1:11434".

Причина 3. Пакет не доходит: ufw, SELinux и чужой фаервол

Симптом другой: соединение не отвергается, а зависает — 000 на таймауте вместо мгновенного отказа.

ufw на Ubuntu и Debian. Есть заблуждение, будто ufw не влияет на Docker. Входящие к опубликованным портам контейнеров он и правда не фильтрует — те идут через цепочку DOCKER в nat, минуя ufw. Но трафик в обратную сторону, из контейнера к порту хоста, приходит на docker0 как обычный входящий и попадает в INPUT с политикой DROP.

sudo ufw allow in on docker0 to any port 11434 proto tcp comment 'ollama for containers'
sudo ufw reload

У сетей compose интерфейс называется br-1a2b3c4d5e6f и меняется при пересоздании, поэтому проще разрешить по подсети: sudo ufw allow from 172.16.0.0/12 to any port 11434 proto tcp. Минус честно: диапазон покрывает все docker-подсети, доступ получит любой контейнер.

SELinux на AlmaLinux, Rocky и RHEL. Контейнеру запрещено ходить на произвольные порты хоста: getsebool container_connect_any покажет container_connect_any --> off, лечится через sudo setsebool -P container_connect_any on. Подтверждается по sudo ausearch -m avc -ts recent — denied для name_connect.

Ollama на отдельном сервере. Когда модели крутятся на GPU-машине, а интерфейс на дешёвом VPS, проверяйте связь отдельно: nc -zv 10.8.0.2 11434 должен ответить succeeded!. По публичному интернету этот трафик гонять нельзя, нужен WireGuard. А если перед Ollama стоит nginx, ждите 403 Forbidden на пустом месте: демон проверяет заголовки Host и Origin, лечится строкой proxy_set_header Host localhost:11434; и переменной OLLAMA_ORIGINS.

Причина 4. Связь есть, а моделей нет

Диагностика проходит, а список пуст. Шесть виновников.

Кэш настроек в базе. Самая дорогая по времени ловушка. OLLAMA_BASE_URL читается только при первом запуске, дальше значение живёт в таблице config файла /app/backend/data/webui.db. Вы правите compose, делаете docker compose up -d, а сервис ходит по старому адресу — это и показывает пятая команда. Лечение: поменять адрес в «Админ-панель → Настройки → Подключения» либо добавить ENABLE_PERSISTENT_CONFIG=False, что надёжнее для инфраструктуры как кода, но обнуляет ручные правки.

Отключённый коннектор. Переменная ENABLE_OLLAMA_API=false или снятый переключатель в подключениях выключают Ollama целиком, молча и без ошибок в логе. Увидели в базе "enable": false — причина найдена.

Лишний /api в адресе. Справка Ollama провоцирует написать http://host.docker.internal:11434/api. Open WebUI сам добавляет путь, получается запрос к /api/api/tags и приходит 404. В базовом URL только хост и порт.

Моделей действительно нет. Свежая Ollama пуста, ollama list не выводит ни строки. Загрузите первую: ollama pull llama3.1:8b — около 4,7 ГБ в квантовании Q4.

Модели скачаны не тем пользователем. Классика: сначала запустили ollama serve руками под root и скачали модели, потом перешли на systemd-сервис от пользователя ollama. Веса лежат в /root/.ollama/models, а демон ищет их в /usr/share/ollama/.ollama/models. Проверка — sudo du -sh по обоим путям, лечение — sudo mv /root/.ollama/models/* /usr/share/ollama/.ollama/models/ && sudo chown -R ollama:ollama /usr/share/ollama/.ollama.

Таймаут запроса списка. У Open WebUI отдельный короткий таймаут на список моделей — по умолчанию около 10 секунд, переменная AIOHTTP_CLIENT_TIMEOUT_MODEL_LIST. Обычно /api/tags отвечает за миллисекунды, но если моделей два десятка, а хранилище холодное или сетевое, ответ не укладывается — поднимите значение до 30. И проверьте права: администратор может ограничивать доступ к моделям, тогда он видит весь список, а обычный пользователь — пустой.

Какой сервер брать под Open WebUI и Ollama в MAATRIX

Половина случаев начинается с неверно выбранной машины: связку ставят на VPS с 2 ГБ памяти, Ollama падает по OOM при загрузке весов, а интерфейс рапортует, что сервиса нет.

Минимум без локальных моделей. Open WebUI поверх внешнего API — 2 vCPU, 4 ГБ RAM, 25–30 ГБ NVMe. Ollama тут не нужна вовсе, диск уходит под базу, историю чатов и документы.

Минимум для локальной модели. Модель 8B в Q4 требует около 6 ГБ памяти под веса плюс запас под контекст, сам Open WebUI съедает 0,7–1 ГБ. Реальный минимум — 4 vCPU, 16 ГБ RAM, 100 ГБ NVMe. Честно про скорость: на CPU это 5–9 токенов в секунду. Для переписки терпимо, для агентов и пакетной обработки — нет.

Комфортный вариант. 8 vCPU, 32 ГБ RAM и от 200 ГБ NVMe, если моделей несколько: три-четыре штуки среднего размера — уже 20–25 ГБ на диске. Для быстрого ответа нужен GPU с 16–24 ГБ VRAM: та же модель ускоряется в десятки раз.

Локация — Лондон. Реестр Ollama и репозитории моделей отдаются с полной скоростью канала, без обходных путей и обрывов на середине пятигигабайтного слоя. До пользователей в Европе пинг минимальный, сервер в GDPR-периметре — это снимает вопросы, если через чат проходят рабочие документы. Из Москвы до Лондона 40–60 мс: для веб-интерфейса незаметно. Если персональные данные должны оставаться в российском правовом поле, есть площадка в РФ.

Оплата — картами российских банков, по СБП, криптой или токеном MAAT: зарубежная карта не нужна. Не уверены, хватит ли CPU под вашу модель — напишите, какую планируете и на сколько человек. Полный путь от чистой системы до рабочего чата разобран в установке Open WebUI на Ubuntu 24.04, выбор моделей — в разборе локального запуска LLM через Ollama.

Частые вопросы