Erro 504 Gateway Timeout na Hostinger: como saber se o problema é o site ou a CDN

Fala aí, beleza? Deu de cara com um 504 no seu site e agora não sabe se a culpa é do WordPress, da hospedagem ou da CDN?

Este guia vale para sites em hospedagem web, Cloud ou Agency da Hostinger com a Hostinger CDN ativa

VPS fica de fora, porque a Hostinger CDN não está disponível em VPS nem para sites hospedados em outro lugar

Se o seu caso é n8n atrás de Nginx numa VPS, o diagnóstico é outro e não entra aqui 😉

Erro 504 x erro 408 na Hostinger: qual é a diferença

Os dois são erros de timeout, mas apontam para lados opostos da conexão

No 504, o site não respondeu a tempo e a CDN desistiu de esperar

No 408, a conexão do visitante foi lenta demais para entregar a requisição completa, o que geralmente indica um problema de rede de quem está acessando

Tudo isso está na página oficial de troubleshooting da Hostinger CDN, que cobre os erros 403, 408, 500, 502, 503 e 504 com a CDN ativa

E a primeira etapa que ela recomenda é justamente descobrir de onde vem o erro, antes de sair mexendo em tudo

Então a regra é simples: confirme o código exato antes de tocar no site

Um 408 isolado de um único visitante não pede que tu destrua seu WordPress por completo haha

Para prevenir confusão, anote o código e o horário de cada ocorrência

Ah, e se o timeout que você está vendo é de uma chamada de API dentro da sua aplicação (e não do site em si), o assunto é outro: aí entra retry com espera crescente e fallback

Como ver o cabeçalho x-hcdn-request-id no navegador

Toda resposta entregue pela Hostinger CDN traz o cabeçalho x-hcdn-request-id

Se ele aparece, a resposta passou pela CDN

Se não aparece, a requisição não passou pela Hostinger CDN (o erro vem direto do site ou de outro proxy, como o Cloudflare)

Bora ver na prática?

1. Abra a página que está dando erro no navegador
2. Pressione F12 para abrir as ferramentas do desenvolvedor
3. Vá na aba Network (ou Rede, se o navegador estiver em português)
4. Recarregue a página com a aba aberta. Erro comum deste passo: abrir a Network e não recarregar, aí a lista fica vazia e parece que nada aconteceu
5. Clique na primeira requisição da lista, ou em outro arquivo específico que você queira checar
6. Procure o x-hcdn-request-id na seção Response Headers

Resultado esperado: com o cabeçalho presente, você sabe que a resposta passou pela CDN

Agora o detalhe que muita gente ignora: copie o valor completo do x-hcdn-request-id e guarde junto com a URL e o horário

Com esse ID, a Hostinger localiza a requisição exata nos logs, então não deixa ele se perder no próximo F5!

Como ler o x-hcdn-cache-status

Na mesma seção Response Headers fica o x-hcdn-cache-status, que mostra como a CDN tratou aquele conteúdo

Entre os valores que podem aparecer estão:

• HIT: servido do cache da CDN
• MISS: buscado no site e armazenado em cache
• EXPIRED: a cópia em cache expirou e foi buscada de novo
• DYNAMIC: conteúdo não cacheável, buscado no site
• BYPASS: cache ignorado (por exemplo, com o Development mode ativo ou visitante logado)
• REVALIDATED: conteúdo revalidado com a origem
• STALE: uma cópia em cache foi servida porque o site estava indisponível ou retornando erro
• UPDATING: uma cópia em cache foi servida enquanto a CDN atualiza o conteúdo em segundo plano

E o que isso significa para o seu 504?

Se o recurso que falhou mostra MISS, DYNAMIC ou BYPASS, a CDN foi buscar a resposta no site

Ou seja, quem demorou foi a origem, e o foco do diagnóstico vira o site e a hospedagem

