Códigos de status HTTP: lista e significados

Significado

O servidor recebeu os cabeçalhos da solicitação e não encontrou problemas. O cliente pode enviar o corpo. Isso faz parte do cabeçalho “Expect: 100-continue”, usado pelo cliente para verificar se o servidor aceitará um upload grande antes de enviá-lo.

Significado

O servidor muda de protocolo a pedido do cliente, por exemplo, de HTTP para WebSocket. Para isso, o cliente enviou o cabeçalho “Upgrade”.

Significado

O servidor ainda está processando a solicitação. Esse código vem do WebDAV e evita um timeout em operações longas. É considerado obsoleto e raramente aparece.

Significado

O servidor envia informações antecipadas, como cabeçalhos “Link” para folhas de estilo ou scripts, enquanto prepara a resposta principal. O navegador já pode carregar esses arquivos. É uma informação, não um erro.

Significado

A requisição foi bem-sucedida. Com GET, a resposta contém o recurso solicitado; com POST, o resultado da ação. É a resposta normal de qualquer página que funciona.

Significado

A requisição foi bem-sucedida e criou um novo recurso. Isso é comum com POST em uma API. O cabeçalho “Location” indica o endereço do novo recurso.

Significado

O servidor aceitou a solicitação, mas ainda não terminou de processá-la. Ele fornecerá o resultado depois, por exemplo, por consulta de status ou webhook. Isso é comum em tarefas em segundo plano.

Significado

A requisição foi bem-sucedida, mas os dados não vieram diretamente do servidor de origem: passaram por um proxy que pode tê-los alterado. É raro encontrar esse código.

Significado

A requisição foi bem-sucedida, mas a resposta não tem corpo intencionalmente. Isso é comum com DELETE ou PUT e em requisições de preflight CORS (OPTIONS). Quem quiser ler a resposta como JSON precisa tratar o corpo vazio.

Significado

A requisição foi bem-sucedida. O cliente deve redefinir a visualização, por exemplo, limpando um formulário. A resposta não tem corpo. É pouco usada.

Significado

O servidor fornece apenas a parte solicitada de um arquivo porque o cliente enviou um cabeçalho “Range”. Usado para streaming de vídeo, downloads pausados e arquivos grandes.

Significado

A resposta contém vários códigos de status para várias operações parciais, em XML. Tem origem no WebDAV e aparece na sincronização de calendários, contatos e arquivos.

Significado

Os membros de uma vinculação WebDAV já foram apresentados em uma parte anterior da mesma resposta e não serão listados novamente. Muito raro.

Significado

O servidor respondeu à solicitação com uma codificação delta: a resposta resulta de uma ou mais modificações da instância do recurso atual. Não é usada na prática.

Significado

Há várias respostas possíveis para a solicitação, como o mesmo arquivo em vários formatos ou idiomas. O cliente ou usuário deve escolher uma. Pouco usado na prática.

Significado

Redirecionamento permanente: o recurso tem um novo endereço, indicado no cabeçalho “Location”. Navegadores e mecanismos de busca devem usar apenas a nova URL daqui em diante.

Causas comuns

• Migração de domínio ou URL, por exemplo, de http para https ou de www para o domínio principal
• Uma página foi renomeada ou movida
• Uma regra de redirecionamento no nginx, Apache ou CMS está sendo aplicada

Como resolver o problema

• Use um link direto para a URL de destino, evitando o redirecionamento.
• Reduza cadeias de redirecionamento (A, B, C) a uma única etapa.
• Se houver um loop (ERR_TOO_MANY_REDIRECTS), confira se as regras de http/https e www não entram em conflito. Muitas vezes, o servidor e o CMS se contradizem.
• Os navegadores armazenam redirecionamentos 301 por muito tempo. Teste as alterações em uma janela anônima ou com curl -I.

Significado

Redirecionamento temporário: o recurso está disponível provisoriamente em outro endereço. O cliente deve seguir o cabeçalho “Location” nesta solicitação, mas continuar usando a URL original no futuro. Alguns clientes transformam um POST em GET nesse processo.

