Erro 504 Gateway Timeout: o que é e como resolver na VPS

Entenda o erro 504 Gateway Timeout no Nginx: leia o log, confira o PHP ou o app, ache a causa da lentidão e veja quando vale aumentar o tempo.

Por Redação Eleven Host · @robson.direitodigital · 28 de outubro de 2026 · 7 min de leitura

O erro 504 gateway timeout aparece quando o Nginx esperou o PHP ou o seu app responder e desistiu. Veja o log, confira se o serviço de trás está vivo e ache o que demora, antes de aumentar o tempo de espera.

Este guia é para quem tem um site ou um app numa VPS com Nginx. Ele segue a ordem do diagnóstico: o que o erro significa, como diferenciar do 502, o que cabe ao visitante, quatro passos para achar a causa e, só no fim, como aumentar o tempo de espera. Os nomes seudominio.com.br e php8.3-fpm são exemplos. Troque pelos seus.

O que significa o erro 504 Gateway Timeout

Segundo a MDN, o código de resposta de erro HTTP 504 Gateway Timeout indica que o servidor, enquanto atuando como gateway ou proxy, não conseguiu responder em tempo.

Em linguagem simples: no seu site, o gateway é em geral o Nginx. Ele recebe o visitante e repassa o pedido para o PHP (no caso do WordPress) ou para um app, como Node ou n8n. Se esse programa de trás demora demais para responder, o Nginx desiste de esperar e mostra o 504. A página não abre, mas o erro não diz, por si só, o que ficou lento.

504 ou 502: qual é a diferença

Os dois erros envolvem o Nginx falando com o programa de trás, mas apontam problemas diferentes:

• 502: o programa de trás respondeu de forma inválida ou não estava lá. O guia Erro 502 Bad Gateway: o que é e como resolver na VPS cobre esse caso.
• 504: o programa de trás não respondeu a tempo.

Resumindo: no 502 o problema é a resposta ou a ausência do programa de trás; no 504 o problema é o tempo que ele levou para responder.

Se você é visitante ou dono do site

Se você só está visitando o site de outra pessoa, a MDN explica que, em geral, não há o que consertar do seu lado. A correção é no servidor. O que você pode fazer é recarregar a página depois de um tempo.

Se o site é seu, o problema está no servidor, e é aí que entram os passos abaixo. Eles vão do mais simples ao que exige mais investigação.

Passo 1: ler o log de erros do Nginx

O Nginx registra o motivo do erro. Veja as últimas 50 linhas do log:

sudo tail -n 50 /var/log/nginx/error.log

Procure a expressão upstream timed out. Junto dela aparece o endereço do programa de trás (o upstream). Ele mostra para onde o Nginx estava olhando.

Se o texto do log for outro, o problema pode não ser tempo de espera, e vale ler a mensagem inteira antes de mexer na configuração.

Passo 2: conferir se o programa de trás está vivo

Veja qual serviço está por trás do Nginx no seu caso.

Para PHP-FPM, descubra a versão instalada e olhe o estado do serviço. Troque 8.3 pela sua versão:

ls /run/php/

sudo systemctl status php8.3-fpm

Para um app Node rodando com PM2, veja se o processo está online:

pm2 status

Para o n8n no Docker, liste os contêineres em execução:

docker ps

Se o serviço está parado, o quadro se parece com o do erro 502 descrito acima. Se ele está ativo, siga para o próximo passo.

Passo 3: olhar CPU e memória

Um programa de trás sem recursos pode responder devagar. Abra o monitor de processos:

top

No topo da tela aparecem o uso de CPU e de memória. Se a VPS está no limite, o 504 pode ser um sintoma disso. O guia VPS lento? O que fazer: 6 sinais de que ficou pequeno ajuda a interpretar esses sinais e a decidir o próximo passo.

Precisa de um servidor para o seu site? Os planos de VPS saem a partir de R$ 17,00/mês, no Plano Bronze; confira na loja o que cada plano inclui. Ver planos de VPS

Passo 4: achar o que demora

