dsh Web: Warum 127.0.0.1:3080 nicht erreichbar ist

Was dsh web: http://127.0.0.1:3080 bedeutet

Wenn Sie das DeepSeek Harness-Webprofil auf einem VPS starten, gibt es zwei Zeilen aus und wartet anschließend:

dsh web: http://127.0.0.1:3080
Ready.

127.0.0.1 ist die Loopback-Adresse. Das ist die Adresse, über die ein Rechner mit sich selbst kommuniziert. Ein Socket, der an 127.0.0.1 gebunden ist, akzeptiert Verbindungen von Prozessen auf demselben Rechner und von keinem anderen. Diese Zeile zeigt daher gleichzeitig zwei Dinge: Wo die Weboberfläche lauscht und wer sie erreichen darf. Das ist ausschließlich auf dem Rechner möglich, auf dem dsh ausgeführt wird.

Deshalb bewirkt die URL nichts, wenn Sie sie in den Browser auf Ihrem Laptop einfügen. Die 127.0.0.1-Adresse Ihres Laptops gehört zu Ihrem Laptop. Das Harness lauscht auf der 127.0.0.1-Adresse des VPS. Das ist ein anderer Rechner mit einem anderen Loopback-Stack. Es ist nichts kaputt. Sie müssen die Verbindung über den VPS weiterleiten.

In der offiziellen README steht der Standardwert eindeutig: „Der Befehl startet die Weboberfläche, die standardmäßig unter http://127.0.0.1:3080 bereitgestellt wird.“ Die Bind-Adresse stammt vom Webserver-Host-Plugin @deepseek-ai/dsh-host-webserver. Dessen Schlüssel host ist als „Host, auf dem gelauscht wird; die beiden unterstützten Werte sind loopback und all-interfaces“ dokumentiert. Ohne Änderung wird loopback verwendet. Wenn Ports für Sie noch neu sind, erklärt wie Ports unter Linux funktionieren das Modell aus Adresse und Port, auf dem dies alles beruht.

Warum die Weboberfläche nur an localhost gebunden ist

dsh ist ein Agent-Harness, also das Programm, das um das Modell herum ausgeführt wird: Es verwaltet die Schleife, die Tool-Aufrufe und die Berechtigungen, unter denen diese Aufrufe ausgeführt werden. Der Browser-Tab ist eine Steuerschnittstelle für einen Prozess, der Shell-Befehle ausführt, Dateien im von Ihnen ausgewählten Arbeitsverzeichnis liest und schreibt und Ihren API-Schlüssel für das Modell verwendet. Jeder, der diese Seite laden kann, kann all das als der Benutzer tun, unter dem dsh ausgeführt wird. Der Netzwerkzugriff ist außerdem nicht der einzige Weg zu diesen Berechtigungen: Ein installiertes Plugin läuft im selben Prozess und mit denselben Berechtigungen. Deshalb verdient die Prüfung eines dsh-Plugins vor der Installation dieselbe Sorgfalt wie die Entscheidung, auf welcher Adresse der Server lauscht.

Port 3080 ist also kein Dashboard mit Nur-Lese-Zugriff. Das Laden dieser Seite ermöglicht die Ausführung von Befehlen auf dem Server.

Wenn Sie die Weboberfläche öffnen, gelangen Sie direkt zur Sitzungsliste. Es gibt keine Anmeldeaufforderung, weil die Entwicklervorschau keine Benutzerkonten und keine Remote-Authentifizierung bereitstellt. Auf dem Loopback-Interface ist das konsistent: Das Betriebssystem übernimmt die Zugriffskontrolle, und nur lokale Prozesse können eine Verbindung herstellen. Binden Sie denselben Server auf einem VPS mit öffentlicher IP an 0.0.0.0, antwortet diese Seite ohne vorgeschaltete Zugriffskontrolle dem gesamten Internet. Automatisierte Scanner prüfen kontinuierlich ungewöhnliche Ports. Behandeln Sie einen veröffentlichten Port 3080 daher als entdeckt.