Causas comuns

• Redirecionamento temporário, por exemplo, para uma campanha ou manutenção
• Redirecionamento de login para uma página de acesso
• Redirecionamento por idioma ou país
• Definido incorretamente, embora a mudança seja permanente

Como resolver o problema

• Sinalize mudanças permanentes de endereço com 301 ou 308; caso contrário, os mecanismos de busca manterão a URL antiga.
• Para preservar o método, use 307 (temporário) ou 308 (permanente).

Significado

Redirecionamento com GET: o cliente deve acessar o resultado em outra URL via GET. Comum após um POST (Post/Redirect/Get), para evitar que a atualização da página reenvie o formulário.

Significado

O recurso não mudou desde a última solicitação. O servidor não envia um corpo de resposta, e o navegador usa a cópia em cache. Para isso, o navegador enviou “If-None-Match” (ETag) ou “If-Modified-Since”. Isso economiza largura de banda e acelera o carregamento da página.

Significado

Redirecionamento temporário como o 302, mas o método HTTP e o corpo permanecem inalterados: um POST continua sendo POST.

Causas comuns

• O Chrome mostra “307 Internal Redirect” nas ferramentas de desenvolvedor para redirecionamentos HSTS de http para https, sem que o servidor tenha enviado nada
• Um servidor redireciona temporariamente uma solicitação de API e quer preservar o método

Como resolver o problema

• Se o redirecionamento for permanente, use 308 em vez de 307.

Significado

Redirecionamento permanente como o 301, mas o método HTTP e o corpo permanecem inalterados: um POST continua sendo um POST. Indicado para migrações permanentes de API e formulários que não podem perder seus dados.

Significado

O servidor não entende a solicitação porque ela está malformada: sintaxe inválida, cabeçalhos corrompidos ou um cookie grande demais. Do ponto de vista do servidor, o erro está no cliente.

Causas comuns

• Caracteres inválidos ou URL codificada incorretamente, como um espaço ou um % sem dois dígitos hexadecimais
• Cookies muito grandes ou corrompidos; no nginx, o erro aparece como “Request Header Or Cookie Too Large”
• Corpo JSON inválido ou campos obrigatórios ausentes em uma API
• Cabeçalhos Host ou Content-Length incorretos, geralmente por causa de um proxy

Como resolver o problema

• Exclua os cookies do domínio no navegador e recarregue a página.
• Verifique a URL e codifique caracteres especiais, por exemplo, com o URL Encoder.
• Compare o corpo da requisição com a documentação da API.
• Se os cabeçalhos forem grandes demais: aumente os buffers do servidor.

Significado

A requisição exige autenticação válida. O cliente não fez login ou suas credenciais são inválidas. O servidor envia o cabeçalho “WWW-Authenticate”, que indica o método esperado. O nome é enganoso: significa “não autenticado”, não “sem permissão” (que corresponde a 403).

Causas comuns

• Token, senha ou chave de API ausente ou expirado
• Cabeçalho Authorization incorreto, por exemplo, sem «Bearer» antes do token
• Proteção HTTP Basic (.htpasswd) na página ou no diretório

Como resolver o problema

• Verifique as credenciais de acesso e a validade do token.
• Verifique o formato do cabeçalho Authorization.
• Para Basic Auth: verifique o usuário no arquivo .htpasswd e o caminho do arquivo na configuração.

Significado

Reservado para futuros sistemas de pagamento e nunca padronizado. Alguns serviços ainda o utilizam, por exemplo, quando uma assinatura expira ou é preciso pagar por uma cota de API.

Como resolver o problema

• Verifique o status da fatura ou da assinatura com o provedor.
• Leia a documentação da API do serviço; ela define o significado.

Significado

O servidor entende a solicitação, mas a recusa. Diferentemente de 401, fazer login novamente geralmente não ajuda: o acesso não é permitido para esta identidade ou este endereço.

Causas comuns

