# Nginx reverse proxy met authenticatie voor je LLM

[Naar de inhoud](#lm-inhoud)Netwerk/NL[EN](/en/)[Hubhub.llmnet.nlModellen vergelijken op taak, taal, kosten en licentie.](https://hub.llmnet.nl/)[Communitycommunity.llmnet.nlPrompttechnieken, patronen en systeemprompts.](https://community.llmnet.nl/)[APIapi.llmnet.nlLLM's robuust in software: rate limits, routing, structured output.](https://api.llmnet.nl/)[Consultancyconsultancy.llmnet.nlAI invoeren in een organisatie, van pilot tot productie.](https://consultancy.llmnet.nl/)[Nieuwsnieuws.llmnet.nlOntwikkelingen in AI, geduid voor Nederland.](https://nieuws.llmnet.nl/)[Benchmarkbenchmark.llmnet.nlZelf meten wat AI-kwaliteit is, voor jouw taken.](https://benchmark.llmnet.nl/)[Vacaturesvacatures.llmnet.nlAI-rollen, salarissen en carrièrepaden in Nederland.](https://vacatures.llmnet.nl/)[Lerenleren.llmnet.nlAI-concepten in gewoon Nederlands, van beginner tot bouwer.](https://leren.llmnet.nl/)[Gidsgids.llmnet.nlAI privé draaien op eigen Mac, pc, NAS of thuisserver.](https://gids.llmnet.nl/)[Directorydirectory.llmnet.nlHet AI-ecosysteem in kaart: tools, modellen, bedrijven.](https://directory.llmnet.nl/)[Radarradar.llmnet.nlSignalen uit X, onderzoek en communities voor indie developers.](https://radar.llmnet.nl/)[llmnet.nl — hoofdsite](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fgids.llmnet.nl%2Fnginx-reverse-proxy-met-authenticatie-voor-je-lokale-llm&text=Nginx%20reverse%20proxy%20met%20authenticatie%20voor%20je%20LLM)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fgids.llmnet.nl%2Fnginx-reverse-proxy-met-authenticatie-voor-je-lokale-llm)[](https://www.reddit.com/submit?url=https%3A%2F%2Fgids.llmnet.nl%2Fnginx-reverse-proxy-met-authenticatie-voor-je-lokale-llm&title=Nginx%20reverse%20proxy%20met%20authenticatie%20voor%20je%20LLM)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fgids.llmnet.nl%2Fnginx-reverse-proxy-met-authenticatie-voor-je-lokale-llm&text=Nginx%20reverse%20proxy%20met%20authenticatie%20voor%20je%20LLM)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fgids.llmnet.nl%2Fnginx-reverse-proxy-met-authenticatie-voor-je-lokale-llm)[](https://www.reddit.com/submit?url=https%3A%2F%2Fgids.llmnet.nl%2Fnginx-reverse-proxy-met-authenticatie-voor-je-lokale-llm&title=Nginx%20reverse%20proxy%20met%20authenticatie%20voor%20je%20LLM)[](#)

 
# Nginx reverse proxy met authenticatie voor je lokale LLM

 Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini)

 Binnen de route van lokaal AI draaien bevindt dit artikel zich in de fase beheren en serveren, direct volgend op de initiële installatie van een modelruntime. Wie een eigen AI-infrastructuur opzet, selecteert voorafgaand de benodigde componenten via het overzicht over [welke hardware nodig is voor lokale LLM's](https://gids.llmnet.nl/hardware-voor-lokale-llm) en richt de onderliggende host in aan de hand van het stappenplan voor [lokale LLM's draaien op Linux](https://gids.llmnet.nl/lokale-llm-op-linux). Zodra backends zoals Ollama, llama.cpp server of vLLM operationeel zijn, ontstaat onvermijdelijk de vraag hoe deze capaciteit betrouwbaar kan worden gedeeld met andere werkstations, applicaties of mobiele apparaten in het netwerk. Zonder extra tussenlaag luisteren deze programma's standaard zonder enige vorm van beveiliging op poorten zoals 11434 of 8000.

 Een doordachte reverse proxy-configuratie met Nginx fungeert als het centrale toegangsschild voor de rekenkracht van je grafische kaart. Hiermee dwingen we sterke TLS-versleuteling af, eisen we geldige API-tokens of wachtwoorden voordat een verzoek de inferentie-engine bereikt, en beschermen we het GPU-geheugen tegen overvraging via fijnmazige rate limiting. In dit artikel behandelen we stap voor stap de configuratie, de specifieke streaming-eisen voor realtime tokengeneratie en de bijbehorende netwerkarchitectuur.

 
 Hardware- en software-uitgangspunten voor deze configuratie:
 
 
- Host-besturingssysteem: Linux serverdistributie (zoals Debian 12 of Ubuntu LTS)
 
- Webserver: Nginx (stabiele distributieversie met HTTP/2 en OpenSSL-ondersteuning)
 
- LLM Backends: Ollama (poort 11434) of vLLM (poort 8000) gebonden aan loopback
 
- Hardware referentieprofiel: Dedicated modelhost met 64 GB RAM en 24 GB VRAM
 
- Modelconfiguratie: Open instructiemodel (zoals Qwen of Llama) in Q4-kwantisatie. Voor de achtergrond over gewichtscompressie en geheugenimpact, zie de uitleg over [kwantisatie bij lokale taalmodellen](https://gids.llmnet.nl/kwantisatie-uitgelegd).
 
 

 
## Waarom inferentie-engines van nature netwerkbeveiliging missen

 Softwareprojecten voor lokale inferentie zijn in de eerste plaats gebouwd voor maximale rekenprestaties en eenvoudige lokale integratie. Wanneer Ollama of llama-server wordt gestart, bindt het proces zich standaard aan het lokale loopback-adres (127.0.0.1). Zodra een beheerder via omgevingsvariabelen zoals OLLAMA_HOST=0.0.0.0 de poort openzet naar het lokale netwerk, ontbreekt elk intern mechanisme voor toegangscontrole. Er zijn geen ingebouwde rollen, geen geldigheidstermijnen voor sessies en geen cryptografische controles op inkomende IP-pakketten.

 Het direct blootstellen van een onbeveiligde engine aan een lokaal bedrijfs- of thuisnetwerk brengt aanzienlijke risico's met zich mee. Iedere client op hetzelfde subnet kan willekeurige modelverzoeken indienen, contextvensters van tienduizenden tokens forceren of modellen uit het geheugen ontladen en vervangen door andere varianten. Omdat een taalmodel tijdens tokengeneratie de volledige capaciteit van een GPU kan opeisen, leidt één ongecontroleerd script al snel tot een algehele onbeschikbaarheid van de host. Bovendien lopen onversleutelde HTTP-verbindingen het gevaar te worden afgeluisterd door andere netwerkapparaten. Voor een breder overzicht van firewall-zones en netwerksegmentatie verwijzen we naar het artikel over [lokale LLM-servers veilig inrichten in je netwerk](https://gids.llmnet.nl/lokale-llm-netwerk-beveiliging).

 
## De netwerkarchitectuur: Loopback binding, SSL-terminatie en request flow

 De veiligste opzet scheidt de netwerklaag strikt van de rekentaak. De LLM-backend luistert uitsluitend op de interne loopback-interface (127.0.0.1) en weigert rechtstreeks verkeer vanaf externe netwerkkaarten. Nginx fungeert als de enige publieke ingang op de machine, luisterend op TCP-poort 443 (HTTPS) en poort 80 (uitsluitend voor een permanente HTTP 301 doorverwijzing naar HTTPS).

 De interactie tussen client en taalmodel wijkt op twee cruciale punten af van standaard webpagina's:

 
 
- Lange verwerkingstijd vóór de eerste byte: Het inlezen van een omvangrijke systeemprompt en contextgeschiedenis (de prompt-verwerkingsfase) vraagt tijd voordat de GPU de eerste voorspelde token retourneert. Standaard webserver-timeouts van 30 of 60 seconden kunnen verbindingen voortijdig verbreken.
 
- Continue streaming via Server-Sent Events (SSE): Gebruikersinterfaces tonen gegenereerde woorden incrementeel. Nginx moet inkomende datablokken direct doorsluizen naar de client zonder te wachten tot de interne transmissiebuffer gevuld is.
 

 
## Nginx installeren en modulair inrichten

 De installatie begint met het toevoegen van Nginx en de bijbehorende hulpprogramma's voor wachtwoordbeheer via de pakketbeheerder van het besturingssysteem:

 # Pakketbronnen bijwerken en Nginx met utility-tools installeren
sudo apt update
sudo apt install -y nginx apache2-utils

# Verifiëren dat de service correct is gestart
sudo systemctl status nginx

 Om configuraties overzichtelijk te houden, plaatsen we de proxy-definities in een apart bestand onder /etc/nginx/sites-available/llm-proxy.conf en activeren we dit via een symbolische link naar /etc/nginx/sites-enabled/. Dit voorkomt vervuiling van het algemene nginx.conf-bestand en maakt snel in- en uitschakelen mogelijk.

 
## Authenticatie met statische Bearer-tokens via Nginx map-tabellen

 Veel client-applicaties, SDK's (zoals de OpenAI Python-bibliotheek) en programmeerframeworks communiceren met taalmodellen via een HTTP Authorization: Bearer <TOKEN> header. Nginx biedt met de map-directieve een uiterst efficiënte methode om inkomende headers in het geheugen te verifiëren zonder dat hiervoor een externe database of auth-service geraadpleegd hoeft te worden.

 Voor diepgaande achtergrond over het structureren van tokenformaten en het scheiden van rollen raadpleeg je het gidsartikel over [authenticatie en autorisatie voor je eigen API](https://api.llmnet.nl/eigen-api-authenticatie-autorisatie). We definiëren een mapping in het HTTP-blok die een variabele $api_client vult met een herkenbare clientnaam zodra een legitiem token wordt meegestuurd:

 # Plaats dit configuratieblok in /etc/nginx/conf.d/llm_auth_map.conf
map $http_authorization $api_client {
 default "";
 "Bearer sk-intern-automatisering-8812" "n8n_agent";
 "Bearer sk-ontwikkeling-werkstation-4421" "dev_machine";
 "Bearer sk-beheer-laptop-3190" "beheerder";
}

 In het serverblok verifiëren we vervolgens of de variabele $api_client gevuld is. Is dit niet het geval, dan breekt Nginx de verbinding onmiddellijk af met een HTTP 401 Unauthorized respons, nog voordat het verzoek naar de inferentie-engine kan doorstromen:

 # Controle binnen het location blok
if ($api_client = "") {
 default_type application/json;
 return 401 '{"error": "Ongeldige of ontbrekende Bearer-token"}';
}

 Voor instructies over het veilig genereren, roteren en geheimhouden van deze tokens binnen ontwikkelomgevingen lees je het dossier over [API-sleutels voor LLM's veilig beheren](https://api.llmnet.nl/api-sleutels-veilig-beheren).

 
## Beveiliging via HTTP Basic Auth voor browser- en dashboardclients

 Niet elke toepassing ondersteunt Bearer-authenticatie via headers. Voor webbrowsers, statische dashboards of eenvoudige geautomatiseerde webhooks vormt HTTP Basic Auth een solide en breed ondersteunde beveiligingslaag. We genereren een wachtwoordenbestand met behulp van bcrypt-versleuteling:

 # Nieuw bestand genereren met sterke bcrypt-hashing (-B)
sudo htpasswd -B -c /etc/nginx/.htpasswd llm_beheerder

# Bestandsrechten strikt instellen voor de Nginx-proceseigenaar
sudo chown www-data:www-data /etc/nginx/.htpasswd
sudo chmod 600 /etc/nginx/.htpasswd

 Binnen een specifiek Nginx-locatieblok activeren we de controle met twee eenvoudige regels:

 auth_basic "Lokale AI Toegang Beveiligd";
auth_basic_user_file /etc/nginx/.htpasswd;

 
## Realtime token streaming: SSE, bufferbeheer en verhoogde timeouts

 Het belangrijkste operationele knelpunt bij het routeren van LLM-verkeer via een proxy is de standaard bufferstrategie van Nginx. Nginx verzamelt normaliter gegevenspakketjes van de upstream-server totdat een interne buffer vol is alvorens deze door te sturen naar de client. Bij Server-Sent Events (SSE) leidt dit ertoe dat woorden die het model genereert worden vastgehouden; de gebruiker ziet een lange pauze, gevolgd door een plotselinge dump van meerdere regels tekst tegelijk.

 Om dit te voorkomen schakelen we buffering expliciet uit met proxy_buffering off; en verhogen we de reactietimeouts naar minimaal 600 seconden. Bij zware modelengines zoals vLLM, waar gelijktijdige batchverwerkingen tijdelijke wachtrijen kunnen veroorzaken, is een ruime timeout essentieel. Raadpleeg voor verdere optimalisaties aan de engine-zijde de handleiding over [vLLM configureren voor hoge doorvoer op Linux](https://gids.llmnet.nl/vllm-server-configureren).

 
 
 
 
 Nginx Parameter | 
 Standaardinstelling | 
 Aanbevolen voor LLM | 
 Toelichting op de werking | 
 

 
 
 
 proxy_buffering | 
 on | 
 off | 
 Schakelt response-caching uit; tokens verschijnen direct live bij de client. | 
 

 
 proxy_read_timeout | 
 60s | 
 600s | 
 Voorkomt vroegtijdige HTTP 504 timeouts tijdens zware modelverwerking. | 
 

 
 proxy_connect_timeout | 
 60s | 
 10s | 
 Signaleert snel wanneer de achterliggende LLM-daemon niet reageert. | 
 

 
 proxy_http_version | 
 1.0 | 
 1.1 | 
 Vereist voor HTTP/1.1 chunked transfer encoding en persistent connections. | 
 

 
 client_max_body_size | 
 1m | 
 64m | 
 Maakt het uploaden van grote RAG-documenten en afbeeldingsprompts mogelijk. | 
 

 
 
 

 
## Rate limiting en concurrency: de GPU beschermen tegen overbelasting

 Een modelserver kan slechts een beperkt aantal gelijktijdige tokengeneraties verwerken voordat de geheugenbandbreedte verzadigd raakt of het VRAM overloopt. Door Nginx rate limiting in te richten, beschermen we de GPU tegen plotselinge pieken in het aantal aanroepen.

 We definiëren een rate-limiting zone in het HTTP-blok op basis van het client-IP ($binary_remote_addr). Hiermee stellen we een limiet in van bijvoorbeeld 10 verzoeken per minuut voor generatieve eindpunten:

 # Definieer de rate limit zone in het http-blok
limit_req_zone $binary_remote_addr zone=llm_generatie:10m rate=10r/m;

 In het proxy-locatieblok koppelen we deze zone en voegen we een burst-buffer toe. Hierdoor mogen korte pieken tijdelijk opgevangen worden zonder dat er direct een HTTP 429 foutmelding volgt:

 # Binnen het location / blok
limit_req zone=llm_generatie burst=3 nodelay;
limit_req_status 429;

 
## Het complete Nginx configuratiebestand voor productieworkloads

 Hieronder staat het complete configuratiebestand dat TLS-versleuteling, Bearer-token authenticatie, rate limiting en geoptimaliseerde streamingparameters verenigt in één coherente serverdefinitie. Sla deze configuratie op in /etc/nginx/sites-available/llm-proxy.conf.

 # HTTP: Automatische permanente omleiding naar HTTPS
server {
 listen 80;
 listen [::]:80;
 server_name ai-server.lokaal;

 return 301 https://$host$request_uri;
}

# HTTPS: Beveiligd proxy-eindpunt
server {
 listen 443 ssl;
 listen [::]:443 ssl;
 http2 on;
 server_name ai-server.lokaal;

 # SSL Certificaten (bijv. via een interne CA of Let's Encrypt)
 ssl_certificate /etc/ssl/certs/llm-proxy.crt;
 ssl_certificate_key /etc/ssl/private/llm-proxy.key;

 # Moderne encryptieprotocollen
 ssl_protocols TLSv1.2 TLSv1.3;
 ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
 ssl_prefer_server_ciphers off;
 ssl_session_cache shared:SSL:10m;
 ssl_session_timeout 1d;

 # Essentiële beveiligingsheaders
 add_header X-Content-Type-Options nosniff always;
 add_header X-Frame-Options DENY always;
 add_header Referrer-Policy no-referrer always;

 # Toegestane payloadgrootte voor omvangrijke prompts
 client_max_body_size 64M;

 # Hoofdlocatie voor AI-inferentie
 location / {
 # 1. Authenticatiecontrole via de geconfigureerde map-tabel
 if ($api_client = "") {
 default_type application/json;
 return 401 '{"error": "Toegang geweigerd: Geen geldige API-sleutel"}';
 }

 # 2. Rate limiting toepassen
 limit_req zone=llm_generatie burst=3 nodelay;

 # 3. Doorschakeling naar de lokale LLM backend (Ollama loopback)
 proxy_pass [http://127.0.0.1:11434](http://127.0.0.1:11434);

 # 4. Verbindings- en streamingheaders
 proxy_http_version 1.1;
 proxy_set_header Upgrade $http_upgrade;
 proxy_set_header Connection "upgrade";
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 proxy_set_header X-Client-Name $api_client;

 # 5. Uitschakelen van response-buffering voor SSE
 proxy_buffering off;
 proxy_cache off;
 chunked_transfer_encoding on;

 # 6. Time-outs afgestemd op langdurige tokengeneratie
 proxy_connect_timeout 10s;
 proxy_send_timeout 600s;
 proxy_read_timeout 600s;
 }

 # Onbeveiligd health-check eindpunt voor uptime-monitoring
 location = /health {
 auth_basic off;
 access_log off;
 default_type application/json;
 return 200 '{"status": "online", "service": "llm-proxy"}';
 }
}

 Activeer de configuratie vervolgens door een symbolische link aan te maken en de syntaxis te testen:

 # Configuratie koppelen aan actieve sites
sudo ln -sf /etc/nginx/sites-available/llm-proxy.conf /etc/nginx/sites-enabled/

# Syntaxis en paden controleren
sudo nginx -t

# Nginx herladen zonder actieve netwerkverbindingen te onderbreken
sudo systemctl reload nginx

 
## Verificatie, streamingtests en foutafhandeling met cURL

 Na het herladen van Nginx verifiëren we de werking vanaf een externe machine in het netwerk met twee gerichte cURL-aanroepen.

 Test 1: Verzoek zonder authenticatie (moet direct falen met HTTP 401):

 curl -k -s -o /dev/null -w "%{http_code}\n" [https://ai-server.lokaal/api/generate](https://ai-server.lokaal/api/generate) \
 -H "Content-Type: application/json" \
 -d '{"model": "qwen2.5:14b", "prompt": "Test"}'
# Verwachte statuscode: 401

 Test 2: Verzoek met geldige Bearer-token en streaminguitvoer:

 curl -k -N -X POST [https://ai-server.lokaal/api/generate](https://ai-server.lokaal/api/generate) \
 -H "Authorization: Bearer sk-intern-automatisering-8812" \
 -H "Content-Type: application/json" \
 -d '{
 "model": "qwen2.5:14b",
 "prompt": "Leg in twee korte zinnen uit waarom rate limiting belangrijk is.",
 "stream": true
 }'

 Tijdens Test 2 moeten de JSON-datastromen direct regel voor regel binnenkomen op de terminal, wat bevestigt dat proxy_buffering off; naar behoren functioneert.

 
## Testen met Nederlandse prompts en modelgedrag valideren

 Wanneer de proxy technisch stabiel functioneert, is het raadzaam om de kwaliteit van de antwoorden en de reactietijd op Nederlandstalige instructies te toetsen. Lokale modellen vertonen soms afwijkend gedrag bij complexe grammatica of specifieke terminologie. Voor handvatten om de formulering van prompts te optimaliseren raadpleeg je de adviezen over [je AI beter laten presteren in het Nederlands](https://gids.llmnet.nl/beter-nederlands).

 Door testaanroepen uit te voeren met typisch Nederlandse zinsstructuren en samenvattingsopdrachten kan direct worden vastgesteld of de Time-to-First-Token acceptabel blijft onder realistische werklasten.

 
## Privacy, AVG-waarborgen en strikte netwerkisolatie

 Het beveiligen van de toegangspoort tot je lokale modelserver is een essentiële voorwaarde voor het waarborgen van gegevensprivacy. Doordat alle netwerkpakketten via TLS worden versleuteld en uitsluitend geautoriseerde clients toegang krijgen, blijven vertrouwelijke documenten en promptgegevens volledig binnen de eigen beheersomgeving. Er lekken geen gegevens naar externe cloud-aanbieders. Voor een diepere beschouwing van privacykaders binnen IT-infrastructuren verwijzen we naar het artikel over [privacyvriendelijk AI-gebruik](https://gids.llmnet.nl/privacyvriendelijk-ai).

 
## Stroomverbruik en operationele kosten van een continu actieve server

 Een Nginx-proces verbruikt in rust vrijwel geen meetbare systeembronnen (slechts enkele megabytes RAM en minimale CPU-cycli). De fysieke modelhost waarop de grafische kaart is geplaatst, heeft daarentegen wel een continu basisverbruik wanneer de machine dag en nacht stand-by staat voor netwerkaanroepen. Een modern werkstation met een high-end GPU vraagt in ruststand gemiddeld 35 tot 50 watt, wat tijdens intensieve berekeningen oploopt tot 350 à 450 watt aan het stopcontact. Om een nauwkeurige inschatting te maken van deze doorlopende energielasten, raadpleeg je de berekeningen in de gids over [wat het stroomverbruik van lokale AI kost](https://gids.llmnet.nl/stroomverbruik-lokale-ai).

 
## Beperkingen en afwegingen bij het inzetten van Nginx

 Hoewel Nginx een buitengewoon robuuste en lichte oplossing biedt voor toegangsbeveiliging, kent het systeem enkele duidelijke functionele beperkingen wanneer de omgeving groeit:

 
 
- Statisch sleutelbeheer: Tokens die in een Nginx map worden vastgelegd, vereisen een configuratieherlaad (systemctl reload nginx) bij elke toevoeging of intrekking. Voor dynamische teams met honderden gebruikers is een geavanceerde OAuth2- of OIDC-proxy flexibeler.
 
- Geen inspectie van modelcapaciteit: Nginx routeert op HTTP-niveau en heeft geen inzicht in de beschikbare VRAM-capaciteit of de actuele KV-cache van de LLM-backend. Wanneer meerdere clients tegelijk zware prompts sturen, kan de backend alsnog geheugentekorten oplopen als er geen strikte wachtrijbeheersing op engine-niveau actief is.
 
- Geen token-accounting per gebruiker: Nginx registreert het aantal bytes en HTTP-verzoeken, maar kan niet meten hoeveel context- en generatietokens een specifieke gebruiker consumeert. Wie harde token-quota per project of afdeling wil opleggen, heeft een gespecialiseerde AI-gateway nodig.
 

 Voor thuislabs, interne ontwikkelteams en middelgrote organisaties biedt een zorgvuldig ingerichte Nginx reverse proxy echter een uitstekende balans tussen betrouwbare beveiliging, minimale overhead en maximale controle over de eigen lokale AI-capaciteit.