Ollama von einem anderen Rechner oder vom Handy nutzen, ohne es offenzulegen

Von MV2 von Munim, Inc. Geprüft am 12. Oktober 2026 anhand der Ollama-FAQ, des Server-Quellcodes von Ollama (server/routes.go), der Tailscale-Serve-Dokumentation, der Open-WebUI-Seite HTTPS using Tailscale und der Server-Dokumentation von LM Studio. Nur für Ihre eigenen Rechner. Diese Seite wurde mit KI aus dem englischen Original übersetzt; bei Abweichungen gilt das Original.

Der übliche Rat lautet: „OLLAMA_HOST=0.0.0.0 setzen“ (oder in der App für macOS und Windows Settings → Expose Ollama to the network einschalten). Das funktioniert, aber die API von Ollama hat keinen Login. Damit kann jedes Gerät in diesem Netz Ihre Modelle nutzen, herunterladen und löschen und die Endpunkte erreichen, in denen die Ollama-CVEs (Englisch) dieses Jahres stecken. Wird der Port irgendwann am Router weitergeleitet, gilt das für das ganze Internet. Wählen Sie die engste Variante, die ihren Zweck erfüllt:

Sie möchten	Nutzen Sie	Wer Ollama sonst noch erreicht
Ab und zu von einem eigenen Laptop zugreifen	A. SSH-Tunnel	Niemand. Es wird nichts Neues geöffnet.
Vom Handy aus chatten, zu Hause oder unterwegs	B. Open WebUI über Tailscale Serve	Nur Ihr Tailnet, und nur über den Login von Open WebUI. Ollama bleibt auf localhost.
Apps auf anderen Geräten, die mit der Ollama-API sprechen (Tools auf einem anderen PC, n8n, eine Handy-App)	C. Ollama in Ihrem Tailnet	Geräte in Ihrem Tailnet
Andere Rechner im selben Heimnetz	D. LAN plus Firewall-Regel	Jedes Gerät in diesem Netz, ohne Login

Nicht tun: Port 11434 am Router weiterleiten; tailscale funnel, ngrok oder cloudflared ohne die Zugriffskontrolle des Anbieters vor Ollama setzen (alle drei veröffentlichen es im Internet); oder OLLAMA_ORIGINS=* setzen, „damit es geht“. Letzteres ändert, welche Websites Ollama aufrufen dürfen, nicht welche Geräte (siehe den Browser-Check (Englisch)).

A. SSH-Tunnel: ein Laptop, nichts zu öffnen

Lassen Sie Ollama auf dem GPU-Rechner auf dem Standard 127.0.0.1:11434. Auf dem Laptop:

ssh -N -L 11434:127.0.0.1:11434 you@gpu-box

Solange der Befehl läuft, ist http://127.0.0.1:11434 auf dem Laptop das Ollama des GPU-Rechners. ollama list, Open WebUI und alles, was standardmäßig localhost nutzt, funktioniert also einfach. Testen Sie es mit curl http://127.0.0.1:11434/api/version. Läuft auf dem Laptop ein eigenes Ollama auf 11434, leiten Sie stattdessen einen anderen Port weiter (-L 11435:127.0.0.1:11434) und richten die Clients darauf, zum Beispiel OLLAMA_HOST=127.0.0.1:11435 ollama list.

(Ersetzen Sie im Befehl you@gpu-box durch Ihren Benutzernamen und den Namen des GPU-Rechners.) Der GPU-Rechner braucht einen SSH-Server: Unter Linux läuft er meist schon; unter macOS schalten Sie Systemeinstellungen → Allgemein → Freigaben → Entfernte Anmeldung ein; unter Windows fügen Sie das optionale Feature „OpenSSH-Server“ hinzu. Der ssh-Client ist in Windows 10/11, macOS und Linux eingebaut. So besteht die Anfrage auch die Host-Prüfung von Ollama (siehe unten), weil sie an 127.0.0.1 gerichtet ist.

B. Vom Handy aus: Open WebUI über Tailscale Serve

