503 ou 403 instantâneo: verifique primeiro acima da aplicação

Latência zero é a primeira medição

O tempo até ao primeiro byte diz se a aplicação fez algum trabalho. Um erro que chega aproximadamente no tempo de ida e volta da rede foi decidido sem ela. Um erro gerado pela aplicação transporta o tempo que ela gastou antes de desistir.

curl -s -o /dev/null -w 'code=%{http_code} ttfb=%{time_starttransfer} total=%{time_total}\n' https://site.example/
curl -sI https://site.example/

Os headers nomeiam a camada na maioria das vezes. Um header Server ou Via que pertence ao edge ou ao balancer e não ao servidor web, um X-Cache ou um request id do edge, um body em texto simples onde a aplicação renderizaria um template: cada um diz quem respondeu. Com isso em mãos, a lista de verificação é curta.

A lista de verificação, de cima para baixo

O CDN ou o edge. Uma regra de WAF, um rate limit, uma regra geográfica, um desafio anti-bot, ou um problema de certificado entre o edge e o origin, que o edge reporta como um 5xx seu. Contorne-o: resolva o nome diretamente para o origin e repita o pedido.

curl -s -o /dev/null -w 'code=%{http_code} ttfb=%{time_starttransfer}\n' \
     --resolve site.example:443:ORIGIN_IP https://site.example/

O origin responde 200, o edge responde 5xx: o erro pertence ao edge, e também a regra que o produziu.

O load balancer. O HAProxy responde 503 por si só quando nenhum backend está ativo, com o seu próprio header Server e um body de uma linha. Isso é uma questão de health check, não de aplicação: um caminho de verificação que mudou no último deploy, uma porta de verificação que se moveu, ou um backend marcado como down por uma razão visível na página de stats. Peça um backend diretamente a partir do host do balancer para confirmar que serve.

A camada da plataforma. Um estado de suspensão ou manutenção no painel de controlo, o interruptor de manutenção de uma ferramenta de deploy, um serviço escalado para zero. Cada um serve uma página fixa sem invocar a aplicação, e cada um é uma flag que pode ler, não uma teoria.

Regras do servidor web. Uma única diretiva return, rewrite ou deny responde instantaneamente e parece catastrófica. Exporte a configuração efetiva e não o ficheiro que pensa estar carregado.

# nginx: the configuration actually in effect, with the rules that short-circuit a request
nginx -T 2>/dev/null | grep -nE '^\s*(return|rewrite|deny|allow)\b'

# IIS: the URL Rewrite rules for the site
appcmd list config /section:system.webServer/rewrite/rules

No Apache, leia a cadeia .htaccess efetiva para o caminho, não apenas o vhost.

DNS. Confirme que o nome resolve para o host que está a depurar. Um registo desatualizado, uma diferença de split-horizon ou uma alteração ainda em propagação significam que a máquina que está a observar não é a que está a responder.

Permissões e SELinux. O servidor web não consegue ler o document root ou ligar-se ao socket upstream. Um 403 ou um 502 sem nenhuma linha no log da aplicação. Num sistema em enforcing, o audit log nomeia a negação e a correção é um policy module, não uma mudança de modo.

ausearch -m avc -ts recent | audit2why

Só agora, a aplicação. Worker pools, runtime, dependências, o código. Cada um destes é caro de investigar individualmente e não pode ser a causa de uma resposta que a aplicação não produziu.

Dois detalhes que prolongam a caça

Um 429 tem dois autores possíveis. Um limiter no edge responde-o com os headers do próprio edge e normalmente um Retry-After. Um limiter da aplicação responde-o a partir de dentro da aplicação, com os headers da aplicação e depois de a aplicação ter feito algum trabalho. O tempo até ao primeiro byte e os headers distinguem-nos, e a correção está num sítio diferente para cada um.

Uma página de erro pode sobreviver à sua causa. Edges e reverse proxies podem guardar em cache um 5xx durante algum tempo, pelo que o origin recupera e o edge continua a servir o erro guardado até expirar. Um header Age na resposta de erro diz que é uma cópia em cache. Faça purge do caminho no edge, ou espere pelo fim do TTL, antes de concluir que a correção não funcionou.

Faça cada camada provar-se a si própria

Cada passo acima emparelha uma camada com uma forma de a contornar: resolver diretamente para o origin contorna o edge, pedir um backend a partir do host do balancer contorna o balancer, pedir a porta da aplicação em localhost contorna o servidor web. O primeiro salto em que a resposta muda do erro para conteúdo é a camada a que o erro pertence. O método é mecânico de propósito, e é isso que o torna rápido a qualquer hora.