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 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 usa 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. Essa linha indica, portanto, duas coisas ao mesmo tempo: onde a Web UI está à escuta e quem pode aceder-lhe. Apenas a máquina em que dsh está em execução.

É por isso que o URL não faz nada quando o cola no browser do portátil. O 127.0.0.1 do 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á nenhuma avaria. É necessário transportar a ligação entre as duas máquinas.

O README oficial indica claramente o comportamento predefinido: "The command starts the Web UI, served at http://127.0.0.1:3080 by default." O endereço de associação é definido pelo plugin de host do servidor web, @deepseek-ai/dsh-host-webserver, cuja chave host está documentada como "Listen host; the two supported values are loopback and all-interfaces". O loopback é usado por predefinição, a menos que o altere. Se os conceitos de portas forem novos para si, como funcionam as portas no Linux explica o modelo de endereço e porta em que tudo isto assenta.

Por que a interface Web fica vinculada apenas a localhost

dsh é um harness de agente, ou seja, o programa que envolve o modelo: controla o loop, as chamadas de ferramentas e as permissões com que essas chamadas são executadas. A aba do navegador é uma superfície de controlo para um processo que executa comandos shell, lê e grava ficheiros no diretório de trabalho que escolheu e consome a chave da API do modelo. Qualquer pessoa que consiga carregar essa página pode fazer tudo isso como o utilizador que executa dsh. A rede também não é a única forma de alcançar esse processo: um plugin que instale é executado dentro do mesmo processo e com as mesmas permissões. Por isso, avaliar um plugin dsh antes de o instalar exige o mesmo cuidado que decidir em que endereço o servidor fica à escuta.

Por isso, a porta 3080 não é um dashboard 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 pedido de início de sessão, porque a versão de pré-visualização para programadores não inclui 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 estabelecer ligação. Vincule 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 proteção à frente. Os scanners automatizados percorrem continuamente portas pouco comuns, por isso deve considerar uma porta 3080 publicada como descoberta.

Não abra a porta 3080 na firewall e não defina host do servidor Web como 0.0.0.0 num VPS público. Essa combinação entrega a execução de comandos no seu servidor à primeira pessoa que estabelecer ligação.

O mesmo raciocínio aplica-se a todos os runtimes de agentes 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 encaminha-o até ela.

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

Existem três formas corretas, e todas mantêm o harness associado à interface loopback.

• Um túnel SSH. Nada de novo fica à escuta na interface pública, e já dispõe das credenciais. É esta a opção a utilizar.
• Uma rede overlay privada, para que a interface seja acessível a partir dos seus próprios dispositivos e permaneça 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 é o mecanismo que transporta o browser até à interface loopback. Nenhuma deve envolver a remoção do harness da interface loopback.

Aceda através de 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 onde 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 tráfego já ter chegado lá. Refere-se ao loopback do VPS, não ao seu. Esse é exatamente 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 informa o SSH para não executar um comando remoto, permitindo obter um encaminhador sem abrir uma shell. Para um túnel em segundo plano que falhe de forma explícita, em vez de falhar silenciosamente:

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 estabelece a ligação mesmo quando não consegue configurar o encaminhamento. Assim, obtém uma sessão ativa e um túnel inoperacional, 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 à 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á disponível em todas as interfaces, incluindo a interface 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 o nome do processo de um socket pertencente a outro utilizador fica oculto de outra forma.

Quando o túnel não inicia

O SSH apresenta esta mensagem e termina:

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

O problema está no seu laptop, não no servidor. Algo local já está a usar a porta 3080, normalmente um túnel anterior que ficou esquecido. Escolha outra porta local livre:

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

Apenas o primeiro campo foi alterado. Agora acede a http://127.0.0.1:3081, enquanto o harness continua à escuta na porta 3080. Os dois números não têm de coincidir.

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 na outra extremidade. Pode ser que dsh tenha terminado ou que tenha feito bind numa porta diferente. Verifique com ss -ltnp | grep 3080 no servidor.

Há mais um problema frequente. 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 na configuração 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 acesso ao agente.

Aceder através de uma rede overlay privada

Uma rede overlay atribui ao seu VPS e ao seu computador portátil endereços numa rede privada à qual apenas os seus dispositivos aderem. Tailscale é a opção mais comum, e o comando serve destina-se exatamente a este caso: tailscaled é executado no VPS e liga-se ao próprio localhost:3080, por isso o harness continua a escutar em loopback e não é necessário alterar a configuração de dsh.

tailscale serve --bg localhost:3080
tailscale serve status

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

tailscale serve --https=443 off

Use serve, nunca funnel. O Funnel publica o mesmo destino na Internet pública, devolvendo o agente a um runtime 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 própria 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, pelo que a autenticação é 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 por pessoa.

