Von Matt Connor 2026-11-02 · Aktualisiert 2026-11-03

Ollama API: Port 11434 prüfen und absichern

Q: Wie mache ich die Ollama-API für einen anderen Rechner erreichbar?

Führen Sie sudo systemctl edit ollama.service aus und fügen Sie Environment="OLLAMA_HOST=0.0.0.0:11434" unter einer [Service]-Zeile ein. Führen Sie anschließend sudo systemctl daemon-reload und sudo systemctl restart ollama aus. Prüfen Sie die neue Bind-Adresse mit ss -ltnp | grep 11434. Die Unit muss bearbeitet werden, weil der Server unter systemd als Benutzer ollama ausgeführt wird. Eine in Ihrer Shell exportierte Variable erreicht den Dienst daher nicht. Die lokale API erfordert von Clients keine Authentifizierung. Richten Sie daher eine Firewall-Regel oder einen passwortgeschützten Proxy davor ein, bevor der Port aus dem Internet erreichbar ist.

Q: Wie ändere ich den Ollama-Port?

Setzen Sie den Port in OLLAMA_HOST, da diese Variable sowohl die Adresse als auch den Port enthält. Tragen Sie Environment="OLLAMA_HOST=127.0.0.1:11500" im systemd-Override ein. Laden Sie anschließend die Konfiguration neu und starten Sie den Dienst neu. Aktualisieren Sie außerdem alle Clients. Ein Client, der weiterhin auf 11434 zeigt, erhält eine Verbindungsablehnung, wenn dort nichts lauscht, oder verbindet sich mit einem anderen Dienst, der diesen Port noch verwendet. Wenn ollama serve mit bind: address already in use beendet wurde, führen Sie zuerst sudo ss -ltnp | grep 11434 aus. Häufig wird der Port von einem bereits laufenden Ollama-Dienst verwendet.

Q: Was ist der Unterschied zwischen /api/generate und /api/chat?

/api/generate übernimmt eine einzelne prompt-Zeichenfolge und gibt eine Vervollständigung zurück. /api/chat übernimmt ein messages-Array mit einem role für jeden Eintrag. Dieser Endpunkt unterstützt Tool-Aufrufe. Keiner der beiden Endpunkte speichert den Gesprächszustand auf dem Server. Ihr Client muss daher bei jeder Eingabe den vollständigen Verlauf senden. Verwenden Sie /api/chat für dialogorientierte Anwendungsfälle und /api/generate für einmalige Textverarbeitung, beispielsweise Klassifizierung.

Prüfen Sie Ollama mit curl an Port 11434, deuten Sie „Connection refused“ korrekt und konfigurieren Sie OLLAMA_HOST, ohne den Server unnötig offenzulegen.

Wofür Port 11434 verwendet wird

Die Ollama API lauscht am TCP-Port (Transmission Control Protocol) 11434. Mit einem einzelnen curl-Aufruf an /api/tags prüfen Sie, ob sie antwortet. Führen Sie den Befehl direkt auf dem Server aus, bevor Sie es von einem anderen Rechner aus versuchen.

curl http://localhost:11434/api/tags

Zwei Ergebnisse sind relevant. Entweder wird JSON zurückgegeben. Dann läuft der Serverprozess, und die API antwortet an diesem Port. Oder curl gibt Connection refused aus. Dann lauscht an dieser Adresse kein Prozess. Eine Ablehnung erfolgt unterhalb der Anwendung: Die TCP-Schicht meldet, dass kein Prozess den Port belegt. Authentifizierung und Modellnamen sind zu diesem Zeitpunkt noch nicht beteiligt.

/api/tags ist die richtige erste Anfrage, weil sie keinen Request-Body benötigt und kein Modell lädt. Sie listet die Modelle auf, die Sie bereits heruntergeladen haben.

Die Antwort ist ein JSON-Objekt mit einem models-Array. Die Struktur sehen Sie unten in gekürzter Form. Betrachten Sie sie als Beispiel, nicht als feste Zusage: Ihre Modellnamen und Größen unterscheiden sich, und zwischen Releases kommen weitere Felder hinzu.

{
  "models": [
    {
      "name": "llama3.2:latest",
      "model": "llama3.2:latest",
      "size": 2019393189,
      "details": {
        "format": "gguf",
        "family": "llama",
        "parameter_size": "3.2B",
        "quantization_level": "Q4_K_M"
      }
    }
  ]
}

