Ollama Port ändern: 11434 konfigurieren, freigeben und absichern

TL;DR

Ollama lauscht standardmäßig auf 127.0.0.1:11434 – also nur auf dem eigenen Rechner. Den Port ändern Sie über die Umgebungsvariable OLLAMA_HOST (Linux, macOS, Windows), nicht über eine Config-Datei. Für den Zugriff aus dem Firmennetz binden Sie 0.0.0.0:11434 und schränken die Firewall auf Ihr Subnetz ein. Wichtig: Ollama bringt keine eingebaute Authentifizierung für den lokalen Server mit – wer den Port erreicht, kann die GPU und die geladenen Modelle nutzen. Deshalb gehört vor jede Freigabe über das LAN hinaus ein Reverse Proxy mit TLS und Login, nicht eine Port-Weiterleitung im Router. Aufwand: 15 Minuten für den Portwechsel, ein halber Tag für die abgesicherte Team-Freigabe. Keine Lizenzkosten.

Warum ist ausgerechnet Port 11434 ein Thema?

Fast jede Anleitung zu lokalen KI-Modellen endet mit dem Satz „Ollama läuft jetzt auf Port 11434". Was dann im Firmenalltag passiert, kennt jeder, der lokale KI schon einmal produktiv betrieben hat: Das zweite Tool will denselben Port, die Fachabteilung im Nachbarbüro kommt nicht auf den Server, oder der Sicherheitsbeauftragte fragt, warum ein KI-Endpoint ohne Login im Netz hängt. Die Frage ist also nicht, ob Sie sich mit dem Port beschäftigen müssen, sondern ab welchem Tag. Dieser Artikel zeigt die fünf Wege vom Einzelplatz-Setup bis zum abgesicherten Team-Endpoint – mit den Configs, die wirklich funktionieren, und den Fallen, die Zeit kosten.

Die 5 Wege: vom Default bis zum Team-Endpoint

Die Wege bauen aufeinander auf: Weg 2 ist Voraussetzung für Weg 3, Weg 5 nutzt Weg 3 als Basis. Wer nur einen Weg braucht, kann die übrigen überspringen.

Achtung Sackgassen: was nicht funktioniert

Es gibt keine Port-Config-Datei. Ollama liest den Port ausschließlich aus der Umgebungsvariable OLLAMA_HOST. Wer in /etc/ollama eine config.toml oder ollama.conf sucht, sucht vergebens – das spart eine Stunde Suche.

Den Port ändern, aber die Clients vergessen. Open WebUI, Python-Skripte und LangChain-Anbindungen zeigen weiter auf localhost:11434 und liefern plötzlich „Connection refused". Nach jedem Portwechsel müssen alle Clients auf die neue Basis-URL zeigen (Open WebUI: OLLAMA_BASE_URL, Python: base_url).

0.0.0.0 ohne Firewall-Regel. Dann kann jede Maschine im LAN Prompts senden, Modelle laden und die GPU belegen. Ollama hat keine eingebaute Benutzerverwaltung im lokalen Server – ein offener Port ist ein offener Endpoint.

Port-Weiterleitung im Router. Wer Port 11434 im Router auf den KI-Server weiterleitet, stellt einen unauthentifizierten LLM-Endpoint ins Internet. Das ist kein „Feature", sondern ein Einfallstor: Fremde nutzen Ihre GPU, und bei vertraulichen Daten ist es ein Datenschutzvorfall nach Art. 33 DSGVO.

Unter Windows den Port in der App-Oberfläche suchen. Die Ollama-App hat keine Port-Einstellung. Sie setzen die System-Umgebungsvariable und starten Ollama neu – dabei das Tray-Symbol beenden, nicht nur das Fenster schließen.

OLLAMA_ORIGINS mit der Netzwerk-Freigabe verwechseln. Diese Variable regelt CORS für Browser-Erweiterungen, macht den Port aber nicht für andere Rechner erreichbar. Für die Freigabe zählt allein OLLAMA_HOST.

Schritt für Schritt: Port ändern und freigeben

Schritt 1: Diagnose – wer belegt Port 11434?

Die häufigste Ursache für „bind: address already in use" ist eine zweite Ollama-Instanz, die nicht sauber beendet wurde. Erst prüfen, dann ändern:

# Linux
ss -ltnp | grep 11434
# macOS
lsof -i :11434

# Windows (PowerShell): PID merken, dann im Task-Manager zuordnen
netstat -ano | findstr 11434

Schritt 2: Linux – Port per systemd ändern

Die saubere Variante für Server ist ein systemd-Override, der beim nächsten Update des Ollama-Pakets erhalten bleibt:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11435"

sudo systemctl daemon-reload
sudo systemctl restart ollama
# Prüfen:
curl http://localhost:11435/api/tags

Wer mehrere GPU-Instanzen mit eigenen Ports betreiben will, findet die Template-Unit dafür im Artikel zum Ollama-Load-Balancer ohne Kubernetes.

