DeepSeek Harness: dlaczego 127.0.0.1:3080 nie działa?

Co oznacza dsh web: http://127.0.0.1:3080

Po uruchomieniu profilu internetowego DeepSeek Harness na serwerze VPS, wyświetlane są dwa wiersze, po czym następuje oczekiwanie:

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

127.0.0.1 to adres pętli zwrotnej (loopback). Jest to adres, którego maszyna używa do komunikacji z samą sobą. Gniazdo powiązane z 127.0.0.1 akceptuje połączenia wyłącznie z procesów działających na tej samej maszynie. Ten wiersz informuje zatem o dwóch kwestiach jednocześnie: gdzie nasłuchuje interfejs Web UI oraz kto ma uprawnienia do nawiązania z nim połączenia. Dostęp ma tylko maszyna, na której uruchomiono dsh.

Dlatego adres URL nie działa po wklejeniu go do przeglądarki na laptopie. Adres 127.0.0.1 laptopa odnosi się do samego laptopa. Narzędzie Harness nasłuchuje na adresie 127.0.0.1 serwera VPS, który jest inną maszyną z odrębnym stosem pętli zwrotnej. Nic nie jest uszkodzone. Należy przekierować połączenie.

Oficjalny plik README jasno określa ustawienie domyślne: „Polecenie uruchamia interfejs Web UI, domyślnie dostępny pod adresem http://127.0.0.1:3080”. Adres powiązania pochodzi z wtyczki hosta serwera WWW, @deepseek-ai/dsh-host-webserver, której klucz host jest udokumentowany jako „Host nasłuchujący; obsługiwane są dwie wartości: loopback oraz all-interfaces”. Wartość loopback jest ustawiona domyślnie, dopóki nie zostanie zmieniona. Jeśli zagadnienie portów jest nowe, artykuł jak działają porty w systemie Linux omawia model adres-plus-port, na którym opiera się cała ta konfiguracja.

Dlaczego interfejs Web UI jest powiązany tylko z localhost

dsh to środowisko uruchomieniowe agenta. Karta przeglądarki stanowi panel sterowania procesem, który wykonuje polecenia powłoki, odczytuje i zapisuje pliki w wybranym katalogu roboczym oraz wykorzystuje klucz API modelu. Każdy, kto załaduje tę stronę, może wykonać te operacje jako użytkownik uruchamiający dsh.

Port 3080 nie jest zatem panelem tylko do odczytu. Załadowanie tej strony umożliwia wykonywanie poleceń na serwerze.

Po otwarciu interfejsu Web UI użytkownik trafia bezpośrednio na listę sesji. Brak monitu logowania wynika z faktu, że wersja deweloperska nie zawiera kont użytkowników ani zdalnego uwierzytelniania. W przypadku interfejsu pętli zwrotnej (loopback) jest to spójne rozwiązanie: system operacyjny pełni rolę kontroli dostępu, a dostęp mają tylko procesy lokalne. Powiązanie tego samego serwera z 0.0.0.0 na VPS z publicznym adresem IP sprawia, że ta sama strona odpowiada całemu internetowi, nie będąc niczym zabezpieczoną. Zautomatyzowane skanery nieustannie przeszukują niestandardowe porty, więc należy założyć, że opublikowany port 3080 zostanie wykryty.

Nie otwieraj portu 3080 w zaporze sieciowej i nie ustawiaj serwera WWW host na 0.0.0.0 na publicznym serwerze VPS. Takie połączenie przekazuje możliwość wykonywania poleceń na serwerze każdemu, kto połączy się jako pierwszy.

To samo rozumowanie dotyczy każdego środowiska uruchomieniowego agenta zainstalowanego na serwerze. Dlatego poradnik bezpiecznego uruchamiania agenta programistycznego na VPS zaczyna się od tej samej zasady: port sterujący agenta musi pozostać prywatny, a dostęp do niego powinien być realizowany za pośrednictwem zaufanego mechanizmu.

Jak otworzyć interfejs WWW dsh z poziomu laptopa?