Ein leeres models-Array zeigt, dass der Server ordnungsgemäß läuft, aber noch kein Modell heruntergeladen wurde. Um ein lokales Modell auszuführen, müssen Sie es herunterladen, nicht den Server neu starten. Für Cloud-Modelle ist kein lokaler Download erforderlich.

Warum curl „Connection refused“ meldet

Führen Sie die vier Prüfungen in dieser Reihenfolge durch. Jede Prüfung schließt eine andere Ursache aus.

systemctl status ollama zeigt, ob der Dienst überhaupt läuft. Eine Unit im Zustand inactive (dead) erklärt die Ablehnung bereits.
ss -ltnp | grep 11434 zeigt, an welche Adresse der Listener gebunden ist. Wenn keine Ausgabe erfolgt, lauscht dort nichts.
journalctl -e -u ollama zeigt, warum der Server beendet wurde oder warum er nicht gestartet werden konnte.
curl http://localhost:11434/api/version fragt die Serverversion ab. Dies ist die kleinste Anfrage, die bestätigt, dass die API selbst antwortet.

Die häufigste Ursache ist kein Absturz. Ollama bindet standardmäßig an 127.0.0.1 Port 11434. Daher akzeptiert es Verbindungen vom Server selbst, aber von keinem anderen Host. Ein curl-Aufruf von Ihrem Laptop an http://your-vps-ip:11434/api/tags wird abgelehnt, weil der Listener nicht an diese Adresse gebunden ist, obwohl dieselbe Anfrage per SSH auf dem Server problemlos funktioniert. Die Lösung ist OLLAMA_HOST. Sie wird weiter unten behandelt und sollte vor ihrer Verwendung sorgfältig geprüft werden.

Die relevanten Endpunkte auf einem Server

Die native API ist unter /api auf diesem einen Port erreichbar. Diese Pfade sollten Sie kennen, wenn Ollama auf einem VPS und nicht auf einem Laptop läuft.

GET /api/tags listet die auf dem Datenträger vorhandenen Modelle auf.
POST /api/pull lädt ein Modell anhand seines Namens herunter.
POST /api/generate führt eine einzelne Eingabe über ein Modell aus.
POST /api/chat führt eine Nachrichtenliste über ein Modell aus.
POST /api/embed wandelt Text in Vektoren um.
GET /api/ps listet die derzeit im Speicher geladenen Modelle auf.
POST /api/show gibt das Template und die Parameter eines Modells zurück.
DELETE /api/delete entfernt ein Modell vom Datenträger.
GET /api/version gibt die Serverversion zurück.

generate und chat: Welchen Endpoint Sie verwenden sollten

/api/generate erwartet einen prompt-String. Die API wendet das Template des Modells an und gibt eine Completion zurück. Auf dem Server gibt es keinen Konversationsstatus. Für eine Folgefrage muss daher der vollständige Verlauf erneut gesendet werden.

/api/chat erwartet ein messages-Array. Jeder Eintrag enthält ein role aus system, user, assistant oder tool sowie den zugehörigen content. Dieser Endpoint unterstützt Tool-Aufrufe. Auch hier speichert Ollama keine vorherigen Nachrichten. Ihr Client muss das vollständige Array bei jeder Anfrage senden.

Verwenden Sie /api/chat für dialogorientierte Anfragen und für alle Anfragen, die Tools aufrufen. Verwenden Sie /api/generate für einmalige Textaufgaben wie Klassifizierung oder Zusammenfassung, bei denen ein Nachrichten-Array keinen zusätzlichen Nutzen bietet.

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "Why is the sky blue?",
  "stream": false
}'

curl http://localhost:11434/api/chat -d '{
  "model": "llama3.2",
  "messages": [
    {
      "role": "user",
      "content": "why is the sky blue?"
    }
  ],
  "stream": false
}'

Ersetzen Sie llama3.2 durch ein Modell, das Sie tatsächlich heruntergeladen haben. Die Anfrage nach einem lokal fehlenden Modell gibt den Statuscode 404 zurück. Die API lädt das Modell nicht für Sie herunter. Ein angemeldeter lokaler Server kann auch ein Cloud-Modell ausführen, ohne es herunterzuladen. Verwenden Sie dazu den Namen eines Cloud-Modells mit dem Suffix :cloud.

