mrsaynothing.devOllama connection refused — диагностика за 60 секунд
Connection refused означает, что на порту 11434 никто не слушает. Шесть реальных причин по убыванию вероятности и одна команда curl, которая назовёт вашу.
Ошибка никогда не врёт о своём смысле: curl: (7) Failed to connect to localhost port 11434: Connection refused — это ваша операционная система сообщает, что на порту 11434 никто не слушает. Ollama не «сломана», модель не повреждена, а рефлекторный ответ интернета — переустановить — проходит мимо шести скучных причин, каждая из которых исключается за минуту.
Сначала выполните диагностическую команду. Она режет проблему пополам до того, как вы дочитаете раздел:
curl http://localhost:11434
Ollama is running — сервер в порядке, и ваш клиент стучится не туда — переходите к вопросам хоста. Connection refused — чинить надо серверную сторону. Я воспроизвёл сам отказ на одноразовой bench-машине, где никто не слушает: ядро отвечает bash: connect: Connection refused ещё до того, как в дело вступит какое-либо приложение.
Почему Ollama выдаёт connection refused?
Потому что TCP-подключение пришло на машину, где ни один сокет не держит порт 11434. Вот и весь механизм — верно одно из шести утверждений, и здесь они ранжированы по частоте, самая вероятная первой.
Ollama вообще запущена?
Десктопные сборки (macOS, Windows) держат Ollama как приложение в трее, и закрыть его случайно проще, чем кажется. В Linux установка идёт через службу systemd, которую после перезагрузки могли ни разу и не включить.
# Linux: жива ли служба?
systemctl status ollama
# Прямая проверка, которая работает везде:
ollama list
Если ollama list достучался до сервера, он ответит таблицей моделей. Если и он отвечает ошибкой соединения, запустите сервер и сделайте автозапуск постоянным:
sudo systemctl enable --now ollama # Linux: запустить + переживать перезагрузки
journalctl -u ollama -n 50 # если постоянно умирает — читайте почему
Служба, которая стартует и тут же умирает, выглядит здесь как crash loop, и journalctl печатает причину — порт уже занят, диск полон, неверный override окружения.
Дело в порте или в том, кого вы вызываете?
По умолчанию Ollama слушает на 127.0.0.1:11434. Два классических рассогласования:
Свой порт. Если вы — или туториал, по которому вы шли — когда-то поставили OLLAMA_HOST=127.0.0.1:11435, сервер отвечает на 11435, и каждый клиент, всё ещё зовущий 11434, получает отказ. Проверьте, что слушает на самом деле:
ss -ltn | grep 1143
Ожидается одна строка с 127.0.0.1:11434. Строк нет вовсе: сервер не запущен (прошлый раздел). Порт или адрес другие — отстают ваши клиенты.
localhost против 127.0.0.1. На некоторых машинах localhost сначала резолвится в IPv6-адрес ::1, и сервер, привязанный только к 127.0.0.1, этих попыток никогда не видит. Различающий тест стоит две секунды:
curl http://127.0.0.1:11434 # работает, а curl http://localhost:11434 отказывает
Если голый IP работает, а имя — нет, привяжите сервер к обоим или направьте клиенты прямо на 127.0.0.1.
Почему на хосте работает, а из Docker — нет?
Это самый частый вариант в дикой природе — потому в автодополнении этой ошибки столько n8n, Open WebUI и расширений VS Code. Каждый контейнер, вызывающий http://localhost:11434, вызывает сам себя: внутри контейнера 127.0.0.1 — это loopback контейнера, где никто не слушает.
| Кто вызывает | Правильный URL к Ollama на хосте |
|---|---|
| Контейнер на Docker Desktop | http://host.docker.internal:11434 |
| Контейнер на чистом Linux | http://host.docker.internal:11434 плюс --add-host=host.docker.internal:host-gateway |
| Контейнер в той же сети Docker | http://<имя-сервиса>:11434 |
| Другая машина в вашей LAN | http://<ip-машины>:11434 (следующий раздел) |
Флаг host-gateway берётся из документации Docker ровно для этого случая, и это одна-единственная строка, чинящая половину отчётов «Ollama connection refused» из контейнеров.
Как открыть Ollama другим машинам?
По умолчанию Ollama привязывается только к loopback — намеренно: у API нет аутентификации. Открыть наружу — одна переменная окружения; задайте её в override systemd, а не в своём шелле, чтобы служба её реально увидела:
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. Два продолжения, которые пропускают: файрвол, всё ещё блокирующий 11434, даёт таймауты, а не отказы (другой сбой, тот же порт); а браузерному JavaScript, зовущему API с другого origin, нужен OLLAMA_ORIGINS — по FAQ самого Ollama такие вызовы доходят, но их заворачивает слой CORS, и снаружи это выглядит точно так же.
Отказ в соединении — проблема размещения, а не сломанная программа: что-то, что должно слушать, не слушает, либо зовущий находится там, куда слушающий не достаёт.
Если возвращается снова и снова?
Значит, один процесс держит порт, а другой каждый раз проигрывает гонку. ss -ltnp | grep 11434 покажет процесс, владеющий сокетом; вторая копия Ollama, запущенная руками, — обычный вор. Уберите самозванку, оставьте службу единственным владельцем — и ошибка уйдёт.
По остальному кластеру: когда сервер уже отвечает, GPU, которую он отказывается использовать — следующая по частоте жалоба, а запуск GGUF-моделей локально закрывает сторону загрузки. Оба живут в хабе локальных LLM.
В сентябре 2026-го Ollama перевалила 181 тысячу звёзд на GitHub — чем больше машин её запускают, тем больше из этих шести ответов ищут в ту же неделю, когда их набирают. Диагностика — за один curl.