Ollama achter een reverse proxy met Caddy of Nginx voor HTTPS-streaming

HTTPS voor Ollama zonder streaming-responses te onderbreken.

Inhoud

Ollama achter een reverse proxy draaien is de eenvoudigste manier om HTTPS, optionele toegangscontrole en voorspelbaar streamgedrag te krijgen.

Dit artikel focust op Caddy en Nginx-ingang voor de Ollama-API, niet op clientcode.

ollama achter proxy

Als u al Python- of Go-clients hebt die met Ollama communiceren, is dit artikel het ontbrekende stuk: ingang en transport voor dezelfde API.

Voor informatie over hoe Ollama past naast vLLM, Docker Model Runner, LocalAI en de afwegingen bij cloud-hosting, zie LLM-hosting in 2026: Lokaal, Self-Hosted & Cloud-infrastructuur vergeleken.

Voor voorbeelden van aanvragen en clientcode, zie Ollama CLI Cheatsheet.

Voor UI’s en multi-gebruikerslagen, zie Open WebUI-overzicht, quickstart en alternatieven.

Voor het grotere plaatje over self-hosting en datacontrole, zie LLM self-hosting en AI-soevereiniteit.

Voor een reproduceerbare single-node Ollama-service in Docker Compose (persistente volumes, OLLAMA_HOST, NVIDIA-gpu’s, upgrades), zie Ollama in Docker Compose met GPU en persistente modelopslag.

Voor externe apparaten zonder openbare inkomende poorten (Tailscale, WireGuard, binding, firewall), zie Externe Ollama-toegang via Tailscale of WireGuard, zonder openbare poorten.

Waarom u Ollama moet proxyen in plaats van poort 11434 open te stellen

Ollama is ontworpen om eerst lokaal te draaien. Standaard bindt het aan localhost op poort 11434, wat geweldig is voor een ontwikkelaarswerkstation en een subtiele hint dat de ruwe poort niet bedoeld is om internet-facing te zijn.

Ik behandel poort 11434 als een interne, dure API. Als deze bereikbaar is vanaf het openbare internet, kan iedereen die het vindt uw CPU- of GPU-tijd verbranden, uw schijf vullen door modellen te downloaden, of gewoon verbindingen open houden tot er een time-out optreedt. Een reverse proxy maakt Ollama niet magisch veiliger, maar het geeft u een plek om de controles die ertoe doen aan de rand te plaatsen: TLS, authenticatie, time-outs, rate limits en logs.

Dit is belangrijk omdat de lokale Ollama-API niet wordt geleverd met een ingebouwde authenticatielaag. Als u het blootstelt, voegt u doorgaans auth toe aan de rand of houdt u het privé en alleen bereikbaar via een vertrouwd netwerk.

De tweede reden is UX. Ollama streamt responses standaard. Als de proxy op de verkeerde plek buffer of comprimeert, voelt streamen kapot aan en lijken UI’s te “denken” zonder output.

Minimale architectuur en bindingsstrategie

Een schone minimum ziet er zo uit:

Client (curl, Python, Go, UI)
        |
        | HTTPS (optionele Basisauth of SSO)
        v
Reverse proxy (Caddy of Nginx)
        |
        | HTTP (privé LAN, localhost of Docker-netwerk)
        v
Ollama server (ollama serve op 127.0.0.1:11434)

Twee praktische regels houden dit op de beste manier saai.

Ten eerste, houd Ollama privé en verplaats de blootstelling naar de proxy. Als Caddy of Nginx op dezelfde host draait, proxy naar 127.0.0.1:11434 en verander Ollama’s bindadres niet. Als de proxy elders draait (separate host, separate VM of een containernetwerk), bind Ollama aan een privé-interface, niet 0.0.0.0 op de openbare NIC, en vertrouw op een firewall.

Ten tweede, beslis vroeg of browsers Ollama direct zullen aanroepen. Als een browsergebaseerd tool Ollama raakt vanuit een andere oorsprong, moet u mogelijk omgaan met CORS. Als alles via de proxy van één domein wordt geserveerd (aanbevolen voor sanity), kunt u vaak CORS volledig vermijden en Ollama streng houden.