Já o STALE é um caso diferente dos outros: ele aparece quando o site estava com erro ou fora do ar, mas a Hostinger CDN nunca armazena respostas de erro (5xx): por isso, nesse momento, ela pode ter servido uma cópia em cache guardada antes do problema. Corrigir a causa no site faz o erro sumir para os visitantes imediatamente

Tome cuidado: com o Development mode ligado, toda requisição mostra BYPASS

Isso é o comportamento esperado, não um bug novo 🙂

Timeout por limite de PHP workers: como conferir o uso no painel da Hostinger

Sintoma clássico: timeouts ou lentidão justamente nos horários de mais acesso

Uma causa comum é o plano atingir o limite de PHP workers, e aí os usuários podem ter atrasos ou timeouts

Que PHP worker?

Pensa nele como um atendente que processa cada pedido PHP do site: se todos estão ocupados, o próximo pedido fica na fila esperando

Fica a ressalva: se o código que aparece é o 503 em vez do 504, o limite atingido pode ser outro, de processos ou de RAM: a Hostinger tem uma tela própria de uso de recursos para esse caso

Para conferir o uso de recursos da hospedagem, vá no painel da Hostinger em Websites → Manage site → Performance. Se quiser ver especificamente o gráfico de PHP Workers (junto com CPU, Memória e I/O), ele fica numa tela separada, a Resources Usage

A correção recomendada é reduzir os plugins e scripts que iniciam processos PHP

Quando o site atinge o limite de PHP workers com frequência, a orientação da Hostinger é considerar um upgrade. Avalie também quais plugins e scripts estão consumindo os recursos antes de escolher a solução para o seu caso

E se a necessidade for temporária, existe o boost do plano para um aumento temporário de recursos

Para prevenir: dá uma olhada na tela de Performance depois de cada plugin novo ou campanha que vai trazer pico de acesso

Plugins e page builders pesados causando timeout no WordPress

O 504 começou logo depois de instalar ou atualizar alguma coisa? Suspeito número um encontrado haha

Um plugin recente ou um page builder pesado pode atrasar a resposta do site a ponto de estourar o tempo

A orientação oficial da Hostinger para erros 504 é desativar temporariamente os plugins adicionados recentemente ou os page builders pesados (essa recomendação vale para o 504; o 408, como vimos antes, costuma ser problema de rede do lado do visitante, não do site)

Como estratégia de diagnóstico deste guia, faça uma mudança por vez e teste novamente. A recomendação oficial é testar a página depois de cada alteração; a organização dos testes aqui é uma sugestão para ajudar a identificar a causa

Se tu desativa cinco de uma vez, até resolve, mas fica sem saber qual era o culpado

Para prevenir: instale um plugin por vez e teste antes de partir para o próximo

Development mode: isolando se o problema é cache da CDN

Sintoma: você já corrigiu algo, mas o erro (ou uma versão antiga da página) continua aparecendo

Antes de sair limpando cache em todo canto, use o Development mode como teste (guia oficial de cache da CDN):

1. No painel, vá em Websites → Manage site → Performance → CDN e ative o Development mode. Nele, a Hostinger CDN ignora o próprio cache por completo e as mudanças aparecem em tempo real (ele afeta só o cache da CDN; o servidor e os plugins continuam cacheando normalmente)
2. Recarregue a página em uma janela anônima

Agora leia o resultado:

• O erro some: a causa era o cache da CDN. Vá em Websites → Manage site → Performance → CDN → Flush cache (na hospedagem Agency, a CDN fica direto na barra lateral) e desative o Development mode. A limpeza invalida as cópias em cache do site inteiro em poucos segundos; não é possível limpar URLs individuais separadamente. Erro comum deste passo: esquecer o Development mode ligado, porque enquanto está ativo o site perde o ganho de velocidade do cache da CDN
• O erro persiste: limpe o cache do servidor LiteSpeed no Cache Manager (Websites → Manage site → Cache Manager) e o cache do plugin de WordPress pelo menu do próprio plugin, antes de seguir culpando a aplicação