Istnieją trzy rzetelne metody, z których każda pozostawia usługę powiązaną z interfejsem loopback.

• Tunel SSH. Żaden nowy port nie nasłuchuje na interfejsie publicznym, a wymagane poświadczenia są już dostępne. Jest to zalecana metoda.
• Prywatna sieć nakładkowa (overlay network), dzięki której interfejs jest dostępny z własnych urządzeń i niewidoczny dla osób trzecich.
• Reverse proxy, które dokonuje terminacji TLS (transport layer security) i wymaga podania hasła przed przekazaniem jakiegokolwiek żądania.

Różnica między tymi metodami polega na sposobie przekierowania ruchu z przeglądarki do interfejsu loopback. Żadna z nich nie powinna wymagać zmiany powiązania usługi z interfejsem loopback.

Dostęp przez tunel SSH

Uruchom to na swoim laptopie, a nie na VPS:

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

Pozostaw proces uruchomiony, a następnie otwórz http://127.0.0.1:3080 w lokalnej przeglądarce. Interfejs WWW zostanie załadowany.

Argument -L zawiera trzy pola rozdzielone dwukropkami. Pierwsze to port, który ma zostać otwarty na laptopie. Drugie i trzecie to adres oraz port, na który ma zostać przekierowane każde połączenie. Kluczowy szczegół: 127.0.0.1 w środkowym polu jest rozwiązywane przez serwer SSH na VPS, już po dotarciu tam ruchu. Oznacza to pętlę zwrotną (loopback) VPS-a, a nie Twojego komputera. Jest to dokładnie ten adres, który wyświetla dsh, dlatego tunel działa, gdy bezpośrednie połączenie z przeglądarki jest niemożliwe.

-N informuje SSH, aby nie uruchamiało zdalnego polecenia, dzięki czemu otrzymujesz tylko przekierowanie bez powłoki. Aby uzyskać tunel działający w tle, który zgłasza błędy zamiast cichego niepowodzenia:

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

-f przenosi proces do tła po uwierzytelnieniu. ExitOnForwardFailure=yes jest ważniejsze, niż się wydaje: bez tego parametru SSH łączy się pomyślnie nawet wtedy, gdy przekierowanie nie mogło zostać ustanowione, co skutkuje działającą sesją przy niedziałającym tunelu bez żadnego ostrzeżenia. ServerAliveInterval=30 wysyła sygnał podtrzymujący co 30 sekund, dzięki czemu bezczynny tunel przetrwa limity czasu NAT (network address translation) w sieciach kawiarnianych lub hotelowych.

Co powinno być widoczne

Na VPS sprawdź, co faktycznie nasłuchuje:

ss -ltnp | grep 3080

Poprawny wynik wskazuje adres pętli zwrotnej:

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

Jeśli w kolumnie adresu lokalnego widnieje 0.0.0.0:3080, interfejs WWW jest dostępny na wszystkich interfejsach, w tym na publicznym. Zatrzymaj usługę i popraw powiązanie (bind), zanim podejmiesz jakiekolwiek inne kroki. Jeśli ss wyświetla gniazdo, ale pozostawia pole users: puste, uruchom polecenie z sudo, ponieważ w przeciwnym razie nazwa procesu dla gniazda należącego do innego użytkownika jest ukryta.

Gdy tunel odmawia uruchomienia

SSH wyświetla poniższy komunikat i kończy działanie:

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

Problem dotyczy laptopa, a nie serwera. Coś lokalnie zajmuje już port 3080, często jest to wcześniejszy tunel, o którym zapomniałeś. Wybierz inny wolny port lokalny:

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

Zmieniono tylko pierwsze pole, więc teraz przeglądasz stronę pod adresem http://127.0.0.1:3081, podczas gdy usługa nadal nasłuchuje na 3080. Te dwie liczby nie muszą być identyczne.

Jeśli tunel się uruchamia, ale przeglądarka zgłasza odmowę połączenia lub pustą odpowiedź, ruch dotarł do VPS, ale nie znalazł niczego po drugiej stronie. Albo dsh zakończyło działanie, albo powiązało się z innym portem. Sprawdź to za pomocą ss -ltnp | grep 3080 na serwerze.