Reverse proxy-configuraties voor streaming en WebSockets

Ollama’s API is reguliere HTTP, en de streaming is newline-delimited JSON (NDJSON). Dat betekent dat u een proxy wilt die drie dingen goed kan doen:

  • Streamde responsen niet bufferen.
  • Langlopende aanvragen niet doden alleen omdat het model even lang duurde om te spreken.
  • Als een UI WebSockets gebruikt (sommige doen dat), Upgrade schoon doorsturen.

U kunt dit simpel houden. In veel gevallen is “correcte WebSocket-afhandeling” gewoon een config die Upgrade-safe is, zelfs als de upstream vandaag geen WebSockets gebruikt.

Caddy Caddyfile-voorbeeld

Caddy is de optie “minder config, meer defaults”. Als u een openbaar domeinnaam in de site-adres plaatst, zal Caddy doorgaans certificaten automatisch verkrijgen en vernieuwen.

Minimale reverse proxy, HTTPS en streaming-vriendelijke instellingen:

# ollama.example.com A/AAAA -> uw proxy host
ollama.example.com {

    # Optionele Basisauth aan de rand.
    # Genereer een wachtwoord-hash met:
    #   caddy hash-password --algorithm bcrypt
    #
    # basic_auth {
    #   alice $2a$12$REDACTED...
    # }

    reverse_proxy 127.0.0.1:11434 {

        # Sommige setups verkiezen het upstream Host-header te pinnen.
        # Ollama's eigen docs tonen dit patroon voor Nginx.
        header_up Host localhost:11434

        # Voor streaming of chat-achtige workloads, verkiert lage latentie.
        # NDJSON-streaming flush doorgaans direct, maar dit maakt het expliciet.
        flush_interval -1

        transport http {
            # Vermijd upstream gzip-onderhandeling als het interfereert met streaming.
            compression off

            # Geef Ollama tijd om een model te laden en het eerste chunk te produceren.
            response_header_timeout 10m
            dial_timeout 10s
        }
    }
}

Als u al een SSO-gateway heeft (oauth2-proxy, Authelia, authentik outpost, enz.), heeft Caddy een opiniëerde forward auth-directive. Het patroon is “auth eerst, dan proxy”:

ollama.example.com {
    forward_auth 127.0.0.1:4180 {
        uri /oauth2/auth
        # Kopieer de identity-headers die uw gateway teruggeeft, als u ze nodig hebt.
        copy_headers X-Auth-Request-User X-Auth-Request-Email Authorization
    }

    reverse_proxy 127.0.0.1:11434
}

Nginx server block-voorbeeld

Nginx geeft u een beetje meer touw. Het voordeel is dat de knoppen expliciet zijn, en het heeft ingebouwde primitieven voor rate limiting en connection limiting. De valkuil is buffering: Nginx buffert geproxied responsen standaard, wat het tegenovergestelde is van wat u wilt voor NDJSON-streaming.

Dit voorbeeld bevat:

  • HTTP naar HTTPS redirect
  • TLS-certificaat paden (Certbot-stijl)
  • WebSocket-safe Upgrade-forwarding
  • Streaming-vriendelijke proxy_buffering off
  • Langere time-outs dan de standaard 60s
# /etc/nginx/conf.d/ollama.conf

# WebSocket-safe Connection header-afhandeling
map $http_upgrade $connection_upgrade {
    default upgrade;
    ""      close;
}

# Optionele aanvraag-rate limiting (IP-gebaseerd)
# 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;

    # Optionele Basisauth aan de rand.
    # auth_basic "Ollama";
    # auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        # Optionele rate limit
        # limit_req zone=ollama_rate burst=20 nodelay;

        proxy_pass http://127.0.0.1:11434;

        # Match Ollama docs patroon bij proxyen naar localhost.
        proxy_set_header Host localhost:11434;

        # WebSocket Upgrade-afhandeling (onbelangrijk als ongebruikt).
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        # Kritisch voor NDJSON-streaming.
        proxy_buffering off;

        # Voorkom 60s idle-time-outs terwijl gewacht wordt op tokens.
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Als u een SSO-stijl gate in Nginx wilt, is het equivalente patroon auth_request. Nginx stuurt een sub-aanvraag naar uw auth-service, en proxyt alleen naar Ollama wanneer auth 2xx teruggeeft.