Streaming ist die Standardeinstellung und überrascht viele

/api/generate und /api/chat streamen standardmäßig, ebenso /api/pull. Eine Streaming-Antwort liegt als NDJSON vor (JSON mit einem Objekt pro Zeile): ein JSON-Objekt pro Zeile, nicht ein einzelnes JSON-Dokument. Wenn Sie den gesamten Body an einen JSON-Parser übergeben, schlägt das Parsen fehl, weil der Body nie ein einzelnes Objekt war.

Setzen Sie "stream": false, erhalten Sie stattdessen ein einzelnes Objekt, sobald das Modell fertig ist. Diese Struktur ist für ein Skript einfacher. Der Nachteil ist die Latenz: Vor der Generierung des letzten Tokens trifft keine Ausgabe ein.

In einer Streaming-Generierungsantwort enthält die letzte Zeile "done": true sowie Timing-Felder wie total_duration und eval_count. Die Zeitangaben sind in Nanosekunden. eval_duration von 4709213000 entspricht daher ungefähr 4.7 Sekunden. eval_count durch diese Anzahl von Sekunden zu teilen, ist die verlässliche Methode, um Tokens pro Sekunde bei einem lokalen Modell zu messen, weil der Wert aus der tatsächlich ausgeführten Anfrage stammt.

Modell über die API herunterladen

curl http://localhost:11434/api/pull -d '{"model": "llama3.2"}'

Die Verbindung bleibt für die Dauer des Downloads geöffnet. Fortschrittsobjekte werden gesendet, sobald sie verfügbar sind. Fügen Sie "stream": false hinzu, damit der Vorgang ohne Ausgabe wartet und am Ende ein einzelnes Statusobjekt empfängt. Ein Download über die API schreibt in denselben Modellspeicher, den auch die Befehlszeile verwendet. Mit ollama list auf dem Server wird das Modell anschließend angezeigt.

Das ist auf einem neuen Server wichtig, wenn nach der Installation zunächst ein Modell auf dem Datenträger benötigt wird. Wenn Sie den Server gerade einrichten, beginnen Sie mit einer funktionierenden Ollama-Installation auf einem VPS und kehren Sie zur API zurück, sobald ollama list etwas anzeigt.

Embeddings

curl http://localhost:11434/api/embed -d '{
  "model": "all-minilm",
  "input": "Why is the sky blue?"
}'

input akzeptiert eine Zeichenkette oder ein Array aus Zeichenketten. Dadurch kann ein Batch in einer einzigen Anfrage verarbeitet werden. Die Antwort enthält ein Feld embeddings mit einem Vektor pro Eingabe sowie Felder zur Zeitmessung.

Ein älterer /api/embeddings-Endpunkt antwortet weiterhin. Er erwartet prompt statt input und gibt ein einzelnes embedding anstelle eines embeddings-Arrays zurück. Neuer Code sollte /api/embed verwenden. Die unterschiedlichen Feldnamen sind der übliche Grund dafür, dass ein kopiertes Beispiel Vektoren zurückgibt, die Ihr Code als undefined einliest.

Der OpenAI-kompatible Pfad unter /v1

Ollama stellt am selben Port außerdem eine OpenAI-kompatible API unter /v1 bereit. Richten Sie einen vorhandenen Client auf http://localhost:11434/v1, prüfen Sie anschließend, ob dessen Funktionen unterstützt werden, und ändern Sie das angeforderte Modell in einen Ollama-Modellnamen. Wenn der Client einen OpenAI-Modellnamen voraussetzt, erstellen Sie mit ollama cp einen lokalen Alias, zum Beispiel ollama cp llama3.2 gpt-3.5-turbo.

curl -X POST http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
  "model": "gpt-oss:20b",
  "messages": [{ "role": "user", "content": "Say this is a test" }]
}'

Die kompatible Oberfläche umfasst /v1/chat/completions, /v1/completions, /v1/models, /v1/models/{model}, /v1/embeddings und /v1/responses. Die meisten SDKs (Softwareentwicklungskits) benötigen zwei Einstellungen: eine Basis-URL mit http://localhost:11434/v1 und einen API-Schlüssel. Ollama ignoriert den Schlüssel, aber viele Clients starten ohne einen solchen Schlüssel nicht. Setzen Sie ihn daher auf die Zeichenfolge ollama.

