Ollama за обратным прокси-сервером Caddy или Nginx для потоковой передачи через HTTPS

HTTPS для Ollama без нарушения потоковой передачи ответов.

Содержимое страницы

Запуск Ollama через обратный прокси — самый простой способ обеспечить поддержку HTTPS, опциональный контроль доступа и предсказуемое поведение потоковой передачи данных.

В этой статье рассматривается настройка входящего трафика (ingress) для API Ollama с помощью Caddy и Nginx, а не клиентский код.

ollama behind proxy

Если у вас уже есть клиенты на Python или Go, взаимодействующие с Ollama, эта статья станет недостающим звеном: настройка входящего трафика и транспорта для того же API.

Чтобы узнать, как Ollama соотносится с vLLM, Docker Model Runner, LocalAI и компромиссами облачного хостинга, см. Хостинг LLM в 2026 году: локальные, самохостинговые и облачные инфраструктуры в сравнении.

Примеры запросов и клиентский код см. в Шпаргалка по CLI Ollama.

Информацию о пользовательских интерфейсах и слоях для многопользовательских систем см. в Обзор Open WebUI, быстрое начало и альтернативы.

О более широкой картине самохостинга и контроля данных см. в Самохостинг LLM и суверенитет ИИ.

Для воспроизводимого одноузлевого сервиса Ollama в Docker Compose (постоянные тома, OLLAMA_HOST, видеокарты NVIDIA, обновления) см. Ollama в Docker Compose с GPU и постоянным хранилищем моделей.

Для доступа с удаленных устройств без открытых портов на публичном интерфейсе (Tailscale, WireGuard, привязка, фаервол) см. Удаленный доступ к Ollama через Tailscale или WireGuard без публичных портов.

Почему стоит использовать прокси для Ollama вместо открытия порта 11434

Ollama разработан для локального запуска. Из коробки он привязывается к localhost на порту 11434, что отлично подходит для рабочей станции разработчика, но также служит негласным намеком на то, что этот «голый» порт не предназначен для работы в интернете.

Я отношусь к порту 11434 как к внутреннему API с высокой стоимостью. Если он доступен из публичного интернета, любой, кто его обнаружит, может истощить ресурсы вашего CPU или GPU, заполнить диск скачиванием моделей или просто держать соединения открытыми до тайм-аута. Обратный прокси не делает Ollama безопасным по волшебству, но он дает вам точку приложения усилий для важных механизмов управления на границе сети: TLS, аутентификация, тайм-ауты, ограничение частоты запросов и логи.

Это важно, потому что локальный API Ollama не поставляется со встроенным слоем аутентификации. Если вы открываете его для внешнего доступа, вы обычно добавляете аутентификацию на уровне прокси или оставляете его приватным и доступным только через доверенную сеть.

Вторая причина — пользовательский опыт (UX). Ollama по умолчанию потоково передает ответы. Если прокси буферизирует или сжимает данные в неправильном месте, потоковая передача кажется сломанной, а интерфейсы выглядят так, будто они «думают», не выдавая результата.

Минимальная архитектура и стратегия привязки

Чистая минимальная конфигурация выглядит так:

Клиент (curl, Python, Go, UI)
        |
        | HTTPS (опционально Basic Auth или SSO)
        v
Обратный прокси (Caddy или Nginx)
        |
        | HTTP (частная LAN, localhost или сеть Docker)
        v
Сервер Ollama (ollama serve на 127.0.0.1:11434)

Два практических правила сохраняют эту схему скучной в лучшем смысле этого слова.

Во-первых, держите Ollama приватным и переносите точку экспозиции на прокси. Если Caddy или Nginx работают на том же хосте, настройте прокси на 127.0.0.1:11434 и не меняйте адрес привязки Ollama. Если прокси работает на другом узле (отдельный хост, отдельная ВМ или контейнерная сеть), привяжите Ollama к приватному интерфейсу, а не к 0.0.0.0 на публичном сетевом интерфейсе, и используйте фаервол.

Во-вторых, заранее решите, будут ли браузеры обращаться к Ollama напрямую. Если инструмент на базе браузера обращается к Ollama с другого источника (origin), возможно, придется решать проблемы с CORS. Если все обслуживается с одного домена через прокси (рекомендуется для спокойствия), вы часто можете полностью избежать CORS и держать Ollama строгим.

