Nginx als Reverse Proxy konfigurieren (2026)

Ein Reverse Proxy steht zwischen Clients und Ihrer Backend-Anwendung. Nginx empfängt eingehende Anfragen, leitet sie an einen Backend-Server weiter (Node.js, Python, Go, Ollama) und gibt die Antwort an den Client zurück. So können Sie TLS-Terminierung, Lastverteilung, Caching und Zugriffskontrolle hinzufügen, ohne Ihre Anwendung zu ändern.

Dieses Tutorial behandelt die Nginx-Reverse-Proxy-Konfiguration von einem einfachen proxy_pass bis hin zu WebSocket-Proxying, Upstream-Lastverteilung und einem produktionsreifen Ollama-Setup.

Voraussetzungen

Bevor Sie beginnen, benötigen Sie:

Einen VPS mit Debian 12 oder Ubuntu 24.04 und Root- oder Sudo-Zugang
Nginx installiert und aktiv (Nginx auf Debian und Ubuntu installieren)
Eine Backend-Anwendung, die auf einem lokalen Port lauscht (das Tutorial enthält Testbeispiele)
Grundkenntnisse der Nginx-Konfigurationsdateistruktur (Nginx-Konfigurationsdateistruktur)

Prüfen Sie, ob Nginx läuft:

sudo systemctl status nginx

In der Ausgabe sollte active (running) stehen.

Wie konfiguriert man proxy_pass in Nginx?

Die proxy_pass-Direktive teilt Nginx mit, wohin Anfragen weitergeleitet werden. Sie wird innerhalb eines location-Blocks in einem server-Block platziert. Nginx sendet die Anfrage des Clients an die angegebene Backend-URL und streamt die Antwort zurück. Die Direktive akzeptiert HTTP- und HTTPS-URLs und kann auf eine IP-Adresse, einen Domainnamen oder einen Unix-Socket verweisen.

Erstellen Sie eine neue Server-Block-Datei:

sudo nano /etc/nginx/sites-available/app.conf

Fügen Sie eine minimale Reverse-Proxy-Konfiguration hinzu:

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Aktivieren Sie die Seite und testen Sie die Konfiguration:

sudo ln -s /etc/nginx/sites-available/app.conf /etc/nginx/sites-enabled/
sudo nginx -t

Wenn nginx -t syntax is ok und test is successful zurückgibt, laden Sie neu:

sudo systemctl reload nginx

Prüfen Sie, ob der Proxy funktioniert:

curl -I http://app.example.com

Die Antwort-Header sollten von Ihrer Backend-Anwendung stammen. Wenn Sie einen 502 Bad Gateway erhalten, läuft Ihr Backend nicht auf Port 3000.

Was bewirkt ein abschließender Slash bei proxy_pass?

Der abschließende Slash (Trailing Slash) in proxy_pass steürt das URI-Rewriting. Dies ist eine der häufigsten Fehlerqüllen bei der Konfiguration.

Konfiguration	Anfrage	Weitergeleitet an Backend
`proxy_pass http://127.0.0.1:3000`	`/app/users`	`http://127.0.0.1:3000/app/users`
`proxy_pass http://127.0.0.1:3000/`	`/app/users`	`http://127.0.0.1:3000/users`
`proxy_pass http://127.0.0.1:3000/v2/`	`/app/users`	`http://127.0.0.1:3000/v2/users`
`proxy_pass http://127.0.0.1:3000/v2`	`/app/users`	`http://127.0.0.1:3000/v2users`

Die Regel: Wenn proxy_pass eine URI enthält (alles nach Host:Port, selbst nur /), entfernt Nginx das passende location-Präfix aus der Anfrage-URI und hängt den Rest an die proxy_pass-URI an. Wenn proxy_pass keine URI hat, wird der ursprüngliche Anfragepfad unverändert durchgereicht.

Für einen location /app/-Block gelten die obigen Beispiele. Beachten Sie die vierte Zeile: Ohne abschließenden Slash bei /v2 wird der Pfad zu /v2users statt /v2/users. Fügen Sie immer einen abschließenden Slash hinzu, wenn Sie einen Pfad angeben.

Welche Header sollten Sie an das Backend weiterleiten?

Ohne explizite Header-Konfiguration kann Ihre Backend-Anwendung die echte IP-Adresse des Clients, das ursprüngliche Protokoll oder den angeforderten Hostnamen nicht sehen. Nginx ersetzt diese standardmäßig. Leiten Sie sie manüll weiter.

