Skip to main content

Erro 104 no NGINX com .NET | (104: Connection reset by peer) while reading response header from upstream | Ambiente .NET

  • Erro 104 no NGINX com .NET | (104: Connection reset by peer) while reading response header from upstream | Ambiente .NET
info

Documentação explicando sobre o erro 104 causado pelo NGINX usando uma aplicação .NET

As documentações foram geradas pelo ChatGPT

Perspectiva 1: 🔗 Clique aqui Perspectiva 2: 🔗 Clique aqui

DETALHES IMPORTANTE​

.NET​

  • Normalmente quando estamos usando threads demais ou pelo caso delas estarem presas, a mensagem abaixo é comum para tal situação:
As of "02/10/2026 14:50:37 +00:00", the heartbeat has been running for "00:00:01.6542195" which is longer than "00:00:01". This could be caused by thread pool starvation.

O que a mensagem quer dizer

"the heartbeat has been running longer than expected"

O heartbeat é um “batimento” interno que o runtime usa para checar se a aplicação está saudável. Ele deveria rodar a cada 1 segundo, mas levou 1.65s.

Isso só acontece quando:

  • a aplicação está ocupada demais
  • não há threads livres para executar tarefas básicas

Ou seja: o processo está vivo, mas sufocado.

warning

Quando se tem threads bloqueadas por lock ou conexões penduradas podemos ter o erro 104

  • Threads bloqueadas
    • Thread pool esgotado
  • Kestrel não consegue responder
  • Alguma conexão é encerrada abruptamente
  • Recebemos os erro: 
    while reading response header

Nesse caso temos problema de concorrência e threadpool

Nginx​

  • Quando é retorno o 104 nos logs, normalmente se retorna 502 Bad Gateway no navegador

Docker​

  • Validar a quantidade de file descriptor no container com o comando ulimit -n.

Erros TCP no Linux (POSIX / Kernel)​

Visão geral​

Erros TCP são códigos retornados pelo kernel do sistema operacional quando uma aplicação tenta usar um socket TCP em um estado inválido ou excepcional.

Eles aparecem para aplicações como:

  • Nginx
  • Kestrel (.NET)
  • Java
  • Node.js
  • Qualquer software que use sockets

Esses erros não pertencem a frameworks e não são HTTP. Eles representam o estado real da conexão TCP.

Como os erros TCP surgem​

Fluxo genérico de execução:

Aplicação chama send() ou recv()
   ↓
Kernel avalia o estado do socket TCP
   ↓
Kernel retorna:
   - sucesso
   - EOF
   - erro (errno)

O valor retornado em errno define qual erro TCP ocorreu.

Local onde os erros são definidos​

  • Padrão POSIX
  • Kernel Linux
  • Arquivo errno.h

Esses códigos são universais em sistemas Unix-like.

Erros TCP mais comuns​

ECONNRESET (104)​

Connection reset by peer

Significado técnico:

  • Um pacote RST foi recebido
  • A outra ponta encerrou a conexão abruptamente
  • O socket se torna inválido imediatamente

Situações comuns:

  • Timeout de proxy
  • Processo encerrado
  • Conexão abortada
  • Escrita após fechamento

Exemplo em C:

ssize_t n = recv(fd, buffer, size, 0);

if (n == -1 && errno == ECONNRESET) {
    printf("Conexão resetada\n");
}

ETIMEDOUT (110)​

Connection timed out

Significado técnico:

  • O TCP aguardou resposta (ACK) e não recebeu
  • Não houve RST imediato
  • A conexão expirou por inatividade ou perda de pacotes

Situações comuns:

  • Redes instáveis
  • Firewalls
  • Serviços que não respondem

ECONNREFUSED (111)​

Connection refused

Significado técnico:

  • Não existe processo escutando na porta
  • O host respondeu com RST imediato
  • A conexão nunca foi estabelecida

Exemplo:

connect() failed (111: Connection refused)

EPIPE (32)​

Broken pipe

Significado técnico:

  • Tentativa de escrita em socket já fechado
  • Normalmente ocorre após FIN ou RST
  • Muito comum em servidores HTTP

Exemplo:

send(fd, data, size, 0); // socket já encerrado
// errno == EPIPE

ENOTCONN (107)​

Transport endpoint is not connected

Significado técnico:

  • Operação em socket não conectado
  • Erro de fluxo lógico da aplicação

EHOSTUNREACH (113)​

No route to host

Significado técnico:

  • O host não é alcançável
  • Problema de roteamento
  • Gateway ou destino indisponível

ENETUNREACH (101)​

Network is unreachable

Significado técnico:

  • A rede inteira não pode ser alcançada
  • Problema local de configuração de rede

EINPROGRESS (115)​

Operation now in progress

Significado técnico:

  • Conexão TCP ainda em andamento
  • Comum em sockets não bloqueantes
  • Não é erro fatal

EALREADY (114)​

Operation already in progress

Significado técnico:

  • Tentativa de nova conexão enquanto outra ainda está em andamento

Diferença entre EOF e erro TCP​

Nem todo encerramento gera erro.

Fechamento normal (FIN)​

ssize_t n = recv(fd, buffer, size, 0);

// n == 0 → EOF
  • Conexão encerrada corretamente
  • Nenhum erro
  • Nenhum errno

Fechamento abrupto (RST)​

ssize_t n = recv(fd, buffer, size, 0);

// n == -1
// errno == ECONNRESET
  • Encerramento imediato
  • Dados descartados
  • Erro reportado

Relação entre erros TCP e códigos HTTP​

Erro TCPCódigo HTTP comumOrigem típica
ECONNRESET502 / log 104Backend ou proxy
ETIMEDOUT504Proxy aguardando
ECONNREFUSED502Serviço offline
EPIPE502 / 499Escrita após fechamento
ENETUNREACH502Falha de rede

O código HTTP exibido depende de quem detecta o problema primeiro.

Relação com proxies e servidores web​

Proxies como Nginx:

  • Não criam erros TCP
  • Apenas chamam send() e recv()
  • Registram o errno retornado pelo kernel

Exemplo de log:

recv() failed (104: Connection reset by peer)

Erros TCP e aplicações modernas​

Frameworks como:

  • ASP.NET
  • SignalR
  • Node.js
  • Java

Apenas propagam o erro retornado pelo sistema operacional.

Eles não controlam:

  • RST
  • FIN
  • ACK
  • Estados TCP

Insight técnico essencial​

Erros TCP descrevem o estado da conexão, não a lógica da aplicação.

Na maioria dos casos, a causa real está em:

  • latência excessiva
  • bloqueio de I/O
  • timeout de proxy
  • encerramento forçado de conexões
  • arquitetura acoplada a operações lentas