Am 2. November 2026 unterstützt die Kompatibilitätsschicht eine Teilmenge der OpenAI API. Logprobs werden unterstützt. Bilder können als Base64 oder als URL gesendet werden. tool_choice wird unterstützt, zustandsbehaftete Anfragen an /v1/responses dagegen nicht. Testen Sie die von Ihnen benötigte Funktion, bevor Sie diesem Pfad vertrauen. Dies ist der von den meisten Editor-Plugins verwendete Weg. Darüber richten Sie einen Coding-Agent auf Ihren eigenen Ollama-Server aus, statt auf einen kostenpflichtigen Endpunkt: einen Coding-Agent auf Ihren eigenen Ollama-Server ausrichten.

Wof `OLLAMA_HOST` bewirkt

OLLAMA_HOST legt die Adresse und den Port fest, an die der Ollama-Server gebunden wird. Standardmäßig ist dies 127.0.0.1:11434, also ausschließlich die Loopback-Adresse.

Dieselbe Variable hat auf der Client-Seite eine zweite Funktion. OLLAMA_HOST=http://10.0.0.5:11434 ollama list fragt einen entfernten Server ab, welche Modelle dort vorhanden sind. Ein Name, zwei Bedeutungen: Beim Server-Prozess legt die Variable fest, an welcher Adresse er Verbindungen annimmt. In der Befehlszeile legt sie fest, zu welcher Adresse eine Verbindung hergestellt wird. Die Verwechslung dieser beiden Funktionen ist der Grund dafür, dass Benutzer die Variable in ihrer Shell exportieren, keinen Dienst neu starten und anschließend keine Änderung der Bind-Adresse feststellen.

Unter Linux wird der Server unter systemd als Benutzer ollama ausgeführt. Eine in Ihrer interaktiven Shell exportierte Variable erreicht diesen Prozess daher nicht. Bearbeiten Sie stattdessen die Unit.

sudo systemctl edit ollama.service

Fügen Sie diesen Block in dem geöffneten Editor ein.

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

Laden Sie anschließend die Konfiguration neu, starten Sie den Dienst neu und prüfen Sie den Listener erneut.

sudo systemctl daemon-reload
sudo systemctl restart ollama
ss -ltnp | grep 11434

ss sollte nun den Listener auf 0.0.0.0:11434 statt auf 127.0.0.1:11434 anzeigen. Wenn weiterhin nur die Loopback-Adresse angezeigt wird, wurde die Überschreibung nicht angewendet. Führen Sie systemctl show ollama --property=Environment aus, um zu prüfen, welche Werte der Dienst tatsächlich erhalten hat, und stellen Sie sicher, dass die Datei unter /etc/systemd/system/ollama.service.d/ abgelegt wurde.

Warum die Veröffentlichung der Ollama API eine bewusste Entscheidung ist

Die lokale Ollama API erfordert von Clients keine Authentifizierung. Für die lokale Inferenz gibt es weder ein Token noch einen Benutzer oder einen Anmeldeschritt. Jeder, der Port 11434 erreichen kann, kann Ihre Modelle auflisten, neue Modelle herunterladen, sie löschen und auf Ihre Kosten Generierungen auf Ihrer Hardware ausführen.

0.0.0.0 bezeichnet jedes Netzwerk, mit dem dieser Rechner verbunden ist. Auf einem VPS gehört dazu auch das öffentliche Internet. Scanner finden einen offenen Port 11434 schnell, weil es sich um einen festen Standardport handelt. Legen Sie daher fest, wer Zugriff benötigt, bevor Sie das Binding ändern, und schalten Sie eine Zugriffskontrolle davor: eine Firewall-Regel, die eine Quelladresse zulässt, oder einen Reverse Proxy, der ein Passwort verlangt. Diese Optionen benötigen mehr Platz, als auf diese Seite passt. Einen öffentlichen Ollama-Endpunkt absichern behandelt sie ausführlich.

Für einen einzelnen Benutzer ist es sicherer, das Binding auf dem Loopback-Interface zu belassen und den Zugriff über SSH zu tunneln.

ssh -N -L 11434:127.0.0.1:11434 user@your-server