• As permissões ou o proprietário do arquivo estão incorretos; o usuário do servidor web não pode ler o arquivo
• Não há um documento de índice no diretório, e a listagem do diretório está desativada
• Bloqueio de IP, regra de firewall ou WAF, ou bloqueio geográfico
• Uma regra no .htaccess ou na configuração do nginx proíbe o acesso (deny all, Require all denied)
• Um módulo de segurança como ModSecurity ou Fail2ban bloqueia a solicitação

Como resolver o problema

• Verifique as permissões: geralmente 755 para diretórios e 644 para arquivos, com o proprietário correspondente ao usuário do servidor web. A calculadora de CHMOD converte os números.
• Crie um arquivo de índice (index.html, index.php) ou configure a diretiva index.
• Consulte o log de erros do servidor web: ele informa a causa exata, por exemplo, “directory index of … is forbidden”.
• Verifique bloqueios de IP e regras do WAF.

Significado

O servidor está acessível, mas não reconhece o endereço solicitado. O recurso não foi encontrado. O servidor não informa se ele nunca existiu ou se está apenas indisponível no momento.

Causas comuns

• Erro de digitação ou link desatualizado
• Página excluída, movida ou renomeada sem redirecionamento
• Caminho do documento incorreto no servidor web (root ou alias) ou uso incorreto de maiúsculas e minúsculas, que o Linux diferencia
• Regras de reescrita ausentes, por exemplo, para links permanentes do WordPress ou um aplicativo de página única
• O arquivo não foi enviado durante o deployment

Como resolver o problema

• Verifique o caminho e o nome do arquivo, inclusive letras maiúsculas e minúsculas.
• Configure try_files no nginx para que os permalinks e aplicativos de página única funcionem: try_files $uri $uri/ /index.php?$args; ou /index.html.
• Redirecione as páginas movidas para o novo endereço com 301.
• Configure uma página 404 personalizada com busca e links.

Significado

O recurso existe, mas não aceita este método HTTP (GET, POST, PUT, DELETE e assim por diante). A resposta deve incluir um cabeçalho “Allow” com os métodos permitidos.

Causas comuns

• POST em uma rota que aceita apenas GET, ou vice-versa
• O nginx responde com 405 a uma solicitação POST para um arquivo estático
• Um redirecionamento 301 ou 302 transformou o POST em GET
• O servidor web ou o WAF bloqueia métodos como PUT e DELETE

Como resolver o problema

• Leia o cabeçalho “Allow”; ele mostra os métodos permitidos.
• Verifique a rota e o controlador no aplicativo.
• Use 307 ou 308 em vez de 301 ou 302 se o método precisar ser preservado no redirecionamento.
• Acesse diretamente o endereço HTTPS final para que nenhum redirecionamento altere o método.

Significado

O servidor não consegue fornecer uma resposta em um formato aceito pelo cliente nos cabeçalhos “Accept”, como tipo de mídia, idioma ou conjunto de caracteres. Alguns firewalls de aplicativos web (ModSecurity) também bloqueiam solicitações com esse código.

Causas comuns

• O cabeçalho Accept solicita, por exemplo, apenas application/xml, mas o servidor fornece apenas JSON
• Uma regra do ModSecurity classificou a requisição como suspeita, algo comum com scripts sem User-Agent

Como resolver o problema

• Ajuste o cabeçalho Accept ou omita-o.
• No ModSecurity, consulte o log de auditoria e verifique a regra acionada.

Significado

Como o 401, mas a autenticação é exigida por um servidor proxy, não pelo servidor de destino. Para isso, o proxy envia o cabeçalho “Proxy-Authenticate”.

Causas comuns

• Um proxy corporativo ou escolar exige login
• Credenciais de proxy incorretas nas configurações do sistema ou no curl

Como resolver o problema

• Insira as credenciais do proxy, por exemplo, no curl com -x benutzer:passwort@proxy:port.
• Peça as credenciais corretas ao departamento de TI ou ao provedor do proxy.

Significado

O servidor esperou tempo demais pela solicitação completa do cliente e encerrou a conexão.

Causas comuns

• Conexão lenta ou instável do cliente
• Um upload grande é interrompido
• Um proxy ou Load Balancer mantém as conexões abertas por pouco tempo
• O navegador abriu uma conexão antecipadamente, mas nunca a utilizou

