~/ / Статьи об ИИ / Локальные LLM на VPS / nginx перед Ollama: базовая аутентификация, HTTPS и настройки потоковой передачи

nginx перед Ollama: базовая аутентификация, HTTPS и настройки потоковой передачи

По умолчанию Ollama слушает только на самом сервере, и это самое безопасное место для него. Если до него должна дотянуться другая машина, FAQ Ollama указывает на прокси-сервер вроде nginx. В этой статье такая схема собрана по документации nginx: пароль, HTTPS, настройки, важные для потоковых ответов, и файрвол, который закрывает остальные входы.

Опубликовано: 2026-10-26 · 5 мин чтения · Проверено по официальной документации Ollama и nginx на 2026-10-26. Значения директив по умолчанию зависят от версии nginx, поэтому проверьте версию, которую вы используете.

Что говорит FAQ Ollama

В FAQ Ollama сказано, что Ollama запускает HTTP-сервер и его можно открыть наружу через прокси-сервер, например Nginx. В приведённом там примере сервер слушает порт 80, задаёт server_name, пересылает запросы через proxy_pass http://localhost:11434 и устанавливает заголовок Host в localhost:11434.

Страница FAQ, которую мы проверяли, не описывает никакой аутентификации для сервера Ollama. Поэтому пароль должен обеспечивать стоящий перед ним прокси. По умолчанию Ollama привязан к 127.0.0.1, порт 11434, так что nginx на том же сервере может обратиться к нему, не меняя этот адрес.

Пароль через базовую аутентификацию

Модуль ngx_http_auth_basic_module ограничивает доступ, проверяя имя пользователя и пароль. Работу выполняют две директивы: auth_basic, чья строка используется как realm и которая по умолчанию имеет значение off, и auth_basic_user_file, которая указывает файл с паролями.

Directive	По умолчанию	Что говорит документация
auth_basic string \| off;	off	Параметр используется как realm аутентификации. Значение off отменяет настройку, унаследованную с предыдущего уровня.
auth_basic_user_file file;	нет	В файле на каждой строке одна запись вида name:password, а строки, начинающиеся с #, считаются комментариями.

Поддерживаемые типы паролей: пароли, зашифрованные с помощью crypt(), и хеши apr1; оба вида создаются утилитой htpasswd из Apache или командой openssl passwd.
Поддерживается и синтаксис {SCHEME}data. На странице сказано, что PLAIN приведён только как пример и использовать его не следует, и что SHA, то есть SHA-1 без соли, тоже использовать не следует, поскольку он уязвим для атак по радужным таблицам. SSHA — это SHA-1 с солью.
Пример из документации: location / { auth_basic "closed site"; auth_basic_user_file conf/htpasswd; }

Страница упоминает htpasswd и openssl passwd, но не приводит команд. Часто используемые варианты, которые принадлежат нам, а не странице: htpasswd -c /etc/nginx/ollama.htpasswd alice, который запрашивает пароль, и openssl passwd -apr1, который выводит хеш, чтобы вставить его после имени пользователя и двоеточия.

Шифрование через HTTPS

Наше толкование, а не утверждение из документов: при базовой аутентификации пароль отправляется с каждым запросом, поэтому используйте её только поверх HTTPS. Согласно документации nginx, серверу нужен параметр ssl на слушающем сокете, а также пути к сертификату и закрытому ключу.

Directive	Пример из документации
listen	listen 443 ssl;
server_name	server_name www.example.com;
ssl_certificate	ssl_certificate www.example.com.crt;
ssl_certificate_key	ssl_certificate_key www.example.com.key;

По умолчанию nginx использует ssl_protocols TLSv1.2 TLSv1.3 и ssl_ciphers HIGH:!aNULL:!MD5, поэтому задавать их явно, как правило, не нужно.
Закрытый ключ следует хранить в файле с ограниченным доступом, но он должен быть доступен для чтения главному процессу (master process) nginx.
Если браузеры сообщают об ошибках для сертификата от известного удостоверяющего центра, серверу, возможно, нужно отправлять промежуточные сертификаты. В объединённом файле сертификат сервера должен идти перед цепочкой сертификатов, иначе nginx не запустится с ошибкой key values mismatch.
На странице Let's Encrypt «Getting started» сказано, что если ваш провайдер не получает сертификаты за вас и вы можете администрировать свой сервер, то можно запустить клиент ACME, и что для большинства пользователей рекомендуется Certbot.

Настройки для потоковых и медленных ответов

Модель пишет ответ по частям, и первая часть может прийти не сразу, например пока большая модель загружается в память. Снаружи это выглядит по-разному в зависимости от трёх настроек nginx.

Directive	По умолчанию	Что говорит документация
proxy_buffering	on	Когда буферизация отключена, ответ передаётся клиенту синхронно, сразу по мере получения. Когда она включена, nginx сначала сохраняет ответ в буферах.
proxy_read_timeout	60s	Таймаут задаётся только между двумя последовательными операциями чтения, а не на весь ответ. Если проксируемый сервер ничего не передаёт в течение этого времени, соединение закрывается.
proxy_http_version	1.1, начиная с nginx 1.29.7	До версии 1.29.7 значением по умолчанию было 1.0. Для keepalive-соединений рекомендуется версия 1.1 или 2.

Наше толкование, а не утверждение из документов: чтобы видеть, как ответ появляется по мере написания, отключите proxy_buffering для location, ведущего к Ollama; а если при загрузке модель может молчать дольше минуты, увеличьте proxy_read_timeout. Явно заданный proxy_http_version 1.1 безвреден в любой версии.

Собираем всё вместе

Эта конфигурация объединяет перечисленные выше директивы для одного имени сервера. Это наша композиция из описанных в документации директив, поэтому перед перезагрузкой проверьте её командой nginx -t.

Line	Зачем
server {	один блок server для имени Ollama
listen 443 ssl;	HTTPS
server_name ollama.example.com;	ваше собственное имя
ssl_certificate /etc/ssl/ollama.crt;	сертификат, после которого идут промежуточные
ssl_certificate_key /etc/ssl/ollama.key;	закрытый ключ, доступный только тем, кому нужно
auth_basic "ollama";	включает пароль
auth_basic_user_file /etc/nginx/ollama.htpasswd;	где хранятся пользователи
location / {	всё направляется в Ollama
proxy_pass http://localhost:11434;	из FAQ Ollama
proxy_set_header Host localhost:11434;	из FAQ Ollama
proxy_http_version 1.1;	рекомендуется для keepalive
proxy_buffering off;	чтобы ответ шёл потоком
proxy_read_timeout 300s;	допускает медленную первую часть
}	конец location
}	конец server

Закройте остальные входы

Прокси помогает, только если до Ollama или стоящего за ним приложения нельзя добраться другим путём. Ollama остаётся на адресе по умолчанию, а файрвол пропускает только те адреса, которыми вы пользуетесь.

Задача	Команда из документации Ubuntu
Включить файрвол	sudo ufw enable
Разрешить порт	sudo ufw allow 22
Разрешить один адрес на один порт	sudo ufw allow proto tcp from 192.168.0.2 to any port 22
Разрешить всю подсеть	замените адрес на 192.168.0.0/24
Проверить состояние	sudo ufw status

На странице Ubuntu сказано, что UFW изначально отключён. Предупреждения о том, что можно заблокировать себе доступ по SSH, там нет. Наша рекомендация: на сервере, к которому вы подключаетесь удалённо, разрешите порт SSH до включения файрвола, а порт 443 разрешайте только для тех адресов, которым он нужен.