Filtre erros do nginx por código de status ou pista do log e veja a causa provável e a mudança de configuração que resolve. Cobre 502, 504, 403, 404 e 413.
O nginx retorna 502 Bad Gateway quando atua como proxy e a aplicação por trás dele não dá uma resposta válida: a aplicação está parada, escutando em outra porta ou socket, ou caiu no meio da resposta. Inicie a aplicação, faça o proxy_pass apontar para o endereço em que ela realmente escuta e depois leia o log de erros do nginx para ver o motivo exato.
Para onde cada erro do nginx aponta
Escolha o código de status que você está vendo, ou digite uma palavra do seu log de erros, e o buscador reduz a lista às causas correspondentes. Cada cartão diz a causa, a verificação que a confirma e um trecho de configuração que você pode adaptar. Todos os cartões aparecem até você filtrar.
Como visitante, nada do que você faz causa esse erro. O proxy tentou acessar a aplicação por trás dele e não recebeu uma resposta válida. Como dono do site, a causa é a sua aplicação ou as configurações do seu proxy, então comece verificando se o processo upstream está rodando.
Um 502 significa que o upstream respondeu mal ou recusou a conexão. Um 504 significa que o nginx esperou e nada chegou a tempo. O primeiro aponta para uma aplicação parada ou travando, o segundo para um processamento lento ou um timeout baixo demais.
Defina client_max_body_size no bloco http, server ou location, por exemplo client_max_body_size 20m;. O padrão é 1m. Um valor 0 desativa a verificação de tamanho, o que raramente é o que você quer em um site público.
Quando a URL termina em barra, o nginx procura um arquivo index, como index.html. Se não existir nenhum e o autoindex estiver desligado, que é o padrão, não há nada que ele possa servir. Adicione o arquivo index ou direcione a requisição com try_files.
O local é definido pela diretiva error_log na sua configuração. Procure error_log no seu nginx.conf e nos arquivos incluídos para encontrá-lo, já que pacotes e containers o colocam em lugares diferentes.
Um ponto de partida para uma aplicação na porta 3000. Ele repassa o host e o esquema originais, define timeouts explícitos e deixa espaço para cabeçalhos maiores.
Teste com nginx -t e depois recarregue. Ajuste a porta e os limites para a sua aplicação.
A aplicação por trás do nginx não está rodando, então a conexão é recusada.
Faça um curl no endereço do proxy_pass a partir da máquina do nginx. Uma conexão recusada confirma.
Inicie a aplicação com um gerenciador de processos que a reinicie depois de uma queda.
O proxy_pass aponta para uma porta ou socket em que a aplicação não escuta.
Compare o endereço no proxy_pass com o que a aplicação mostra ao iniciar.
Faça os dois baterem exatamente, incluindo a parte do host.
A aplicação envia cabeçalhos de resposta maiores que o buffer em que o nginx os lê, por exemplo muitos cookies.
Procure uma linha no log que diga que o cabeçalho é grande demais.
Aumente o proxy_buffer_size para esse location. O padrão é uma página de memória, 4k ou 8k.
A aplicação demorou mais que o proxy_read_timeout entre duas leituras, 60 segundos por padrão.
Meça o tempo da mesma requisição direto na aplicação com curl.
Acelere o endpoint ou mova o trabalho para uma tarefa em segundo plano. Aumente o timeout só para esse location.
O nginx nem conseguiu abrir uma conexão dentro do proxy_connect_timeout, 60 segundos por padrão.
Verifique se há um firewall ou um host inacessível a partir do proxy.
Corrija o caminho de rede. A documentação do nginx observa que esse timeout normalmente não pode passar de 75 segundos, então aumentá-lo não ajuda.
Uma URL terminada em barra não tem arquivo index e o autoindex está desligado.
Liste a pasta para a qual o root aponta e procure o index.html.
Adicione o arquivo index, ou envie a requisição para a sua aplicação com try_files.
O usuário do worker do nginx não consegue ler o arquivo ou entrar em uma das pastas acima dele.
Procure no log de erros uma linha de permission denied com o caminho.
Dê ao usuário do worker permissão de leitura nos arquivos e de execução em cada pasta pai.
Uma regra allow ou deny correspondeu ao visitante. As regras são verificadas em ordem e a primeira que corresponde vence.
Leia cada linha allow e deny que se aplica ao location, de cima para baixo.
Reordene as regras para que o allow específico venha antes do deny all geral.
Foi usado root onde deveria ser alias, então o nginx adiciona o prefixo do location ao caminho duas vezes.
Calcule o caminho do arquivo: root acrescenta a URI inteira, alias substitui o prefixo correspondente.
Use alias, com barra final dos dois lados, quando o nome da pasta for diferente da URL.
Uma rota de single page app, como /dashboard, não tem arquivo no disco.
A página inicial carrega, mas atualizar qualquer rota interna falha.
Use try_files com fallback para index.html para que o router da aplicação trate o caminho.
O corpo da requisição é maior que o client_max_body_size, 1m por padrão.
Uploads abaixo de um megabyte funcionam e os maiores falham.
Aumente o limite apenas no location de upload.
Código de status
Todos os códigos
Palavras do seu log de erros
por exemplo: refused, timed out, denied
Verificação
Correção
{n} causas correspondentes
Nenhuma causa corresponde. Limpe a busca ou escolha outro código.
Comece grátis · Sem cartão de crédito