Jest jeszcze jedna kwestia, która sprawia problemy. Działający na pierwszym planie npx @deepseek-ai/dsh web kończy pracę po zamknięciu powłoki, więc tunel wyłącza się w momencie wylogowania. Uruchom go wewnątrz tmux lub jako usługę użytkownika systemd, co jest tym samym problemem rozwiązanym w utrzymywaniu agenta programistycznego na VPS. Podczas pracy nad konfiguracją SSH warto najpierw zająć się zabezpieczeniem SSH na VPS, ponieważ tunel sprawia, że logowanie SSH staje się jedyną drogą dostępu do agenta.

Dostęp przez prywatną sieć nakładkową

Sieć nakładkowa (overlay network) nadaje serwerowi VPS oraz laptopowi adresy w prywatnej sieci, do której należą tylko Twoje urządzenia. Tailscale jest powszechnym wyborem, a polecenie serve idealnie pasuje do tego przypadku: tailscaled uruchamia się na serwerze VPS i łączy z localhost:3080, dzięki czemu mechanizm pozostaje na interfejsie loopback, a konfiguracja dsh nie wymaga żadnych zmian.

tailscale serve --bg localhost:3080
tailscale serve status

Interfejs użytkownika jest wtedy dostępny pod nazwą Twojego urządzenia wewnątrz sieci tailnet, przez HTTPS, bez otwierania portów na publicznym interfejsie. Wymaga to włączenia certyfikatów HTTPS dla Twojej sieci tailnet, w przeciwnym razie serve nie będzie mieć certyfikatu do przedstawienia. Aby wyłączyć dostęp, powtórz polecenie z flagą off:

tailscale serve --https=443 off

Używaj serve, nigdy funnel. Funkcja Funnel publikuje ten sam cel w publicznym Internecie, co przywraca stan nieuwierzytelnionego środowiska uruchomieniowego agenta na otwartym porcie. Oba polecenia wyglądają niemal identycznie, a wykonują przeciwne operacje, dlatego przed wpisaniem któregokolwiek z nich zapoznaj się z różnicami między Tailscale Serve a Funnel. Artykuł Tailscale jako sieć prywatna opisuje sam proces konfiguracji.

Dostęp przez reverse proxy z weryfikacją hasła

Jest to opcja, która faktycznie wystawia port do Internetu, więc uwierzytelnianie stanowi jedyną barierę między osobą z zewnątrz a wykonaniem poleceń na serwerze. Wybierz to rozwiązanie, gdy z interfejsu musi korzystać kilka osób, a tworzenie osobnego tunelu dla każdej z nich jest niepraktyczne.

Harness działa na 127.0.0.1:3080. nginx pracuje na tej samej maszynie, dzięki czemu może uzyskać dostęp do interfejsu loopback, nasłuchując na porcie 443 z użyciem certyfikatu oraz pliku haseł.

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

Utwórz plik haseł i przeładuj konfigurację:

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

nginx -t powinno zwrócić syntax is ok, a następnie test is successful. Przeładowanie z uszkodzonym plikiem kończy się niepowodzeniem i pozostawia działającą konfigurację bez zmian, dlatego należy odczytać błąd zamiast restartować usługę w ciemno.

Trzy z tych linii proxy nie są jedynie dekoracją. Nagłówki Upgrade oraz Connection umożliwiają poprawne nawiązanie połączenia WebSocket; bez nich strona wczytuje się, ale nie aktualizuje. proxy_read_timeout 3600s zastępuje domyślny limit 60 sekund, który w przeciwnym razie przerywa długie działanie agenta w trakcie odpowiedzi, pozostawiając interfejs w stanie zawieszenia. proxy_buffering off przesyła dane wyjściowe modelu do przeglądarki w czasie rzeczywistym, zamiast wstrzymywać je do momentu zakończenia odpowiedzi. Konfiguracja reverse proxy nginx, linia po linii wyjaśnia pozostałe elementy, a wybór między nginx, Caddy i Traefik omawia realizację tego samego zadania z automatycznymi certyfikatami.

