DeepSeek Harness: http://127.0.0.1:3080 niet bereikbaar

Wat dsh web: http://127.0.0.1:3080 betekent

Wanneer u het DeepSeek Harness webprofiel op een VPS start, worden er twee regels getoond en wacht het proces vervolgens:

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

127.0.0.1 is het loopback-adres. Dit is het adres dat een machine gebruikt om met zichzelf te communiceren. Een socket die is gebonden aan 127.0.0.1 accepteert alleen verbindingen van processen op diezelfde machine, en nergens anders vandaan. Die regel vertelt u dus twee dingen tegelijk: waar de Web UI luistert en wie deze mag bereiken. Alleen de machine waarop dsh draait.

Dat is de reden waarom de URL niets doet wanneer u deze in de browser op uw laptop plakt. De 127.0.0.1 van uw laptop is uw laptop zelf. De harness luistert op de 127.0.0.1 van de VPS, wat een andere machine is met een eigen loopback-stack. Er is niets defect. U moet de verbinding overbruggen.

De officiële README vermeldt de standaardinstelling duidelijk: "Het commando start de Web UI, die standaard wordt geserveerd op http://127.0.0.1:3080." Het bind-adres is afkomstig van de webserver host-plugin, @deepseek-ai/dsh-host-webserver, waarvan de host-sleutel als volgt gedocumenteerd is: "Listen host; de twee ondersteunde waarden zijn loopback en all-interfaces". Loopback is wat u krijgt tenzij u dit wijzigt. Als poorten nieuw voor u zijn, behandelt hoe poorten werken op Linux het adres-plus-poort-model waar dit alles op gebaseerd is.

Waarom de Web UI alleen aan localhost bindt

dsh is een agent-harness, oftewel het programma dat om het model heen is gebouwd: het beheert de loop, de tool-aanroepen en de rechten waaronder deze aanroepen worden uitgevoerd. Het browsertabblad fungeert als bedieningspaneel voor een proces dat shell-commando's uitvoert, bestanden leest en schrijft in de door u gekozen werkmap, en uw model-API-key verbruikt. Iedereen die die pagina kan laden, kan dit alles doen als de gebruiker die dsh uitvoert. Het netwerk is bovendien niet de enige toegangsweg: een plugin die u installeert, draait in hetzelfde proces met dezelfde rechten. Daarom verdient het controleren van een dsh-plugin voordat u deze installeert dezelfde zorgvuldigheid als de beslissing waar de server op luistert.

Poort 3080 is dus geen dashboard met alleen-lezen-toegang. Het laden van die pagina geeft de mogelijkheid om commando's uit te voeren op de server.

Open de Web UI en u komt direct in de sessielijst terecht. Er is geen inlogscherm, omdat de developer preview geen gebruikersaccounts en geen externe authenticatie bevat. Op loopback is dit consistent: het besturingssysteem fungeert als toegangscontrole en alleen lokale processen krijgen toegang. Bindt u dezelfde server aan 0.0.0.0 op een VPS met een publiek IP-adres, dan reageert diezelfde pagina op het gehele internet, zonder enige beveiliging ervoor. Geautomatiseerde scanners scannen continu op ongebruikelijke poorten, dus beschouw een gepubliceerde 3080 als gevonden.

Open poort 3080 niet in uw firewall en stel de webserver host niet in op 0.0.0.0 op een publieke VPS. Die combinatie geeft iedereen die als eerste verbinding maakt de mogelijkheid om commando's op uw server uit te voeren.

Dezelfde redenering geldt voor elke agent-runtime die u op een server plaatst. Daarom begint het veilig draaien van een coding agent op een VPS met dezelfde regel: de controlepoort van de agent blijft privé en u gebruikt een vertrouwde methode om er toegang toe te krijgen.

Hoe open ik de dsh Web UI vanaf mijn laptop?

Er zijn drie betrouwbare methoden, waarbij de harness in elk scenario gebonden blijft aan loopback.

• Een SSH-tunnel. Er luistert geen nieuwe service op de publieke interface en u beschikt al over de inloggegevens. Dit is de aanbevolen methode.
• Een privaat overlay-netwerk, zodat de UI bereikbaar is vanaf uw eigen apparaten en onzichtbaar blijft voor anderen.
• Een reverse proxy die TLS (transport layer security) termineert en om een wachtwoord vraagt voordat verkeer wordt doorgestuurd.

Het verschil tussen deze methoden is de wijze waarop uw browser verbinding maakt met loopback. In geen enkel geval hoeft de harness van loopback te worden gehaald.

Bereik het via een SSH-tunnel

Voer dit uit op uw laptop, niet op de VPS:

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

