Registros de acceso al servidor — La historia de cada solicitud que ha recibido su aplicación

Cada solicitud HTTP que maneja tu servidor deja una línea en el registro de acceso. La mayoría de las veces, estos archivos quedan en disco creciendo silenciosamente hasta que se activa una alerta de disco o algo falla en producción. Entonces, de repente, todos quieren leerlos.

Aquí tienes una línea única de un servidor que está ejecutando el formato combinado de registro:

203.0.113.42 - jsmith [09/May/2026:14:32:11 +0000] "GET /api/users/profile HTTP/1.1" 200 1843 "https://example.com/dashboard" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"

Ocho campos. Cada uno es una pieza de evidencia sobre lo que ocurrió. Vamos de izquierda a derecha.

Los Campos, Uno por Uno

1. IP del cliente — 203.0.113.42

La dirección IP que abrió la conexión TCP hacia tu servidor. Esto es no necesariamente la IP del usuario final. Si estás detrás de un balanceador de carga, un CDN o un reverso proxy (por ejemplo, Nginx frente a una aplicación Node), esta será la IP del proxy. La IP real del cliente está en los X-Forwarded-For o X-Real-IP encabezados — y debes configurar explícitamente tu formato de registro para capturarlos.

En Nginx, eso se ve agregando $http_x_forwarded_for a tu log_format directiva. En Apache, usa %{X-Forwarded-For}i. Si omites esto y luego recibes una queja por abuso o necesitas bloquear a un mal actor, te encontrarás mirando la IP de tu propio balanceador de carga en cada línea del registro.

2. Ident — -

Siempre un guión. Este campo estaba destinado a contener el resultado de una consulta identd — un protocolo antiguo (RFC 1413) que permitía a los servidores preguntar al sistema operativo del cliente quién era el proceso que estaba haciendo la conexión. Nadie ejecuta identd actualmente. El campo existe porque el formato de registro común fue estandarizado cuando identd aún era algo real. Omitelo.

3. Usuario autenticado — jsmith

El nombre de usuario, rellenado cuando se utiliza autenticación HTTP básica o digest. Para la mayoría de las aplicaciones modernas — autenticación por token, cookies de sesión, JWTs — este será un guión. Si proteges una zona de administración con htpasswd, los intentos fallidos se muestran como - a un estado 401; los exitosos muestran el nombre de usuario.

4. Fecha y hora — [09/May/2026:14:32:11 +0000]

La hora en que el servidor terminó procesar la solicitud (no cuando comenzó). El formato es day/Mon/year:HH:MM:SS timezone. La diferencia horaria es más importante de lo que se piensa — si tu servidor de aplicación corre en UTC pero tu herramienta de monitoreo o alertas está en una zona horaria local, correlacionar un pico en los registros con un incidente específico requiere cálculos de conversión cada vez que se hace. Ejecuta todo en UTC.

5. Línea de solicitud — "GET /api/users/profile HTTP/1.1"

El campo más denso en información. Tres partes: el método HTTP, la ruta con cadena de consulta y la versión del protocolo.

• Método — GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS. Los métodos inesperados en un endpoint merecen ser notados.
• Ruta + cadena de consulta — te dice exactamente qué se solicitó. Las cadenas de consulta pueden contener términos de búsqueda, IDs y, en APIs mal diseñadas, tokens de autenticación. Registra adecuadamente.
• Protocolo — los clientes HTTP/1.0 en tus registros en 2026 son ya integraciones antiguas o algo que imita un cliente viejo. Los clientes HTTP/2 y HTTP/3 se registran como esas versiones si tu servidor los soporta.

6. Código de estado — 200

El código HTTP que el servidor envió de regreso. Este es el campo de veredicto.

• 2xx — éxito. La solicitud fue atendida.
• 3xx — redirección. El cliente necesita ir a otro lugar.
• 4xx — error del cliente. Solicitud incorrecta, falta de autenticación, no encontrado. Puede ser uso legítimo o escaneo.
• 5xx — error del servidor. Tu aplicación se cayó, se agotó el tiempo o devolvió datos incorrectos. Estos siempre deben investigarse.