Como resolver o problema

• Verifique a conexão e repita a solicitação.
• Aumente os tempos limite no servidor.
• Para uploads: reduza o tamanho dos arquivos ou envie-os em partes.

Significado

A requisição entra em conflito com o estado atual do recurso, por exemplo, devido a alterações simultâneas ou a uma entrada que já existe. O cliente pode resolver o conflito e tentar novamente.

Causas comuns

• Um valor único já existe, como um endereço de e-mail, nome de usuário ou nome de domínio
• Dois usuários alteram o mesmo recurso; a versão não corresponde mais
• O recurso não pode ser alterado ou excluído no estado atual

Como resolver o problema

• Recarregue o estado atual e aplique sua alteração novamente.
• Consulte o corpo da resposta: APIs bem projetadas especificam o conflito ali.

Significado

O recurso existia, mas foi removido intencionalmente e não voltará. Diferentemente do 404, o servidor indica que ele foi removido permanentemente.

Causas comuns

• O conteúdo foi removido intencionalmente, por exemplo, uma oferta expirada
• Uma regra do servidor retorna 410 para URLs antigas

Como resolver o problema

• Se houver uma página substituta, redirecione com 301.
• Responda deliberadamente com 410 para URLs excluídas que nunca voltarão.

Significado

O servidor exige o cabeçalho “Content-Length”, ausente na solicitação. Ele só aceita o corpo se o tamanho for conhecido.

Causas comuns

• Um cliente envia o corpo da solicitação em partes (chunked) a um servidor que não aceita esse formato
• Um script ou proxy omite o cabeçalho

Como resolver o problema

• Defina Content-Length ou use um cliente HTTP que envie o cabeçalho automaticamente.
• Verifique as configurações de buffering de solicitações do proxy.

Significado

Uma condição no cabeçalho da requisição (If-Match, If-Unmodified-Since etc.) não foi atendida. Por isso, o servidor não aplica a alteração. Isso evita que alterações sejam sobrescritas.

Causas comuns

• O recurso mudou desde que o cliente carregou o ETag
• ETag obsoleta em If-Match

Como resolver o problema

• Recarregue o recurso, obtenha o ETag atualizado e envie a alteração novamente.

Significado

O corpo da solicitação é maior do que o servidor aceita. Isso é comum em uploads de arquivos. Antes, o código se chamava «Payload Too Large» e, anteriormente, «Request Entity Too Large».

Causas comuns

• nginx: client_max_body_size é de apenas 1 MB por padrão
• Apache: LimitRequestBody está definido
• PHP: upload_max_filesize ou post_max_size estão muito baixos
• Um CDN ou proxy à frente limita o tamanho

Como resolver o problema

• Aumente o limite na configuração e recarregue o servidor (nginx -s reload).
• Aumente upload_max_filesize e post_max_size em php.ini. post_max_size deve ser pelo menos igual a upload_max_filesize.
• Verifique cada etapa da cadeia: CDN, proxy, servidor web e PHP. O menor limite prevalece.

Significado

A URL é mais longa do que o servidor consegue processar. Geralmente, isso indica um erro no aplicativo, não um endereço real.

Causas comuns

• Muitos parâmetros em uma solicitação GET
• Um loop de redirecionamento acrescenta mais parâmetros a cada passagem
• Grandes volumes de dados são transmitidos pela URL em vez de POST

Como resolver o problema

• Envie grandes volumes de dados via POST.
• Corrija o loop de redirecionamento.
• Se necessário, aumente o limite do servidor.

Significado

O servidor não reconhece o formato do corpo enviado (cabeçalho “Content-Type”). Por exemplo, ele só processa JSON, mas recebeu dados de formulário.

Causas comuns

• O cabeçalho Content-Type está ausente ou incorreto, por exemplo, application/json em vez de text/plain
• O servidor espera multipart/form-data para uploads

Como resolver o problema

• Defina Content-Type de acordo com o corpo da requisição.
• Leia a documentação da API.

Significado