Während dieser Befehl ausgeführt wird, erreicht curl http://localhost:11434/api/tags auf Ihrem Laptop die Loopback-Schnittstelle des Servers über die SSH-Sitzung. Nichts wird im Internet veröffentlicht, und es ist keine Firewall-Regel erforderlich.

So ändern Sie den Ollama-Port, wenn 11434 belegt ist

Ports können kollidieren. Ein anderer Dienst oder eine zweite Ollama-Instanz verwendet möglicherweise bereits 11434. Ermitteln Sie, welcher Prozess den Port verwendet, bevor Sie Änderungen vornehmen.

sudo ss -ltnp | grep 11434

Wenn ollama serve den Port nicht verwenden kann, wird der Prozess sofort beendet. Die Meldung nennt die Adresse und endet mit bind: address already in use. Häufig ist der systemd-Dienst bereits aktiv und Sie haben einen zweiten Server manuell gestartet. Beenden Sie eine der beiden Instanzen mit sudo systemctl stop ollama, oder verwenden Sie einfach den bereits aktiven Dienst.

Um den Port zu ändern, setzen Sie ihn in derselben Variable. OLLAMA_HOST enthält Adresse und Port gemeinsam.

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

Nach daemon-reload und restart müssen alle Clients angepasst werden. Die Befehlszeile benötigt OLLAMA_HOST=http://127.0.0.1:11500, und bei jedem HTTP-Client muss die Basis-URL entsprechend geändert werden. Ein Client, der weiterhin auf 11434 zeigt, erhält Connection refused, wenn dort nichts lauscht. Wenn ein anderer Dienst oder eine andere Ollama-Instanz diesen Port verwendet, verbindet sich der Client stattdessen mit diesem Dienst.

Zwei weitere wichtige Variablen

OLLAMA_ORIGINS steuert CORS (Cross-Origin Resource Sharing). Die standardmäßige Allowlist ist weiter gefasst, als die Ollama-FAQ vermuten lässt. Im Quellcode umfasst sie localhost, 127.0.0.1 und 0.0.0.0 über http:// und https://, jeweils mit oder ohne Port, sowie die Schemata app://, file://, tauri://, vscode-webview:// und vscode-file://, die Desktop-Anwendungen und Editoren verwenden. Daher passiert eine Seite unter http://localhost:3000 oder eine VS-Code-Webview die standardmäßige CORS-Prüfung von Ollama. Eine lokale Datei kann Origin: null senden. Das entspricht nicht file://* und wird standardmäßig abgelehnt. Eine Browser-Anfrage mit einem anderen Origin, beispielsweise Ihrer eigenen Domain oder einer Browser-Erweiterung, erhält von Ollama 403 Forbidden. Fügen Sie die benötigten Origins hinzu, zum Beispiel Environment="OLLAMA_ORIGINS=chrome-extension://*". Die gesetzten Werte werden zu den Standardwerten hinzugefügt und ersetzen sie nicht. Die Prüfung liest den Header Origin, den Browser anhängen, den curl jedoch nicht sendet. Dadurch wird eine Webseite eingeschränkt, curl aber überhaupt nicht.

OLLAMA_KEEP_ALIVE legt fest, wie lange ein Modell nach einer Anfrage im Speicher bleibt. Standardmäßig beträgt dieser Zeitraum fünf Minuten. Danach werden die Gewichte aus dem Speicher entfernt, und die nächste Anfrage muss die Ladezeit erneut abwarten. Pro Anfrage können Sie "keep_alive": "30m" senden oder -1 verwenden, um das Modell unbegrenzt im Speicher zu halten. GET /api/ps zeigt an, was derzeit geladen ist, einschließlich eines Zeitstempels expires_at und des von jedem Modell belegten Speichers. Der Zielkonflikt zwischen Speicherverbrauch und der Latenz bis zum ersten Token wird unter ein im Speicher geladenes Ollama-Modell beibehalten erläutert.

Optionen pro Anfrage

Sowohl /api/generate als auch /api/chat akzeptieren ein options-Objekt mit Modellparametern.

curl http://localhost:11434/api/chat -d '{
  "model": "llama3.2",
  "messages": [{"role": "user", "content": "summarise this log line"}],
  "stream": false,
  "options": {"temperature": 0, "num_ctx": 8192}
}'

