Ollama im Netzwerk freigeben: Port, Bind-Adresse und Absicherung

Ollama bindet seinen API-Port nach der Installation ausschließlich an 127.0.0.1:11434. Damit erreichst du die Modelle nur von dem Host, auf dem der Dienst läuft. Sobald ein zweiter Rechner, ein Container oder eine Web-UI auf die API zugreifen soll, musst du die Bind-Adresse ändern und den Port im selben Schritt absichern, denn Ollama bringt keine eigene Authentifizierung mit.

Warum ist der Ollama Port standardmäßig nicht erreichbar?

Der Ollama Port 11434 ist von außen nicht erreichbar, weil der Dienst per Voreinstellung OLLAMA_HOST=127.0.0.1:11434 verwendet und damit nur am Loopback-Interface lauscht, nicht an den Netzwerk-Interfaces des Hosts.

Das ist eine bewusste Voreinstellung. Die REST-API von Ollama kennt weder Benutzer noch Tokens: Wer den Port erreicht, kann Modelle ziehen, löschen und beliebige Prompts ausführen. Ein direkt aus dem Internet erreichbarer Port 11434 ist ein offener Inferenz-Endpunkt auf deiner GPU, den fremde Clients auf deine Kosten nutzen können.

Voraussetzungen

• Ein Linux-Host mit systemd und installiertem Ollama, eingerichtet über das offizielle Skript curl -fsSL https://ollama.com/install.sh | sh
• Ollama in Version 0.3 oder neuer, geprüft mit ollama --version
• Ein Benutzerkonto mit sudo-Rechten
• Das interne Subnetz, aus dem die Clients kommen, zum Beispiel 10.0.0.0/24
• Für Modelle ab 13B Parametern eine GPU-Instanz, etwa eine Cloud-GPU für LLM-Inference

Alle Befehle laufen als root oder mit vorangestelltem sudo.

Bind-Adresse über OLLAMA_HOST setzen

Die Bind-Adresse steuerst du ausschließlich über die Umgebungsvariable OLLAMA_HOST im Format host:port. Eine Konfigurationsdatei gibt es nicht. Bei einer systemd-Installation trägst du die Variable in ein Override der Unit ein, damit sie ein Paket-Update übersteht.

systemd-Override anlegen

$ sudo systemctl edit ollama.service

Der Editor öffnet eine leere Drop-in-Datei unter /etc/systemd/system/ollama.service.d/override.conf. Trage dort den Abschnitt [Service] ein:

[Service]
Environment="OLLAMA_HOST=10.0.0.5:11434"
Environment="OLLAMA_KEEP_ALIVE=30m"

Binde bevorzugt an die konkrete interne IP des Hosts statt an 0.0.0.0. Damit lauscht der Dienst nicht auf einer öffentlichen Adresse, selbst wenn eine Firewall-Regel später fehlerhaft ist. Nur wenn sich die IP dynamisch ändert oder Container über eine Bridge zugreifen, ist 0.0.0.0:11434 die pragmatische Wahl.

Danach lädst du die Unit-Definitionen neu und startest den Dienst:

$ sudo systemctl daemon-reload
$ sudo systemctl restart ollama.service
$ systemctl show ollama.service -p Environment

Die letzte Ausgabe muss OLLAMA_HOST=10.0.0.5:11434 enthalten. Fehlt der Wert dort, hat systemd das Override nicht geladen und jede weitere Fehlersuche am Netzwerk ist vergeblich.

Ollama ohne systemd starten

Auf Hosts ohne systemd, etwa in einem Container-Image, setzt du die Variable direkt vor dem Serverstart:

$ OLLAMA_HOST=0.0.0.0:11434 ollama serve

In einem Docker-Container reicht -e OLLAMA_HOST=0.0.0.0:11434 -p 11434:11434. Die Bind-Adresse 0.0.0.0 ist hier korrekt, weil sie sich auf das Container-Netzwerk bezieht und das Port-Mapping die Sichtbarkeit nach außen bestimmt.

Firewall auf Port 11434 beschränken