Конфигурации обратного прокси для потоковой передачи и WebSockets

API Ollama — это обычный HTTP, а его потоковая передача использует JSON, разделенный новыми строками (NDJSON). Это означает, что прокси должен хорошо выполнять три вещи:

  • Не буферизировать потоковые ответы.
  • Не прерывать длительные запросы просто потому, что модели потребовалось время, чтобы начать отвечать.
  • Если интерфейс использует WebSockets (некоторые так делают), корректно передавать заголовок Upgrade.

Вы можете оставить это простым. Во многих случаях «корректная обработка WebSockets» — это просто наличие конфигурации, безопасной для Upgrade, даже если upstream сейчас не использует WebSockets.

Пример Caddyfile для Caddy

Caddy — это вариант «меньше конфигурации, больше настроек по умолчанию». Если вы укажете публичное доменное имя в адресе сайта, Caddy, как правило, автоматически получит и обновит сертификаты.

Минимальная конфигурация обратного прокси с HTTPS и настройками для потоковой передачи:

# ollama.example.com A/AAAA -> ваш хост прокси
ollama.example.com {

    # Опциональная аутентификация Basic Auth на границе.
    # Сгенерируйте хеш пароля с помощью:
    #   caddy hash-password --algorithm bcrypt
    #
    # basic_auth {
    #   alice $2a$12$REDACTED...
    # }

    reverse_proxy 127.0.0.1:11434 {

        # В некоторых настройках предпочтительно фиксировать заголовок Host для upstream.
        # Собственная документация Ollama показывает этот паттерн для Nginx.
        header_up Host localhost:11434

        # Для потоковых или чат-подобных рабочих нагрузок предпочтительна низкая задержка.
        # NDJSON-потоки обычно выгружаются сразу, но это делает это явным.
        flush_interval -1

        transport http {
            # Избегайте переговоров gzip с upstream, если это мешает потоковой передаче.
            compression off

            # Дайте Ollama время загрузить модель и сгенерировать первый кусок данных.
            response_header_timeout 10m
            dial_timeout 10s
        }
    }
}

Если у вас уже есть шлюз SSO (oauth2-proxy, Authelia, outpost authentik и т. д.), в Caddy есть директива forward_auth с четкой позицией. Паттерн: «сначала аутентификация, затем прокси»:

ollama.example.com {
    forward_auth 127.0.0.1:4180 {
        uri /oauth2/auth
        # Скопируйте заголовки идентификации, которые возвращает ваш шлюз, если они нужны.
        copy_headers X-Auth-Request-User X-Auth-Request-Email Authorization
    }

    reverse_proxy 127.0.0.1:11434
}

Пример блока сервера для Nginx

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

Этот пример включает:

  • Перенаправление с HTTP на HTTPS
  • Пути к сертификатам TLS (стиль Certbot)
  • Передачу Upgrade, безопасную для WebSocket
  • Отключение буферизации (proxy_buffering off) для потоковой передачи
  • Более длительные тайм-ауты, чем стандартные 60 секунд
# /etc/nginx/conf.d/ollama.conf

# Обработка заголовка Connection, безопасная для WebSocket
map $http_upgrade $connection_upgrade {
    default upgrade;
    ""      close;
}

# Опциональное ограничение частоты запросов (по IP)
# limit_req_zone $binary_remote_addr zone=ollama_rate:10m rate=10r/s;