TLS-automatisering en vernieuwing valkuilen

Voor TLS is de operationele splitsing simpel.

Met Caddy is TLS doorgaans “deel van de reverse proxy”. Automatisch HTTPS is een van zijn vlaggeschepen, dus certificaatuitgifte en vernieuwing zijn gekoppeld aan het houden van Caddy draaiend, werkende DNS en het openen van poorten 80 en 443.

Met Nginx is TLS doorgaans “een aparte ACME-client plus Nginx”. De gebruikelijke faalmode is niet crypto, het is leidingwerk:

  • Poort 80 niet bereikbaar voor HTTP-01-challenges.
  • Certificaten opgeslagen in een container maar niet gepersisteerd.
  • Rate limits bij het doen van herhaalde verse installaties of test-deployments.

Een subtiele punt die belangrijk is voor langlevende services is dat certificaatlevensduren per ontwerp kort zijn. Behandel vernieuwingen als een achtergrondautomatiseringsvereiste, niet als een jaarlijks kalendergebeurtenis.

Authenticatie, misbruikcontrole en verificatie

Dit is het deel dat een internet-facing LLM-endpunt professioneel doet voelen.

Authenticatie-opties, van bot naar elegant

Basisauth aan de proxy is bot, maar verrassend effectief voor een privé-endpunt. Het is ook makkelijk toe te passen op zowel HTTP-aanvragen als WebSocket-upgrades.

Als u browser-vriendelijke login-flow wilt, zijn forward auth en auth_request het gebruikelijke patroon. Uw proxy blijft stateless, en een auth-gateway bezit sessies en MFA. De afweging is meer bewegende onderdelen.

Als u al Open WebUI draait, kunt u ook vertrouwen op de app-level authenticatie en Ollama zelf privé houden. De proxy beschermt dan Open WebUI, niet Ollama direct.

Als u überhaupt geen openbare toegang nodig hebt, kan een alleen-netwerkbenadering schoner zijn. Bijvoorbeeld, Tailscale Serve kan een lokale service binnen uw tailnet openen zonder inkomende poorten op uw router te openen. Voor volledige patronen (WireGuard, OLLAMA_HOST op VPN-interfaces, firewall-pinning, beveiligingscontrolelijst), zie Externe Ollama-toegang via Tailscale of WireGuard, zonder openbare poorten.

Misbruik-basis voor een dure API

Ollama is een krachtige lokale API, en zijn oppervlak gaat verder dan generatie. Het heeft endpoints voor chat, embeddings, modellenlijst en versiecontroles. Behandel de hele API als gevoelig.

Officiële API-referentie (endpoints en streaming): https://docs.ollama.com/api

Op de proxy-laag zijn er drie lage-inspanningscontroles die dag-één-pijn verminderen:

  • Rate limiting per IP op generatie-endpoints.
  • Connection limits om een klein aantal clients te stoppen alles open te houden.
  • Conservatieve time-outs die matchen met uw model en hardware-reëelheid, niet generieke web-standaarden.

Op de Ollama-laag kan het ook overbelasting afwijzen met 503 en heeft het server-side knoppen voor queueing. Proxy rate limiting houdt u er minder vaak aan.

Verificatiecontrolelijst

Gebruik dezelfde checks die u voor elke streaming-API zou gebruiken.

  1. Basisconnectiviteit en TLS

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

  2. Streaming werkt van begin tot eind (geen buffering)

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

    Als u achter Basisauth zit:

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

  3. Browser-UI sanity

    • Laad uw chat-UI en trigger een respons.
    • Als de UI WebSockets gebruikt, bevestig dat u geen 400 of 426 fouten ziet en de verbinding open blijft tijdens generatie.

Als de curl-output alleen aan het einde verschijnt, is het bijna altijd buffering aan de proxy. Controleer proxy_buffering off in Nginx opnieuw, en overweeg het forceren van lage-latentie flushing in Caddy voor de Ollama-site block.