Schritt 3: macOS – Variable per launchctl setzen

launchctl setenv OLLAMA_HOST "127.0.0.1:11435"

Danach die Ollama-App komplett beenden und neu starten. Hinweis: launchctl setenv gilt nur für die aktuelle Sitzung – nach einem Neustart erneut setzen oder als LaunchAgent anlegen.

Schritt 4: Windows – System-Umgebungsvariable setzen

setx OLLAMA_HOST "127.0.0.1:11435"

Ollama über das Tray-Symbol beenden und neu starten. Prüfen:

curl http://localhost:11435/api/tags

setx wirkt erst in neu gestarteten Prozessen – offene Terminals neu öffnen. Ausführlicher zur Installation unter Windows: Ollama Docs – Windows.

Schritt 5: LAN-Freigabe mit Firewall-Regel

Sollen mehrere Rechner im Firmennetz zugreifen, bindet Ollama an alle Schnittstellen – aber die Firewall lässt nur das eigene Subnetz durch:

sudo systemctl edit ollama

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

sudo systemctl daemon-reload
sudo systemctl restart ollama

# Nur das Fertigungs-Subnetz, z. B. 192.168.10.0/24:
sudo ufw allow from 192.168.10.0/24 to any port 11434 proto tcp
sudo ufw enable

Vom zweiten Rechner testen:

curl http://<ip-des-ki-servers>:11434/api/tags

Schritt 6: Reverse Proxy mit TLS und Auth

Für den Zugriff aus mehreren Standorten oder vom Homeoffice gehört ein authentifizierender Proxy davor – nginx mit Basic Auth als Mindestmaß:

server {
    listen 443 ssl;
    server_name ki-gateway.intern;
    # ssl_certificate /etc/nginx/certs/ki-gateway.crt;
    # ssl_certificate_key /etc/nginx/certs/ki-gateway.key;

    location / {
        auth_basic "KI-Gateway";
        auth_basic_user_file /etc/nginx/.htpasswd;
        proxy_pass http://127.0.0.1:11434;
        proxy_read_timeout 900s;
        proxy_set_header Host $host;
    }
}

Für echte Mehrbenutzer-Umgebungen mit Rollen und Protokollierung ist Keycloak die robustere Variante – die Architektur dafür steht im Artikel LLM-Endpoint-Security mit Keycloak.

Kosten: Was kostet der Port-Umbau wirklich?

Die Software ist überall kostenlos – die Kosten stecken in der Arbeitszeit und, im Fall von Remote-Zugriff, in VPN oder kleinem VPS. Die GPU selbst dominiert die laufenden Kosten; eine Übersicht liefert der Artikel KI-Server: laufende Kosten.

Bei externer Umsetzung (Dienstleister, 120–160 EUR/h) kostet Weg 5 einmalig 240–640 EUR; intern (70 EUR/h) 140–280 EUR. Wer den Betrieb ohnehin fremdvergeben hat, braucht für den Zugriff des Dienstleisters einen Auftragsverarbeitungsvertrag – dazu unten mehr.

DSGVO und Recht: der Port als Datenschutzfrage