Niezależnie od wybranego proxy, port 3080 musi pozostać zamknięty na firewallu, aby jedyną drogą dostępu był kanał uwierzytelniony. Podstawy firewalla ufw opisuje odpowiednie reguły. Uwierzytelnianie podstawowe (Basic Auth) przez TLS to absolutne minimum, a nie kompletny model bezpieczeństwa: każdy, kto posiada hasło, uzyskuje dostęp do powłoki na serwerze. Jeśli to możliwe, preferuj użycie tunelu.

Jak zmienić port, na którym nasłuchuje interfejs webowy dsh?

--port należy do aplikacji webowej, a nie do launchera. Dokumentacja CLI podaje bezpośredni przykład:

dsh --profile web --port 8080

dsh web jest aliasem --profile web, więc dsh web --port 8080 to to samo polecenie. Launcher analizuje tylko własne flagi, a wszystko, co po nich następuje, przekazuje do uruchomionego profilu. Flagi launchera muszą zatem znajdować się na początku, a pierwszy token, którego launcher nie rozpoznaje, rozpoczyna argumenty aplikacji. Umieść --port po profilu, nigdy przed nim.

Zamiast zakładać adres, odczytaj URL wyświetlony przez polecenie, ponieważ ta linia informuje o adresie, do którego serwer faktycznie się przypisał. Następnie zaktualizuj ostatnie pole tunelu, aby było zgodne:

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

W celu trwałej zmiany, port należy zdefiniować w konfiguracji profilu zamiast w wierszu poleceń. Profile web oraz headless inicjują się automatycznie przy pierwszym użyciu na podstawie dostarczonych szablonów, znajdujących się w ~/.dsh. Aby sprawdzić, co faktycznie obowiązuje po złożeniu wszystkich warstw:

dsh --dump-config

Wtyczka serwera WWW udostępnia dokładnie dwa klucze: host oraz port. Ustawienie port na 0 prosi system operacyjny o przydzielenie wolnego portu, co jest udokumentowane jako "zero żąda portu przydzielonego przez system operacyjny". Gwarantuje to brak konfliktów, jednak jest nieodpowiednie dla tunelu, ponieważ numer zmienia się przy każdym restarcie.

Dlaczego dsh kończy się błędem "address already in use"?

Ponieważ inny proces już zajmuje dany adres i port, więc jądro odmawia wykonania drugiego powiązania (bind). Węzeł zgłasza to w następujący sposób:

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

Przed wprowadzeniem jakichkolwiek zmian należy zidentyfikować proces zajmujący zasób:

sudo ss -ltnp | grep 3080

Pole users:(("node",pid=1042,fd=21)) wskazuje nazwę procesu oraz jego PID. Najczęstszą przyczyną jest wcześniejsza instancja dsh, która według założeń powinna być zatrzymana, a często nadal działa w odłączonym oknie tmux. Należy ją zatrzymać za pomocą kill 1042 lub uruchomić nową instancję na innym porcie. Należy pamiętać, że 127.0.0.1:3080 oraz 0.0.0.0:3080 również wchodzą ze sobą w konflikt, ponieważ powiązanie ze wszystkimi interfejsami automatycznie obejmuje również interfejs loopback.

Przypnij wersję, ponieważ jest to wersja poglądowa dla programistów

Plik README jasno to określa: DeepSeek Harness znajduje się w fazie poglądowej dla programistów i jest szybko rozwijany, co oznacza, że wystąpią zmiany powodujące brak kompatybilności wstecznej.

npx @deepseek-ai/dsh web przy każdym uruchomieniu pobiera najnowszą opublikowaną wersję. Serwer, którego nie dotykałeś przez tydzień, może przy kolejnym uruchomieniu wystartować z inną wersją CLI i innymi flagami. Przypnij wersję, aby restart nie oznaczał aktualizacji:

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

