dsh web: por que aparece http://127.0.0.1:3080

O que dsh web: http://127.0.0.1:3080 significa

Quando inicia o perfil Web do DeepSeek Harness numa VPS, são apresentadas duas linhas e, em seguida, o processo fica à espera:

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

127.0.0.1 é o endereço de loopback. É o endereço que uma máquina utiliza para comunicar consigo própria. Um socket associado a 127.0.0.1 aceita ligações de processos nessa mesma máquina, e de nenhum outro local. Portanto, essa linha informa duas coisas ao mesmo tempo: onde a Web UI está à escuta e quem pode aceder-lhe. Apenas a máquina onde dsh está a ser executado.

É por isso que o URL não produz qualquer efeito quando o cola no navegador do seu portátil. O 127.0.0.1 do seu portátil é o próprio portátil. O harness está à escuta no 127.0.0.1 da VPS, que é outra máquina com uma pilha de loopback diferente. Não há nada avariado. É necessário transportar a ligação entre as duas máquinas.

O README oficial indica claramente o comportamento predefinido: "O comando inicia a Web UI, servida por predefinição em http://127.0.0.1:3080." O endereço de associação vem do plugin de host do servidor Web, @deepseek-ai/dsh-host-webserver, cuja chave host está documentada como "Host de escuta; os dois valores suportados são loopback e todas as interfaces". O valor loopback é utilizado por predefinição, a menos que o altere. Se as portas forem uma novidade para si, como funcionam as portas no Linux explica o modelo de endereço e porta em que tudo isto se baseia.

Por que a interface Web fica ligada apenas a localhost

dsh é um harness de agente. A aba do navegador é uma superfície de controlo de um processo que executa comandos shell, lê e grava ficheiros no diretório de trabalho escolhido e consome a chave da API do seu modelo. Qualquer pessoa que consiga carregar essa página pode fazer tudo isso com a conta que executa dsh.

Por isso, a porta 3080 não é um painel apenas de leitura. Carregar essa página permite executar comandos no servidor.

Abra a interface Web e verá diretamente a lista de sessões. Não existe um pedido de início de sessão, porque a versão de pré-visualização para programadores não fornece contas de utilizador nem autenticação remota. Em loopback, isto é coerente: o sistema operativo funciona como controlo de acesso, e apenas os processos locais conseguem ligar-se. Ligue o mesmo servidor a 0.0.0.0 num VPS com um IP público e essa mesma página responderá a toda a Internet, sem qualquer camada à frente. Os scanners automatizados varrem continuamente portas incomuns. Por isso, trate uma porta 3080 publicada como uma porta que será encontrada.

Não abra a porta 3080 na firewall e não configure o host do servidor Web para 0.0.0.0 num VPS público. Essa combinação dá execução de comandos no seu servidor à primeira pessoa que se ligar.

O mesmo raciocínio aplica-se a qualquer runtime de agente que coloque num servidor. Por isso, executar um agente de programação com segurança num VPS começa pela mesma regra: a porta de controlo do agente permanece privada, e algo em que confia fornece o acesso até ela.

Como abrir a interface Web do dsh a partir do meu portátil?

Existem três formas corretas, e todas mantêm o harness ligado ao loopback.

• Um túnel SSH. Nada novo fica à escuta na interface pública, e já tem as credenciais. É esta a opção recomendada.
• Uma rede overlay privada, para que a interface seja acessível a partir dos seus próprios dispositivos e fique invisível para todos os outros.
• Um reverse proxy que termina o TLS (transport layer security) e exige uma palavra-passe antes de encaminhar qualquer pedido.

A diferença entre estas opções está no mecanismo que transporta o browser até ao loopback. Nenhuma deve envolver mover o harness para fora do loopback.

Aceda com um túnel SSH

Execute isto no seu laptop, não no VPS:

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

Deixe-o em execução e abra http://127.0.0.1:3080 no navegador local. A Web UI será carregada.

