~/ / KI-Artikel / Lokale LLMs auf einem VPS / nginx vor Ollama schalten: Basic Authentication, HTTPS und Einstellungen für Streaming

nginx vor Ollama schalten: Basic Authentication, HTTPS und Einstellungen für Streaming

Ollama lauscht standardmäßig nur auf dem Server selbst, und das ist der sicherste Ort dafür. Wenn ein anderer Rechner darauf zugreifen muss, verweist die Ollama-FAQ auf einen Proxyserver wie nginx. Dieser Artikel baut dieses Setup anhand der nginx-Dokumentation auf: ein Passwort, HTTPS, die Einstellungen, die für gestreamte Antworten wichtig sind, und eine Firewall, die die übrigen Zugänge schließt.

Veröffentlicht: 2026-10-26 · 5 Min. Lesezeit · Geprüft anhand der offiziellen Dokumentation von Ollama und nginx am 2026-10-26. Die Standardwerte der Direktiven hängen von der nginx-Version ab; prüfen Sie daher die Version, die Sie einsetzen.

Was die Ollama-FAQ sagt

Laut Ollama-FAQ betreibt Ollama einen HTTP-Server und kann über einen Proxyserver wie Nginx erreichbar gemacht werden. Das Beispiel dort lauscht auf Port 80, setzt einen server_name, leitet Anfragen mit proxy_pass http://localhost:11434 weiter und setzt den Host-Header auf localhost:11434.

Die FAQ-Seite, die wir geprüft haben, beschreibt keinerlei Authentifizierung für den Ollama-Server. Deshalb muss das Passwort vom vorgeschalteten Proxy kommen. Ollama bindet standardmäßig 127.0.0.1 auf Port 11434, sodass ein nginx auf demselben Server es erreichen kann, ohne diese Adresse zu ändern.

Ein Passwort per Basic Authentication

Das ngx_http_auth_basic_module beschränkt den Zugriff durch eine Prüfung von Benutzername und Passwort. Zwei Direktiven erledigen die Arbeit: auth_basic, dessen Zeichenfolge als Realm verwendet wird und das standardmäßig off ist, und auth_basic_user_file, das die Passwortdatei benennt.

Direktive	Standard	Was die Dokumentation sagt
auth_basic string \| off;	off	Der Parameter wird als Authentifizierungs-Realm verwendet. Der Wert off hebt eine von einer vorherigen Ebene geerbte Einstellung auf.
auth_basic_user_file file;	keiner	Die Datei enthält pro Zeile einen Eintrag name:password; Zeilen, die mit # beginnen, sind Kommentare.

Unterstützte Passworttypen: mit crypt() verschlüsselte Passwörter und apr1-Hashes, beide erzeugt mit dem Dienstprogramm htpasswd von Apache oder mit openssl passwd.
Die Syntax {SCHEME}data wird ebenfalls unterstützt. Die Seite sagt, PLAIN sei nur ein Beispiel und solle nicht verwendet werden, und SHA, ein ungesalzenes SHA-1, solle ebenfalls nicht verwendet werden, da es anfällig für Rainbow-Table-Angriffe ist. SSHA ist gesalzenes SHA-1.
Das Beispiel der Dokumentation: location / { auth_basic "closed site"; auth_basic_user_file conf/htpasswd; }

Die Seite nennt htpasswd und openssl passwd, gibt aber keine Befehle an. Gebräuchliche Formen, die von uns stammen und nicht von der Seite, sind htpasswd -c /etc/nginx/ollama.htpasswd alice, das nach einem Passwort fragt, und openssl passwd -apr1, das einen Hash ausgibt, den Sie hinter dem Benutzernamen und einem Doppelpunkt einfügen.

Verschlüsselung mit HTTPS

Unsere Lesart, keine Aussage der Dokumente: Basic Authentication sendet das Passwort bei jeder Anfrage mit, verwenden Sie sie daher nur hinter HTTPS. Laut nginx-Dokumentation braucht ein Server den Parameter ssl an seinem lauschenden Socket sowie die Pfade zu Zertifikat und privatem Schlüssel.

Direktive	Beispiel aus der Dokumentation
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;

