Porta VPS já em uso (2026): Address already in use, EADDRINUSE, solução de conflitos Docker/Nginx

No Linux moderno, prefira ss:

sudo ss -lntp

Para consultar apenas uma porta, por exemplo 80:

sudo ss -lntp | grep ':80 '

Para consultar 3000:

sudo ss -lntp | grep ':3000 '

Na saída, observe principalmente:

• Local Address:Port: endereço e porta de escuta;
• users:(...): qual processo está ocupando;
• pid=: ID do processo;
• LISTEN: indica que esta porta está sendo escutada.

Se você vir:

LISTEN 0 511 0.0.0.0:80 users:(("nginx",pid=1234,fd=6))

significa que a porta 80 já está ocupada pelo Nginx.

lsof também é muito útil:

sudo lsof -i :3000

Para mostrar apenas o PID:

sudo lsof -t -i :3000

A saída típica informa:

• o nome do comando;
• o PID;
• o usuário;
• IPv4 / IPv6;
• o estado LISTEN.

Se não estiver instalado:

sudo apt install lsof -y

ou:

sudo dnf install lsof -y

ss é melhor para diagnóstico do sistema, enquanto lsof é melhor para ver rapidamente "qual processo está ocupando esta porta".

Para ver o uso da porta:

sudo fuser -v 3000/tcp

Para mostrar apenas o PID:

sudo fuser 3000/tcp

Se você já confirmou que este processo pode ser parado, pode usar:

sudo fuser -k 3000/tcp

Mas em produção não é recomendado matar diretamente assim. O mais seguro é primeiro ver a qual serviço o processo pertence:

ps -fp PID
systemctl status 服务名 --no-pager

Se puder usar systemctl stop, não faça diretamente kill -9.

O conflito de porta mais comum em serviços web é 80/443.

Consultar a porta:

sudo ss -lntp | egrep ':80 |:443 '

Consultar o status do serviço:

sudo systemctl status nginx --no-pager
sudo systemctl status apache2 --no-pager
sudo systemctl status caddy --no-pager

Se o Nginx informar:

bind() to 0.0.0.0:80 failed (98: Address already in use)

normalmente é porque Apache, Caddy, outro Nginx ou um contêiner Docker já ocupa a 80.

A solução não é "matar todos":

• manter apenas uma entrada web;
• mover o outro serviço para 8080/8443;
• deixar o Nginx/Caddy atuar como proxy reverso;
• desabilitar o serviço que não é usado:

sudo systemctl stop apache2
sudo systemctl disable apache2

Depois de alterar a configuração do Nginx:

sudo nginx -t
sudo systemctl reload nginx

Para erros de configuração do Nginx, consulte: Erros de configuração do Nginx no VPS.

O erro do Docker geralmente aparece assim:

Bind for 0.0.0.0:8080 failed: port is already allocated

Primeiro veja o mapeamento de portas dos contêineres:

docker ps --format "table {{.Names}}\t{{.Ports}}"

Depois veja as portas do host:

sudo ss -lntp | grep ':8080 '

Causas comuns:

• dois contêineres especificam -p 8080:80;
• o Nginx do host já ocupa a 80 e o contêiner também quer -p 80:80;
• um contêiner antigo não foi removido e ainda ocupa a porta;
• o estado do docker-proxy ou da rede do Docker está anormal.

Como resolver:

docker ps -a
docker stop 容器名
docker rm 容器名

Ou alterar o mapeamento de portas:

ports:
  - "8081:80"

Não mapeie vários serviços para a 80 de qualquer jeito só para fazê-los rodar. Em um mesmo IP do host, a mesma porta só pode ser ocupada por um único listener por vez.

Se o serviço é gerenciado pelo systemd, primeiro veja:

sudo systemctl status app --no-pager
sudo journalctl -u app -n 100 --no-pager

Log comum:

Error: listen EADDRINUSE: address already in use :::3000
Failed with result 'exit-code'

Isso indica que a aplicação falhou ao vincular a porta na inicialização; o systemd apenas relata que o serviço falhou, não que o systemd em si tenha problema.

Ordem de diagnóstico:

sudo ss -lntp | grep ':3000 '
ps -fp PID
sudo systemctl stop 冲突服务
sudo systemctl restart app

Se o serviço reinicia repetidamente, também pode acionar start-limit-hit. Nesse caso, corrija primeiro o conflito de porta e depois:

sudo systemctl reset-failed app
sudo systemctl start app