O intervalo solicitado (cabeçalho «Range») está fora do arquivo. O servidor informa o tamanho real em «Content-Range».

Causas comuns

• Um download é retomado a partir de um deslocamento, mas o arquivo diminuiu ou foi substituído
• Um gerenciador de downloads com defeito

Como resolver o problema

• Exclua o download parcial e comece de novo.

Significado

O servidor não consegue atender à expectativa indicada no cabeçalho “Expect”. Geralmente se trata de “100-continue”, que o proxy ou servidor não suporta.

Causas comuns

• Um proxy ou servidor antigo sem suporte a Expect
• Em requisições POST grandes, curl envia Expect: 100-continue automaticamente

Como resolver o problema

• Desative o cabeçalho no curl com -H 'Expect:'.
• Atualize o proxy.

Significado

Uma brincadeira de 1º de abril da RFC 2324 (Hyper Text Coffee Pot Control Protocol): um bule de chá se recusa a preparar café. O código é reservado e, na prática, é usado como brincadeira ou para bloquear bots.

Significado

A solicitação foi enviada a um servidor que não consegue responder a essa combinação de esquema e host. Isso ocorre em HTTP/2 quando um navegador reutiliza uma conexão para vários nomes de host.

Causas comuns

• Vários domínios em um IP com certificado compartilhado, mas configuração diferente para cada host
• SNI e o cabeçalho Host não correspondem

Como resolver o problema

• Padronize os certificados e os hosts virtuais dos domínios afetados.
• Use curl --resolve para verificar qual host responde.

Significado

O servidor entende a solicitação e seu formato está correto, mas o conteúdo é inválido, por exemplo, porque falta um campo obrigatório ou um valor está fora do intervalo permitido. Esse código era chamado de “Unprocessable Entity”. Muitos frameworks o usam para erros de validação.

Causas comuns

• A validação falha, por exemplo, devido ao formato do e-mail, ao tamanho ou a um campo obrigatório
• Um erro lógico, como uma data de término anterior à data de início

Como resolver o problema

• Consulte o corpo da resposta: ele contém os campos e as mensagens de erro.
• Compare os dados inseridos com a documentação da API.

Significado

O recurso está bloqueado, por exemplo, porque alguém fez seu checkout para edição no WebDAV.

Como resolver o problema

• Libere o bloqueio (UNLOCK) ou aguarde até que o outro usuário termine.

Significado

A requisição falhou porque outra requisição da qual depende também falhou. Esse código vem do WebDAV e também é usado por ferramentas de orquestração.

Significado

O servidor não quer processar uma solicitação que poderia ser repetida (ataque de replay). Isso ocorre com TLS 1.3 Early Data (0-RTT).

Significado

O servidor exige outro protocolo, indicado no cabeçalho “Upgrade”. Um exemplo é uma solicitação por HTTP/1.1 quando o servidor exige TLS ou HTTP/2.

Causas comuns

• Versão obsoleta do TLS
• A API só pode ser acessada por WebSocket ou HTTPS

Como resolver o problema

• Atualize o cliente e a biblioteca.
• Envie a solicitação pelo protocolo exigido.

Significado

O servidor exige uma condição (If-Match) para evitar a substituição acidental de uma versão desatualizada.

Causas comuns

• Uma solicitação PUT sem If-Match para um recurso protegido

Como resolver o problema

• Obtenha o ETag do recurso e defina-o no cabeçalho If-Match.

Significado

O cliente enviou solicitações demais em determinado período (Rate Limiting). O cabeçalho «Retry-After» informa quando ele poderá tentar novamente.

Causas comuns

• Limite de API ou de login excedido, por exemplo, devido a um loop no script
• Um bot, crawler ou scraper gera muita carga
• Uma proteção contra força bruta (Fail2ban, WAF) está atuando
• Vários usuários compartilham um endereço IP (NAT, VPN) e são contabilizados juntos

Como resolver o problema

• Aguarde o tempo indicado por Retry-After e tente novamente com intervalos crescentes (backoff exponencial).
• Agrupe as solicitações e armazene as respostas em cache.
• Se você administra o serviço: defina limites por IP ou API-Key e responda com 429; o nginx usa 503 por padrão.
• Permita crawlers legítimos.