Standardmäßig verwendet nginx ssl_protocols TLSv1.2 TLSv1.3 und ssl_ciphers HIGH:!aNULL:!MD5, sodass es in der Regel nicht nötig ist, sie ausdrücklich zu konfigurieren.
Der private Schlüssel sollte in einer Datei mit eingeschränktem Zugriff gespeichert werden, muss aber vom Master-Prozess von nginx lesbar sein.
Wenn Browser bei einem Zertifikat einer bekannten Zertifizierungsstelle Fehler melden, muss der Server möglicherweise die Zwischenzertifikate mitsenden. Das Serverzertifikat muss in der kombinierten Datei vor den verketteten Zertifikaten stehen, sonst startet nginx nicht und meldet einen Fehler wegen nicht übereinstimmender Schlüsselwerte (key values mismatch).
Die Seite „Getting started“ von Let's Encrypt sagt: Wenn Ihr Anbieter Zertifikate nicht für Sie beschafft und Sie Ihren Server administrieren können, können Sie einen ACME-Client ausführen; für die meisten Menschen empfiehlt sie Certbot.

Einstellungen für gestreamte und langsame Antworten

Ein Modell schreibt seine Antwort Stück für Stück, und das erste Stück kann eine Weile auf sich warten lassen, etwa während ein großes Modell in den Speicher geladen wird. Drei nginx-Einstellungen bestimmen, wie sich das von außen darstellt.

Direktive	Standard	Was die Dokumentation sagt
proxy_buffering	on	Bei deaktivierter Pufferung wird die Antwort synchron an den Client weitergegeben, sofort beim Empfang. Bei aktivierter Pufferung speichert nginx die Antwort zunächst in Puffern.
proxy_read_timeout	60s	Das Timeout gilt nur zwischen zwei aufeinanderfolgenden Leseoperationen, nicht für die gesamte Antwort. Überträgt der Proxy-Server innerhalb dieser Zeit nichts, wird die Verbindung geschlossen.
proxy_http_version	1.1 seit nginx 1.29.7	Vor 1.29.7 war der Standard 1.0. Für Keepalive-Verbindungen wird Version 1.1 oder 2 empfohlen.

Unsere Lesart, keine Aussage der Dokumente: Um eine Antwort beim Schreiben mitzuverfolgen, schalten Sie proxy_buffering für die Ollama-Location aus, und wenn das Modell beim Laden länger als eine Minute schweigen kann, erhöhen Sie proxy_read_timeout. Proxy_http_version 1.1 ausdrücklich zu setzen ist bei jeder Version unschädlich.

Alles zusammensetzen

Diese Konfiguration kombiniert die obigen Direktiven für einen Servernamen. Sie ist unsere Zusammenstellung aus den dokumentierten Direktiven, testen Sie sie daher mit nginx -t, bevor Sie neu laden.

Zeile	Warum
server {	ein Server-Block für den Ollama-Namen
listen 443 ssl;	HTTPS
server_name ollama.example.com;	Ihr eigener Name
ssl_certificate /etc/ssl/ollama.crt;	das Zertifikat, mit den Zwischenzertifikaten danach
ssl_certificate_key /etc/ssl/ollama.key;	der private Schlüssel, nur so weit nötig lesbar
auth_basic "ollama";	schaltet das Passwort ein
auth_basic_user_file /etc/nginx/ollama.htpasswd;	wo die Benutzer gespeichert sind
location / {	alles geht an Ollama
proxy_pass http://localhost:11434;	aus der Ollama-FAQ
proxy_set_header Host localhost:11434;	aus der Ollama-FAQ
proxy_http_version 1.1;	empfohlen für Keepalive
proxy_buffering off;	damit die Antwort gestreamt wird
proxy_read_timeout 300s;	erlaubt ein langsames erstes Stück
}	Ende der Location
}	Ende des Servers

Die übrigen Zugänge schließen

Der Proxy hilft nur, wenn niemand Ollama oder die Anwendung dahinter auf anderem Weg erreichen kann. Ollama bleibt auf seiner Standardadresse, und eine Firewall lässt nur die Adressen durch, die Sie verwenden.

Aufgabe	Befehl aus der Ubuntu-Dokumentation
Die Firewall einschalten	sudo ufw enable
Einen Port erlauben	sudo ufw allow 22
Eine Adresse für einen Port erlauben	sudo ufw allow proto tcp from 192.168.0.2 to any port 22
Ein ganzes Subnetz erlauben	ersetzen Sie die Adresse durch 192.168.0.0/24
Den Status prüfen	sudo ufw status

Die Ubuntu-Seite sagt, UFW sei zunächst deaktiviert. Eine Warnung davor, sich per SSH selbst auszusperren, enthält sie nicht. Unsere Empfehlung: Erlauben Sie Ihren SSH-Port, bevor Sie die Firewall auf einem Server einschalten, den Sie aus der Ferne erreichen, und erlauben Sie Port 443 nur von den Adressen, die ihn brauchen.