Według stanu na sierpień 2026 opublikowany pakiet ma wersję 0.1.0-rc.7. Sprawdź, co pobrałoby zwykłe npx, zanim to zaakceptujesz:

npm view @deepseek-ai/dsh version

W kolejnych wydaniach poglądowych flagi są przenoszone między programem uruchamiającym a aplikacją internetową. Jeśli --port przestanie działać w sposób opisany w tym przewodniku, zamiast zgadywać, poproś aplikację o wyświetlenie listy obsługiwanych flag:

dsh --profile web --help

Informacje na temat samej instalacji, konfiguracji obszaru roboczego oraz klucza modelu znajdują się w sekcji instalacja DeepSeek Harness na VPS. Krótszy przewodnik dotyczący samego etapu uzyskiwania dostępu znajduje się w uzyskiwanie dostępu do interfejsu WWW dsh na VPS, gdzie opisano tunelowanie bez wyjaśniania mechanizmów wnioskowania.

FAQ

Dlaczego nie mogę otworzyć http://127.0.0.1:3080 w przeglądarce na laptopie?

Ponieważ 127.0.0.1 oznacza maszynę, na której obecnie pracujesz. Interfejs WWW DeepSeek Harness jest powiązany z adresem loopback serwera VPS, więc tylko procesy działające na tym serwerze mogą się z nim połączyć. Twój laptop posiada własny, odrębny interfejs loopback, na którym żaden proces nie nasłuchuje na porcie 3080. Przekieruj port za pomocą SSH przy użyciu ssh -N -L 3080:127.0.0.1:3080 you@your-vps, a następnie otwórz http://127.0.0.1:3080 lokalnie. Środkowy człon argumentu -L jest rozwiązywany po stronie serwera, co sprawia, że wskazuje on na harness.

Czy bezpieczne jest powiązanie interfejsu WWW dsh z adresem 0.0.0.0 na publicznym serwerze VPS?

Nie. Interfejs WWW stanowi panel sterowania dla agenta, który wykonuje polecenia powłoki i edytuje pliki z uprawnieniami użytkownika uruchamiającego dsh, a wersja poglądowa dla programistów nie posiada żadnego ekranu logowania. Powiązanie z wszystkimi interfejsami na publicznym adresie IP oznacza, że każda osoba, która uzyska dostęp do portu 3080, zyska możliwość wykonywania poleceń na Twoim serwerze. Pozostaw powiązanie na 127.0.0.1, zablokuj port 3080 na firewallu i korzystaj z tunelu SSH, prywatnej sieci nakładkowej lub reverse proxy wymagającego uwierzytelnienia hasłem.

Jak utrzymać działanie interfejsu WWW dsh po zamknięciu sesji SSH?

Proces npx @deepseek-ai/dsh web uruchomiony na pierwszym planie jest procesem potomnym Twojej powłoki logowania, więc zostaje zakończony w momencie jej zamknięcia. Uruchom go wewnątrz sesji tmux i odłącz się za pomocą Ctrl-b d lub uruchom go jako usługę użytkownika systemd z włączonym trybem lingering. Tunel i harness są od siebie niezależne: możesz zrywać i zestawiać tunel SSH dowolną liczbę razy bez wpływu na działający harness, o ile sam harness posiada proces nadrzędny, który działa dłużej niż Twoja sesja logowania.

Dlaczego interfejs WWW dsh zawiesza się w trakcie długiego zadania agenta działającego za nginx?

Ponieważ domyślny parametr proxy_read_timeout w nginx wynosi 60 sekund, więc serwer zamyka połączenie, w którym przez minutę nie przesyłano żadnych danych, co często zdarza się podczas długich kroków pracy agenta. Ustaw proxy_read_timeout 3600s; w bloku location. Dodaj proxy_buffering off;, aby dane wyjściowe były przesyłane do przeglądarki na bieżąco, oraz przekaż nagłówki Upgrade i Connection za pomocą proxy_http_version 1.1;, aby zapewnić poprawne nawiązanie połączenia WebSocket. Bez tych nagłówków strona ładuje się, ale nie otrzymuje żadnych aktualizacji.