503 o 403 instantáneo: mire primero por encima de la aplicación

La ausencia de latencia es la primera medición

El tiempo hasta el primer byte le dice si la aplicación hizo algún trabajo. Un error que llega aproximadamente en el tiempo de ida y vuelta de la red se decidió sin ella. Un error generado por la aplicación arrastra el tiempo que esta gastó antes de rendirse.

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

Las cabeceras nombran la capa la mayoría de las veces. Una cabecera Server o Via que pertenece al edge o al balanceador y no al servidor web, una X-Cache o un request id del edge, un cuerpo de texto plano donde la aplicación renderizaría una plantilla: cada una dice quién respondió. Con eso en la mano, la lista de comprobación es corta.

La lista de comprobación, de arriba abajo

El CDN o el edge. Una regla de WAF, un rate limit, una regla geográfica, un desafío anti-bot o un problema de certificado entre el edge y el origen, que el edge notifica como un 5xx propio. Sáltelo: resuelva el nombre directamente al origen y repita la petición.

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

El origen responde 200, el edge responde 5xx: el error pertenece al edge, y también la regla que lo produjo.

El balanceador de carga. HAProxy responde 503 por sí mismo cuando ningún backend está arriba, con su propia cabecera Server y un cuerpo de una línea. Eso es una cuestión de health check, no de aplicación: una ruta de comprobación que cambió en el último despliegue, un puerto de comprobación que se movió, o un backend marcado como caído por un motivo visible en la página de stats. Pida un backend directamente desde el host del balanceador para confirmar que sirve.

La capa de plataforma. Un estado de suspensión o mantenimiento en el panel de control, el interruptor de mantenimiento de una herramienta de despliegue, un servicio escalado a cero. Cada uno sirve una página fija sin invocar la aplicación, y cada uno es un indicador que puede leer, no una teoría.

Reglas del servidor web. Una sola directiva return, rewrite o deny responde al instante y parece catastrófica. Vuelque la configuración efectiva y no el archivo que cree que está cargado.

# 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

En Apache, lea la cadena .htaccess efectiva para la ruta, no solo el vhost.

DNS. Confirme que el nombre resuelve al host que está depurando. Un registro obsoleto, una diferencia de split-horizon o un cambio aún propagándose significan que la máquina que está mirando no es la que responde.

Permisos y SELinux. El servidor web no puede leer el document root o conectarse al socket upstream. Un 403 o un 502 sin una sola línea en el log de la aplicación. En un sistema en enforcing, el log de auditoría nombra la denegación y la solución es un módulo de política, no un cambio de modo.

ausearch -m avc -ts recent | audit2why

Solo ahora, la aplicación. Pools de workers, runtime, dependencias, el código. Cada uno de estos es caro de investigar y no puede ser la causa de una respuesta que la aplicación no produjo.

Dos detalles que alargan la búsqueda

Un 429 tiene dos posibles autores. Un limitador en el edge lo responde con las cabeceras del propio edge y normalmente un Retry-After. Un limitador de la aplicación lo responde desde dentro de la aplicación, con las cabeceras de la aplicación y después de que esta hiciera algún trabajo. El tiempo hasta el primer byte y las cabeceras los distinguen, y la solución está en un sitio distinto para cada uno.

Una página de error puede sobrevivir a su causa. Los edges y los reverse proxies pueden cachear un 5xx durante un tiempo, así que el origen se recupera y el edge sigue sirviendo el error almacenado hasta que caduca. Una cabecera Age en la respuesta de error dice que es una copia en cache. Purgue la ruta en el edge, o espere a que venza el TTL, antes de concluir que la solución no funcionó.

Haga que cada capa se demuestre a sí misma

Cada paso anterior empareja una capa con una forma de rodearla: resolver directamente al origen se salta el edge, pedir un backend desde el host del balanceador se salta el balanceador, pedir el puerto de la aplicación en localhost se salta el servidor web. El primer salto en el que la respuesta cambia del error al contenido es la capa a la que pertenece el error. El método es mecánico a propósito, y eso es lo que lo hace rápido a cualquier hora.