Header	Wert	Zweck
`Host`	`$host`	Bewahrt den originalen Host-Header, damit das Backend weiss, welche Domain angefragt wurde
`X-Real-IP`	`$remote_addr`	Übergibt die IP-Adresse des Clients an das Backend
`X-Forwarded-For`	`$proxy_add_x_forwarded_for`	Hängt die Client-IP an die Proxy-Kette an
`X-Forwarded-Proto`	`$scheme`	Teilt dem Backend mit, ob die ursprüngliche Anfrage HTTP oder HTTPS verwendete

Fügen Sie diese Header zu Ihrem location-Block hinzu:

location / {
    proxy_pass http://127.0.0.1:3000;
    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;
}

Laden Sie Nginx neu und prüfen Sie, ob die Header beim Backend ankommen. Wenn Ihre Anwendung eingehende Header protokolliert, kontrollieren Sie diese:

sudo systemctl reload nginx
curl -s http://app.example.com/headers

Ihr Backend sollte bei X-Real-IP die IP des Clients anzeigen, nicht 127.0.0.1. Wenn 127.0.0.1 erscheint, fehlen die proxy_set_header-Direktiven oder sie stehen im falschen Kontext.

Sicherheitshinweis: Verwenden Sie $proxy_add_x_forwarded_for statt $remote_addr für X-Forwarded-For. Es hängt die Client-IP an einen eventüll vorhandenen X-Forwarded-For-Header an. Wenn Sie nur $remote_addr setzen, geht die Proxy-Kette verloren, was die IP-Nachverfolgung hinter mehreren Proxys stört. Wenn Nginx Ihr einziger Proxy ist, sind beide gleichwertig.

Wie richten Sie einen Reverse Proxy für eine Node.js-Anwendung ein?

Hier ist ein vollständiger Server-Block zum Proxying einer Node.js-Anwendung auf Port 3000. Dieses Beispiel beinhaltet Header-Weiterleitung, WebSocket-Unterstützung und Versionsausblendung.

Erstellen Sie den Server-Block:

sudo nano /etc/nginx/sites-available/nodeapp.conf

server {
    listen 80;
    server_name nodeapp.example.com;

    # Hide Nginx version in responses
    server_tokens off;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;

        # Header forwarding
        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;

        # WebSocket support
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # Timeouts
        proxy_connect_timeout 60s;
        proxy_read_timeout 60s;
        proxy_send_timeout 60s;
    }
}

Aktivieren, testen und neu laden:

sudo ln -s /etc/nginx/sites-available/nodeapp.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Prüfen Sie, ob der Proxy funktioniert:

curl -I http://nodeapp.example.com

Achten Sie darauf: Die Antwort sollte keine Zeile Server: nginx/1.x.x enthalten. Die Direktive server_tokens off blendet die Versionsnummer aus. Versionsinformationen helfen Angreifern, bekannte Schwachstellen gezielt auszunutzen.

Für TLS-Terminierung mit Let's Encrypt siehe Nginx SSL/TLS mit Let's Encrypt.

Wie leiten Sie WebSocket-Verbindungen überNginx weiter?

WebSocket-Verbindungen beginnen als HTTP-Anfrage mit einem Upgrade-Header und wechseln dann zu einer persistenten bidirektionalen Verbindung. Nginx verwendet standardmäßig HTTP/1.0 für Upstream-Verbindungen, was den Upgrade-Mechanismus nicht unterstützt. Sie benötigen drei Direktiven, damit WebSocket funktioniert: proxy_http_version auf 1.1 setzen, den Upgrade-Header weiterleiten und den Connection-Header auf "upgrade" setzen.

Für Locations, die sowohl regulären HTTP- als auch WebSocket-Verkehr bedienen, verwenden Sie die map-Direktive, um den Connection-Header bedingt zu setzen. Fügen Sie dies zum http-Block in /etc/nginx/nginx.conf hinzu:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

Referenzieren Sie dann $connection_upgrade in Ihrem Server-Block:

server {
    listen 80;
    server_name ws.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $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;

        # Prevent idle timeout killing WebSocket connections
        proxy_read_timeout 3600s;
        proxy_send_timeout 3600s;
    }
}

Der Standard-proxy_read_timeout beträgt 60 Sekunden. Wenn in diesem Zeitfenster keine Daten überdie Verbindung fliessen, schließt Nginx sie. Setzen Sie den Wert für WebSocket-Verbindungen höher. Ihre Anwendung sollte WebSocket-Ping-Frames in einem kürzeren Intervall als dieses Timeout senden.

Testen Sie die Konfiguration:

sudo nginx -t && sudo systemctl reload nginx

Um die WebSocket-Konnektivität zu prüfen, installieren Sie wscat und verbinden Sie sich:

npm install -g wscat
wscat -c ws://ws.example.com/

Wenn die Verbindung aufgebaut wird, funktioniert das WebSocket-Proxying. Wenn Sie unexpected server response (200) erhalten, werden die Upgrade-Header nicht weitergeleitet. Prüfen Sie, ob die map-Direktive innerhalb des http-Blocks steht und nicht innerhalb eines server-Blocks.

Wie richten Sie einen Reverse Proxy für Ollama (Self-Hosted AI) ein?

Ollama stellt LLM-Inferenz standardmäßig auf Port 11434 bereit und bindet sich an 127.0.0.1. Ein Nginx-Proxy davor ermöglicht TLS, Authentifizierung und Zugriffskontrolle, ohne die Ollama-Konfiguration zu ändern. Der zentrale Unterschied zum Standard-Proxying: LLM-Inferenz kann mehrere Minuten daürn, und Streaming-Antworten erfordern deaktiviertes Buffering.

Erstellen Sie den Server-Block:

sudo nano /etc/nginx/sites-available/ollama.conf

server {
    listen 80;
    server_name ollama.example.com;

    server_tokens off;

    # Restrict access to specific IPs
    allow 192.168.1.0/24;
    allow 10.0.0.0/8;
    deny all;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_http_version 1.1;

        # Header forwarding
        proxy_set_header Host localhost:11434;
        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 Connection '';

        # Disable buffering for streaming responses
        proxy_buffering off;
        proxy_cache off;
        chunked_transfer_encoding on;

        # Extended timeouts for LLM inference
        proxy_connect_timeout 300s;
        proxy_read_timeout 600s;
        proxy_send_timeout 600s;
    }
}

Aktivieren und testen:

sudo ln -s /etc/nginx/sites-available/ollama.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Prüfen Sie, ob Ollama überden Proxy antwortet:

curl http://ollama.example.com/api/tags

Sie sollten eine JSON-Antwort mit den verfügbaren Modellen erhalten. Wenn Sie einen 403 Forbidden bekommen, ist Ihre Client-IP nicht in der allow-Liste. Wenn Sie einen 502 Bad Gateway erhalten, läuft Ollama nicht:

sudo systemctl status ollama

Testen Sie eine Streaming-Vervollständigung:

curl -N http://ollama.example.com/api/generate -d '{
  "model": "llama3.2",
  "prompt": "Hello",
  "stream": true
}'

Achten Sie darauf: Das -N-Flag deaktiviert das Ausgabe-Buffering von curl. Sie sollten Token einzeln ankommen sehen. Wenn die gesamte Antwort auf einmal eintrifft, ist proxy_buffering off nicht gesetzt oder wird überschrieben.

Warum sich diese Einstellungen vom Standard-Proxy unterscheiden:

proxy_buffering off: Nginx puffert Backend-Antworten normalerweise und sendet sie als Block. Für LLM-Streaming soll jedes Token sofort an den Client gesendet werden.
proxy_read_timeout 600s: LLM-Inferenz bei großen Modellen kann mehrere Minuten daürn. Der Standard von 60s würde die Verbindung mitten in der Generierung trennen.
proxy_set_header Host localhost:11434: Ollama prüft den Host-Header und lehnt Anfragen ab, die nicht seiner konfigurierten Bind-Adresse entsprechen.
proxy_set_header Connection '': Leert den Connection-Header, um Keep-Alive-Probleme beim Chunked Streaming zu vermeiden.

Für TLS-Terminierung, um Ollama sicher überdas Internet bereitzustellen, siehe Nginx SSL/TLS mit Let's Encrypt. Stellen Sie Ollama niemals ohne Zugriffskontrolle bereit. Kombinieren Sie IP-Einschränkungen mit HTTP Basic Auth oder API-Key-Validierung für den Produktionsbetrieb.

Um HTTP Basic Auth zusätzlich zu IP-Einschränkungen hinzuzufügen:

sudo apt install apache2-utils
sudo htpasswd -c /etc/nginx/.ollama_htpasswd apiuser
sudo chmod 640 /etc/nginx/.ollama_htpasswd
sudo chown root:www-data /etc/nginx/.ollama_htpasswd

Fügen Sie dann zum location-Block in ollama.conf hinzu:

    auth_basic "Ollama API";
    auth_basic_user_file /etc/nginx/.ollama_htpasswd;

Prüfen Sie die Dateiberechtigungen:

ls -la /etc/nginx/.ollama_htpasswd

Die Datei sollte -rw-r----- mit Eigentümer root und Gruppe www-data anzeigen. Eingeschränkte Berechtigungen verhindern, dass andere Benutzer auf dem Server die Passwort-Hashes lesen können.