Significado

Os cabeçalhos da solicitação são grandes demais, no total ou individualmente. A causa mais comum é a quantidade ou o tamanho excessivo dos cookies.

Causas comuns

• Cookies acumulados (rastreamento, sessões) em um domínio
• Um cabeçalho Authorization muito longo, como um JWT grande
• Um loop de redirecionamento acrescenta cada vez mais cookies

Como resolver o problema

• Exclua os cookies do domínio.
• Aumente os buffers de cabeçalho do servidor.
• Mantenha JWTs e cabeçalhos pequenos.

Significado

Um código específico do nginx que nunca é enviado ao cliente: o nginx fecha a conexão sem responder. Ele aparece apenas no log de acesso. Administradores usam return 444; para rejeitar bots e solicitações com host inválido.

Causas comuns

• return 444; na configuração do nginx, por exemplo, no servidor padrão

Como resolver o problema

• Se for intencional, você não precisa fazer nada.
• Se não for intencional, verifique a regra com nginx -T e procure return 444.

Significado

O recurso está bloqueado por motivos legais, como uma ordem judicial, censura ou bloqueio geográfico. O código faz referência ao romance “Fahrenheit 451”, de Ray Bradbury.

Causas comuns

• Bloqueio por determinação legal, por exemplo, devido a direitos autorais ou a uma ordem de autoridade pública
• O provedor bloqueia determinadas regiões por exigências legais

Como resolver o problema

• O operador geralmente informa o motivo no corpo da resposta.
• Pergunte ao responsável; contornar o bloqueio pode ser ilegal.

Significado

O cliente fechou a conexão antes que o nginx pudesse enviar a resposta. O código aparece apenas no log do nginx; não é um código HTTP real.

Causas comuns

• Um usuário interrompe o carregamento da página ou fecha a aba
• O tempo limite do cliente é menor que o tempo de resposta do servidor
• Um Load Balancer ou proxy à frente encerra a conexão cedo demais

Como resolver o problema

• Reduza o tempo de resposta da aplicação, por exemplo, em consultas lentas ao banco de dados.
• Ajuste os tempos limite do cliente, do proxy e do servidor para que sejam compatíveis.

Significado

Um erro geral no servidor: o servidor encontrou um problema inesperado e não conseguiu atender à solicitação. O código não revela o que deu errado; a causa está no log de erros.

Causas comuns

• Erro no código do aplicativo, como um erro fatal de PHP ou uma exceção não tratada
• Arquivo .htaccess inválido ou configuração incorreta do servidor web
• Permissões de arquivo ou proprietário incorretos nos scripts
• O banco de dados está inacessível ou as credenciais estão incorretas
• O limite de memória do PHP (memory_limit) ou o max_execution_time foi atingido
• Falta uma extensão PHP ou a versão do PHP é incompatível com o plugin

Como resolver o problema

• Consulte o log de erros: ele indica o arquivo e a linha do erro.
• Reverta as alterações dos últimos minutos (plugin, atualização, .htaccess).
• Teste a configuração com nginx -t ou apachectl configtest.
• Ative o modo de depuração (WP_DEBUG, APP_DEBUG) apenas localmente ou por pouco tempo, nunca permanentemente em um sistema de produção.

Significado

O servidor não reconhece o método solicitado ou não consegue implementá-lo. Diferentemente de 405, o problema não se limita a este recurso: o método não é suportado em geral.

Causas comuns

• Um método HTTP incomum ou escrito incorretamente
• O servidor ou proxy não oferece suporte à função, por exemplo, devido a software antigo

Como resolver o problema

• Verifique o método utilizado.
• Atualize o software do servidor.

Significado

Um servidor que atua como gateway ou proxy (nginx, Apache, Load Balancer, CDN) recebeu uma resposta inválida ou nenhuma resposta do servidor por trás dele. O erro ocorre entre os servidores, não no dispositivo do visitante.

Causas comuns