O argumento -L contém três campos separados por dois-pontos. O primeiro é a porta a abrir no seu laptop. O segundo e o terceiro são o endereço e a porta para os quais cada ligação será encaminhada. O detalhe importante é que 127.0.0.1 no campo intermédio é resolvido pelo servidor SSH no VPS, depois de o seu tráfego já ter chegado lá. Refere-se ao loopback do VPS, não ao seu. É precisamente o endereço apresentado por dsh, razão pela qual o túnel funciona quando uma ligação direta pelo navegador não funciona.

-N indica ao SSH que não deve executar um comando remoto, para obter apenas um encaminhador e não uma shell. Para um túnel em segundo plano que falhe de forma explícita:

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

-f coloca-o em segundo plano depois da autenticação. ExitOnForwardFailure=yes é mais importante do que parece: sem esta opção, o SSH liga-se com sucesso mesmo quando não consegue configurar o encaminhamento. Assim, obtém uma sessão funcional e um túnel inativo, sem aviso. ServerAliveInterval=30 envia um keepalive a cada 30 segundos, para que um túnel inativo sobreviva aos timeouts de NAT (network address translation) dos routers de cafés e hotéis.

O que deve ver

No VPS, confirme o que está efetivamente em escuta:

ss -ltnp | grep 3080

Um resultado correto apresenta o endereço de loopback:

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

Se a coluna de endereço local apresentar 0.0.0.0:3080, a Web UI está em todas as interfaces, incluindo a pública. Pare-a e corrija o bind antes de fazer qualquer outra coisa. Se ss apresentar o socket mas deixar o campo users: vazio, execute-o com sudo, porque, caso contrário, o nome do processo de um socket pertencente a outro utilizador fica oculto.

Quando o túnel se recusa a iniciar

O SSH apresenta isto e termina:

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

Isto diz respeito ao seu laptop, não ao servidor. Algo local já está a usar a porta 3080, muitas vezes um túnel anterior que se esqueceu de terminar. Escolha outra porta local livre:

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

Apenas o primeiro campo mudou. Agora, aceda a http://127.0.0.1:3081 no navegador, enquanto o harness continua a escutar na porta 3080. Os dois números não precisam de ser iguais.

Se o túnel iniciar, mas o navegador indicar uma ligação recusada ou uma resposta vazia, o tráfego chegou ao VPS e não encontrou nada no destino. Ou dsh terminou, ou foi associado a uma porta diferente. Verifique com ss -ltnp | grep 3080 no servidor.

Há mais um problema frequente neste caso. Um npx @deepseek-ai/dsh web em primeiro plano termina quando a shell é fechada, pelo que o harness para assim que termina a sessão. Inicie-o dentro de tmux ou através de um serviço de utilizador do systemd. É o mesmo problema resolvido em manter um agente de programação em execução num VPS. Enquanto trabalha no lado do SSH, vale a pena reforçar a segurança do SSH no seu VPS primeiro, porque o túnel faz do seu login SSH a única porta de entrada para o agente.

Aceda através de uma rede overlay privada

Uma rede overlay atribui ao seu VPS e ao seu portátil endereços numa rede privada à qual apenas os seus dispositivos aderem. Tailscale é a opção habitual, e o comando serve é adequado exatamente para este caso: tailscaled é executado no VPS e liga-se ao próprio localhost:3080, mantendo o harness em loopback e sem alterar a configuração de dsh.

tailscale serve --bg localhost:3080
tailscale serve status

A interface fica então acessível através do nome da sua máquina na tailnet, por HTTPS, sem nenhuma porta aberta na interface pública. Para isso, é necessário ativar certificados HTTPS para a tailnet; caso contrário, serve não terá nenhum certificado para apresentar. Para desativá-lo, repita o comando com off:

tailscale serve --https=443 off

Use serve, nunca funnel. Funnel publica o mesmo destino na Internet pública, fazendo com que volte a ter um runtime de agente sem autenticação numa porta aberta. Os dois comandos são quase idênticos, mas têm efeitos opostos. Leia a diferença entre Tailscale Serve e Funnel antes de executar qualquer um deles. Tailscale como rede privada explica a configuração.