Öffnen Sie Port 3080 nicht in Ihrer Firewall und setzen Sie host des Webservers auf einem öffentlichen VPS nicht auf 0.0.0.0. Diese Kombination ermöglicht jedem, der zuerst eine Verbindung herstellt, die Ausführung von Befehlen auf Ihrem Server.

Dieselbe Überlegung gilt für jede Agent-Laufzeitumgebung, die Sie auf einem Server betreiben. Deshalb beginnt auch der sichere Betrieb eines Coding-Agenten auf einem VPS mit derselben Regel: Der Steuerungsport des Agenten bleibt privat, und eine vertrauenswürdige Komponente stellt die Verbindung zu ihm her.

Wie öffne ich die dsh-Weboberfläche von meinem Laptop aus?

Dafür gibt es drei sinnvolle Möglichkeiten. Bei allen bleibt das Harness an die Loopback-Schnittstelle gebunden.

• Einen SSH-Tunnel. Dabei lauscht nichts zusätzlich an der öffentlichen Schnittstelle, und Sie haben die Zugangsdaten bereits. Diese Variante sollten Sie verwenden.
• Ein privates Overlay-Netzwerk. Dadurch ist die Weboberfläche von Ihren eigenen Geräten aus erreichbar und für alle anderen unsichtbar.
• Einen Reverse Proxy, der TLS (Transport Layer Security) terminiert und ein Passwort verlangt, bevor er Anfragen weiterleitet.

Der Unterschied liegt darin, was Ihren Browser mit der Loopback-Schnittstelle verbindet. Keine dieser Varianten sollte das Harness von der Loopback-Schnittstelle lösen.

Zugriff über einen SSH-Tunnel

Führen Sie diesen Befehl auf Ihrem Laptop aus, nicht auf dem VPS:

ssh -N -L 3080:127.0.0.1:3080 you@your-vps

Lassen Sie den Befehl laufen und öffnen Sie anschließend http://127.0.0.1:3080 in Ihrem lokalen Browser. Die Weboberfläche wird geladen.

Das Argument -L enthält drei durch Doppelpunkte getrennte Felder. Das erste Feld ist der Port, der auf Ihrem Laptop geöffnet wird. Das zweite und dritte Feld geben die Adresse und den Port an, an die jede Verbindung weitergeleitet wird. Entscheidend ist: 127.0.0.1 im mittleren Feld wird vom SSH-Server auf dem VPS aufgelöst, nachdem Ihr Datenverkehr dort bereits angekommen ist. Gemeint ist die Loopback-Adresse des VPS, nicht die Ihres Laptops. Genau diese Adresse hat dsh ausgegeben. Deshalb funktioniert der Tunnel, obwohl eine direkte Browserverbindung fehlschlägt.

-N weist SSH an, keinen Remote-Befehl auszuführen. Dadurch erhalten Sie nur eine Weiterleitung und keine Shell. Für einen Tunnel im Hintergrund, der Fehler deutlich meldet, statt still zu scheitern:

ssh -N -f -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 -L 3080:127.0.0.1:3080 you@your-vps

-f verschiebt den Prozess nach der Authentifizierung in den Hintergrund. ExitOnForwardFailure=yes ist wichtiger, als es zunächst scheint: Ohne diese Option stellt SSH die Verbindung auch dann erfolgreich her, wenn die Weiterleitung nicht eingerichtet werden konnte. Sie erhalten dann eine funktionierende Sitzung, aber einen nicht funktionierenden Tunnel ohne Warnung. ServerAliveInterval=30 sendet alle 30 Sekunden ein Keepalive. Dadurch bleibt ein inaktiver Tunnel trotz NAT (Network Address Translation)-Timeouts auf Routern in Cafés und Hotels bestehen.

Was Sie sehen sollten

Prüfen Sie auf dem VPS, welcher Prozess tatsächlich lauscht:

ss -ltnp | grep 3080