• O serviço de backend (PHP-FPM, Node.js, Gunicorn, Docker-Container) não está em execução ou falhou
• Upstream incorreto: a porta ou o socket em proxy_pass ou fastcgi_pass não corresponde
• O backend encerra a conexão prematuramente, por exemplo, devido a problemas de memória ou a uma falha
• Um firewall ou o SELinux bloqueia a conexão com o backend
• Uma CDN não consegue acessar corretamente o servidor de origem

Como resolver o problema

• Verifique o status do serviço de backend e reinicie-o (systemctl status, docker ps).
• Verifique se há um serviço escutando no endereço de upstream (ss -tlnp).
• Consulte o log de erros do servidor web: “connect() failed (111: Connection refused) while connecting to upstream” indica o destino.
• Verifique o caminho do socket e as permissões do PHP-FPM.
• A memória RAM é suficiente? O OOM Killer costuma encerrar primeiro o processo de backend.

Significado

O servidor está temporariamente incapaz de processar a solicitação, geralmente por sobrecarga ou manutenção. Ele pode usar “Retry-After” para informar quando tentar novamente.

Causas comuns

• Modo de manutenção, por exemplo, do WordPress ou Laravel, ou manutenção programada
• Sobrecarga: muitas solicitações ou processos simultâneos; por exemplo, o limite pm.max_children do PHP-FPM foi atingido
• Um serviço de backend atrás de um proxy ou balanceador de carga está inacessível
• Por padrão, o nginx responde com 503 quando os limites de limit_req e limit_conn são excedidos
• Os limites de recursos da hospedagem (CPU, RAM, processos) foram atingidos

Como resolver o problema

• Desative o modo de manutenção. Verifique se há um arquivo .maintenance (WordPress) ou o comando php artisan down (Laravel).
• Confira o uso de recursos (top, free -m) e aumente os limites de processos, como pm.max_children.
• Durante a manutenção programada, retorne intencionalmente 503 com Retry-After.
• Verifique se há erros de upstream no log do servidor web.

Significado

O gateway ou proxy não recebeu uma resposta a tempo do servidor por trás dele. Ao contrário do erro 502, a resposta não é inválida: ela está demorando demais.

Causas comuns

• Um aplicativo lento: consulta pesada ao banco de dados, relatório, importação ou chamada a uma API externa
• O backend está sobrecarregado; todos os workers do PHP-FPM estão ocupados
• Os valores de timeout do proxy são menores que o tempo de execução da solicitação
• Um problema de rede entre o proxy e o backend

Como resolver o problema

• Encontre consultas e scripts lentos e acelere-os (Slow Query Log, Profiler).
• Execute tarefas longas como trabalhos em segundo plano.
• Aumente os tempos limite de forma coordenada: proxy_read_timeout, fastcgi_read_timeout e max_execution_time no PHP.
• Verifique a capacidade do backend (workers, memória RAM).

Significado

O servidor não suporta a versão HTTP usada na solicitação.

Causas comuns

• Um cliente ou proxy muito antigo ou com defeito usa uma versão incomum do HTTP
• O sistema de destino aceita apenas uma versão específica

Como resolver o problema

• Atualize o cliente ou force HTTP/1.1; no curl, use --http1.1.

Significado

A configuração de Content Negotiation do servidor está incorreta: a variante escolhida aponta para uma nova negociação. Na prática, isso só ocorre com configurações incorretas.

Significado

O servidor não tem espaço de armazenamento suficiente para concluir a solicitação.

Causas comuns

• Disco rígido, cota ou inodes esgotados
• Não é mais possível salvar o upload

Como resolver o problema

• Verifique o armazenamento com df -h e df -i e remova logs, Backups e caches antigos.
• Aumente a cota.

Significado

O servidor detectou um loop infinito durante o processamento.

Causas comuns

• Uma associação WebDAV circular
• Uma estrutura de diretórios com loop de links simbólicos

Como resolver o problema

• Verifique os pontos de montagem e links simbólicos.

Significado

A requisição não inclui a extensão exigida pelo servidor conforme a RFC 2774. Esse código é histórico e praticamente nunca aparece.