Aceda através de um reverse proxy que valida uma palavra-passe

Esta é a opção que efetivamente publica uma porta na Internet. A autenticação é, portanto, a única barreira entre um desconhecido e a execução de comandos no seu servidor. Escolha-a quando várias pessoas precisarem da interface e não for prático usar um túnel para cada uma.

O harness continua em 127.0.0.1:3080. O nginx é executado no mesmo host, por isso consegue aceder ao loopback, e escuta na porta 443 com um certificado e um ficheiro de palavras-passe.

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

Crie o ficheiro de palavras-passe e recarregue a configuração:

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

nginx -t deve apresentar syntax is ok seguido de test is successful. Um reload com um ficheiro inválido falha e mantém a configuração em execução. Leia o erro em vez de reiniciar sem verificar.

Três dessas diretivas do proxy são necessárias. Os cabeçalhos Upgrade e Connection permitem o handshake do WebSocket. Sem eles, a página é carregada, mas nunca é atualizada. proxy_read_timeout 3600s substitui o valor predefinido de 60 segundos. Caso contrário, uma execução longa do agente é interrompida a meio da resposta e a interface parece bloqueada. proxy_buffering off envia a saída do modelo para o navegador à medida que é recebida, em vez de a manter retida até a resposta terminar. Uma configuração de reverse proxy nginx, linha a linha explica o restante, e como escolher entre nginx, Caddy e Traefik descreve como fazer o mesmo com certificados automáticos.

Mantenha a porta 3080 fechada na firewall, independentemente do proxy escolhido, para que o único caminho de entrada passe pelo proxy autenticado. Conceitos básicos da firewall ufw explica as regras. A autenticação básica através de TLS é um nível mínimo de proteção, não um modelo de segurança completo: quem tiver essa palavra-passe terá acesso a uma shell no seu servidor. Prefira o túnel quando possível.

Como altero a porta em que o dsh web escuta?

--port pertence à aplicação web, não ao launcher. A documentação da CLI apresenta diretamente este exemplo:

dsh --profile web --port 8080

dsh web é um alias de --profile web, portanto dsh web --port 8080 é o mesmo comando. O launcher analisa apenas os seus próprios flags e encaminha tudo o que vem depois deles para o profile iniciado. Por isso, os flags do launcher vêm primeiro, e o primeiro token que o launcher não reconhece inicia os argumentos da aplicação. Coloque --port depois do profile, nunca antes.

Leia o URL apresentado pelo comando em vez de o presumir, porque essa linha indica o endereço ao qual o servidor ficou efetivamente associado. Depois, atualize o último campo do túnel para corresponder:

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

Para uma alteração permanente, a porta fica na configuração do profile, e não na linha de comandos. Os profiles web e headless são inicializados automaticamente na primeira utilização a partir dos templates fornecidos, em ~/.dsh. Para ver o que está efetivamente em vigor depois da combinação de todas as camadas:

dsh --dump-config

O plugin do webserver expõe exatamente duas chaves: host e port. Definir port como 0 pede ao sistema operativo uma porta livre. A documentação explica que "zero requests an OS-assigned port". Isto garante que nunca ocorre um conflito, mas é inadequado para um túnel, porque o número muda a cada reinício.

Por que o dsh falha com o endereço já em uso?

Porque outro processo já detém esse endereço e essa porta. Por isso, o kernel recusa o segundo bind. O Node apresenta o erro desta forma:

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

Identifique o processo que detém o endereço antes de alterar qualquer coisa:

sudo ss -ltnp | grep 3080

O campo users:(("node",pid=1042,fd=21)) identifica o processo e o respetivo PID. Normalmente, trata-se de uma instância anterior do dsh que julgava ter sido terminada. Muitas vezes, ela continua ativa numa janela tmux desanexada. Pare-a com kill 1042 ou inicie a nova instância noutra porta. Tenha em atenção que 127.0.0.1:3080 e 0.0.0.0:3080 também entram em conflito, porque associar-se a todas as interfaces já inclui o loopback.

