Teste lokal mit GET /api/tags. Für einen Portwechsel setzt du OLLAMA_HOST passend zum Startweg von Ollama und stellst anschließend die Clients um. Eine andere Portnummer schützt den Zugriff nicht; Container und andere Rechner benötigen ihre jeweils passende Zieladresse.
Was Port und Bind-Adresse bedeuten
Die Adresse http://127.0.0.1:11434 besteht aus dem lokalen Rechner, der Portnummer und dem HTTP-Protokoll. Die Ollama-FAQ nennt diese Bindung als Standard. localhost bezeichnet ebenfalls den eigenen Rechner; welche IP-Adresse dafür aufgelöst wird, kann vom System abhängen.
Entscheidend ist der Ort des Aufrufs. Ein Browser auf deinem Laptop, ein Programm im Container und eine Anwendung auf einem zweiten Rechner haben nicht automatisch denselben „eigenen Rechner“. Notiere daher zuerst: Wo läuft der Client, wo läuft Ollama und welche Adresse verbindet beide?
Die API-Übersicht unterscheidet außerdem die native lokale Basis /api von kompatiblen Schnittstellen wie /v1. Eine Anwendung, die eine bestimmte API erwartet, benötigt neben dem richtigen Port auch den richtigen API-Pfad. Die Grundlagen erklärt Was ist Ollama?
Zuerst lokal prüfen
Starte den Test auf dem Rechner, auf dem Ollama läuft. Dieser lesende Aufruf fragt vorhandene Modelle ab und startet keine Modellgenerierung:
curl http://127.0.0.1:11434/api/tagsIn Windows PowerShell kannst du ausdrücklich curl.exe verwenden, um das Kommandozeilenprogramm aufzurufen. Der dokumentierte Endpunkt liefert eine JSON-Antwort mit einer models-Liste. Eine leere Liste bedeutet etwas anderes als eine gescheiterte Verbindung: Der Server kann antworten, obwohl noch kein Modell vorhanden ist.
Halte für die Fehlersuche URL, Zeitpunkt und genaue Meldung fest. „Verbindung abgelehnt“ bedeutet, dass an dieser Adresse keine Verbindung zum gewünschten Dienst zustande kommt. Prüfe zuerst Listener, Bind-Adresse und eine mögliche aktive Ablehnung durch das System. Eine HTTP-Antwort zeigt dagegen, dass bereits ein HTTP-Dienst geantwortet hat. Prüfe dann, ob es der gewünschte Dienst und der richtige API-Pfad war. Dieses Prüfprotokoll ist ein Vorschlag für dein Setup, kein hier aufgezeichneter Testlauf.
Eine erreichbare API bestätigt noch nicht die GPU-Zuordnung des geladenen Modells. Wie du Ollama mit GPU prüfen kannst, zeigt der separate Guide zur PROCESSOR-Ausgabe und zur tatsächlichen Serverinstanz.
Verbindung in vier Schritten eingrenzen
Teste zuerst auf dem Rechner, auf dem Ollama tatsächlich läuft. Der folgende Aufruf liest nur die Modellliste; er startet keine Generierung. Die Begrenzung auf vier Sekunden ist unser Diagnosebeispiel und keine Hersteller-Latenzgarantie.
curl.exe --noproxy "*" --connect-timeout 2 --max-time 4 -i http://127.0.0.1:11434/api/tagscurl.exe ist die Windows-Schreibweise. Unter macOS und Linux verwendest du curl. --noproxy "*" verhindert für diesen lokalen Versuch den Umweg über einen konfigurierten Proxy.
| Beobachtung | Was sie belegt | Was du als Nächstes prüfst |
|---|---|---|
| Verbindung abgelehnt | Keine erfolgreiche Verbindung zu diesem Ziel | Listener, App/Dienst und tatsächliche Bindung prüfen |
| Zeitüberschreitung | Keine rechtzeitige Antwort im gewählten Zeitfenster | Zieladresse, Netzweg und Filter eingrenzen; keinen Port blind öffnen |
| HTTP 401/403 | Ein HTTP-Dienst verweigert Zugriff | Reverse Proxy und vorgesehenen Zugang prüfen; keine Zugangskontrolle abschalten |
| HTTP 404 oder HTML | Ein Dienst antwortet, aber nicht im erwarteten API-Format | Basisadresse und /api/tags abgleichen |
| HTTP 200 und models: [] | Die erwartete Listenstruktur ist erreichbar, die Liste ist leer | Vorhandene Modelle und den tatsächlichen Clientstandort prüfen |
Den Listener kannst du unter Windows lesend mit Get-NetTCPConnection -LocalPort 11434 -State Listen, unter Linux mit ss -ltnp und unter macOS mit lsof -nP -iTCP:11434 -sTCP:LISTEN suchen. Prozessdetails können zusätzliche Rechte benötigen. Beende keinen Prozess allein wegen seiner Portnummer.
Der lokale Antwortprüfer wertet einen gespeicherten HTTP-Status und einen Antworttext aus. Er baut selbst keine Verbindung auf. Beispiel: python antwort-pruefen.py 200 antwort.json. „Listenformat erkannt“ beweist weder die Identität des Servers noch GPU-Nutzung oder eine erfolgreiche Generierung.
Bei einem Portkonflikt den Prozess zuordnen
Die Meldung address already in use kann auftreten, wenn du einen zweiten Server auf derselben Bindung startest. Eine laufende Desktop-App oder ein vorhandener Dienst ist deshalb der erste Kandidat. Prüfe die bestehende Installation, bevor du zusätzlich ollama serve aufrufst.
| Befund | Prüfen |
|---|---|
| Der lokale API-Aufruf funktioniert schon | Vorhandene Instanz weiterverwenden; keine zweite starten |
| Port belegt, API-Aufruf unpassend | Prozessname und Installationsort des Listeners zuordnen |
| Nach App-Neustart weiterhin Konflikt | Zusätzlichen Dienst oder Container auf derselben Host-Bindung prüfen |
| Nur ein Client scheitert | Seine gespeicherte Basis-URL und Schnittstelle vergleichen |
Unter Windows zeigt der Ressourcenmonitor beziehungsweise eine lesende Portabfrage den zugehörigen Prozess. Unter Linux oder macOS kannst du die Listener mit den Systemwerkzeugen prüfen. Beende einen Prozess erst, wenn seine Aufgabe feststeht. Ein fremder Dienst kann eine bewusst gewählte Portnummer bereits benötigen.
Port ändern und Clients nachziehen
Unser Beispiel verwendet 127.0.0.1:11435 für einen lokal gebundenen Server. Die Zahl 11435 ist frei gewählt und muss auf deinem Rechner verfügbar sein. Der Hersteller dokumentiert dafür OLLAMA_HOST und je nach Startweg unterschiedliche Einstellungen:
- Windows-App: Ollama vollständig über den Infobereich beenden, die Benutzer-Umgebungsvariable
OLLAMA_HOSTauf127.0.0.1:11435setzen und die App neu starten. - macOS-App: Die Variable mit
launchctl setenv OLLAMA_HOST "127.0.0.1:11435"setzen und Ollama neu starten. - Linux-Dienst mit systemd: Einen Override für den tatsächlich verwendeten Dienst anlegen, unter
[Service]die ZeileEnvironment="OLLAMA_HOST=127.0.0.1:11435"setzen, die Dienstkonfiguration neu laden und den Dienst neu starten.
Für einen bewusst manuell gestarteten Server in einer POSIX-Shell lautet die Einstellung für diesen Prozess:
OLLAMA_HOST=127.0.0.1:11435 ollama servePrüfe anschließend http://127.0.0.1:11435/api/tags und ändere die Basis-URL jedes zugehörigen Clients. Eine Variable in einem offenen Terminal verändert eine bereits laufende Desktop-App oder einen systemd-Dienst nicht nachträglich.
Linux-Dienst: Den Override Schritt für Schritt setzen
Für einen tatsächlich über systemd gestarteten Ollama-Dienst öffnest du zuerst den Override-Editor:
sudo systemctl edit ollama.serviceTrage dort den folgenden Abschnitt ein und speichere die Datei. Verwende den vorhandenen Abschnitt [Service], wenn du bereits einen Override bearbeitest:
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11435"Lade anschließend die Dienstkonfiguration neu, starte diesen Dienst neu und prüfe die neue Adresse:
sudo systemctl daemon-reload
sudo systemctl restart ollama.service
curl http://127.0.0.1:11435/api/tagsDie erwartete Antwort ist ein JSON-Objekt mit einer models-Liste; sie darf leer sein. Kommt keine Antwort, prüfe den tatsächlich verwendeten Dienst und die neue Bindung. Die Hersteller-FAQ zur Dienstkonfiguration beschreibt Editor und Neustart. Das Beispiel verändert einen Dienst auf deinem Rechner und wurde hier nicht ausgeführt.
Container, LAN und Browser auseinanderhalten
Im gleichen Compose-Netz können Container einen Dienst über seinen Dienstnamen erreichen. Die Docker-Dokumentation trennt dabei den Container-Port vom veröffentlichten Host-Port. Ein Dienst namens ollama mit internem Port 11434 kann dort beispielsweise unter http://ollama:11434 erreichbar sein. Der Host nutzt seine veröffentlichte Bindung. Das konkrete Setup zeigt Ollama mit Docker.
Für einen zweiten Rechner brauchst du eine erreichbare Serveradresse sowie eine dazu passende Bindung und Zugriffsregel. 0.0.0.0 bezeichnet beim Server das Lauschen auf allen IPv4-Schnittstellen; es ist keine passende Zieladresse für deinen entfernten Client.
Die Authentifizierungsreferenz erklärt, dass die lokale API keine Anmeldung verlangt. Begrenze deshalb einen erweiterten Zugriff bewusst, etwa über ein geeignetes privates Netz oder einen authentifizierenden Zugang. Ein verschlüsselter Tunnel allein beantwortet noch nicht, wer diesen Zugang verwenden darf.
Wenn ein Browseraufruf an CORS scheitert, prüfe getrennt die erlaubte Herkunft über OLLAMA_ORIGINS. Diese Einstellung regelt Browser-Ursprünge. Sie ersetzt weder eine Firewall noch eine Anmeldung und macht eine falsche Zieladresse nicht richtig.
Quellen & Methode
Vorgehen und Grenzen
Mit KI recherchierte und erstellte Dokumentationsanleitung. Vier ausgewählte Haupttexte wurden vollständig gelesen und verglichen; technische Aussagen wurden mit aktueller Originaldokumentation abgeglichen. Beispiele und Grafiken sind eigene Erläuterungen. Es wurden hier keine Laufzeiten, Modellantworten oder produktiven Workflow-Ausführungen gemessen. Gezielte Ergänzung vom 21.10.2026: eigene Diagnose- und Abnahmefälle mit aktueller Originaldokumentation abgeglichen. Die Beispiele wurden nicht als Modellleistung oder produktiver Laufzeittest gemessen.
Bei Recherche, Texterstellung und Grafiken wird KI eingesetzt. Welche eigenen Versuche vorliegen und was nur als Beispiel dient, beschreibt dieser Beitrag. Unser Redaktionsstandard erklärt die Anforderungen an Belege und Berichtigungen.