Significado

O cliente precisa se autenticar na rede antes de obter acesso. Enviado por um Captive Portal, como em redes Wi-Fi de hotéis, aeroportos ou cafés.

Causas comuns

• Um portal cativo na rede Wi-Fi exige login ou consentimento

Como resolver o problema

• Acesse qualquer página via http, por exemplo, http://neverssl.com, para exibir o portal.
• Entre no portal.

Significado

A Cloudflare recebeu uma resposta do servidor de origem que não conseguiu processar: vazia, interrompida ou com cabeçalhos inválidos. É um erro genérico da Cloudflare.

Causas comuns

• O servidor de origem falha ao processar a solicitação, por exemplo, devido a um erro de PHP
• Os cabeçalhos da resposta excedem 32 KB, geralmente devido ao excesso de cookies
• A resposta está vazia ou a conexão foi encerrada sem resposta
• Um firewall bloqueia parcialmente os endereços IP da Cloudflare

Como resolver o problema

• Consulte o log de erros do servidor de origem.
• Libere os intervalos de IP da Cloudflare no firewall e no Fail2ban.
• Reduza o tamanho dos cabeçalhos e cookies.

Significado

A Cloudflare não conseguiu estabelecer uma conexão com o servidor de origem: ele recusou a conexão. O site e a Cloudflare estão acessíveis, mas o servidor por trás deles não.

Causas comuns

• O servidor web (nginx, Apache) não está em execução
• Um firewall ou o provedor de hospedagem bloqueia os endereços IP da Cloudflare
• IP de origem ou porta incorreta nas configurações da Cloudflare

Como resolver o problema

• Inicie o servidor web e verifique se ele está escutando nas portas 80 e 443.
• Libere os intervalos de IP da Cloudflare.
• Verifique o registro DNS A e a porta do servidor de origem.

Significado

A Cloudflare tentou se conectar ao servidor de origem, mas o handshake TCP não foi concluído a tempo. A conexão expirou antes mesmo de uma solicitação ser enviada.

Causas comuns

• O servidor de origem está sobrecarregado ou offline
• Um firewall descarta pacotes da Cloudflare
• Endereço IP incorreto ou problema de roteamento

Como resolver o problema

• Verifique se o servidor está acessível e sua carga.
• Libere os intervalos de IP da Cloudflare no firewall.
• Verifique o endereço IP no registro DNS.

Significado

A Cloudflare não consegue acessar o servidor de origem, por exemplo, devido a um erro de DNS ou à ausência de uma rota.

Causas comuns

• Endereço IP incorreto no registro DNS
• Servidor ou data center offline, problema de roteamento

Como resolver o problema

• Verifique o registro DNS.
• Consulte o provedor de hospedagem e verifique a rede.

Significado

A Cloudflare conseguiu se conectar, mas o servidor de origem não enviou uma resposta HTTP em até 100 segundos.

Causas comuns

• Scripts, exportações ou importações longos
• Um servidor sobrecarregado

Como resolver o problema

• Execute tarefas longas como trabalhos em segundo plano.
• Reduza o tempo de resposta.
• Para tarefas longas, use streaming ou consultas de status em vez de uma única solicitação.

Significado

A negociação TLS entre a Cloudflare e o servidor de origem falhou.

Causas comuns

• O servidor de origem não oferece HTTPS na porta 443
• Não há nenhuma suíte de cifras ou versão de TLS em comum
• SNI ausente ou o certificado não corresponde

Como resolver o problema

• Verifique a configuração TLS do servidor de origem.
• Selecione o modo SSL/TLS no Cloudflare de acordo com o servidor de origem.

Significado

A Cloudflare não conseguiu validar o certificado do servidor de origem. Ocorre no modo “Full (strict)”.

Causas comuns

• Certificado expirado, autoassinado ou não emitido para o domínio
• Falta um certificado intermediário

Como resolver o problema

• Instale um certificado válido (Let's Encrypt ou um Cloudflare Origin Certificate).
• Forneça a cadeia completa de certificados.