Zum Chatten vom Handy aus bringen Sie Handy und Server in ein privates Netz und greifen auf Open WebUI zu, nicht auf Ollama. Ollama verlässt localhost nie, und die Konten von Open WebUI bleiben die Zugangskontrolle.

Installieren Sie Tailscale auf dem Server und auf dem Handy und melden Sie sich auf beiden mit demselben Konto an.
Lassen Sie Open WebUI auf localhost. In Docker: -p 127.0.0.1:3000:8080 (in Compose: ports: [ "127.0.0.1:3000:8080" ]), wobei Ollama wie bisher über OLLAMA_BASE_URL erreicht wird.
Auf dem Server:
```
tailscale serve --bg 3000
tailscale serve status
```
Der Status zeigt Ihre Adresse, https://<machine>.<tailnet>.ts.net (mit dem Namen Ihres Rechners und Ihres Tailnets). Tailscale Serve braucht für Ihr Tailnet aktivierte HTTPS-Zertifikate; sind sie aus, führt Sie der erste Aufruf zu einer Zustimmungsseite. --bg lässt es auch nach Neustarts weiterlaufen.
Teilen Sie Open WebUI seine Adresse mit, wie es auf seiner Tailscale-Seite steht: WEBUI_URL=https://<machine>.<tailnet>.ts.net und CORS_ALLOW_ORIGIN=https://<machine>.<tailnet>.ts.net. Erstellen Sie den Container neu. (Warum das wichtig ist, und die Einstellungen für Cookies und den geheimen Schlüssel: Open WebUI behind a proxy (Englisch).)
Öffnen Sie diese Adresse auf dem Handy und melden Sie sich an. Mit „Zum Home-Bildschirm“ wird daraus ein App-Symbol. Die Open-WebUI-Dokumentation weist darauf hin, dass Browser-Funktionen wie Sprachanrufe HTTPS brauchen, und das liefert Serve.

Testen: Schalten Sie das WLAN des Handys aus und laden Sie neu: Über mobile Daten sollte es weiterhin funktionieren. Ein Gerät, das nicht in Ihrem Tailnet ist, sollte die Adresse gar nicht laden. Ist die Registrierung in Open WebUI offen, schließen Sie sie (ENABLE_SIGNUP=False), nachdem Sie Ihre Konten angelegt haben. Rückgängig machen: tailscale serve reset.

Nicht tailscale funnel. Funnel macht dieselbe Adresse öffentlich im Internet erreichbar. Die Open-WebUI-Dokumentation warnt davor, und mit Blick auf die Sicherheitshinweise von Open WebUI aus dem September (Englisch) ist ein privates Tailnet die sicherere Voreinstellung.

C. Die Ollama-API selbst in Ihrem Tailnet

Manche Clients brauchen die rohe API: Ollama auf einem anderen PC, n8n oder ein Skript auf einem anderen Server, Handy-Apps, die sich direkt mit einer Ollama-URL verbinden.

Warum `tailscale serve 11434` 403 liefert

Der naheliegende Schritt, tailscale serve vor ein nur auf localhost lauschendes Ollama zu setzen, bringt bei jeder Anfrage 403 Forbidden. Das liegt nicht an Tailscale. Lauscht Ollama auf einer Loopback-Adresse, prüft seine allowedHostsMiddleware den Host-Header der Anfrage. Sie akzeptiert nur localhost, den eigenen Hostnamen des Rechners, Namen, die auf .localhost, .local oder .internal enden, sowie Loopback-, private oder lokale Schnittstellen-IPs. Diese Prüfung schützt vor DNS-Rebinding durch Websites. Serve reicht <machine>.<tailnet>.ts.net durch, und das steht nicht auf der Liste. Auf dem Server selbst sehen Sie es so: curl http://127.0.0.1:11434/api/version antwortet, während curl -H "Host: gpu-box.example.ts.net" http://127.0.0.1:11434/api/version 403 erhält. Lauscht Ollama auf einer Adresse, die keine Loopback-Adresse ist, entfällt diese Prüfung.

