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 o dwóch kwestiach: gdzie nasłuchuje interfejs WWW 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 komputerze lokalnym. Adres 127.0.0.1 komputera lokalnego odnosi się do tego właśnie urządzenia. Harness nasłuchuje na adresie 127.0.0.1 serwera VPS, czyli innej maszyny z odrębnym stosem pętli zwrotnej. System jest sprawny. Należy przekierować połączenie.

Oficjalny plik README jasno określa ustawienie domyślne: „Polecenie uruchamia interfejs WWW, 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 stosowana, dopóki nie zostanie zmieniona. Jeśli zagadnienie portów jest nowe, artykuł jak działają porty w systemie Linux wyjaśnia model adres-plus-port, na którym opiera się to rozwiązanie.

Dlaczego interfejs Web UI jest powiązany tylko z localhost

dsh to środowisko uruchomieniowe agenta, czyli program otaczający model: zarządza on pętlą, wywołaniami narzędzi oraz uprawnieniami, z jakimi te wywołania są wykonywane. Karta przeglądarki stanowi panel sterowania dla procesu, który wykonuje polecenia powłoki, odczytuje i zapisuje pliki w wybranym katalogu roboczym oraz wykorzystuje klucz API modelu. Każdy, kto może załadować tę stronę, uzyskuje te same możliwości co użytkownik uruchamiający dsh. Sieć nie jest jedyną drogą dostępu: zainstalowana wtyczka działa w tym samym procesie z tymi samymi uprawnieniami, dlatego weryfikacja wtyczki dsh przed instalacją wymaga takiej samej uwagi, jak decyzja o tym, na jakim interfejsie nasłuchuje serwer.

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

Po otwarciu Web UI użytkownik trafia bezpośrednio na listę sesji. Brak jest ekranu logowania, ponieważ wersja deweloperska nie zawiera obsługi kont użytkowników ani zdalnego uwierzytelniania. W przypadku interfejsu loopback jest to spójne: system operacyjny pełni rolę kontroli dostępu i tylko lokalne procesy mają możliwość połączenia. Powiązanie tego samego serwera z 0.0.0.0 na serwerze VPS z publicznym adresem IP sprawia, że strona staje się dostępna dla całego Internetu bez żadnych zabezpieczeń. Zautomatyzowane skanery nieustannie przeszukują niestandardowe porty, więc należy założyć, że wystawiony port 3080 zostanie wykryty.

Nie należy otwierać portu 3080 w zaporze sieciowej ani ustawiać 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 bezpieczne uruchamianie agenta programistycznego na VPS opiera się na tej samej zasadzie: port sterujący agenta pozostaje prywatny, a dostęp do niego jest realizowany za pośrednictwem zaufanego komponentu.

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 proces nie nasłuchuje na publicznym interfejsie, a wymagane poświadczenia już istnieją. 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 nimi polega na sposobie przekierowania ruchu z przeglądarki do interfejsu loopback. Żadna z tych metod nie powinna wymagać zmiany konfiguracji nasłuchiwania usługi poza interfejs loopback.

Dostęp przez tunel SSH

Uruchom to na swoim laptopie, 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 adres pętli zwrotnej (loopback) VPS-a, a nie Twojego komputera. Jest to dokładnie ten adres, który wyświetla dsh, dlatego tunel działa, podczas gdy bezpośrednie połączenie z przeglądarki nie.

-N instruuje SSH, aby nie uruchamiało zdalnego polecenia, dzięki czemu otrzymujesz tylko przekierowanie bez powłoki. Aby uruchomić tunel w tle, który w razie błędu zakończy działanie z komunikatem:

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 (keepalive) co 30 sekund, dzięki czemu bezczynny tunel przetrwa limity czasu NAT (network address translation) na routerach w kawiarniach czy hotelach.

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 kolumna adresu lokalnego zawiera 0.0.0.0:3080, interfejs WWW jest dostępny na wszystkich interfejsach, w tym publicznym. Zatrzymaj usługę i popraw konfigurację powiązania (bind) przed wykonaniem jakichkolwiek innych działań. Jeśli ss wyświetla gniazdo, ale pozostawia pole users: puste, uruchom polecenie z sudo, ponieważ nazwa procesu dla gniazda należącego do innego użytkownika jest w przeciwnym razie 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, 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 porcie 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 usługa zatrzymuje się w momencie wylogowania. Uruchom go wewnątrz tmux lub jako usługę systemd użytkownika, co jest tym samym problemem rozwiązanym w utrzymywaniu agenta programistycznego na VPS. Podczas pracy nad SSH warto najpierw wykonać zabezpieczenie 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 VPS i łączy z localhost:3080, dzięki czemu mechanizm działa na interfejsie loopback i nie wymaga zmiany konfiguracji dsh.

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 sieci tailnet, w przeciwnym razie serve nie będzie mieć certyfikatu do przedstawienia. Aby wyłączyć dostęp, należy powtórzyć polecenie z flagą off:

tailscale serve --https=443 off