Para um diagnóstico mais detalhado de falhas de inicialização do systemd, consulte: Serviço systemd não inicia no VPS.

Às vezes você vê claramente apenas um serviço, mas ainda assim aparece conflito de porta; a causa pode ser a escuta dual-stack IPv4/IPv6.

Ver os endereços de escuta:

sudo ss -lntp | grep ':80 '

Você pode ver:

0.0.0.0:80
[::]:80

O significado é aproximadamente:

• 0.0.0.0:80: escuta em todos os endereços IPv4;
• [::]:80: escuta em endereços IPv6;
• em algumas configurações [::]:80 também pode aceitar IPv4 ao mesmo tempo.

No Nginx, recomenda-se escrever explicitamente:

listen 80;
listen [::]:80;

Se quiser escutar apenas em IPv4:

listen 0.0.0.0:80;

Não deixe um serviço escutando em 0.0.0.0:80 e outro em [::]:80, esperando que cada um cuide de si. O comportamento real depende do sistema e da configuração da aplicação, e isso facilmente causa confusão no diagnóstico.

Muita gente vê um monte de TIME_WAIT e acha que a porta está ocupada.

Consultar:

ss -tan | grep TIME-WAIT | wc -l

TIME_WAIT é um estado normal do TCP, geralmente relacionado a muitas conexões curtas. Em geral não impede um serviço de escutar em uma porta fixa como 0.0.0.0:80.

O que realmente precisa de atenção é:

sudo ss -lntp

se há algum processo no estado LISTEN ocupando a porta de destino.

Não altere tcp_tw_reuse, tcp_fin_timeout sem critério. Se for esgotamento de portas efêmeras, é outro tipo de problema; se o serviço informa EADDRINUSE ao iniciar, verifique primeiro o processo em LISTEN.

Comum no Node.js:

Error: listen EADDRINUSE: address already in use :::3000

Diagnóstico:

sudo ss -lntp | grep ':3000 '

Se for ambiente de desenvolvimento, você pode trocar a porta:

PORT=3001 npm start

Python / Flask / FastAPI são semelhantes:

uvicorn app:app --host 0.0.0.0 --port 8001

Em produção, não deixe os serviços trocarem de porta aleatoriamente. Ou você fixa a porta e libera o processo em conflito, ou faz o Nginx atuar como proxy reverso para a nova porta e atualiza a configuração junto.

O comando comum encontrado na internet:

sudo kill -9 $(sudo lsof -t -i:3000)

Ele realmente libera a porta, mas o risco é: você pode matar um processo que está atendendo tráfego, um proxy de banco de dados, um proxy reverso ou uma tarefa em segundo plano de outra pessoa.

Um fluxo mais seguro:

sudo lsof -i :3000
ps -fp PID
systemctl status 相关服务 --no-pager

Depois de confirmar que está correto, então:

sudo systemctl stop 服务名

Só quando você confirmar que não é um serviço systemd nem um processo crítico, considere kill.

Ao encontrar Address already in use, EADDRINUSE, port is already allocated, verifique nesta ordem:

1. sudo ss -lntp | grep ':端口 ' para encontrar o processo em LISTEN.
2. sudo lsof -i :端口 para ver o nome do processo, o usuário e o PID.
3. ps -fp PID para confirmar o que é.
4. Se for um serviço systemd, primeiro systemctl status 服务名.
5. Se for Docker, docker ps --format "table {{.Names}}\t{{.Ports}}".
6. Se for 80/443, verifique se Nginx, Apache ou Caddy estão em conflito.
7. Veja journalctl -u 服务名 -n 100 para confirmar o erro da aplicação.
8. Se necessário, troque a porta, pare o serviço em conflito ou altere o mapeamento do Docker.
9. Não trate TIME_WAIT como a causa principal de conflito de porta de escuta.
10. Não faça kill -9 às cegas; confirme primeiro a quem pertence o processo.

O núcleo do diagnóstico de porta ocupada é simples: primeiro encontre quem está em LISTEN e depois decida como proceder.

ss -lntp é a primeira prioridade, lsof -i :端口 serve para confirmar o processo e fuser pode localizar e liberar rapidamente. Nginx/Apache/Caddy disputando 80/443, conflitos de mapeamento de portas do Docker e serviços Node/Python iniciados duas vezes são as causas mais comuns em um VPS.

Não misture TIME_WAIT, firewall, grupos de segurança e escuta de portas. Address already in use se refere a um conflito de vinculação de porta local; firewall e grupos de segurança afetam se o acesso externo é possível, o que é outro tipo de problema.