Para prevenir: mantenha só um plugin de cache ativo

Dois plugins de cache brigando é receita certa para dor de cabeça…

Desativar a CDN temporariamente para isolar a causa

Se ainda não ficou claro de onde vem o erro, desligue a CDN por completo para tirar a dúvida

O caminho é Hostinger dashboard → Websites → Manage site → Performance → CDN → Disable

Aguarde alguns minutos para as mudanças de DNS valerem e teste de novo

Agora leia o resultado assim:

• Erro persiste com a CDN desativada: a causa está no site ou no ambiente de hospedagem. Volte para as seções de recursos e de plugins
• Erro só aparece com a CDN ativa: reative a CDN e acione o suporte, informando a URL, o horário e o x-hcdn-request-id da resposta que falhou

Para prevenir: não deixe a CDN desligada além do tempo do teste, ela é só uma ferramenta de isolamento aqui

Nota: loop de redirecionamento com Cloudflare ou outro proxy

Isso não é 504, mas aparece muito junto nessa mesma investigação, então fica a nota rápida

Sintoma: a página entra em loop de redirecionamento e nunca carrega

Uma causa comum é ter outro proxy, como o Cloudflare, ativo ao mesmo tempo que a Hostinger CDN (só pode haver uma CDN por site)

Outra é um redirecionamento manual no .htaccess ou nas configurações do WordPress em conflito com o redirecionamento HTTPS

Solução: deixe só uma CDN ou proxy por site e revise os redirecionamentos

Para prevenir: documente onde cada redirecionamento foi configurado (já me imagino caçando regra perdida em .htaccess às 2 da manhã kkk)

O que enviar ao suporte da Hostinger quando o erro só aparece com a CDN

O cenário aqui é: o erro some sem a CDN e volta quando ela é reativada, mesmo depois do Flush cache

Reative a CDN e mande para o suporte da Hostinger:

• A URL que deu erro
• O horário do erro
• O valor completo do x-hcdn-request-id da resposta que falhou

Com esse ID, a Hostinger localiza a requisição exata nos logs, e o atendimento não começa do zero

Para evitar atraso: copie e guarde o x-hcdn-request-id completo logo quando o erro aparecer, junto com a URL e o horário, antes de fazer qualquer outro teste

Vídeo do canal

Confira também outros conteúdos do canal Hora de Codar para quem desenvolve sistemas

Próximo passo: monte seu roteiro de diagnóstico

Na próxima vez que o 504 aparecer, antes de mexer em QUALQUER coisa, anote o código, a URL, o horário e o x-hcdn-request-id

Só depois siga a ordem: recursos, plugins, cache e, por último, CDN desligada para isolar

E se você ainda está escolhendo onde hospedar, a hospedagem de sites da Hostinger (este e os demais links para a Hostinger neste artigo são de afiliado) faz sentido para esse cenário por um motivo bem prático: a CDN vem incluída sem custo extra nos planos Web Premium, Business e Unlimited, além de Cloud e Agency. No plano Single, a documentação oficial da Hostinger apresenta informações divergentes sobre a inclusão da CDN: se esse for o seu caso, vale confirmar diretamente com o suporte antes de decidir

Desde agosto de 2026, a CDN é ativada automaticamente nos sites elegíveis de hospedagem web (sites com nameservers externos à Hostinger não entram nessa ativação automática)

E as ferramentas de diagnóstico deste guia ficam no próprio painel: Performance, Development mode, Flush cache e Cache Manager

As limitações também contam: a CDN não existe em VPS nem para sites hospedados fora da Hostinger

E Single e Premium não têm todos os recursos de CDN, já que os níveis avançados de segurança exigem Business/Unlimited ou superior

Se esses recursos importam para o seu projeto, vale comparar os planos de hospedagem da Hostinger com isso em mente

Só não caia na armadilha: um 504 causado por plugin, cache ou configuração não se resolve comprando plano maior

Primeiro diagnostica, depois decide =)

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.