Art. 32 DSGVO – Sicherheit der Verarbeitung. Ein offener Port 11434 ohne Authentifizierung ist keine angemessene technische Maßnahme, sobald mehr als eine Person Zugriff hat oder personenbezogene Daten verarbeitet werden. Zugriffskontrolle („nur wer muss") ist Pflicht, nicht Kür.

Datenhoheit als Vorteil. Solange Ollama auf 127.0.0.1 oder im eigenen LAN läuft, verlassen die Daten das Unternehmen nicht: kein Drittlandtransfer, kein Cloud-Anbieter als Auftragsverarbeiter. Das ist der zentrale DSGVO-Vorteil des lokalen Betriebs gegenüber API-Anbietern. Ein AVV nach Art. 28 DSGVO wird erst nötig, wenn ein externer Dienstleister (Managed Service) Zugriff auf den Server erhält – dann sauber dokumentieren.

§ 203 StGB bei Kanzleien und Praxen. Wer als Anwalt, Arzt oder Psychotherapeut KI einsetzt, muss verhindern, dass Berufsgeheimnisse abfließen. Ein unauthentifizierter Endpoint im LAN ist dafür ein reales Risiko. Die defensible Variante: lokaler Betrieb auf 127.0.0.1, Remote-Zugriff ausschließlich per VPN, Protokollierung aller Zugriffe.

KI-Verordnung (AI Act). Für Hochrisiko-Anwendungen (z. B. medizinische Diagnostik, Personalentscheidungen) reicht ein lokales Setup allein nicht aus – dann sind Konformitätsbewertung und Dokumentation gefordert. Für Assistenz- und Dokumentationsanwendungen im Mittelstand greift das in der Regel nicht.

Use-Cases: zwei Branchen, zwei Port-Strategien

Fertigung – Freigabe im Werk. Ein KI-Server mit zwei GPUs (z. B. 2× RTX 5070 Ti, 16 GB VRAM) steht im Netzwerkraum, sechs Arbeitsplätze der Fertigungssteuerung greifen über Open WebUI zu. Umsetzung: OLLAMA_HOST=0.0.0.0:11434, Firewall auf 192.168.10.0/24 beschränkt, Zugriff nur über den Reverse Proxy mit Login. Qualitätsprotokolle und Maschinendaten verlassen das Werk nicht – Betriebsrat und Datenschutzbeauftragter bekommen eine dokumentierte, nachvollziehbare Architektur. Die GPU-Auswahl für diesen Einsatzzweck finden Sie im GPU-Vergleich für LLM-Inferenz.

Kanzlei – kein Netzwerk-Port. Eine Einzelkanzlei nutzt Ollama auf dem Arbeitsrechner für Entwürfe und Zusammenfassungen. Umsetzung: bewusst 127.0.0.1:11434 behalten, keinen Port ins LAN öffnen. Unterwegs läuft der Zugriff über WireGuard-VPN auf den Arbeitsrechner. Ergebnis: keine Mandantendaten in der Cloud, kein AVV, § 203 StGB sauber eingehalten – und bei einer Fachanwaltssoftware mit eigener KI bleibt die Kontrolle über den Endpoint beim Anwalt.

Entscheidungsmatrix: welcher Weg passt zu Ihnen?

Faustregel: Einzelplatz → Weg 1. Port-Konflikt → Weg 2. Eine Abteilung im Haus → Weg 3, spätestens bei mehreren Teams mit Weg 5. Remote-Zugriff oder externe Mitarbeiter → immer Weg 5, nie Router-Port-Weiterleitung.

Fazit

Der Port 11434 ist der unsichtbare Flaschenhals jedes lokalen KI-Setups: Er entscheidet, wer auf Ihre Modelle und GPUs zugreifen kann. Die gute Nachricht: Die Konfiguration ist eine einzige Umgebungsvariable, die Absicherung eine Firewall-Regel und ein Reverse Proxy. Wer die fünf Wege kennt, spart sich die klassischen Fehler – die gesuchte Config-Datei, den vergessenen Client-Port und die offene Freigabe ohne Login. Wenn Sie die Architektur für Ihre Umgebung planen möchten – von der GPU-Wahl über die Port-Strategie bis zur DSGVO-Dokumentation – sprechen Sie uns an.

Sprechen Sie uns an →

FAQ

Welchen Port nutzt Ollama standardmäßig?

Ollama lauscht standardmäßig auf TCP-Port 11434 und bindet dabei an 127.0.0.1 – erreichbar ist der Server also nur vom eigenen Rechner. Die Konfiguration steht in der offiziellen Ollama-FAQ.

Wie ändere ich den Ollama-Port unter Windows?

setx OLLAMA_HOST "127.0.0.1:11435" in PowerShell ausführen, Ollama über das Tray-Symbol beenden und neu starten. Danach zeigt der Server auf den neuen Port; alle Clients (z. B. Open WebUI) müssen auf die neue Basis-URL umgestellt werden.

Warum kommt „bind: address already in use" auf Port 11434?

Meist läuft eine zweite Ollama-Instanz oder ein anderes Programm auf dem Port. Mit netstat -ano | findstr 11434 (Windows), ss -ltnp | grep 11434 (Linux) oder lsof -i :11434 (macOS) die belegende PID finden und den Prozess beenden – oder Ollama per OLLAMA_HOST auf einen freien Port umziehen.

Wie mache ich Ollama im Firmennetz erreichbar?

OLLAMA_HOST=0.0.0.0:11434 setzen und in der Firewall nur das gewünschte Subnetz freigeben, z. B. sudo ufw allow from 192.168.10.0/24 to any port 11434 proto tcp. Test vom zweiten Rechner: curl http://<ip>:11434/api/tags.

Ist es sicher, Port 11434 ins Internet zu öffnen?

Nein. Ollama bringt für den lokalen Server keine eingebaute Authentifizierung mit – jeder, der den Port erreicht, kann Prompts senden und die GPU nutzen. Remote-Zugriff gehört hinter einen VPN oder einen Reverse Proxy mit TLS und Login, niemals in eine Router-Port-Weiterleitung.

Müssen Open WebUI und andere Tools nach einem Portwechsel angepasst werden?

Ja. Jeder Client speichert die Basis-URL des Ollama-Servers: Open WebUI über OLLAMA_BASE_URL, die Python-Bibliothek über base_url, LangChain über die jeweilige Endpoint-Konfiguration. Nach dem Portwechsel alle Clients prüfen – „Connection refused" ist fast immer ein vergessener Client-Port.