num_ctx ist die Option mit dem größten Einfluss auf den Speicherverbrauch, weil der KV-Cache (Key-Value-Cache) mit der Kontextlänge wächst. Ist der Wert auf einem kleinen VPS zu hoch, reicht der RAM nicht aus oder das Modell kann überhaupt nicht geladen werden. num_ctx für Ihre Hardware dimensionieren beschreibt, wie Sie einen passenden Wert auswählen. Wenn mehrere Clients gleichzeitig auf die API zugreifen, ist auch das Warteschlangenverhalten relevant. OLLAMA_NUM_PARALLEL und OLLAMA_MAX_QUEUE legen fest, wie viele Anfragen gleichzeitig ausgeführt werden und wie viele warten.

Fehlerbilder und die angezeigten Meldungen

Connection refused. An dieser Adresse und diesem Port lauscht kein Prozess. Prüfen Sie zuerst den Dienst und anschließend die Bind-Adresse mit ss -ltnp. Von einem entfernten Rechner bedeutet das fast immer, dass Ollama noch an die Loopback-Adresse gebunden ist.

404 mit einem Feld error. Lesen Sie die Fehlermeldung. Sowohl ein fehlendes lokales Modell als auch ein fehlender Blob führen zu dieser Antwort. /api/generate lädt nichts automatisch nach. Wenn die Fehlermeldung ein fehlendes lokales Modell nennt, führen Sie zuerst den Pull aus. Prüfen Sie dabei sowohl den Tag als auch den Namen: llama3.2 und llama3.2:1b sind unterschiedliche Modelle. Cloud-Modelle benötigen keinen lokalen Download.

400 mit einem Feld error. Der Request-Body wurde abgelehnt. In einer Shell liegt das meist an der Quoting-Syntax. -d "{"model": "llama3.2"}" funktioniert nicht, weil die Shell die äußeren doppelten Anführungszeichen entfernt, bevor curl sie überhaupt sieht. Setzen Sie das JSON in einfache Anführungszeichen oder speichern Sie es in einer Datei und senden Sie es mit -d @request.json.

429, zu viele Requests. Das wird durch ein Rate-Limit verursacht. Wenn dieser Fehler bei Ihrem eigenen Server auftritt, zeigt das entweder, dass Ihre Base-URL auf einen gehosteten Endpunkt statt auf Port 11434 Ihres Servers verweist, oder dass der Request ein :cloud-Modell angegeben hat. Ihr Server übergibt dieses Modell an den gehosteten Dienst von Ollama, und die Nutzung wird dem betreffenden Konto angerechnet.

Ein Fehler tritt mitten in einem Stream auf. Eine Streaming-Antwort hat bereits HTTP 200 gesendet, wenn das Modell fehlschlägt. Daher bleibt der Statuscode 200, und der Fehler erscheint als JSON-Objekt mit einem Feld error innerhalb des Streams. Ein Client, der nur den Statuscode prüft, meldet eine fehlgeschlagene Generierung als erfolgreich. Analysieren Sie jede Zeile.

Die erste Anfrage dauert deutlich länger als die folgenden. Das Modell wird von der Festplatte in den Arbeitsspeicher gelesen. GET /api/ps gibt vor dem Aufruf eine leere Liste und danach ein geladenes Modell zurück und bestätigt damit genau dieses Verhalten. Durch Erhöhen von keep_alive wird verhindert, dass dies wiederholt auftritt.

Jeder Befehl in diesem Abschnitt wird gegen Ihre eigene Instanz ausgeführt. Die Ausgabe stammt daher von Ihrem Server und ist kein Transkript meiner Ausgabe. Führen Sie die Befehle auf dem Server in der angegebenen Reihenfolge aus, bevor Sie die Bind-Adresse ändern. So erkennen Sie, welche Schicht fehlerhaft ist, wenn ein Dienst nicht mehr antwortet.

FAQ

Wofür wird Port 11434 verwendet?

Port 11434 ist der standardmäßige TCP-Port der Ollama-HTTP-API. Der Server bindet sich nach einer Standardinstallation an 127.0.0.1:11434, und die ollama-Befehlszeile sowie alle HTTP-Clients greifen dort darauf zu. Die native API ist unter /api erreichbar, eine OpenAI-kompatible API unter /v1 am selben Port. curl http://localhost:11434/api/tags ist die schnellste Prüfung, ob der Server antwortet.

Warum meldet curl bei Port 11434 „Connection refused“?