Lösung 1 (jedes Betriebssystem): Ollama nur an die Tailscale-Adresse binden

Ermitteln Sie die IPv4-Adresse des Servers im Tailnet: tailscale ip -4 (zum Beispiel 100.101.102.103).
Setzen Sie OLLAMA_HOST=100.101.102.103:11434 so, wie es die Ollama-FAQ beschreibt. Linux: sudo systemctl edit ollama.service, dann unter [Service] die Zeile Environment="OLLAMA_HOST=100.101.102.103:11434" hinzufügen, dann sudo systemctl daemon-reload && sudo systemctl restart ollama. macOS-App: launchctl setenv OLLAMA_HOST "100.101.102.103:11434", dann Ollama beenden und neu öffnen. Windows: Ollama beenden, OLLAMA_HOST unter „Umgebungsvariablen für dieses Konto bearbeiten“ setzen und Ollama dann über das Startmenü starten. Lassen Sie den Schalter „Expose Ollama to the network“ in der App aus.
Prüfen Sie, worauf Ollama wirklich lauscht (Linux ss -tlnp | grep 11434, macOS lsof -nP -iTCP:11434 -sTCP:LISTEN, Windows netstat -ano | findstr :11434). Sie wollen die 100.x-Adresse sehen, nicht 0.0.0.0 oder *.
Clients nutzen http://100.101.102.103:11434 oder den MagicDNS-Namen des Rechners, etwa http://gpu-box:11434. Für die Ollama-CLI auf einem anderen Rechner: OLLAMA_HOST=http://gpu-box:11434 ollama list.

Zwei Nebenwirkungen. (1) localhost:11434 antwortet auf dem Server selbst nicht mehr. Richten Sie lokale Tools ebenfalls auf die 100.x-Adresse, zum Beispiel OLLAMA_HOST=100.101.102.103:11434 ollama run ..., und ebenso die OLLAMA_BASE_URL von Open WebUI auf demselben Rechner. (2) Startet Ollama, bevor Tailscale seine Adresse hat, schlägt das Binden fehl. Die Linux-Unit, die der Ollama-Installer schreibt, enthält Restart=always und RestartSec=3, versucht es also so lange erneut, bis das Binden klappt. Unter macOS und Windows starten Sie Ollama neu, sobald Tailscale verbunden ist.

Lösung 2 (Linux mit ufw): überall lauschen, aber nur das Tailnet hereinlassen

So funktioniert localhost:11434 weiterhin. Setzen Sie OLLAMA_HOST=0.0.0.0:11434 (wie oben) und dann:

sudo ufw allow OpenSSH            # first, if you manage this box over SSH
sudo ufw default deny incoming
sudo ufw allow in on tailscale0 to any port 11434 proto tcp
sudo ufw enable
sudo ufw status verbose            # no other rule should allow 11434