Laat dit draaien en open vervolgens http://127.0.0.1:3080 in uw lokale browser. De Web UI wordt geladen.

Het -L-argument bevat drie velden gescheiden door dubbele punten. Het eerste is de poort die op uw laptop wordt geopend. Het tweede en derde veld zijn het adres en de poort waarheen elke verbinding moet worden doorgestuurd. Het detail dat ertoe doet: 127.0.0.1 in het middelste veld wordt opgelost door de SSH-server op de VPS, nadat uw verkeer daar al is aangekomen. Het betekent de loopback van de VPS, niet die van u. Dat is precies het adres dat dsh toonde, en daarom werkt de tunnel wanneer een directe browserverbinding dat niet doet.

-N vertelt SSH om geen extern commando uit te voeren, zodat u een forwarder krijgt zonder shell. Voor een achtergrondtunnel die luidruchtig faalt in plaats van stilzwijgend:

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

-f plaatst het proces op de achtergrond na authenticatie. ExitOnForwardFailure=yes is belangrijker dan het lijkt: zonder dit argument verbindt SSH succesvol, zelfs als de forward niet kon worden opgezet. U krijgt dan een werkende sessie en een dode tunnel zonder waarschuwing. ServerAliveInterval=30 stuurt elke 30 seconden een keepalive, zodat een inactieve tunnel NAT-timeouts (network address translation) op café- en hotelrouters overleeft.

Wat u zou moeten zien

Controleer op de VPS wat er daadwerkelijk luistert:

ss -ltnp | grep 3080

Een gezond resultaat toont het loopback-adres:

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

Als de kolom voor het lokale adres 0.0.0.0:3080 toont, staat de Web UI op elke interface, inclusief de publieke. Stop het proces en corrigeer de bind voordat u iets anders doet. Als ss de socket toont maar het users:-veld leeg laat, voer het dan uit met sudo, omdat de procesnaam voor een socket die eigendom is van een andere gebruiker anders verborgen blijft.

Wanneer de tunnel weigert te starten

SSH toont dit en sluit af:

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

Dit heeft betrekking op uw laptop, niet op de server. Iets lokaals bezet al poort 3080, vaak een eerdere tunnel die u bent vergeten. Kies in plaats daarvan een vrije lokale poort:

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

Alleen het eerste veld is gewijzigd, dus u surft nu naar http://127.0.0.1:3081 terwijl de harness blijft luisteren op 3080. De twee getallen hoeven nooit overeen te komen.

Als de tunnel tot stand komt maar de browser een geweigerde verbinding of een leeg antwoord rapporteert, is het verkeer naar de VPS gegaan en vond daar niets. Ofwel dsh is afgesloten, of het proces is gebonden aan een andere poort. Controleer dit met ss -ltnp | grep 3080 op de server.

Nog één ding waar mensen hier tegenaan lopen. Een npx @deepseek-ai/dsh web op de voorgrond sterft wanneer de shell sluit, dus de harness stopt zodra u uitlogt. Start het binnen tmux of als een systemd user service; dit is hetzelfde probleem als opgelost in een coding agent draaiende houden op een VPS. Terwijl u aan de SSH-kant werkt, is SSH beveiligen op uw VPS de moeite waard om als eerste te doen, omdat de tunnel uw SSH-login de enige toegangspoort tot de agent maakt.

Bereik het via een privaat overlay-netwerk

Een overlay-netwerk voorziet uw VPS en uw laptop van adressen op een privaat netwerk waar alleen uw apparaten lid van zijn. Tailscale is de gangbare keuze, en het serve-commando sluit precies aan bij deze situatie: tailscaled draait op de VPS en verbindt met localhost:3080 zelf, waardoor de harness op loopback blijft en u niets hoeft te wijzigen aan de configuratie van dsh.

tailscale serve --bg localhost:3080
tailscale serve status

De UI is vervolgens bereikbaar via de naam van uw machine binnen uw tailnet, via HTTPS, zonder dat er een poort openstaat op de publieke interface. Hiervoor moeten HTTPS-certificaten zijn ingeschakeld voor uw tailnet, anders heeft serve geen certificaat om te presenteren. Om het weer uit te schakelen, herhaalt u het commando met off:

tailscale serve --https=443 off

Gebruik serve, nooit funnel. Funnel publiceert hetzelfde doel naar het publieke internet, waardoor u weer terug bent bij een niet-geauthenticeerde agent-runtime op een open poort. De twee commando's lijken bijna identiek en doen tegenovergestelde dingen, dus lees het verschil tussen Tailscale Serve en Funnel voordat u een van beide typt. Tailscale als privaat netwerk behandelt de installatie zelf.