O harness continua em 127.0.0.1:3080. O nginx é executado no mesmo sistema, 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 recarregamento 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 linhas do proxy não são decorativas. Os cabeçalhos Upgrade e Connection permitem o handshake 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 chega, em vez de a manter retida até a resposta terminar. Uma configuração de reverse proxy do nginx, linha a linha explica o restante, e escolher entre nginx, Caddy e Traefik explica como fazer o mesmo com certificados automáticos.

Mantenha a porta 3080 fechada na firewall, independentemente do proxy escolhido, para que o único acesso seja através do proxy autenticado. fundamentos da firewall ufw explica as regras. A autenticação básica sobre TLS é um nível mínimo, 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 fica à escuta?

--port pertence à aplicação web, não ao launcher. A documentação da CLI apresenta diretamente o 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 passa tudo o que vem depois deles ao perfil 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 perfil, nunca antes dele.

Leia o URL apresentado pelo comando, em vez de o assumir, 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 perfil, e não na linha de comandos. Os perfis web e headless são inicializados automaticamente na primeira utilização a partir dos templates fornecidos, em ~/.dsh. Esse mesmo diretório contém as definições da API key e do model endpoint. Por isso, configurar chaves, modelos e endpoints do dsh é a leitura complementar quando já está a editar estes ficheiros. Para ver o que está efetivamente em vigor depois de todas as camadas serem combinadas:

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 descreve este comportamento como "zero requests an OS-assigned port". Isto garante que nunca ocorre um conflito, mas é uma opção inadequada para um túnel, porque o número muda em cada reinício.

Por que o dsh falha com "address already in use"?

Isso acontece porque outro processo já detém esse endereço e essa porta. Por isso, o kernel recusa o segundo bind. O Node informa 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 pensava ter parado, muitas vezes ainda em execução numa janela tmux desanexada. Pare essa instância 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 o serviço a todas as interfaces já inclui a interface de loopback.

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

O README é claro: DeepSeek Harness está em pré-visualização para programadores, evolui rapidamente e terá alterações que quebram a compatibilidade. Se esse ritmo for o motivo da sua hesitação, como o dsh se compara com Claude Code e Omnigent avalia-o em relação a dois harnesses que estão em pontos diferentes da mesma evolução.

npx @deepseek-ai/dsh web resolve sempre para a versão publicada mais recente quando é executado. Um servidor que não é atualizado há uma semana pode iniciar um 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 é a versão 0.1.0-rc.7. Verifique o que um npx sem versão fixa instalaria antes de aceitar:

npm view @deepseek-ai/dsh version

Se a versão fixa recusar a instalação, ou se npx continuar a iniciar a build antiga depois de fixar uma nova, os erros de instalação e versão apresentados explica como limpar a cache do npx e verificar qual npm acompanha o seu Node.

As flags mudam entre o launcher e a aplicação web ao longo das 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 num VPS. Para um guia mais curto apenas sobre o acesso, aceder à interface Web do dsh num 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 você está digitando. A interface Web do DeepSeek Harness está vinculada ao endereço de loopback do VPS, portanto somente processos no VPS podem se conectar a ela. O seu laptop tem um loopback separado, e não há nada escutando na porta 3080 nele. Encaminhe a porta por SSH com ssh -N -L 3080:127.0.0.1:3080 you@your-vps e carregue http://127.0.0.1:3080 localmente. O campo intermediário do argumento -L é resolvido no lado do servidor, o que faz com que ele aponte para o harness.

É seguro vincular a interface Web do dsh a 0.0.0.0 em um VPS público?

Não. A interface Web é a superfície de controle de um agente que executa comandos shell e edita arquivos como o usuário que executa dsh, e a versão de prévia para desenvolvedores não apresenta nenhuma tela de login. Vincular a todas as interfaces em um IP público significa que qualquer pessoa que alcance a porta 3080 poderá executar comandos no seu servidor. Mantenha o vínculo em 127.0.0.1, mantenha a porta 3080 fechada no firewall e use um túnel SSH, uma rede overlay privada ou um reverse proxy que exija uma senha.

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 do seu shell de login, portanto é encerrado quando esse shell termina. Inicie-o dentro de uma sessão tmux e separe-o com Ctrl-b d, ou execute-o como um serviço de usuário do systemd com o lingering ativado. O túnel e o harness são independentes: você pode interromper 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 ao seu login.

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

Porque o proxy_read_timeout padrão do nginx é de 60 segundos. Assim, ele fecha uma conexão que não produz dados durante um minuto, algo que uma etapa longa do agente pode fazer facilmente. Defina proxy_read_timeout 3600s; no bloco location. Adicione proxy_buffering off; para que a saída seja transmitida ao navegador assim que chegar e envie 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 carrega, mas nunca recebe uma atualização.