An der angeforderten Adresse lauscht kein Prozess. Führen Sie systemctl status ollama aus, um zu prüfen, ob der Dienst aktiv ist, und anschließend ss -ltnp | grep 11434, um die Bind-Adresse anzuzeigen. Wenn die Prüfung auf dem Server funktioniert, aber von Ihrem Laptop aus fehlschlägt, liegt die Ursache an der standardmäßigen Bind-Adresse: Ollama lauscht nur auf 127.0.0.1, daher wird eine Verbindung über das öffentliche Interface abgewiesen. Setzen Sie entweder OLLAMA_HOST und richten Sie eine Zugriffskontrolle ein oder leiten Sie den Port mit ssh -N -L 11434:127.0.0.1:11434 user@your-server weiter.

Wie mache ich die Ollama-API für einen anderen Rechner erreichbar?

Führen Sie sudo systemctl edit ollama.service aus und fügen Sie Environment="OLLAMA_HOST=0.0.0.0:11434" unter einer [Service]-Zeile ein. Führen Sie anschließend sudo systemctl daemon-reload und sudo systemctl restart ollama aus. Prüfen Sie die neue Bind-Adresse mit ss -ltnp | grep 11434. Die Unit muss bearbeitet werden, weil der Server unter systemd als Benutzer ollama ausgeführt wird. Eine in Ihrer Shell exportierte Variable erreicht den Dienst daher nicht. Die lokale API erfordert von Clients keine Authentifizierung. Richten Sie daher eine Firewall-Regel oder einen passwortgeschützten Proxy davor ein, bevor der Port aus dem Internet erreichbar ist.

Wie ändere ich den Ollama-Port?

Setzen Sie den Port in OLLAMA_HOST, da diese Variable sowohl die Adresse als auch den Port enthält. Tragen Sie Environment="OLLAMA_HOST=127.0.0.1:11500" im systemd-Override ein. Laden Sie anschließend die Konfiguration neu und starten Sie den Dienst neu. Aktualisieren Sie außerdem alle Clients. Ein Client, der weiterhin auf 11434 zeigt, erhält eine Verbindungsablehnung, wenn dort nichts lauscht, oder verbindet sich mit einem anderen Dienst, der diesen Port noch verwendet. Wenn ollama serve mit bind: address already in use beendet wurde, führen Sie zuerst sudo ss -ltnp | grep 11434 aus. Häufig wird der Port von einem bereits laufenden Ollama-Dienst verwendet.

Was ist der Unterschied zwischen /api/generate und /api/chat?

/api/generate übernimmt eine einzelne prompt-Zeichenfolge und gibt eine Vervollständigung zurück. /api/chat übernimmt ein messages-Array mit einem role für jeden Eintrag. Dieser Endpunkt unterstützt Tool-Aufrufe. Keiner der beiden Endpunkte speichert den Gesprächszustand auf dem Server. Ihr Client muss daher bei jeder Eingabe den vollständigen Verlauf senden. Verwenden Sie /api/chat für dialogorientierte Anwendungsfälle und /api/generate für einmalige Textverarbeitung, beispielsweise Klassifizierung.

War dieser Artikel hilfreich?

#ollama #api#curl#self-hosted-llm #networking

Wofür Port 11434 verwendet wird

Warum curl „Connection refused“ meldet

Die relevanten Endpunkte auf einem Server

generate und chat: Welchen Endpoint Sie verwenden sollten

Streaming ist die Standardeinstellung und überrascht viele

Modell über die API herunterladen

Embeddings

Der OpenAI-kompatible Pfad unter /v1

Wof OLLAMA_HOST bewirkt

Warum die Veröffentlichung der Ollama API eine bewusste Entscheidung ist

So ändern Sie den Ollama-Port, wenn 11434 belegt ist

Zwei weitere wichtige Variablen

Optionen pro Anfrage

Fehlerbilder und die angezeigten Meldungen

FAQ

Wofür wird Port 11434 verwendet?

Warum meldet curl bei Port 11434 „Connection refused“?

Wie mache ich die Ollama-API für einen anderen Rechner erreichbar?

Wie ändere ich den Ollama-Port?

Was ist der Unterschied zwischen /api/generate und /api/chat?

War dieser Artikel hilfreich?

Wof `OLLAMA_HOST` bewirkt