Bereik het via een reverse proxy die een wachtwoord controleert

Dit is de optie die daadwerkelijk een poort openstelt voor het internet. De authenticatie is hierbij de enige barrière tussen een buitenstaander en het uitvoeren van commando's op uw server. Kies hiervoor wanneer meerdere personen de UI nodig hebben en een individuele tunnel voor iedereen onpraktisch is.

De harness draait op 127.0.0.1:3080. nginx draait op dezelfde machine, waardoor deze localhost kan bereiken. De proxy luistert op poort 443 met een certificaat en een wachtwoordbestand.

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;
    }
}

Maak het wachtwoordbestand aan en herlaad de configuratie:

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

nginx -t hoort syntax is ok te tonen, gevolgd door test is successful. Een herlaadactie met een defect bestand mislukt en behoudt de huidige configuratie; lees daarom de foutmelding in plaats van blindelings te herstarten.

Drie van deze proxylijnen zijn geen opvulling. De headers Upgrade en Connection laten de WebSocket-handshake door; zonder deze headers laadt de pagina wel, maar vindt er geen update plaats. proxy_read_timeout 3600s vervangt de standaardwaarde van 60 seconden, die anders een langdurige agent-run halverwege afbreekt, waardoor de UI bevroren lijkt. proxy_buffering off stuurt modeloutput naar de browser zodra deze binnenkomt, in plaats van te wachten tot de volledige respons is voltooid. Een nginx reverse proxy configuratie, regel voor regel legt de rest uit, en kiezen tussen nginx, Caddy en Traefik behandelt hoe u hetzelfde bereikt met automatische certificaten.

Houd 3080 gesloten in de firewall, ongeacht welke proxy u kiest, zodat de enige toegangsweg via de geauthenticeerde proxy verloopt. Basisbeginselen van ufw firewall behandelt de regels. Basisauthenticatie over TLS is een ondergrens, geen volledig beveiligingsmodel: wie het wachtwoord heeft, heeft toegang tot een shell op uw server. Geef de voorkeur aan de tunnel waar mogelijk.

Hoe wijzig ik de poort waarop dsh web luistert?

--port hoort bij de webapplicatie, niet bij de launcher. De CLI-documentatie geeft het voorbeeld direct:

dsh --profile web --port 8080

dsh web is een alias van --profile web, dus dsh web --port 8080 is hetzelfde commando. De launcher verwerkt alleen zijn eigen vlaggen en geeft alles wat daarna komt door aan het opgestarte profiel. Launcher-vlaggen staan daarom vooraan, en het eerste token dat de launcher niet herkent, start de argumenten van de applicatie. Plaats --port na het profiel, nooit ervoor.

Lees de URL die het commando afdrukt in plaats van er zomaar vanuit te gaan, omdat die regel het adres rapporteert waaraan de server daadwerkelijk is gebonden. Werk daarna het laatste veld van uw tunnel bij om overeen te komen:

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

Voor een permanente wijziging bevindt de poort zich in de profielconfiguratie in plaats van op de opdrachtregel. De web en headless profielen initialiseren automatisch bij het eerste gebruik vanuit meegeleverde sjablonen, onder ~/.dsh. In diezelfde map staan ook uw API-sleutel en model-endpointinstellingen, dus dsh-sleutels, modellen en endpoints configureren is de bijbehorende leestip zodra u deze bestanden toch aan het bewerken bent. Om te zien wat er daadwerkelijk van kracht is nadat alle lagen zijn samengevoegd:

dsh --dump-config

De webserver-plugin stelt precies twee sleutels bloot, host en port. Door port in te stellen op 0 vraagt u het besturingssysteem om een vrije poort, gedocumenteerd als "nul verzoekt om een door het OS toegewezen poort". Dat garandeert dat u nooit een conflict krijgt, en het is ongeschikt voor een tunnel, omdat het nummer bij elke herstart verandert.

Waarom faalt dsh met de melding address already in use?

Dit gebeurt omdat een ander proces dat adres en die poort al bezet houdt, waardoor de kernel de tweede bind-opdracht weigert. Node rapporteert dit als volgt:

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

Zoek de eigenaar van de poort op voordat u wijzigingen aanbrengt:

sudo ss -ltnp | grep 3080

Het veld users:(("node",pid=1042,fd=21)) toont de naam van het proces en het bijbehorende PID. De meest voorkomende oorzaak is een eerdere dsh waarvan u dacht dat deze was gestopt, maar die vaak nog actief is in een losgekoppeld tmux-venster. Stop dat proces met kill 1042, of start de nieuwe instantie op een andere poort. Let op: 127.0.0.1:3080 en 0.0.0.0:3080 conflicteren ook met elkaar, omdat het binden aan alle interfaces automatisch ook de loopback-interface omvat.

