Leer el registro del servidor web y el del proxy inverso

Una petición web deja una línea en cada servidor por el que pasa, y cada línea trae lo básico: la hora, la dirección que se conectó, el método (leer una página o enviar datos), la ruta pedida, el estado de la respuesta, los bytes que pesó y el programa con el que se presentó el cliente. Hasta ahí, igual en todos los servidores.

Lo que cambia con un proxy inverso es quién se conecta con quién. El cliente se conecta al proxy, y el proxy abre otra conexión hacia el servidor de aplicaciones. Para el servidor, quien pide siempre es el proxy: toda la tienda llega desde una única dirección interna. La dirección del cliente real viaja aparte, en una cabecera que el proxy añade a la petición reenviada, llamada X-Forwarded-For. Cada proxy de la cadena añade al final de la lista la dirección de quien le habló.

Por eso el primer reflejo del analista no es contar peticiones por dirección en el registro del servidor: es comprobar si la dirección que ve es la de un cliente o la del proxy.

La cabecera X-Forwarded-For tiene un problema: cualquier cliente puede escribirla él mismo al hacer su petición. Si el cliente manda ya una dirección en ella, el proxy no la borra: añade la suya detrás. El resultado es una lista donde lo escrito por el cliente va primero y lo añadido por tu propio proxy va último.

De esa lista, solo se puede fiar uno de lo que añadieron proxies propios: la última entrada, la que anotó tu proxy al ver con quién hablaba. Todo lo que está antes es información que el cliente quiso dar. Un control del tipo «solo se permite la dirección tal» que lea la primera entrada de la lista se salta con solo escribirla.

En el registro de esta mañana, una petición llegó con la cabecera ya escrita por el cliente. Encuentra a quién pertenecía de verdad esa conexión.

El estado de la respuesta es un número de tres cifras, y su primera cifra dice la familia: 2xx el servidor atendió la petición; 3xx redirigió; 4xx el problema está en la petición (no existe, no tiene permiso, está mal formada); 5xx el problema está en el servidor, que no supo atenderla.

Hay dos errores de lectura típicos. El primero, creer que un 200 es siempre una visita normal: una respuesta 200 solo dice que el servidor contestó, no que lo pedido fuera legítimo. El segundo, ignorar los 5xx de una ruta que casi nunca los da: un servidor que falla justo con una entrada rara es un dato.

Hoy el servidor de la tienda dio una sola respuesta de familia 5xx. Anota cuándo.

La respuesta de error de la tarea anterior llegó justo después de una petición que sí se atendió, a la misma ruta, del mismo origen y con la misma cabecera escrita a mano. El servidor tardó 40 milisegundos en contestar el error y 842 en contestar la petición normal anterior; y la página de error pesó 612 bytes frente a los 9 100 de la respuesta normal.

Un error 5xx no prueba que alguien haya entrado: prueba que la aplicación no supo atender esa petición. Es una pista, no una conclusión. Lo que decide qué hacer es lo que ese mismo origen hizo antes y después, y qué ve la aplicación en su propio registro.