Sunday, 20 September 2026 | Updating Daily AI insight, written for builders

Ollama-Port: Standardmäßig 11434, Änderung und Behebung von Konflikten

Aktualisiert · Originally published August 5, 2026
  • Der Standard-Ollama-Port ist 11434, bereitgestellt über einfaches HTTP und gebunden an 127.0.0.1 (ausschließlich localhost).
  • Ändern Sie ihn mithilfe der OLLAMA_HOST Umgebungsvariablen – z. B. OLLAMA_HOST=127.0.0.1:11435. Es gibt keine OLLAMA_PORT Variable.
  • Um Ollama von einem anderen Rechner aus zu erreichen, binden Sie an 0.0.0.0:11434 und öffnen Sie die Firewall – allerdings verfügt die API über keine Authentifizierung, daher sollten Sie den Zugriff auf ein vertrauenswürdiges Netzwerk beschränken oder einen Reverse-Proxy davor schalten.
  • Überprüfen Sie dies mit curl http://127.0.0.1:11434, woraufhin die Antwort lautet Ollama läuft.

Ollama lauscht standardmäßig auf Port 11434 über HTTP, gebunden an die Loopback-Adresse 127.0.0.1. Die Basis-URL der API auf dem lokalen Rechner lautet daher http://127.0.0.1:11434. Da Ollama an die Loopback-Adresse und nicht an alle Netzwerkschnittstellen gebunden ist, kann von außerhalb dieses Rechners kein Zugriff erfolgen, solange Sie die Bind-Adresse nicht bewusst ändern.

Was tatsächlich auf Port 11434 läuft

Port 11434 hostet den Ollama-HTTP-Server – denselben Prozess, den ollama serve gestartet wird und den auch die Desktop-Anwendung im Hintergrund startet. Alle Komponenten von Ollama kommunizieren mit ihm: die Ollama Befehlszeilenschnittstelle (CLI), das Desktop-Chat-Fenster sowie beliebige Drittanbieter-Clients, die darauf zugreifen.

Endpunkt Zweck
GET / Health-Check – gibt den Klartext Ollama läuft
GET /api/tags Listet lokal installierte Modelle als JSON auf
POST /api/generate, POST /api/chat Native Ollama-Inferenz-Endpunkte
POST /api/pull, DELETE /api/delete Modulverwaltung – Herunterladen und Entfernen von Modellen
/v1/chat/completions OpenAI-kompatible Schicht für SDKs, die eine OpenAI-Basis-URL erwarten

Beachten Sie die Zeile für /api/pull und /api/delete. Jeder, der Zugriff auf diesen Port hat, kann mehrere Gigabyte große Modelle auf Ihre Festplatte herunterladen oder bereits installierte Modelle löschen. Das ist in einem Satz die gesamte Sicherheitslage – und genau deshalb erfolgt die Standardbindung ausschließlich an die Loopback-Schnittstelle. Falls Sie noch unsicher sind, welche Modelle Sie lokal installieren möchten, enthält die Ollama-Modellliste Übersicht eine Liste aller verfügbaren Modelle sowie deren jeweilige Größe.

OLLAMA_HOST: Die einzige Variable, die den Port steuert

Sowohl die Bind-Adresse als auch der Port werden durch eine einzige Umgebungsvariable gesteuert, nämlich OLLAMA_HOST. Es gibt keine separate Port-Einstellung und auch keine Konfigurationsdatei, die diese überschreiben könnte.

Wert Ergebnis
nicht gesetzt Lauscht auf 127.0.0.1:11434
127.0.0.1:11435 Gleiche Verhalten nur für die Loopback-Schnittstelle, aber mit anderem Port
0.0.0.0:11434 Lauscht auf allen IPv4-Schnittstellen – vom lokalen Netzwerk aus erreichbar
192.168.1.50:11434 Lauscht ausschließlich auf einer bestimmten Schnittstelle

Schreiben Sie sie stets als Host:Port. Kürzere Formate werden in einigen Versionen akzeptiert, doch das explizite Paar verhält sich in allen Versionen konsistent.