In einer korrekten Ausgabe ist die Loopback-Adresse aufgeführt:

LISTEN 0  511  127.0.0.1:3080  0.0.0.0:*  users:(("node",pid=1042,fd=21))

Wenn die Spalte für die lokale Adresse stattdessen 0.0.0.0:3080 enthält, ist die Weboberfläche an jeder Schnittstelle verfügbar, auch an der öffentlichen. Stoppen Sie den Dienst und korrigieren Sie die Bind-Adresse, bevor Sie etwas anderes tun. Wenn ss den Socket ausgibt, aber das Feld users: leer lässt, führen Sie den Befehl mit sudo aus. Andernfalls wird der Prozessname eines Sockets, der einem anderen Benutzer gehört, ausgeblendet.

Wenn der Tunnel nicht gestartet werden kann

SSH gibt diese Meldung aus und beendet sich:

bind [127.0.0.1]:3080: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 3080

Das betrifft Ihren Laptop, nicht den Server. Ein lokaler Prozess verwendet bereits Port 3080. Häufig ist das ein früherer Tunnel, den Sie vergessen haben. Wählen Sie stattdessen einen freien lokalen Port:

ssh -N -L 3081:127.0.0.1:3080 you@your-vps

Nur das erste Feld wurde geändert. Sie öffnen die Verbindung daher jetzt unter http://127.0.0.1:3081, während der Harness weiterhin auf Port 3080 lauscht. Die beiden Portnummern müssen nicht übereinstimmen.

Wenn der Tunnel zwar startet, der Browser aber eine abgelehnte Verbindung oder eine leere Antwort meldet, hat der Datenverkehr den VPS erreicht, dort jedoch am Ziel nichts gefunden. Entweder wurde dsh beendet oder der Prozess hat einen anderen Port verwendet. Prüfen Sie dies mit ss -ltnp | grep 3080 auf dem Server.

Ein weiterer Punkt führt hier häufig zu Problemen. Ein npx @deepseek-ai/dsh web-Prozess im Vordergrund wird beendet, sobald seine Shell geschlossen wird. Der Harness wird daher beendet, sobald Sie sich abmelden. Starten Sie ihn innerhalb von tmux oder unter einem systemd-Benutzerdienst. Damit wird dasselbe Problem gelöst wie in einen Coding-Agent auf einem VPS weiterlaufen lassen. Während Sie die SSH-Seite einrichten, sollten Sie außerdem zuerst SSH auf Ihrem VPS absichern, weil der Tunnel Ihren SSH-Login zum einzigen Zugang zum Agenten macht.

Zugriff über ein privates Overlay-Netzwerk

Ein Overlay-Netzwerk weist Ihrem VPS und Ihrem Laptop Adressen in einem privaten Netzwerk zu, dem nur Ihre Geräte beitreten. Tailscale ist dafür die gängige Wahl. Der Befehl serve ist für diesen Anwendungsfall genau geeignet: tailscaled wird auf dem VPS ausgeführt und verbindet sich mit localhost:3080 selbst. Dadurch bleibt der Harness an Loopback gebunden, und Sie müssen an der Konfiguration von dsh nichts ändern.

tailscale serve --bg localhost:3080
tailscale serve status

Die Benutzeroberfläche ist anschließend unter dem Rechnernamen Ihres Geräts in Ihrem Tailnet über HTTPS erreichbar. Am öffentlichen Interface muss dafür kein Port geöffnet werden. Dazu müssen HTTPS-Zertifikate für Ihr Tailnet aktiviert sein. Andernfalls kann serve kein Zertifikat bereitstellen. Um den Zugriff wieder zu deaktivieren, führen Sie den Befehl mit off erneut aus:

tailscale serve --https=443 off

