Connection refused на 11434: тот, кто звал, тот, кто слушал, шесть причин

■ space · прозаическая полоса

КАРТА ЗВОНЯЩЕГО

Половина всех отчётов — проблема размещения: слушающий в порядке — звонящий звонит оттуда, куда слушающий не дотягивается.

контейнеру на голом Linux нужен --add-host=host.docker.internal:host-gateway — собственная документация Docker называет этот флаг ровно для этого случая · контейнер-в-контейнер в одной сети: http://<имя-сервиса>:11434

ШЕСТЬ ПРИЧИН, ПО РАНЖИРУ

Сверху вниз — первая строка, попавшая в вашу ошибку, несёт починку:

OLLAMA ВООБЩЕ ЗАПУЩЕНА?

Десктопные сборки (macOS, Windows) гоняют Ollama как приложение в трее, и закрыть её проще, чем люди думают. Сборка под Linux гоняет systemd-сервис, который после ребута может так и остаться невключённым. ollama list к серверу отвечает таблицей моделей; если и он отвечает ошибкой соединения, запустите сервер и сделайте запуск постоянным:

systemctl status ollama
sudo systemctl enable --now ollama   # start + survive reboots
journalctl -u ollama -n 50           # if it keeps dying, read why

проверка: systemctl is-active ollama → active · ollama list → таблица моделей

ПОРТ, ХОСТ, LAN

Ollama слушает на 127.0.0.1:11434, если не сказали иначе. Свой порт: если вы когда-то ставили OLLAMA_HOST=127.0.0.1:11435, сервер отвечает на 11435, и всякий клиент, продолжающий стучать на 11434, получает отказ — подтвердите, кто реально слушает, командой ss -ltn | grep 1143. Ловушка IPv6: на некоторых машинах localhost первым делом разрешается в ::1, а сервер, слушающий только на 127.0.0.1, этих попыток вовек не видит — различающий тест стоит две секунды: curl http://127.0.0.1:11434 работает, а curl http://localhost:11434 отказывает. Звоните на 127.0.0.1, слушайте оба, или направьте клиентов на голый IP.

Открывать в LAN: по умолчанию Ollama слушает только loopback — из принципа, ведь у API нет никакой аутентификации. Ставьте это в systemd-override, а не в свой shell, чтобы сервис реально это видел:

sudo systemctl edit ollama
# [Service]
# Environment="OLLAMA_HOST=0.0.0.0:11434"
sudo systemctl restart ollama

проверка: ss -ltn | grep 11434 → 0.0.0.0:11434 · с другой машины: curl http://<host-ip>:11434 → «Ollama is running»

Два соседа «refused», которые суть разные поломки: фаервол, всё ещё закрывающий 11434, производит таймауты, не отказы — «отказано» значит активное «нет», таймаут значит, что пакеты так и не доехали. А браузерному JavaScript, зовущему API с чужого происхождения, нужен выставленный OLLAMA_ORIGINS: те вызовы приезжают и заворачиваются на слое CORS — снаружи выглядит один в один.

Отказанное соединение — проблема размещения, а не сломанная программа: то, что должно было слушать, не слушает, или звонящий звонит оттуда, куда слушающий не дотягивается.

ВЕРНУЛОСЬ, И ЕЩЁ РАЗ

Тогда порт держит один процесс, а другой раз за разом проигрывает скачку. ss -ltnp | grep 11434 показывает процесс, сжимающий сокет; рука-запущенная вторая инстанция Ollama — обычный воришка. Прибейте бродягу, оставьте сервис единоличным владельцем, и ошибка уйдёт насовсем.

проверка: ss -ltnp | grep 11434 → одна строка, один PID — сервис

Ollama перевалила 181 000 звёзд GitHub в сентябре 2026 — больше машин на ней значит больше спросов на эти шесть ответов в ту же неделю, когда их ищут. Когда сервер отвечает, отказавшийся жить GPU — следующая по частоте жалоба. Диагностика — один curl.

конец карты звонящего · ничего не fetched · всё локально