Należy używać serve, nigdy funnel. Funkcja Funnel publikuje ten sam cel w publicznym Internecie, co przywraca stan nieuwierzytelnionego agenta na otwartym porcie. Oba polecenia wyglądają niemal identycznie, a działają odwrotnie, dlatego przed użyciem któregokolwiek z nich zapoznaj się z różnicą 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 możliwością wykonania 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, więc ma dostęp do interfejsu loopback i nasłuchuje na porcie 443, korzystając z certyfikatu oraz pliku z hasłami.

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 z hasłem 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 błędnym plikiem kończy się niepowodzeniem i pozostawia działającą konfigurację bez zmian, dlatego należy odczytać komunikat o błędzie 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 załaduje się, ale nie będzie aktualizować danych. proxy_read_timeout 3600s zastępuje domyślny limit 60 sekund, który w przeciwnym razie przerywałby 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 całej odpowiedzi. Konfiguracja nginx jako reverse proxy, linia po linii wyjaśnia pozostałe elementy, a wybór między nginx, Caddy i Traefik opisuje realizację tego samego zadania z automatycznymi certyfikatami.

Niezależnie od wybranego proxy, port 3080 musi pozostać zamknięty na firewallu, aby jedyna droga dostępu prowadziła przez uwierzytelniony punkt wejścia. Podstawy firewalla ufw opisują odpowiednie reguły. Uwierzytelnianie typu 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 uruchamianego profilu. Flagi launchera muszą zatem znajdować się na początku, a pierwszy token, którego launcher nie rozpoznaje, rozpoczyna argumenty aplikacji. Flagę --port należy umieścić po profilu, nigdy przed nim.

Należy odczytać adres URL wyświetlany przez polecenie, zamiast zakładać jego wartość, ponieważ ten wiersz informuje o adresie, do którego serwer faktycznie się przypisał. Następnie należy zaktualizować ostatnie pole tunelu, aby było zgodne z tym adresem:

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 są automatycznie inicjowane przy pierwszym użyciu na podstawie dostarczonych szablonów w lokalizacji ~/.dsh. W tym samym katalogu znajdują się klucze API oraz ustawienia endpointów modeli, dlatego konfiguracja kluczy, modeli i endpointów dsh jest lekturą uzupełniającą, przydatną podczas edycji tych plików. Aby sprawdzić, jakie ustawienia obowiązują po połączeniu wszystkich warstw konfiguracji:

dsh --dump-config

Wtyczka serwera WWW udostępnia dokładnie dwa klucze: host oraz port. Ustawienie port na 0 powoduje żądanie wolnego portu od systemu operacyjnego, co w dokumentacji opisano jako „zero żąda portu przydzielonego przez system”. Gwarantuje to brak konfliktów, jednak jest to rozwiązanie nieodpowiednie dla tunelu, ponieważ numer portu 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 w rzeczywistości 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 zwrotny (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 szybko ewoluuje, co oznacza, że wystąpią zmiany powodujące brak kompatybilności wstecznej. Jeśli to tempo jest powodem wahania, porównanie dsh z Claude Code i Omnigent zestawia to narzędzie z dwoma innymi rozwiązaniami znajdującymi się na różnych etapach rozwoju.

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 starcie uruchomić inny CLI z innymi flagami. Przypnij wersję, aby restart nie oznaczał aktualizacji:

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

W sierpniu 2026 roku opublikowaną wersją pakietu jest 0.1.0-rc.7. Sprawdź, co pobrałoby polecenie npx bez wskazania wersji, zanim je zaakceptujesz:

npm view @deepseek-ai/dsh version

Jeśli przypięcie wersji kończy się błędem instalacji lub npx nadal uruchamia starą kompilację po przypięciu nowej, błędy instalacji i wersji wyjaśniają, jak wyczyścić pamięć podręczną npx oraz sprawdzić, którego npm używają pakiety Node.

W wersjach poglądowych flagi są przenoszone między programem uruchamiającym a aplikacją internetową. Jeśli --port przestanie działać zgodnie z opisem w tym przewodniku, zamiast zgadywać, wyświetl listę flag obsługiwanych przez samą aplikację:

dsh --profile web --help

Informacje dotyczące 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, dostęp do interfejsu WWW dsh na VPS, opisuje tunelowanie bez szczegółowego 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 aktualnie pracujesz. Interfejs Web UI DeepSeek Harness jest powiązany z adresem loopback serwera VPS, więc tylko procesy uruchomione 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 przez SSH za pomocą 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 Web UI dsh z adresem 0.0.0.0 na publicznym serwerze VPS?

Nie. Web UI stanowi panel sterowania dla agenta, który wykonuje polecenia powłoki i edytuje pliki z uprawnieniami użytkownika uruchamiającego dsh, a wersja deweloperska nie posiada ekranu logowania. Powiązanie z wszystkimi interfejsami na publicznym adresie IP oznacza, że każda osoba, która uzyska dostęp do portu 3080, może wykonywać polecenia na 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.

Jak utrzymać działanie Web UI dsh po zamknięciu sesji SSH?

Proces npx @deepseek-ai/dsh web uruchomiony na pierwszym planie jest procesem potomnym 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 skonfiguruj go jako usługę systemd użytkownika 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 proces harnessa posiada proces nadrzędny, który działa dłużej niż sesja logowania.

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

Ponieważ domyślny limit proxy_read_timeout w nginx wynosi 60 sekund, co powoduje zamknięcie połączenia, jeśli przez minutę nie są przesyłane żadne dane, co często zdarza się podczas długich operacji 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.