Ein häufiger Fallstrick betrifft nahezu alle Nutzer: OLLAMA_HOST wird sowohl vom Client als auch vom Server gelesen. Wenn Sie den Server auf Port 11435 verschieben, aber Ihr Terminal weiterhin den Standardwert enthält, ollama list schlägt mit einem Verbindungsfehler fehl, obwohl der Server vollständig funktionsfähig ist. Legen Sie die Variable an beiden Stellen fest, oder führen Sie die CLI als OLLAMA_HOST=127.0.0.1:11435 ollama list.

Ändern des Ollama-Ports unter Linux

Das Linux-Installations-Skript registriert einen systemd-Service; Umgebungsvariablen in Ihrer Shell sind daher irrelevant – Sie müssen sie in der Unit-Datei angeben. Verwenden Sie stattdessen eine Drop-in-Override-Datei, anstatt die vom Paket bereitgestellte Unit-Datei direkt zu bearbeiten, da diese bei Paketaktualisierungen überschrieben wird:

sudo systemctl edit ollama.service

Fügen Sie diesen Block hinzu (bei neueren systemd-Versionen zwischen den ### Alles zwischen hier... Markierungskommentaren):

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Dadurch wird die Datei /etc/systemd/system/ollama.service.d/override.conferstellt. Übernehmen Sie die Änderung mit:

sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo systemctl status ollama

Fügen Sie pro Variable Environment= eine Zeile hinzu – eine zweite Zeile ersetzt die erste nicht. Falls Sie außerdem den Speicherort für Modelle ändern möchten, gehört Environment="OLLAMA_MODELS=/mnt/models" ebenfalls in denselben Block.

Wenn Sie ollama serve manuell

ausführen – ohne systemd – exportieren Sie die Variable einfach so: OLLAMA_HOST=0.0.0.0:11434 ollama serve. Stellen Sie sicher, dass der systemd-Service zuvor gestoppt wurde (sudo systemctl stop ollama), andernfalls kämpfen beide Prozesse um den Port.

Ändern des Ollama-Ports unter macOS

Die macOS-App wird von der GUI-Sitzung gestartet, die Ihr Shell-Profil nicht erbt. Das Exportieren von OLLAMA_HOST in .zshrc ändert nur die CLI, nicht aber den Hintergrundserver. Verwenden Sie stattdessen launchctl :

launchctl setenv OLLAMA_HOST "0.0.0.0:11434"

Beenden Sie Ollama anschließend über das Menüleistensymbol und starten Sie es neu. Der neue Wert gilt nur für danach gestartete Prozesse.

launchctl setenv überlebt nicht keinen Neustart. Für eine dauerhafte Änderung müssen Sie den Befehl bei jedem Login erneut ausführen – z. B. mittels einer LaunchAgent-Property-Liste oder eines Login-Eintrags, der den Befehl ausführt. Neuere Versionen der macOS-App bieten zudem einen Netzwerkzugriffsschalter in den Einstellungen an; falls Ihre Version diesen enthält, nutzen Sie ihn vorzugsweise, da er korrekt persistent bleibt. Prüfen Sie vor dem Erstellen einer LaunchAgent zunächst die Einstellungsseite der App selbst und sehen Sie sich die Kompletter Ollama-Leitfaden an, um zu erfahren, was dort noch enthalten ist.

Ändern des Ollama-Ports unter Windows

Ollama unter Windows läuft als normaler Benutzerprozess mit Symbol in der Taskleiste, sodass eine Umgebungsvariable auf Benutzerebene ausreichend ist.

  1. Presse Windows, eingeben Umgebungsvariablen, und öffnen Sie Systemumgebungsvariablen bearbeitenUmgebungsvariablen…
  2. Unter Benutzervariablenklicken Sie auf Neu.
  3. Name: OLLAMA_HOSTWert: 0.0.0.0:11434 (oder Ihren gewünschten Port).
  4. Klicken Sie in beiden Dialogfeldern auf „OK“.
  5. Rechtsklicken Sie auf das Ollama-Symbol in der Taskleiste und wählen Sie „Beenden“, starten Sie Ollama dann erneut über das Startmenü.

Schritt 5 ist der Schritt, den viele überspringen. Das Schließen des Fensters beendet den Server nicht – dieser läuft weiterhin mit dem alten Wert. Alternativ können Sie dies auch über ein Terminal durchführen: setx OLLAMA_HOST "0.0.0.0:11434" – allerdings wirkt setx nur auf Prozesse, die danach danach gestartet werden, weshalb das Beenden und Neustarten nach wie vor erforderlich ist. Falls Sie Ollama neu einrichten, führt Sie die Ollama-Installationsanleitung Schritt für Schritt durch den Windows-Installer.

Überprüfen, ob der Server lauscht

Zwei Prüfungen in dieser Reihenfolge: Ist etwas an den Port gebunden, und handelt es sich dabei um Ollama?

Plattform Befehl
Jede(r) curl http://127.0.0.1:11434Ollama läuft
Jede(r) curl http://127.0.0.1:11434/api/tags → JSON-Liste der Modelle
Linux sudo ss -tlnp | grep 11434
macOS lsof -nP -iTCP:11434 -sTCP:LISTEN
Windows netstat -ano | findstr :11434
Windows (PowerShell) Get-NetTCPConnection -LocalPort 11434

Lesen Sie die Spalte „Lokale Adresse“ sorgfältig. 127.0.0.1:11434 bedeutet ausschließlich Loopback – eine entfernte Maschine kann niemals eine Verbindung herstellen, unabhängig von den Firewall-Einstellungen. 0.0.0.0:11434 oder *:11434 bedeutet alle Netzwerkschnittstellen.

Ollama für andere Rechner erreichbar machen

Binden an 0.0.0.0 ist erforderlich, aber in der Regel nicht ausreichend. Drei Bedingungen müssen gleichzeitig erfüllt sein: Der Server ist an eine Nicht-Loopback-Adresse gebunden, die Host-Firewall erlaubt eingehenden TCP-Verkehr auf dem Port, und der Client verwendet die LAN-IP des Hosts statt localhost.

Firewall-Regeln

Plattform So aktivieren Sie eingehenden TCP-Verkehr auf Port 11434
Windows PowerShell als Administrator ausführen: New-NetFirewallRule -DisplayName "Ollama" -Direction Inbound -Protocol TCP -LocalPort 11434 -Action Allow
Linux (ufw) sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp
Linux (firewalld) sudo firewall-cmd --permanent --add-port=11434/tcp dann sudo firewall-cmd --reload
macOS Systemeinstellungen → Netzwerk → Firewall → Optionen, dann eingehende Verbindungen für Ollama zulassen (oder beim ersten Start auf die Aufforderung mit „Ja“ antworten)

Beschränken Sie den Gültigkeitsbereich der Regel möglichst auf Ihr Subnetz (wie im ufw-Beispiel), statt weltweiten Zugriff zuzulassen.

Die Sicherheitsauswirkungen, klar und deutlich

Die Ollama-API verfügt über keine Authentifizierung, keine API-Schlüssel und keine TLS-Verschlüsselung. Bindung an 0.0.0.0 Damit erhält jeder, der eine Route zu dieser Adresse besitzt, vollständige Kontrolle: Ausführung von Inferenzvorgängen, Lesen der Modellliste, Herunterladen neuer Modelle, Löschen bestehender Modelle. Internetzugängliche Ollama-Instanzen werden von Scannern rasch entdeckt, da Port 11434 ein bekannter Port ist.

Sicherere Alternativen – grob nach Aufwand geordnet:

  • SSH-Tunnel – belassen Sie die Bindung bei Loopback und leiten Sie sie weiter: ssh -L 11434:127.0.0.1:11434 user@serverNichts wird nach außen exponiert; der Client kommuniziert mit seinem eigenen localhost.
  • Overlay-Netzwerk – Tailscale, WireGuard oder vergleichbar. Binden Sie an die IP-Adresse der Overlay-Schnittstelle, sodass nur Geräte in Ihrem Tailnet eine Verbindung herstellen können.
  • Reverse-Proxy – Caddy oder nginx vorangestellt, mit TLS-Terminierung und Durchsetzung einer einfachen Authentifizierung oder eines Bearer-Tokens; Ollama selbst läuft weiterhin im Loopback-Modus.

Wenn Sie zwischen einem gemeinsam genutzten Heim-Lab-Server und einer kostenpflichtigen Token-basierten Lösung abwägen, liefert die Selbsthosting- versus-API-Kosten-Grenzwert-Rechner die konkreten Zahlen für diesen Kompromiss, und die VRAM-Rechner zeigt Ihnen, ob der gewünschte Rechner das Modell tatsächlich speichern kann.

Diagnose eines Port-Konflikts

Das typische Symptom ist ein Startfehler, der die betroffene Adresse nennt, etwa folgendermaßen:

Fehler: listen tcp 127.0.0.1:11434: bind: Adresse bereits in Verwendung

Ermitteln Sie den Besitzer des Ports:

# Linux
sudo ss -tlnp | grep 11434

# macOS
lsof -nP -iTCP:11434 -sTCP:LISTEN

# Windows – PID ermitteln, dann Prozessnamen abfragen
netstat -ano | findstr :11434
tasklist /FI "PID eq 12345"

In der Praxis ist der Übeltäter fast immer Ollama selbst, das zweimal ausgeführt wird. Häufige Varianten hierfür sind:

  • Die Desktop-Anwendung läuft bereits im Infobereich (Windows) bzw. Menüleiste (macOS) und Sie haben den Befehl ollama serve in einem Terminal eingegeben. Der vom Desktop-App-Server bereitgestellte Dienst funktioniert einwandfrei – nutzen Sie ihn einfach.
  • Unter Linux ist der systemd-Service aktiv und Sie haben den Befehl ollama serve manuell ausgeführt. Beenden Sie einen der beiden: sudo systemctl stop ollama.
  • Ein Docker-Container veröffentlicht -p 11434:11434 und belegt damit den Host-Port. Überprüfen Sie dies mit docker ps.

Falls es sich tatsächlich um eine andere Anwendung handelt, wechseln Sie besser den Port für Ollama, statt mit der anderen Anwendung zu konkurrieren – wählen Sie stattdessen einen freien hohen Port wie etwa 127.0.0.1:11435 und legen Sie OLLAMA_HOST wie oben beschrieben fest. Denken Sie daran, die Basis-URL aller Clients zu aktualisieren, einschließlich sämtlicher OpenAI-kompatibler SDK-Konfigurationen.

Docker und WSL

Innerhalb des offiziellen Containers bindet der Server bereits an 0.0.0.0:11434 – Sie wählen lediglich die Zuordnung auf dem Host-System: docker run -d -p 127.0.0.1:11434:11434 --name ollama ollama/ollama hält den Zugriff lokal, während -p 11434:11434 den Dienst auf allen Host-Schnittstellen verfügbar macht. Um den Host-Port zu ändern, passen Sie nur die linke Zahl an – -p 11435:11434 — und den internen Port des Containers unverändert lassen.

Von WSL2 zu einer auf dem Windows-Host laufenden Ollama-Instanz localhost löst sich nicht immer in die Host-Adresse auf. Binden Sie Ollama auf Windows-Seite an 0.0.0.0:11434, erlauben Sie den Port in der Windows Defender-Firewall und stellen Sie von WSL aus über die Host-IP aus /etc/resolv.conf oder über die Adresse des gespiegelten Netzwerks her, je nach Ihrer WSL-Konfiguration.

Häufig gestellte Fragen

Gibt es eine Umgebungsvariable OLLAMA_PORT?

Nein. Port und Bind-Adresse werden beide über OLLAMA_HOSTfestgelegt, geschrieben als Host:Port. Die Festlegung von OLLAMA_PORT hat keinerlei Auswirkung – Ollama ignoriert sie und verwendet weiterhin den Standardport 11434; daher scheint die Änderung stillschweigend zu fehlschlagen.

Ich habe OLLAMA_HOST auf 0.0.0.0 gesetzt, doch entfernte Rechner können trotzdem keine Verbindung herstellen. Warum?

Überprüfen Sie nacheinander die drei Ebenen: Stellen Sie sicher, dass der Server tatsächlich an 0.0.0.0 und nicht an 127.0.0.1 mithilfe ss, lsof oder netstatgebunden ist; vergewissern Sie sich, dass die Host-Firewall eingehenden TCP-Verkehr auf dem betreffenden Port zulässt; und prüfen Sie, ob der Client die LAN-IP des Hosts verwendet – nicht localhost. Die häufigste einzelne Ursache ist, dass der Ollama-Prozess nach Setzen der Variablen nicht vollständig neu gestartet wurde.

Führt die Portänderung zu Problemen mit der Ollama-CLI?

Ja, das kann passieren. Die CLI liest dieselbe OLLAMA_HOST Umgebungsvariable, um zu ermitteln, mit welchem Ziel sie eine Verbindung herstellen soll; wenn sich der Server also verschoben hat, aber Ihre Shell dies noch nicht weiß, schlagen Befehle wie ollama list mit einer Verbindungsfehlermeldung fehl. Legen Sie die Variable daher auch in Ihrem Shell-Profil fest oder setzen Sie sie vor einzelnen Befehlen als Präfix.

Kann ich zwei Ollama-Instanzen auf unterschiedlichen Ports betreiben?

Ja – starten Sie jede mit einer anderen OLLAMA_HOSTUmgebungsvariablenangabe. Sie teilen sich standardmäßig dasselbe Modellverzeichnis, es sei denn, Sie weisen jeder Instanz zusätzlich einen eigenen OLLAMA_MODELS Pfad zu. Beachten Sie jedoch, dass beide Instanzen Gewichte in dieselbe GPU laden, sodass bei gleichzeitigem Betrieb zweier großer Modelle ein Konkurrenzkampf um den verfügbaren VRAM entsteht; die VRAM-Anforderungen nach Modell Referenz zeigt Ihnen, wie viel Spielraum Sie tatsächlich haben.

Welche Basis-URL benötigen OpenAI-kompatible Clients?

Richten Sie die Basis-URL des SDKs auf http://localhost:11434/v1 (passen Sie Host und Port ggf. an). Die meisten Clients verlangen zudem, dass das API-Key-Feld nicht leer ist – obwohl Ollama diesen Wert ignoriert – geben Sie daher einen beliebigen Platzhalterstring wie Ollama.

Ist es sicher, Port 11434 ins Internet freizugeben?

Nein. Es gibt weder integrierte Authentifizierung noch Verschlüsselung, und die exponierte API umfasst Funktionen zum Herunterladen und Löschen von Modellen. Falls Sie Remote-Zugriff benötigen, verwenden Sie stattdessen einen SSH-Tunnel oder ein privates Overlay-Netzwerk, oder platzieren Sie einen authentifizierenden Reverse-Proxy mit TLS davor. Falls Remote-Zugriff die Hauptanforderung ist, vergleichen Sie die laufenden Kosten mit gehosteter Inferenz über den API-Kostenrechner bevor Sie die Infrastruktur aufbauen.

Schnellreferenz

Aufgabe Aktion
Standardport 11434 auf 127.0.0.1, HTTP
Port ändern OLLAMA_HOST=127.0.0.1:11435
Für das lokale Netzwerk freigeben OLLAMA_HOST=0.0.0.0:11434 + Firewall-Regel
Dauerhaft unter Linux systemctl edit ollama.serviceEnvironment="OLLAMA_HOST=…"
Dauerhaft unter macOS launchctl setenv OLLAMA_HOST "…", bei jedem Login erneut angewendet
Dauerhaft unter Windows Benutzer-Umgebungsvariable, danach beenden und über das Taskleistensymbol neu starten
Health-Check curl http://127.0.0.1:11434

Sobald der Port korrekt konfiguriert ist, stellt sich als nächstes meist die Frage, welches Modell dahinter platziert werden soll – die besten lokalen Modelle für Ollama behandelt die aktuellen Optionen nach Hardware-Stufe.

Verfasst von Mustafa Ihsan

Mustafa Ihsan ist Gründer und Chefredakteur von Convly.ai. Er entwickelte und pflegt die Live-Datenbank für KI-Modelle der Website, ihren Preis-Leistungs-Index sowie kostenlose Rechner für VRAM-Anforderungen, API-Kosten und Wirtschaftlichkeit des Self-Hostings. Er schreibt über Modellpreise, Benchmark-Ergebnisse und die Hardware, die zum lokalen Betrieb von KI-Modellen erforderlich ist, und bevorzugt stets messbare Zahlen gegenüber Herstellerangaben.

Scroll to Top