Fixe a versão, porque isto é uma pré-visualização para programadores

O README é claro: o DeepSeek Harness está em pré-visualização para programadores e evolui rapidamente. Serão introduzidas alterações que podem quebrar a compatibilidade.

npx @deepseek-ai/dsh web resolve sempre para a versão publicada mais recente em cada execução. Um servidor que não é alterado há uma semana pode iniciar uma CLI diferente na execução seguinte, com flags diferentes. Fixe a versão para que um reinício não seja uma atualização:

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

Em agosto de 2026, o pacote publicado está na versão 0.1.0-rc.7. Verifique o que um npx sem versão definida instalaria antes de aceitar:

npm view @deepseek-ai/dsh version

As flags mudam entre o launcher e a aplicação Web nas versões de pré-visualização. Se --port deixar de funcionar como descrito neste guia, peça à própria aplicação a lista de flags, em vez de tentar adivinhar:

dsh --profile web --help

Para a instalação, a configuração do workspace e a chave do modelo, consulte instalar o DeepSeek Harness numa VPS. Para um guia mais curto apenas sobre a etapa de acesso, aceder à interface Web dsh numa VPS explica o túnel sem a parte do raciocínio.

FAQ

Por que não consigo abrir http://127.0.0.1:3080 no navegador do meu laptop?

Porque 127.0.0.1 representa a máquina onde está a escrever. A interface Web do DeepSeek Harness está ligada ao endereço de loopback do VPS. Por isso, apenas processos no VPS podem estabelecer ligação com ela. O seu laptop tem um loopback separado e não há nada a escutar na porta 3080 nesse equipamento. Encaminhe a porta por SSH com ssh -N -L 3080:127.0.0.1:3080 you@your-vps e, em seguida, abra http://127.0.0.1:3080 localmente. O campo intermédio do argumento -L é resolvido no servidor. É isso que faz com que a ligação aponte para o harness.

É seguro ligar a interface Web do dsh a 0.0.0.0 num VPS público?

Não. A interface Web é a superfície de controlo de um agente que executa comandos de shell e edita ficheiros com o utilizador que executa dsh. Além disso, a versão de pré-visualização para programadores não apresenta qualquer ecrã de início de sessão. Ligar a todas as interfaces num IP público significa que qualquer pessoa com acesso à porta 3080 pode executar comandos no seu servidor. Mantenha a ligação em 127.0.0.1, mantenha a porta 3080 fechada na firewall e utilize um túnel SSH, uma rede overlay privada ou um reverse proxy que exija palavra-passe.

Como mantenho a interface Web do dsh em execução depois de fechar a sessão SSH?

Um npx @deepseek-ai/dsh web em primeiro plano é um processo filho da sua shell de login. Por isso, é terminado quando essa shell sai. Inicie-o dentro de uma sessão tmux e desligue-a com Ctrl-b d. Em alternativa, execute-o como um serviço de utilizador do systemd com o lingering ativado. O túnel e o harness são independentes. Pode terminar e recriar o túnel SSH quantas vezes quiser sem afetar o harness em execução, desde que o próprio harness tenha um processo pai que sobreviva à sua sessão de login.

Por que a interface Web do dsh bloqueia a meio de uma execução longa do agente atrás do nginx?

Porque o valor predefinido de proxy_read_timeout no nginx é 60 segundos. Por isso, o nginx fecha uma ligação que não produz dados durante um minuto, algo que uma etapa longa do agente pode facilmente fazer. Defina proxy_read_timeout 3600s; no bloco location. Adicione proxy_buffering off; para que a saída seja transmitida para o navegador à medida que é produzida. Encaminhe também os cabeçalhos Upgrade e Connection com proxy_http_version 1.1; para que o handshake do WebSocket seja concluído. Sem esses cabeçalhos, a página é carregada, mas nunca recebe atualizações.