Sobald Ollama an einer externen Adresse lauscht, entscheidet allein die Firewall darüber, wer den Port 11434 erreicht. Erlaube ausdrücklich nur das Subnetz deiner Clients.

Mit ufw:

$ sudo ufw allow from 10.0.0.0/24 to any port 11434 proto tcp
$ sudo ufw deny 11434/tcp
$ sudo ufw status numbered

ufw wertet die Regeln in der angezeigten Reihenfolge aus. Die allow-Regel für das interne Netz muss vor der generellen deny-Regel stehen, sonst blockiert die Firewall auch deine Clients.

Mit nftables:

$ sudo nft add rule inet filter input ip saddr 10.0.0.0/24 tcp dport 11434 ct state new accept
$ sudo nft add rule inet filter input tcp dport 11434 drop

Liegt zwischen Client und Server zusätzlich eine Cloud-Firewall oder eine Security Group, musst du die Freigabe dort ebenfalls eintragen. Zwei Filterebenen mit widersprüchlichen Regeln sind die häufigste Ursache für ein stilles Timeout.

graph TD
    A["Client im internen Netz"] --> B{"Firewall: Quell-IP erlaubt?"}
    B -- "nein" --> C["Paket verwerfen"]
    B -- "ja" --> D["nginx auf Port 443"]
    D --> E{"Basic Auth gültig?"}
    E -- "nein" --> F["401 zurückgeben"]
    E -- "ja" --> G["Ollama auf 127.0.0.1:11434"]
    G --> H["Antwort an den Client streamen"]

Was bewirkt OLLAMA_ORIGINS?

OLLAMA_ORIGINS ist eine kommaseparierte Liste erlaubter Origin-Header und steuert ausschließlich, welche Browser-Anwendungen die API per JavaScript aufrufen dürfen. Die Variable ersetzt keine Authentifizierung und filtert keine Kommandozeilen-Clients.

Eine Web-UI auf einem anderen Host trägst du so ein:

[Service]
Environment="OLLAMA_ORIGINS=https://ui.<deine-domain>,http://10.0.0.20:3000"

Verwende hier keinen Platzhalter wie *. Ein solcher Wert erlaubt jeder beliebigen Website im Browser deiner Nutzer, Requests gegen deine Ollama-Instanz zu senden. Requests ohne Origin-Header, also curl und die Ollama-CLI, sind von dieser Prüfung ohnehin nicht betroffen.

Zugriff über nginx mit Basic Auth absichern

Ein Reverse Proxy ergänzt genau die zwei Dinge, die Ollama selbst nicht mitbringt: TLS und Authentifizierung. Dafür setzt du OLLAMA_HOST zurück auf 127.0.0.1:11434 und lässt nur nginx nach außen lauschen.

Zuerst die Zugangsdaten anlegen, htpasswd steckt im Paket apache2-utils beziehungsweise httpd-tools:

$ sudo htpasswd -c /etc/nginx/ollama.htpasswd <benutzername>

Danach die Server-Definition unter /etc/nginx/sites-available/ollama.conf:

server {
    listen 443 ssl;
    server_name <ollama-host>;
    ssl_certificate     /etc/letsencrypt/live/<ollama-host>/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/<ollama-host>/privkey.pem;
    client_max_body_size 100M;
    location / {
        auth_basic           "Ollama API";
        auth_basic_user_file /etc/nginx/ollama.htpasswd;
        proxy_pass         http://127.0.0.1:11434;
        proxy_set_header   Host 127.0.0.1:11434;
        proxy_http_version 1.1;
        proxy_buffering    off;
        proxy_read_timeout 600s;
    }
}

Drei Einstellungen sind hier nicht optional. proxy_set_header Host 127.0.0.1:11434 verhindert, dass Ollama den Request wegen eines fremden Host-Headers mit 403 ablehnt. proxy_buffering off gibt die Token-Streams sofort weiter statt sie zu puffern. proxy_read_timeout 600s deckt lange Generierungen ab, die über die nginx-Vorgabe von 60 Sekunden hinausgehen.