Wie konfiguriert man Upstream-Lastverteilung?

Der upstream-Block definiert eine Gruppe von Backend-Servern, auf die Nginx Anfragen verteilt. Standardmässig verwendet Nginx gewichtetes Round-Robin. Jeder Server erhält einen Anteil der Anfragen proportional zu seinem Gewicht (Standardgewicht: 1).

Fügen Sie einen upstream-Block vor Ihrem server-Block hinzu:

upstream app_backends {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://app_backends;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Lastverteilungsmethoden

Round-Robin (Standard): Anfragen werden gleichmäßig auf die Server verteilt. Keine Direktive erforderlich.

Least Connections (wenigste Verbindungen): Sendet Anfragen an den Server mit den wenigsten aktiven Verbindungen. Besser für Backends mit unterschiedlichen Antwortzeiten:

upstream app_backends {
    least_conn;
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

IP Hash: Bindet jede Client-IP an ein bestimmtes Backend. Nützlich für Session-Persistenz ohne Sticky Cookies:

upstream app_backends {
    ip_hash;
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

Gesundheitsprüfungen mit max_fails und fail_timeout

Nginx überwacht die Backend-Gesundheit passiv. Wenn ein Server nicht antwortet, markiert Nginx ihn als nicht verfügbar und sendet für einen Zeitraum keine Anfragen mehr.

upstream app_backends {
    server 127.0.0.1:3000 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:3001 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:3002 backup;
}

Parameter	Standard	Beschreibung
`max_fails`	1	Anzahl fehlgeschlagener Versuche innerhalb von `fail_timeout`, bevor der Server als nicht verfügbar markiert wird
`fail_timeout`	10s	Zeitfenster zum Zählen von Fehlern und Daür der Nichtverfügbarkeitsmarkierung
`backup`	-	Server empfängt nur Anfragen, wenn alle primären Server ausgefallen sind
`weight`	1	Relativer Anteil der Anfragen beim Round-Robin

Testen und laden Sie nach der Upstream-Konfiguration neu:

sudo nginx -t && sudo systemctl reload nginx

Prüfen Sie die Lastverteilung, indem Sie mehrere Anfragen senden und kontrollieren, welches Backend antwortet:

for i in $(seq 1 6); do curl -s http://app.example.com/health; echo; done

Wenn Ihre Backends eine Kennung in der Antwort zurückgeben, sollten Sie sehen, dass Anfragen auf sie verteilt werden.

Wie passen Sie Proxy-Buffering und Timeouts an?

Nginx puffert Backend-Antworten standardmäßig. Es liest die gesamte Antwort vom Backend in den Speicher (oder auf die Festplatte, wenn der Puffer überschritten wird) und sendet sie dann an den Client. Das ist für die meisten Anwendungen effizient, aber falsch für Streaming, Server-Sent Events (SSE) oder Long-Polling.

Timeout-Direktiven

Direktive	Standard	Empfohlen	Zweck
`proxy_connect_timeout`	60s	5-10s	Zeit zum Aufbau der Verbindung zum Backend. Kurz halten für schnelles Scheitern.
`proxy_read_timeout`	60s	60-300s	Wartezeit auf Backend-Antwort. Erhöhen für langsame APIs.
`proxy_send_timeout`	60s	60s	Zeit zum Senden des Reqüst-Body an das Backend. Erhöhen für große Uploads.

location / {
    proxy_pass http://127.0.0.1:3000;

    proxy_connect_timeout 10s;
    proxy_read_timeout 120s;
    proxy_send_timeout 60s;
}

Diese Timeouts gelten zwischen zwei aufeinanderfolgenden Lese-/Schreiboperationen, nicht für die gesamte Anfrage. Eine Antwort, die alle 30 Sekunden Daten sendet, löst nie einen 60-Sekunden-proxy_read_timeout aus.

Buffering-Steürung

Direktive	Standard	Beschreibung
`proxy_buffering`	on	Gesamte Backend-Antwort puffern, bevor sie an den Client gesendet wird
`proxy_buffer_size`	4k oder 8k	Puffer für den ersten Teil der Antwort (Header)
`proxy_buffers`	8 4k oder 8 8k	Anzahl und Größe der Puffer für den Antwortkörper
`proxy_busy_buffers_size`	8k oder 16k	Maximale Größe der Puffer, die gleichzeitig zum Senden an den Client belegt sein können

Wann sollten Sie Proxy-Buffering deaktivieren?

Deaktivieren Sie Buffering, wenn das Backend Daten streamt: LLM-Inferenz (Ollama, vLLM), Server-Sent Events, WebSocket-ähnliche Langantworten oder jede API, die Chunked-Daten inkrementell sendet.

location /stream/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_buffering off;
}

Lassen Sie Buffering für Standard-Reqüst/Response-APIs aktiviert. Buffering schützt Ihr Backend vor langsamen Clients: Nginx nimmt die Antwort schnell auf und sendet sie mit der Geschwindigkeit des Clients. Ohne Buffering hält ein langsamer Client eine Backend-Verbindung offen.

Für fortgeschrittenes Performance-Tuning siehe .

Wie beheben Sie 502- und 504-Fehler?

502 Bad Gateway bedeutet, dass Nginx keine Verbindung zum Backend herstellen konnte oder das Backend eine ungültige Antwort gesendet hat. 504 Gateway Timeout bedeutet, dass das Backend nicht innerhalb von proxy_read_timeout geantwortet hat.

502 Bad Gateway Checkliste

Läuft das Backend?

ss -tlnp | grep 3000

Keine Ausgabe bedeutet, dass Ihr Backend nicht auf Port 3000 lauscht. Starten Sie es.

Ist die proxy_pass-URL korrekt? Prüfen Sie auf Tippfehler bei Portnummer oder IP-Adresse. Häufiger Fehler: https:// für ein Backend verwenden, das nur HTTP spricht.
Blockiert SELinux die Verbindung? (RHEL/CentOS)

sudo setsebool -P httpd_can_network_connect 1

Prüfen Sie das Nginx-Fehlerprotokoll:

sudo tail -20 /var/log/nginx/error.log

Suchen Sie nach connect() failed (111: Connection refused) oder no live upstreams.

504 Gateway Timeout Checkliste

proxy_read_timeout erhöhen:

proxy_read_timeout 300s;

Prüfen Sie, ob das Backend langsam ist:

time curl http://127.0.0.1:3000/slow-endpoint

Wenn dies länger als Ihr proxy_read_timeout daürt, erhöhen Sie den Timeout oder optimieren Sie das Backend.

Upstream-Gesundheit prüfen: Bei Verwendung von Upstream-Blöcken könnten alle Server als ausgefallen markiert sein. Prüfen Sie das Fehlerprotokoll auf no live upstreams while connecting to upstream.

Nginx-Protokolle lesen

Nginx schreibt Fehlerdetails nach /var/log/nginx/error.log. Für Echtzeit-Monitoring:

sudo journalctl -u nginx -f

Oder beobachten Sie das Fehlerprotokoll direkt:

sudo tail -f /var/log/nginx/error.log

Für Protokolle pro Website fügen Sie access_log- und error_log-Direktiven zu Ihrem Server-Block hinzu:

server {
    listen 80;
    server_name app.example.com;

    access_log /var/log/nginx/app-access.log;
    error_log /var/log/nginx/app-error.log;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

So werden Protokolle nach Anwendung getrennt, was das Debuggen von Problemen mit einem bestimmten Backend vereinfacht.

Häufige Header-Probleme

Wenn Ihr Backend 127.0.0.1 als Client-IP empfängt statt der echten Adresse, fehlt die Direktive proxy_set_header X-Real-IP $remote_addr. Wenn Ihre Anwendung HTTP-Links mit http:// generiert, obwohl sie https:// verwenden sollte, wird der X-Forwarded-Proto-Header nicht weitergeleitet. Einige Frameworks (Express, Django, Rails) benötigen explizite Konfiguration, um Proxy-Headern zu vertraün. In Express:

app.set('trust proxy', 1);

In Django setzen Sie SECURE_PROXY_SSL_HEADER:

SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')

Ohne diese Einstellungen ignoriert Ihre Anwendung die weitergeleiteten Header, auch wenn Nginx sie korrekt sendet.

Referenz: Proxy-Direktiven

Zur schnellen Referenz hier der minimale Satz an Direktiven für verschiedene Proxy-Szenarien:

# Standard HTTP proxy
location / {
    proxy_pass http://127.0.0.1:3000;
    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;
}

# WebSocket proxy
location /ws/ {
    proxy_pass http://127.0.0.1:8080;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_read_timeout 3600s;
}

# Streaming proxy (SSE, LLM)
location /stream/ {
    proxy_pass http://127.0.0.1:11434;
    proxy_http_version 1.1;
    proxy_buffering off;
    proxy_cache off;
    proxy_read_timeout 600s;
}

Für Server-Blöcke mit mehreren Domains siehe Nginx Server Blocks. Für Sicherheitshärtung einschliesslich Rate Limiting und Zugriffskontrolle siehe .

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfältigung, Wiederveröffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.

Verwandte Artikel