(Die Kommentare bedeuten: die erste Zeile zuerst, falls Sie diesen Rechner per SSH verwalten; und in der Statusausgabe sollte keine andere Regel 11434 erlauben.) Das gilt für ein nativ installiertes Ollama. Läuft Ollama in Docker mit veröffentlichtem Port, greift ufw nicht: Docker schreibt eigene Firewall-Regeln (siehe Docker can't reach Ollama (Englisch)).

In beiden Fällen: Standardmäßig kann jedes Gerät in Ihrem Tailnet jedes andere erreichen. Haben Sie den Rechner mit anderen Personen geteilt oder haben Sie Geräte, denen Sie weniger vertrauen, beschränken Sie Port 11434 in der Zugriffsrichtlinie des Tailnets auf Ihre eigenen Geräte. Wenn Apps zusätzlich einen Schlüssel senden sollen, setzen Sie einen Proxy mit Bearer-Schlüssel (Englisch) davor.

D. Nur im selben Heimnetz: LAN plus Firewall-Regel

In einem Heimnetz, dem Sie vertrauen, ist das in Ordnung. Im WLAN von Büro, Wohnheim, Hotel oder Café ist es das nicht: Jeder im Netz, auch Gäste, bekommt Ihr Ollama ohne Login.

Setzen Sie OLLAMA_HOST=0.0.0.0:11434 (Schritte wie in Lösung 1, mit 0.0.0.0) oder schalten Sie in der App „Expose Ollama to the network“ ein. Beenden Sie Ollama vollständig und öffnen Sie es neu.
Beschränken Sie, wer sich verbinden darf:
- Linux (ufw): sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp (mit Ihrem eigenen Subnetz) zusammen mit default deny incoming, wie oben.
- Windows: Wenn Windows fragt, ob Ollama zugelassen werden soll, erlauben Sie nur Private Netzwerke, und stellen Sie sicher, dass das Profil Ihres Heimnetzes auf „Privat“ steht. Oder in einer PowerShell mit Administratorrechten:
```
New-NetFirewallRule -DisplayName "Ollama LAN only" -Direction Inbound -Protocol TCP -LocalPort 11434 -RemoteAddress LocalSubnet -Profile Private -Action Allow
```
  Zulassungsregeln addieren sich unter Windows. Öffnen Sie deshalb auch Windows Defender Firewall → Erweiterte Einstellungen → Eingehende Regeln und entfernen oder verengen Sie jede ältere Ollama-Regel, die öffentliche Netzwerke oder jede beliebige Adresse zulässt.
- macOS: Die eingebaute Firewall erlaubt oder blockiert pro App, nicht pro Subnetz. Nutzen Sie auf einem Mac stattdessen Variante A oder C.
Richten Sie am Router niemals eine Portweiterleitung für 11434 ein.

Testen: Von einem anderen Gerät im Netz sollte curl http://<server LAN IP>:11434/api/version (mit der LAN-IP des Servers) antworten. Von einem Handy über mobile Daten (WLAN aus) darf dieselbe Adresse nicht antworten.

LM Studio

LM Studio hat eigene Schalter unter Developer → Server Settings. Ab 0.4.0 schalten Sie Require Authentication ein, bevor Sie Serve on Local Network einschalten, legen unter Manage Tokens ein Token an, das nur die Rechte hat, die der Client braucht, und lassen die Clients Authorization: Bearer <token> senden. Die Authentifizierung ist standardmäßig aus. Lassen Sie Enable CORS aus, außer eine Webseite braucht es wirklich (der Browser-Check (Englisch) testet auch Port 1234). Die Varianten A, C und D funktionieren mit Port 1234 genauso, zum Beispiel ssh -N -L 1234:127.0.0.1:1234 you@gpu-box.

Das Ergebnis prüfen

Das kostenlose Skript local-ai-checkup meldet KI-Ports auf einem Rechner, die aus dem Netz erreichbar sind, und prüft Ihre Ollama-Version, OLLAMA_ORIGINS und die Docker-Portbindungen. Es liest nur und sendet nichts vom Rechner weg. Prüfen Sie danach die Versionen mit dem CVE-Checker (Englisch). Die Checkliste zum Absichern steht auf Ist mein Ollama offen im Netz?

Lieber prüfen lassen?

MV2 von Munim, Inc. bietet einen lokalen KI-Gesundheitscheck für 49 US-Dollar für einen Rechner an, oder einen Check für kleine Büros für 199 US-Dollar für bis zu 5 Rechner oder einen gemeinsam genutzten Ollama- oder Open-WebUI-Server. Sie erhalten einen schriftlichen Bericht darüber, was offen, riskant oder langsam ist und was Sie zuerst beheben sollten, mit genauen Befehlen für Ihr Betriebssystem und Modellvorschlägen, die zu Ihrer GPU passen. Der Bericht ist auf Englisch. Beispielbericht ansehen (Englisch). 49 $ zahlen oder 199 $ zahlen über Stripe, und senden Sie dann an munimversion2@gmail.com die Ausgabe von python3 local_ai_checkup.py --json, Ihr Betriebssystem und wofür Sie es nutzen. MV2 fragt nie nach Passwörtern, Schlüsseln oder Fernzugriff.