Wenn du die Inferenz auf einer GPU-Instanz betreibst und den Proxy davor auf einer separaten Maschine terminieren willst, genügt dafür eine kleine skalierbare Cloud-VPS im selben privaten Netz. Der GPU-Host bleibt dann vollständig ohne öffentliche Route.

Konfiguration aktivieren und prüfen:

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

Freigabe verifizieren

Prüfe zuerst lokal, an welcher Adresse der Dienst tatsächlich lauscht:

$ ss -tlnp | grep 11434
LISTEN 0 4096 10.0.0.5:11434 0.0.0.0:* users:(("ollama",pid=812,fd=3))

Steht dort weiterhin 127.0.0.1:11434, greift dein Override nicht. Steht dort *:11434, lauscht Ollama auf allen Interfaces.

Den Rest testest du von einem zweiten Rechner aus. Der Wurzel-Endpunkt antwortet mit einem festen Text, /api/tags liefert die installierten Modelle als JSON:

$ curl -s http://10.0.0.5:11434/
Ollama is running
$ curl -s http://10.0.0.5:11434/api/tags | jq '.models[].name'
"llama3.1:8b"
"nomic-embed-text:latest"

Hinter dem Reverse Proxy kommen TLS und Zugangsdaten dazu:

$ curl -su <benutzername> https://<ollama-host>/api/tags

Die Ollama-CLI liest dieselbe Variable und lässt sich auf den entfernten Server richten:

$ export OLLAMA_HOST=http://10.0.0.5:11434
$ ollama list

Troubleshooting

Connection refused trotz gesetzter Variable. Das Override wurde angelegt, aber systemctl daemon-reload fehlte oder der Dienst wurde nur neu geladen statt neu gestartet. Kontrolliere mit systemctl show ollama.service -p Environment und starte den Dienst anschließend mit restart neu.

403 Forbidden von der API. Ollama prüft Host- und Origin-Header. Bei Browser-Clients fehlt der Origin in OLLAMA_ORIGINS, bei einem Reverse Proxy fehlt meist die Zeile proxy_set_header Host 127.0.0.1:11434.

Timeout bei der ersten Anfrage. Das Modell wird beim ersten Request in den VRAM geladen, was bei großen Gewichten je nach Datenträger deutlich über eine Minute dauern kann. Setze OLLAMA_KEEP_ALIVE=30m, damit das Modell zwischen den Anfragen geladen bleibt, und erhöhe die Client-Timeouts.

Verbindung bricht mitten im Stream ab. Zwischen Client und Server puffert oder trennt eine Komponente. Prüfe proxy_buffering und proxy_read_timeout im Proxy sowie Idle-Timeouts eines vorgelagerten Load Balancers.

Fazit

Die Freigabe des Ollama Ports besteht aus drei Schritten: OLLAMA_HOST im systemd-Override auf die interne IP setzen, Port 11434 per Firewall auf das eigene Subnetz begrenzen und Authentifizierung über einen Reverse Proxy nachrüsten. Verifiziere jede Änderung mit ss -tlnp und einem curl von einem zweiten Host, bevor du weiterbaust. Für Zugriffe über Standortgrenzen hinweg ist ein WireGuard-Tunnel die sauberere Alternative zu einer öffentlich erreichbaren API, weil der Port dann gar nicht erst im Internet sichtbar ist.

Weiterlesen

• Lokales Coding-Modell mit Ollama in der IDE nutzen
• Die Ollama-API aus eigenen Anwendungen ansprechen
• Ollama auf Ubuntu 24.04 installieren und als Dienst betreiben
• Ollama im Docker-Container betreiben
• Ollama, LM Studio oder llama.cpp: Welches Werkzeug wofür?
• Ollama mit MCP-Servern verbinden: Werkzeuge für lokale Modelle
• Ollama-Modelle verwalten: aktualisieren, aufräumen, Speicher sparen
• Open WebUI als Oberfläche für Ollama einrichten
• Was ist Ollama? Funktionsweise, Modelle und Einsatzgebiete