Verwenden Sie serve, niemals funnel. Funnel veröffentlicht dasselbe Ziel im öffentlichen Internet. Dadurch läuft der Agent wieder unauthentifiziert an einem offenen Port. Die beiden Befehle sehen fast gleich aus, bewirken aber das Gegenteil. Lesen Sie daher den Unterschied zwischen Tailscale Serve und Funnel, bevor Sie einen der beiden Befehle eingeben. Tailscale als privates Netzwerk beschreibt die Einrichtung selbst.

Zugriff über einen Reverse Proxy mit Passwortprüfung

Diese Option veröffentlicht tatsächlich einen Port im Internet. Damit ist die Authentifizierung die einzige Hürde zwischen einer fremden Person und der Ausführung von Befehlen auf Ihrem Server. Wählen Sie diese Option, wenn mehrere Personen die Benutzeroberfläche benötigen und ein eigener Tunnel pro Person unpraktisch ist.

Der Harness bleibt auf 127.0.0.1:3080. nginx läuft auf demselben Rechner, kann daher auf die Loopback-Schnittstelle zugreifen und lauscht mit einem Zertifikat und einer Passwortdatei auf Port 443.

server {
    listen 443 ssl;
    server_name dsh.example.com;

    ssl_certificate     /etc/letsencrypt/live/dsh.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/dsh.example.com/privkey.pem;

    auth_basic           "dsh";
    auth_basic_user_file /etc/nginx/dsh.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:3080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

Erstellen Sie die Passwortdatei und laden Sie die Konfiguration neu:

sudo apt install -y apache2-utils
sudo htpasswd -c /etc/nginx/dsh.htpasswd you
sudo nginx -t && sudo systemctl reload nginx

nginx -t sollte syntax is ok gefolgt von test is successful ausgeben. Das Neuladen mit einer fehlerhaften Datei schlägt fehl und lässt die laufende Konfiguration unverändert. Lesen Sie daher die Fehlermeldung, statt den Dienst blind neu zu starten.

Drei dieser Proxy-Zeilen sind erforderlich. Die Header Upgrade und Connection ermöglichen den WebSocket-Handshake. Ohne sie wird die Seite geladen, aber nicht aktualisiert. proxy_read_timeout 3600s ersetzt den Standardwert von 60 Sekunden. Andernfalls wird eine lange Agent-Ausführung während der Antwort abgebrochen, und die Benutzeroberfläche wirkt eingefroren. proxy_buffering off sendet die Modellausgabe sofort an den Browser, statt sie bis zum Abschluss der Antwort zurückzuhalten. Eine nginx-Reverse-Proxy-Konfiguration Zeile für Zeile erklärt die übrigen Einstellungen. Auswahl zwischen nginx, Caddy und Traefik beschreibt, wie Sie dasselbe mit automatischen Zertifikaten umsetzen.

Halten Sie Port 3080 unabhängig von der Wahl des Proxys in der Firewall geschlossen. Der einzige Zugriffsweg soll über den authentifizierten Proxy führen. Grundlagen der ufw-Firewall erklärt die erforderlichen Regeln. Eine einfache Authentifizierung über TLS ist eine Mindestmaßnahme, aber kein vollständiges Sicherheitskonzept: Wer dieses Passwort besitzt, hat Zugriff auf eine Shell auf Ihrem Server. Verwenden Sie nach Möglichkeit den Tunnel.

Wie ändere ich den Port, auf dem der dsh-Webserver lauscht?

--port gehört zur Webanwendung, nicht zum Launcher. Die CLI-Dokumentation enthält dafür direkt das folgende Beispiel:

dsh --profile web --port 8080

dsh web ist ein Alias für --profile web. Daher ist dsh web --port 8080 derselbe Befehl. Der Launcher verarbeitet nur seine eigenen Flags und übergibt alles dahinter an das gestartete Profil. Die Flags des Launchers stehen deshalb zuerst. Das erste Token, das der Launcher nicht erkennt, leitet die Argumente der Anwendung ein. Setzen Sie --port nach dem Profil, niemals davor.

Lesen Sie die URL, die der Befehl ausgibt, statt sie anzunehmen. Diese Zeile zeigt die Adresse an, an die der Server tatsächlich gebunden wurde. Aktualisieren Sie anschließend das letzte Feld Ihres Tunnels entsprechend:

ssh -N -L 3080:127.0.0.1:8080 you@your-vps

Für eine dauerhafte Änderung wird der Port in der Profilkonfiguration statt in der Befehlszeile festgelegt. Die Profile web und headless werden bei der ersten Verwendung automatisch anhand der mitgelieferten Vorlagen initialisiert, und zwar unter ~/.dsh. In demselben Verzeichnis befinden sich auch Ihre Einstellungen für den API-Schlüssel und den Modellendpunkt. dsh-Schlüssel, Modelle und Endpunkte konfigurieren ist daher der passende ergänzende Abschnitt, wenn Sie diese Dateien ohnehin bearbeiten. Mit dem folgenden Befehl sehen Sie, welche Einstellungen nach dem Zusammenführen aller Ebenen tatsächlich gelten:

dsh --dump-config

Das Webserver-Plugin stellt genau zwei Schlüssel bereit: host und port. Wenn Sie port auf 0 setzen, fordert das Betriebssystem einen freien Port an. In der Dokumentation steht dazu: „zero requests an OS-assigned port“. Dadurch vermeiden Sie Portkonflikte. Für einen Tunnel ist diese Einstellung jedoch ungeeignet, weil sich die Portnummer bei jedem Neustart ändert.

Warum schlägt dsh mit der Meldung „address already in use“ fehl?

Ein anderer Prozess verwendet diese Adresse und diesen Port bereits. Deshalb verweigert der Kernel den zweiten Bind-Vorgang. Node meldet das so:

Error: listen EADDRINUSE: address already in use 127.0.0.1:3080

Ermitteln Sie den belegenden Prozess, bevor Sie etwas ändern:

sudo ss -ltnp | grep 3080

Das Feld users:(("node",pid=1042,fd=21)) nennt den Prozess und seine PID. In der Regel handelt es sich um eine frühere dsh-Instanz, von der Sie dachten, sie sei beendet. Häufig läuft sie noch in einem abgekoppelten tmux-Fenster. Beenden Sie diese Instanz mit kill 1042 oder starten Sie die neue Instanz auf einem anderen Port. Beachten Sie, dass 127.0.0.1:3080 und 0.0.0.0:3080 ebenfalls miteinander kollidieren. Das Binden an alle Schnittstellen schließt die Loopback-Schnittstelle bereits ein.

Version festsetzen, weil dies eine Entwicklervorschau ist

Die README formuliert es eindeutig: DeepSeek Harness befindet sich in der Entwicklervorschau und wird schnell weiterentwickelt. Dabei wird es zu inkompatiblen Änderungen kommen. Wenn dieses Tempo der Grund für Ihre Zurückhaltung ist, wie sich dsh von Claude Code und Omnigent unterscheidet vergleicht es mit zwei Harnesses an unterschiedlichen Punkten derselben Entwicklung.

npx @deepseek-ai/dsh web löst bei jeder Ausführung die neueste veröffentlichte Version auf. Ein Server, den Sie eine Woche lang nicht angefasst haben, kann beim nächsten Start eine andere CLI mit anderen Flags ausführen. Setzen Sie die Version fest, damit ein Neustart kein Upgrade ausführt:

npx @deepseek-ai/dsh@0.1.0-rc.7 web

Im August 2026 ist das veröffentlichte Paket Version 0.1.0-rc.7. Prüfen Sie, was ein unverändertes npx installieren würde, bevor Sie dies bestätigen:

npm view @deepseek-ai/dsh version

Wenn sich die festgesetzte Version nicht installieren lässt oder npx nach dem Festsetzen einer neuen Version weiterhin den alten Build startet, behandelt die dabei auftretenden Installations- und Versionsfehler das Leeren des npx-Cache und die Prüfung, welches npm zu Ihrer Node-Installation gehört.

Zwischen Launcher und Webanwendung ändern sich die Flags in den Preview-Releases. Wenn --port nicht mehr wie in dieser Anleitung beschrieben funktioniert, fragen Sie die Anwendung nach ihrer eigenen Flag-Liste, statt die Flags zu erraten:

dsh --profile web --help

Informationen zur eigentlichen Installation, zur Einrichtung des Workspace und zum Model-Key finden Sie unter DeepSeek Harness auf einem VPS installieren. Eine kürzere Anleitung nur für den Zugriffsschritt finden Sie unter die dsh-Web-UI auf einem VPS erreichen. Dort wird der Tunnel ohne die Begründungsschritte beschrieben.

FAQ

Warum kann ich http://127.0.0.1:3080 im Browser meines Laptops nicht öffnen?

Weil 127.0.0.1 den Rechner bezeichnet, auf dem Sie den Befehl eingeben. Die DeepSeek Harness Web UI ist an die Loopback-Adresse der VPS gebunden. Daher können nur Prozesse auf der VPS eine Verbindung herstellen. Ihr Laptop hat eine eigene Loopback-Adresse. Dort lauscht kein Dienst auf Port 3080. Leiten Sie den Port mit ssh -N -L 3080:127.0.0.1:3080 you@your-vps über SSH weiter. Öffnen Sie anschließend http://127.0.0.1:3080 lokal. Das mittlere Feld des Arguments -L wird serverseitig aufgelöst. Dadurch verweist es auf den Harness.

Ist es sicher, die dsh Web UI auf einer öffentlichen VPS an 0.0.0.0 zu binden?

Nein. Die Web UI ist die Steuerschnittstelle für einen Agenten, der Shell-Befehle ausführt und Dateien als der Benutzer bearbeitet, unter dem dsh läuft. Die Developer Preview zeigt überhaupt keinen Anmeldebildschirm an. Wenn Sie den Dienst an alle Schnittstellen einer öffentlichen IP-Adresse binden, kann jeder, der Port 3080 erreicht, Befehle auf Ihrem Server ausführen. Lassen Sie die Bind-Adresse auf 127.0.0.1 gesetzt. Halten Sie Port 3080 in der Firewall geschlossen. Verwenden Sie stattdessen einen SSH-Tunnel, ein privates Overlay-Netzwerk oder einen Reverse Proxy mit Passwortschutz.

Wie lasse ich die dsh Web UI nach dem Schließen meiner SSH-Sitzung weiterlaufen?

Ein npx @deepseek-ai/dsh web im Vordergrund ist ein Kindprozess Ihrer Login-Shell. Er wird beendet, sobald diese Shell endet. Starten Sie ihn innerhalb einer tmux-Sitzung und trennen Sie die Sitzung mit Ctrl-b d. Alternativ können Sie ihn als systemd-Benutzerdienst mit aktiviertem Lingering ausführen. Der Tunnel und der Harness sind unabhängig voneinander. Sie können den SSH-Tunnel beliebig oft trennen und neu aufbauen, ohne den laufenden Harness zu beeinflussen. Voraussetzung ist, dass der Harness selbst einen übergeordneten Prozess hat, der länger als Ihre Login-Sitzung läuft.

Warum friert die dsh Web UI bei einer langen Agent-Ausführung hinter nginx nach einiger Zeit ein?

Der Standardwert von nginx für proxy_read_timeout beträgt 60 Sekunden. Daher schließt nginx eine Verbindung, über die eine Minute lang keine Daten übertragen werden. Das kann bei einem langen Agent-Schritt leicht passieren. Setzen Sie proxy_read_timeout 3600s; im Block location. Fügen Sie proxy_buffering off; hinzu, damit die Ausgabe beim Eintreffen an den Browser gestreamt wird. Übergeben Sie außerdem die Header Upgrade und Connection mit proxy_http_version 1.1;, damit der WebSocket-Handshake erfolgreich ist. Ohne diese Header wird die Seite geladen, empfängt aber keine Aktualisierungen.