Zet de versie vast, aangezien dit een developer preview is

De README is hier duidelijk over: DeepSeek Harness bevindt zich in een developer preview en ondergaat snelle iteraties, waarbij wijzigingen die compatibiliteit verbreken onvermijdelijk zijn. Als dat tempo de reden is voor uw twijfel, vergelijkt hoe dsh zich verhoudt tot Claude Code en Omnigent dit met twee andere harnesses die zich in verschillende stadia van hetzelfde traject bevinden.

npx @deepseek-ai/dsh web haalt bij elke uitvoering telkens de nieuwst gepubliceerde versie op. Een server die u een week niet heeft aangeraakt, kan bij de volgende start een andere CLI laden, met andere flags. Zet de versie vast zodat een herstart geen upgrade is:

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

Per augustus 2026 is het gepubliceerde pakket versie 0.1.0-rc.7. Controleer wat een kale npx zou ophalen voordat u dit accepteert:

npm view @deepseek-ai/dsh version

Als het vastzetten van de versie niet lukt, of als npx de oude build blijft opstarten nadat u een nieuwe heeft vastgezet, behandelt de installatie- en versie-fouten die dit veroorzaakt het legen van de npx-cache en het controleren welke npm uw Node-bundels gebruikt.

Flags verplaatsen zich tussen de launcher en de webapplicatie in verschillende preview-releases. Als --port zich niet meer gedraagt zoals in deze handleiding beschreven, vraag de applicatie dan om de eigen lijst met flags in plaats van te gokken:

dsh --profile web --help

Voor de installatie zelf, de inrichting van de workspace en de model-key, zie DeepSeek Harness installeren op een VPS. Voor een kortere doorloop van enkel de toegangsstap, behandelt de dsh Web UI bereiken op een VPS de tunnel zonder de achterliggende logica.

FAQ

Waarom kan ik http://127.0.0.1:3080 niet openen in de browser op mijn laptop?

Omdat 127.0.0.1 verwijst naar de machine waarop u typt. De DeepSeek Harness Web UI is gebonden aan het loopback-adres van de VPS, waardoor alleen processen op de VPS verbinding kunnen maken. Uw laptop heeft een eigen, afzonderlijk loopback-adres en daar luistert niets op poort 3080. Stuur de poort door via SSH met ssh -N -L 3080:127.0.0.1:3080 you@your-vps en open vervolgens http://127.0.0.1:3080 lokaal. Het middelste veld van het -L-argument wordt aan de serverzijde opgelost, waardoor het naar de harness verwijst.

Is het veilig om de dsh Web UI aan 0.0.0.0 te binden op een publieke VPS?

Nee. De Web UI is het bedieningspaneel voor een agent die shell-commando's uitvoert en bestanden bewerkt als de gebruiker die dsh draait, en de developer preview bevat geen inlogscherm. Binden aan alle interfaces op een publiek IP-adres betekent dat iedereen die poort 3080 bereikt, commando's op uw server kan uitvoeren. Houd de binding op 127.0.0.1, houd 3080 gesloten in de firewall en gebruik een SSH-tunnel, een privaat overlay-netwerk of een reverse proxy die om een wachtwoord vraagt.

Hoe houd ik de dsh Web UI draaiende nadat ik mijn SSH-sessie heb gesloten?

Een npx @deepseek-ai/dsh web op de voorgrond is een kindproces van uw inlog-shell en wordt beëindigd wanneer die shell sluit. Start het proces binnen een tmux-sessie en koppel los met Ctrl-b d, of draai het als een systemd user service met 'lingering' ingeschakeld. De tunnel en de harness zijn onafhankelijk: u kunt de SSH-tunnel zo vaak verbreken en opnieuw opbouwen als u wilt zonder de actieve harness te beïnvloeden, zolang de harness zelf een ouderproces heeft dat uw inlogsessie overleeft.

Waarom bevriest de dsh Web UI tijdens een lange agent-taak achter nginx?

Omdat de standaard proxy_read_timeout van nginx 60 seconden is; de verbinding wordt gesloten als er een minuut lang geen data wordt verstuurd, wat bij een lange agent-stap snel gebeurt. Stel proxy_read_timeout 3600s; in binnen het location-blok. Voeg proxy_buffering off; toe zodat de output naar de browser wordt gestreamd zodra deze beschikbaar is, en geef de headers Upgrade en Connection door met proxy_http_version 1.1; zodat de WebSocket-handshake slaagt. Zonder deze headers laadt de pagina wel, maar ontvangt deze nooit updates.