Com o serviço vivo e a VPS respirando, a lentidão pode vir de algo dentro da aplicação. Três pontos para investigar:

• Banco de dados lento. Uma consulta pesada pode atrasar a página. O guia MySQL lento: como achar as consultas que travam o site mostra como achar a consulta.
• Chamada a serviço externo. O site espera a resposta de outro serviço que demora.
• Plugin pesado. Uma extensão do WordPress que faz muito trabalho a cada visita.

No PHP-FPM, dá para pedir que o próprio PHP registre as requisições lentas. Isso é o slowlog. Segundo o manual do PHP, o request_slowlog_timeout define depois de quanto tempo a requisição é registrada, e o slowlog define o arquivo. Os dois vêm com valor 0, que significa desligado.

No Ubuntu, essas linhas ficam no arquivo do pool. Abra-o:

sudo nano /etc/php/8.3/fpm/pool.d/www.conf

Acrescente ou ajuste estas duas linhas. O 10s e o nome do arquivo são exemplos:

request_slowlog_timeout = 10s

slowlog = /var/log/php-fpm-slow.log

Salve e recarregue o PHP-FPM:

sudo systemctl reload php8.3-fpm

Reproduza a lentidão e leia o arquivo de log. Ele grava o rastreamento da requisição lenta, e você vê em que ponto do código ela estava quando passou do tempo.

Se a demora vem de um app com proxy (Node, n8n), o caminho é parecido: veja nos logs do próprio app o que estava rodando na hora do erro.

Quando aumentar o tempo de espera

Há tarefas legítimas que demoram mesmo, como uma importação grande ou um relatório pesado. Nesses casos, aumentar o tempo faz sentido, mas é preciso mexer nos dois lados: no Nginx e no PHP.

Segundo a documentação do Nginx, o fastcgi_read_timeout (para PHP-FPM) e o proxy_read_timeout (para proxy a um app) têm padrão de 60 segundos. Esse tempo conta entre duas leituras seguidas, não para a resposta inteira. No PHP, o manual indica que o max_execution_time tem padrão de 30 segundos.

No bloco location ~ \.php$ do site, em /etc/nginx/sites-available/seudominio.com.br, acrescente:

fastcgi_read_timeout 120s;

Se o seu caso é um app atrás de proxy, a linha vai no location do proxy, como no guia Nginx proxy reverso: como configurar na sua VPS:

proxy_read_timeout 120s;

No PHP, ajuste o php.ini do FPM (não o da linha de comando):

sudo nano /etc/php/8.3/fpm/php.ini

Procure e altere a linha:

max_execution_time = 120

O 120 é só um exemplo, não um valor recomendado: use o tempo que a sua tarefa pede. Depois, teste a configuração do Nginx, recarregue-o e reinicie o PHP-FPM:

sudo nginx -t

sudo systemctl reload nginx

sudo systemctl restart php8.3-fpm

Se o nginx -t apontar erro, não recarregue: corrija a linha indicada antes. Trate esse ajuste como exceção para uma tarefa específica, e não como conserto da lentidão.

Quer um domínio para o seu site na VPS? Registre o seu na Eleven Host; confira na loja o que cada plano inclui. Registrar domínio

Perguntas frequentes

O erro 504 é culpa do navegador ou da internet do visitante?

Segundo a MDN, o 504 indica que o servidor, atuando como gateway ou proxy, não respondeu em tempo. Para quem visita, em geral a correção está no servidor.

Qual a diferença entre o 504 e o 502?

No 502, o programa de trás respondeu de forma inválida ou não estava lá. No 504, ele não respondeu a tempo.

Aumentar o tempo do Nginx resolve o 504?

Pode evitar o erro numa tarefa que demora de verdade, desde que o PHP também tenha tempo para terminar. Se a causa é uma consulta lenta ou falta de recursos, o visitante continua esperando e a demora segue lá.

Qual é o tempo padrão do Nginx para esperar o PHP?

Segundo a documentação do Nginx, o fastcgi_read_timeout tem padrão de 60 segundos, e o proxy_read_timeout também.