Al triagear un incidente, filtra por 5xx primero. Luego revisa la hora del primer 500 — esa es cuando comenzó el fallo. Todo antes de eso es el preludio; todo después es el alcance del incidente.

7. Bytes enviados — 1843

El tamaño del cuerpo de la respuesta en bytes, sin contar encabezados. Un guión significa cero bytes (típico para 304 Not Modified respuestas — el cliente ya tiene el contenido). Valores inesperadamente grandes en endpoints que deberían devolver unos pocos cientos de bytes es una señal de alarma. Un usuario autenticado que accede a un endpoint “obtener mi perfil” y recibe 40MB es ya un error o alguien que está abusando de una exportación de datos.

8. Referer — "https://example.com/dashboard"

De dónde vino el cliente antes de hacer esta solicitud — la URL en el encabezado del navegador. (El especificación HTTP cometió un error de ortografía en 1996 y seguimos con ello.) El tráfico directo, los marcadores y las solicitudes de aplicaciones nativas llegan con un referer vacío. Este campo solo existe en el formato combinado de registro; el formato común original termina en bytes enviados. Referer El spam de referer — encabezados de referer falsos en solicitudes masivas tratando de aparecer en tus análisis — era más común antes pero ahora es una reliquia. Aún vale la pena filtrarlo de tus estadísticas agregadas.

9. Agente de usuario —

El identificador del cliente. Los agentes de usuario son fáciles de falsificar, así que trátalos como una pista, no como una verdad. Los recorridores legítimos suelen identificarse honestamente: "Mozilla/5.0 (Windows NT 10.0; Win64; x64)…"