server {
    listen 80;
    server_name ollama.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name ollama.example.com;

    ssl_certificate     /etc/letsencrypt/live/ollama.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ollama.example.com/privkey.pem;

    # Опциональная аутентификация Basic Auth на границе.
    # auth_basic "Ollama";
    # auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        # Опциональное ограничение частоты
        # limit_req zone=ollama_rate burst=20 nodelay;

        proxy_pass http://127.0.0.1:11434;

        # Соответствие паттерну документации Ollama при проксировании на localhost.
        proxy_set_header Host localhost:11434;

        # Обработка Upgrade для WebSocket (безвредно, если не используется).
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        # Критично для потоковой передачи NDJSON.
        proxy_buffering off;

        # Предотвратите тайм-ауты простоя в 60 секунд при ожидании токенов.
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Если вам нужен шлюз в стиле SSO в Nginx, эквивалентным паттерном является auth_request. Nginx отправляет подзапрос в ваш сервис аутентификации и проксирует запрос в Ollama только тогда, когда аутентификация возвращает статус 2xx.

Подводные камни автоматизации и обновления TLS

В отношении TLS операционное разделение простое.

В Caddy TLS обычно является «частью обратного прокси». Автоматический HTTPS — одна из его флагманских функций, поэтому выпуск и обновление сертификатов связаны с запуском Caddy, работоспособностью DNS и открытием портов 80 и 443.

В Nginx TLS обычно представляет собой «отдельный клиент ACME плюс Nginx». Типичный режим отказа связан не с криптографией, а с инфраструктурой:

  • Порт 80 недоступен для вызовов HTTP-01.
  • Сертификаты хранятся в контейнере, но не сохраняются при перезапуске.
  • Ограничения частоты при повторных свежих установках или тестовых разворачиваниях.

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

Аутентификация, контроль злоупотреблений и проверка

Это та часть, которая делает конец LLM, ориентированный на интернет, профессиональным.

Варианты аутентификации: от грубых до элегантных

Basic Auth на уровне прокси — решение грубое, но удивительно эффективное для приватного эндпоинта. Его также легко применить как к HTTP-запросам, так и к обновлениям WebSocket.

Если вам нужны потоки входа, удобные для браузера, используйте паттерны forward_auth и auth_request. Ваш прокси остается без состояния, а шлюз аутентификации управляет сессиями и MFA. Компромисс — больше движущихся частей.

Если у вас уже работает Open WebUI, вы также можете полагаться на его уровень аутентификации приложения и держать сам Ollama приватным. В этом случае прокси защищает Open WebUI, а не Ollama напрямую.

Если публичный доступ вообще не нужен, подход только на уровне сети может быть чище. Например, Tailscale Serve может экспонировать локальный сервис внутри вашей сети tailnet без открытия входящих портов на вашем роутере. Для полных паттернов (WireGuard, OLLAMA_HOST на интерфейсах VPN, настройка фаервола, чек-лист безопасности) см. Удаленный доступ к Ollama через Tailscale или WireGuard без публичных портов.

Основы борьбы со злоупотреблениями для дорогого API

Ollama — мощный локальный API, и его поверхность выходит за пределы генерации. У него есть эндпоинты для чата, эмбеддингов, списка моделей и проверки версии. Относитесь ко всему API как к чувствительному.

Официальная ссылка на API (эндпоинты и потоковая передача): https://docs.ollama.com/api

На уровне прокси есть три простых контроля, которые уменьшают боль в первый день:

  • Ограничение частоты запросов по IP для эндпоинтов генерации.
  • Ограничение количества соединений, чтобы остановить небольшое количество клиентов, удерживающих всё открытым.
  • Консервативные тайм-ауты, соответствующие вашей модели и реальности оборудования, а не общим веб-стандартам.

На уровне Ollama также можно отклонять перегрузки с кодом 503, и там есть серверные настройки для очередей. Ограничение частоты на прокси помогает реже доходить до этого.

Чек-лист проверки

Используйте те же проверки, что и для любого потокового API.

  1. Базовая связность и TLS

    • curl -sS https://ollama.example.com/api/version
    • curl -sS https://ollama.example.com/api/tags | head

  2. Потоковая передача работает от начала до конца (без буферизации)

    • curl -N https://ollama.example.com/api/generate -H "Content-Type: application/json" -d '{"model":"mistral","prompt":"Write 10 words only.","stream":true}'

    Если вы находитесь за Basic Auth:

    • curl -N -u alice:REDACTED https://ollama.example.com/api/generate -H "Content-Type: application/json" -d '{"model":"mistral","prompt":"Write 10 words only.","stream":true}'

  3. Проверка интерфейса браузера

    • Загрузите ваш чат-интерфейс и инициируйте ответ.
    • Если интерфейс использует WebSockets, убедитесь, что вы не видите ошибок 400 или 426, и соединение остается открытым во время генерации.

Если вывод curl появляется только в конце, это почти всегда буферизация на прокси. Проверьте, что proxy_buffering off включен в Nginx, и рассмотрите возможность принудительной выгрузки с низкой задержкой в Caddy для блока сайта Ollama.