. Los scrapers que imitan navegadores envían la cadena completa Mozilla/5.0 Chrome. Curl envía Googlebot/2.1 (+http://www.google.com/bot.html), Bingbot/2.0a menos que alguien lo sobrescriba con curl/8.x Patrones a monitorear: cadenas idénticas de agente de usuario que hacen peticiones a los mismos endpoints a velocidad de máquina, o un agente de usuario que dice ser Safari iOS pero hace peticiones en un patrón que ningún navegador humano haría (sin imágenes, sin CSS, recorridos secuenciales de páginas de producto). -A.

Patrones que aparecen en cada registro de log

El escaneo de vulnerabilidades

Una IP o una pequeña red de IP que hace docenas de rutas en rápida sucesión:

. Todas devuelven 404. Esto es un escáner automático que ejecuta una lista, no un ataque dirigido. Ellos ejecutan contra cada IP pública constantemente. /.env, /wp-login.php, /phpmyadmin, /admin/config.yml, /.git/configLa pregunta correcta no es “por qué están escaneándome” — es “¿alguna de esas rutas devolvió 200?”. Si

devuelve 200 en tu servidor, eso es el problema real. /.env El robo de credenciales

# Check if any sensitive paths actually returned 200
grep -E '"(GET|POST) /(wp-login\.php|\.env|\.git/config|phpmyadmin|admin)' access.log | awk '$9 == 200'

Solicitudes POST de alta volumen a tu punto de entrada de inicio de sesión, casi todas devolviendo 401, provenientes de un conjunto distribuido de IPs. La señal es el patrón: mismo endpoint, tamaño de respuesta consistente (la página de error), muchos IPs diferentes que comparten un ASN. Los tiempos de respuesta tienden a ser constantes también — los intentos automáticos de inicio de sesión se ejecutan a una velocidad constante para evitar el límite de tasa.

El pico de 404 tras una actualización

# Count POST /login attempts with 401 status by source IP
awk '$6 == "\"POST" && $7 == "/api/login" && $9 == "401" {print $1}' access.log \
  | sort | uniq -c | sort -rn | head -20

Haces una nueva versión. Los 404 aumentan. Los enlaces antiguos en correos, marcadores y sitios externos apuntan a URLs que ya no existen. Esto es normal — pero si los 404 están en URLs que

deberían existir en la nueva versión, eso es un error de ruteo. Compara los caminos 404 con tus definiciones de rutas. El agrupamiento de respuestas lentas

El formato estándar de registro no incluye el tiempo de respuesta. Debes añadirlo: en Apache, agrega

(microsegundos) a tu %D ; en Nginx, añade LogFormatbloque. Una vez que lo tengas: $request_time a tu log_format Si las solicitudes lentas se agrupan en un intervalo de tiempo específico, eso es una competencia — un trabajo de cron, un proceso en lote o una copia de seguridad que está golpeando la base de datos. Si una ruta específica es lentamente constante independientemente del tiempo, eso es una consulta lenta o una llamada bloqueante que necesita perfilado.

# Nginx: show requests slower than 3 seconds (request_time in last field)
awk '{if ($NF+0 > 3) print $0}' /var/log/nginx/access.log | head -20

Depuración de un incidente desde los registros

El registro de acceso es una línea del tiempo. Cuando un usuario reporta “algo falló alrededor de las 3 de la tarde”, tú:

Filtra al intervalo de 14:50–15:10

• Busca el primer 5xx — eso es cuando comenzó
• Revisa qué cambió en los minutos anteriores: ¿hubo una actualización? ¿Un empuje de configuración? ¿Una renovación de certificado?
• Revisa qué rutas tuvieron 5xx — ¿es todo o un endpoint específico?
• Revisa los bytes enviados en respuestas exitosas antes y después — ¿algo comenzó a devolver respuestas truncadas?
• Algunas firmas de fallo que vale la pena conocer:

Pico de 502

• — murió tu upstream (crash de servidor de aplicación, agotamiento del pool de conexiones, base de datos caída). Los 502 comienzan en un timestamp preciso. Bucle de redirección
• — 301/302 desde la misma IP hacia la misma ruta repetidamente. Normalmente es una configuración incorrecta de redirección HTTPS o un ajuste de SSL de Cloudflare que se enfrenta con la lógica de redirección de tu aplicación. 200 con cero bytes
• — estado 200 pero bytes enviados es 0 o . Tu aplicación aceptó la solicitud, atrapó una excepción y devolvió un cuerpo vacío. Caso clásico de error no manejado. -Pico de 413
• — clientes enviando cuerpos de solicitud por encima de tu límite. O bien tu límite es demasiado bajo para el caso de uso o alguien está explorando vulnerabilidades de carga. Si estás trabajando con registros en múltiples formatos — formato común de Apache, formato combinado de Apache, formato predeterminado de Nginx, formatos personalizados —

el Formato de registro de acceso puede analizar y anotar los campos para que no tengas que mapear posiciones de campos cada vez que cambies entre servidores. Gestión de registros que lamentarás no haber configurado

Rotación de registros

• configurada para rotar diariamente, comprimir y conservar entre 14 y 30 días. Sin ella, — logrotate crece hasta que se llena el disco. Esto ocurre en producción. access.log Registro centralizado
• — una vez que tengas más de un servidor, seguir los archivos de registro individualmente no escala. Envía a Loki + Grafana, Elasticsearch o un servicio gestionado. El formato estructurado de registros en JSON hace mucho más fácil la consulta que parsear CLF con awk. Control de acceso en registros brutos
• — los archivos de registro pueden contener parámetros de consulta con tokens, datos personales de usuarios y rutas internas. No los hagas accesibles para todos. Sé deliberado sobre los periodos de retención de registros si estás bajo GDPR o similares. No registra parámetros sensibles
• — si tu aplicación acepta tokens de autenticación o contraseñas como parámetros de URL (no debería, pero algunas APIs heredadas sí lo hacen), filtra esos parámetros en el nivel de registro antes de que lleguen al disco. — si su aplicación acepta tokens de autenticación o contraseñas como parámetros de URL (no debería hacerlo, pero algunas APIs legadas lo hacen), filtre esos datos al nivel de registro antes de que lleguen al disco.

También te puede interesar