Por qué las peticiones HTTP pueden bloquearse aunque haya suficientes recursos disponibles

Las peticiones HTTP pueden bloquearse aunque la CPU, la RAM y el ancho de banda parezcan abiertos porque los límites, filtros y colas invisibles surten efecto a lo largo de toda la cadena. Explico dónde Límites cómo funcionan y qué ajustes configuro para que las solicitudes vuelvan a funcionar sin problemas.

Puntos centrales

Antes de entrar en detalles, resumiré las causas más importantes y nombraré lo que miro primero. Estos puntos abarcan los cuellos de botella típicos que provocan atascos a pesar de los recursos libres. He mantenido deliberadamente la lista compacta para que puedas comprobar inmediatamente los puntos de partida. El punto clave es que cada capa tiene sus propias reglas que se aplican independientemente de la CPU y la RAM. Si conoces estas reglas, podrás resolver rápidamente muchos tiempos de espera „inexplicables“.

• Límites de trabajadoresDemasiados pocos procesos/hilos bloquean nuevas conexiones a pesar de haber CPU libre.
• Capa de seguridadLos filtros WAF/web bloquean patrones, métodos o clientes, a menudo sin una carga elevada.
• ConcurrenciaPHP-FPM, la base de datos y los proxies limitan las sesiones simultáneas.
• Keep-Alive/TimeoutsLas conexiones largas ocupan las franjas horarias, las solicitudes acaban en las colas.
• Filtro de clientesLas extensiones del navegador detienen las peticiones antes de que lleguen al servidor.

Estos puntos clave suelen bastar para comprobar el comportamiento de forma específica. A continuación, le mostraré cómo obtengo medidas específicas a partir de esto y Atascos limpiamente.

Por qué se bloquean las peticiones HTTP a pesar de haber recursos libres

Una solicitud pasa por varias capas: Cliente, red, filtro, servidor web, entorno de ejecución y base de datos. Cada capa aporta su propia Límites que tienen efecto independientemente de la CPU, RAM o ancho de banda. Si las ranuras de los trabajadores están ocupadas o hay reglas activas, la solicitud espera en una cola o se cancela inmediatamente. Este tiempo de espera no suele aparecer en absoluto en los diagramas de recursos clásicos. Esto es precisamente lo que lleva a la idea errónea de que el servidor está „vacío“, aunque no se esté respondiendo a las peticiones.

Capa de seguridad: WAF, filtros y reglas del proveedor

Muchos bloqueos se producen incluso antes de que se ejecute la aplicación. Los cortafuegos de aplicaciones web, los IDS/IPS y los filtros del lado del proveedor reconocen los patrones y los ralentizan o bloquean [1][5][9]. Parámetros sospechosos, protocolos antiguos o combinaciones de métodos bastan para provocar un Cerradura para encenderse. Desde el punto de vista del operador, esto parece un error del servidor, pero la decisión se toma „aguas arriba“. Por lo tanto, compruebo los registros del WAF y anoto el ID de la solicitud, la IP, la hora y el código de estado. Con estos datos, se puede identificar la regla y ajustarla de forma selectiva sin comprometer la seguridad.

Del lado del cliente: extensiones del navegador y bloqueadores locales

No todas las peticiones llegan al servidor. Los bloqueadores de anuncios, los gestores de contraseñas y los bloqueadores de scripts ya detienen las URL en el navegador; las DevTools muestran entonces „Las solicitudes al servidor han sido bloqueadas por una extensión“ [3][7]. Hago la prueba en una ventana privada, desactivo las extensiones y compruebo si el Solicitar se envió en absoluto. También ayuda a controlar las prioridades en el front end, por ejemplo con un Priorización de solicitudes para activos críticos. Así se evita que las llamadas de terceros no críticas retrasen las rutas importantes.

Método de comprensión y encaminamiento: 405, 403, 429

Un 405 „Método no permitido“ muestra claramente que el servidor reconoce el recurso pero no permite el método utilizado [5]. Del mismo modo, 403 indican filtros o derechos y 429 limitación de velocidad activa. En los registros, puedo reconocer rápidamente si una regla global permite métodos como PUT o DELETE o si un endpoint nunca ha sido implementado. A continuación, ajusto el enrutamiento, el controlador o la regla WAF. De este modo, el supuesto „bloqueo“ se disuelve en una corrección limpia de métodos y rutas.

Arquitectura del servidor web y límites de los trabajadores

Apache, NGINX, LiteSpeed y OpenLiteSpeed gestionan las conexiones de forma diferente [4]. Los factores decisivos son el número de procesos de trabajador, hilos y cómo los sockets keep-alive ocupan las ranuras. Si todos los workers están ocupados por conexiones largas, las nuevas peticiones se mueven a un Cola, aunque la CPU y la RAM parecen libres. Por lo tanto, analizo los estados de conexión y ajusto los trabajadores, los backlogs y los tiempos de espera. Los conocimientos previos sobre colas ayudan, por ejemplo con el tema de Cola de servidores y latencia.

capa	Límite pertinente	Síntoma típico	Nota de diagnóstico
Servidor web	Recuento de trabajadores/hilos	Colas, 503 bajo carga	Módulos de estado, comprobar estados de conexión
PHP-FPM/FastCGI	max_hijos / pm	Peticiones colgantes, alto tiempo hasta el primer byte	Registros FPM, registro lento, número de procesos
Base de datos	max_conexiones	Error „Demasiadas conexiones“	SHOW PROCESSLIST, Picos de conexión
WAF/Filtro	Firmas, métodos	403/405, mensajes de formulario rotos	Registros WAF, ID de aciertos de reglas
Equilibrador de carga	Límite de conexión por respaldo	Tiempos de respuesta incoherentes	LB-Stats, Backend-Salud

Concurrencia en PHP-FPM, base de datos y proxies

El procesamiento concurrente a menudo estalla primero en el entorno de ejecución. Si todos los PHP FPM workers están ocupados, no hay espacio disponible para nuevos scripts; las peticiones esperan aunque el CPU apenas funciona. La situación es similar para bases de datos con max_connections o para proxies con límites de conexión por backend. Primero optimizo la duración de las solicitudes individuales antes de aumentar los límites. De esta forma, acorto el tiempo de documento por slot y reduzco la probabilidad de que las colas crezcan.

Backends lentos y bloqueo de sesión PHP

Las consultas largas a bases de datos, las API externas o la E/S de archivos atascan a los trabajadores durante mucho más tiempo. El bloqueo de sesiones también puede ralentizar cadenas enteras, como los inicios de sesión en WordPress o los carritos de la compra. Compruebo si las peticiones paralelas al mismo ID de sesión se ejecutan consecutivamente en lugar de simultáneamente. Si es así, recurro al desbloqueo selectivo, reduzco los accesos de escritura críticos y sigo las instrucciones probadas de la página web Bloqueo de sesión PHP. Esto me permite liberar franjas horarias más rápidamente y reducir Tiempos de espera notable.

Tiempos de espera, keep-alive y estrategias de conexión

Los tiempos Keep-alive demasiado largos consumen recursos, mientras que los demasiado cortos generan handshakes y latencia. Elijo valores que se ajusten al perfil de tráfico y establezco límites para los tiempos de espera de cabecera, cuerpo y backend. Es importante fijar los tiempos de espera no sólo en la cabecera, el cuerpo y el backend. Servidor web pero estandarizado a lo largo de la cadena: proxy, app, base de datos. Además, evito el bloqueo por inactividad mediante una configuración y priorización HTTP/2/HTTP/3 más precisas. De este modo, las franjas horarias se mantienen disponibles sin que los clientes tengan que reconectarse constantemente.

Modelos de alojamiento: Compartido, VPS, Dedicado

El alojamiento compartido establece filtros tempranos y cuotas duras para que la plataforma siga siendo equitativa [1]. En los VPS, los proveedores aíslan CPU y RAM, pero mantienen límites para E/S, red o seguridad; las diferencias en rendimiento y monitorización son claras [10]. En los servidores dedicados, asumo toda la responsabilidad de la configuración del servidor web, la base de datos y el WAF. Las comparaciones muestran que las pilas modernas con HTTP/3, NVMe y protección DDoS ofrecen claras ventajas [2][6][11][8]. Los que necesitan un alto paralelismo se benefician de unas ventajas claramente documentadas Límites y apoyo, lo que ayuda con las unidades de reglas.

Análisis sistemático: paso a paso

Empiezo por la fuente: ¿Realmente DevTools está enviando la petición, o es una extensión [3][7] la que la está bloqueando? Luego miro los códigos de estado: 403/405/429/503 dan fuertes indicios de filtros, métodos o capacidad [5]. Al mismo tiempo, compruebo los registros del servidor web, la aplicación y el WAF para encontrar patrones y firmas recurrentes [1][9]. A continuación, compruebo el número de trabajadores, los parámetros FPM, las conexiones keep-alive y de base de datos y aumento los límites a modo de prueba con puntos de medición antes y después. Por último, simulo la carga, observo los cuellos de botella en tiempo real y verifico que el Colas loquero.

Buenas prácticas contra los bloqueos

Formulo objetivos de concurrencia por capa y establezco límites para amortiguar los picos de carga. El servidor web debe ajustarse al patrón de tráfico; los puntos de referencia ayudan en la selección y configuración [4]. Primero optimizo los backends lógicamente: consultas más rápidas, transacciones más cortas, menos secciones en serie. Mantengo unas normas de seguridad suficientemente estrictas contra los ataques, pero con excepciones para los legítimos Muestra. La supervisión no termina con la CPU/RAM: miro las conexiones, las colas, los tiempos de respuesta y los códigos de error para que los cuellos de botella sigan siendo visibles [6][11].

Notas prácticas: bloqueo de solicitudes de alojamiento

En los entornos compartidos, los bloqueos terminan a menudo antes que el espacio web real; el soporte necesita entonces datos específicos de las peticiones para ajustar las reglas [1]. En VPS, escalo gradualmente: más trabajadores, valores de keep-alive más apropiados y una supervisión más estrecha de la base de datos [10]. En mi propio hardware, decido el equilibrio de carga, las reglas WAF y los límites por backend. Los proyectos con acceso altamente paralelo se benefician de una configuración HTTP/2/HTTP/3 limpia y reservas claras para Consejos. Si espera crecer, planifique el cambio a tarifas más potentes al principio y ahórrese mucho esfuerzo de ajuste más adelante [2][6][10][11].

Límites de la red y el núcleo: acumulación, puertos y descriptores

Además del servidor web y la aplicación, el núcleo limita cuántas conexiones pueden llegar, establecerse y gestionarse al mismo tiempo. Primero compruebo el Lista de atrasosLa cola de aceptación: Aunque el servidor web tenga muchos trabajadores, la cola de aceptación puede ser corta. La interacción entre la aplicación (listen backlog), el kernel (somaxconn) y SYN backlog (tcp_max_syn_backlog) determina si las conexiones permanecen en la cola o son descartadas. Los síntomas son el aumento de los tiempos de conexión y retransmisiones, con una baja utilización de la CPU. Comparo los valores y mido la utilización real de las colas para evitar caídas.

Otro clásico es el mesa conntrack para configuraciones NAT/firewall. Si está lleno, las conexiones desaparecen „sin dejar rastro“; la aplicación nunca ve una petición. Lo reconozco por los mensajes en el registro del sistema y los tiempos de espera repentinos durante los picos de carga. Las contramedidas son: tamaño adecuado de la tabla, tiempos de espera realistas para los protocolos, menos rutas NAT innecesarias y keep-alives eficientes que reutilicen las conexiones de forma razonable.

También compruebo el número de Descriptores de archivos (ulimit -n). Si muchos sockets y archivos simultáneos alcanzan los límites restrictivos, Accept falla („demasiados archivos abiertos“) y se acumulan nuevas peticiones delante de él. La solución suele ser trivial: establezca los límites de archivos no para el servidor web, el proxy y la base de datos a un nivel saludable, y hágalos persistentes, no sólo interactivos.

En configuraciones fuertemente paralelas observo Alcance del puerto efímero y TIME_WAIT-estados. Especialmente detrás de pasarelas NAT, los puertos de origen disponibles se agotan cuando se establecen conexiones cortas en masa. Por ello, confío en la reutilización de conexiones (keep-alive, HTTP/2/3), reduzco las conexiones cortas innecesarias y ajusto cuidadosamente el manejo de TIME_WAIT sin arriesgar la estabilidad. El resultado: menos agotamiento de puertos y tiempos de conexión más estables bajo carga.

En la tarjeta de red, compruebo la longitud de las colas, los ajustes de descarga y la distribución de IRQ. Las interrupciones distribuidas de forma desigual o las colas sobrecargadas generan picos de latencia que no se aprecian en los registros de la aplicación. Con un equilibrado balanceo de IRQ y una configuración sensata de Qdisc (palabra clave Bufferbloat) Reduzco la latencia sin restringir el ancho de banda.

HTTP/2 y HTTP/3: Utilizar correctamente la multiplexación

La multiplexación resuelve muchos problemas, pero conlleva nuevos límites: Número máximo de flujos, La ventana de control de flujo y los tiempos muertos se aplican por conexión. Si el valor de flujos simultáneos es demasiado bajo, las nuevas peticiones se „cuelgan“ aunque la conexión TCP o QUIC esté establecida. Por ello, compruebo cuántos recursos críticos deben cargarse en paralelo y ajusto cuidadosamente los límites de flujos. Al mismo tiempo, presto atención a unos límites razonables de Control del caudal-para que las respuestas grandes no sean estranguladas.

El multiplexor HTTP/2 sobre TCP puede sufrir de bloqueo de cabecera en caso de pérdida de paquetes; HTTP/3 sobre QUIC evita esto, pero requiere configuraciones TLS/ALPN limpias y reglas de manejo de rutas estables. Yo pruebo ambas rutas y selecciono los protocolos que se ajustan al perfil de tráfico. Importante: no confíes ciegamente en la priorización; los navegadores y los servidores la interpretan de forma diferente. Me centro en las rutas críticas y compruebo si las prioridades funcionan realmente y si los huecos no están siendo ocupados por flujos secundarios de larga duración.

CORS, vuelos previos y límites de cabecera/cuerpo

No todos los errores 4xx proceden del servidor. Infracciones CORS se producen en el navegador y aparecen en la consola, no en el registro de acceso. Compruebo si las solicitudes de verificación previa (OPTIONS) se responden correctamente y si los WAF/proxies permiten este método. Si faltan cabeceras como Access-Control-Allow-Methods/-Headers, el navegador „bloquea“ la respuesta, sin carga para el servidor.

Otro cuello de botella: Tamaños de cabecera y galleta. Cookies sobrecargadas, muchas cabeceras Vary o grandes líneas referer conducen a errores 431 o caídas silenciosas debido a los límites del buffer. Limito el lastre de las cookies, consolido las cabeceras y establezco tamaños de búfer coherentes a lo largo de la cadena. Para las cargas, presto atención a los límites del cuerpo, a la gestión de 100 continuos y a la coherencia de los tamaños de búfer. Codificación por trozos-Soporte para todos los proxies. Si los límites de cuerpo y subida no coinciden, los clientes esperan una liberación que nunca llega -las peticiones parecen „colgarse“.

DNS y TLS: los apretones de manos como latencia oculta

La resolución DNS y la negociación TLS son puntos ciegos frecuentes. Múltiples cadenas CNAME, resolvedores lentos o desajustes IPv6/IPv4 prolongan el tiempo de inicio sin utilizar CPU. Reduzco los saltos DNS innecesarios, establezco TTL razonables y aseguro rutas de resolución rápidas. En cuanto a TLS, compruebo las cadenas de certificados, los conjuntos de cifrado activados, el grapado OCSP y la reanudación de la sesión. Un apretón de manos ALPN limpio evita los downgrades a HTTP/1.1, que ejercen una mayor presión sobre las ranuras keep-alive. Resultado: menor tiempo hasta el primer byte y paralelismo más estable, especialmente en redes móviles.

CDN/Edge: almacenamiento en caché, límites de velocidad y reputación IP

Entre el cliente y el origen, las CDN, los proxies inversos y los sistemas de protección DDoS deciden sobre Alcantarilla y el acelerador. Compruebo si las rutas críticas se almacenan en caché correctamente (stale-while-revalidate, stale-if-error) y si las cachés negativas retienen los errores más tiempo del necesario. Los límites de velocidad, la gestión de bots y la reputación de IP pueden reducir el tráfico legítimo, sobre todo en redes compartidas o con mucho acceso a API. Segmento el tráfico (por ejemplo, API frente a activos), defino claves de caché claras y desactive reglas de forma selectiva para clientes de confianza. Esto alivia la carga de Origin y evita que las colas de la CDN crezcan mientras el servidor parece „infrautilizado“.

Contenedores y orquestación: cgroups, Ingress y conntrack

En recipientes aplicar Límites del cgrupo para CPU, RAM, pids y archivos. Una cuota de CPU demasiado ajustada provoca estrangulamiento: los procesos esperan tiempo de CPU aunque el host esté libre. Compruebo las cuotas y me aseguro de que los pods de entrada/proxy tienen suficientes descriptores de archivos y buffers. En Kubernetes, compruebo los tiempos de espera de entrada, las sondas de disponibilidad/liviandad y las implementaciones de servicio (IPVS), porque las sondas o los tiempos de espera defectuosos generan latencia en zigzag y reinicios innecesarios.

Un cuello de botella que a menudo se pasa por alto es el Capacidad NAT/conntrack por nodo. Muchas conexiones de corta duración (por ejemplo, salidas a API externas) llenan la tabla conntrack, y luego las peticiones „desaparecen“ en la red. Escalo la tabla, establezco tiempos de espera realistas y agrupo las llamadas externas para que se creen menos conexiones nuevas. Planifico los PodDisruptionBudgets, las rolling updates y el escalado HPA de tal forma que no se deduzca capacidad del planificador en horas punta - de lo contrario se forman colas, aunque la app teóricamente tendría suficientes trabajadores.

Observabilidad: correlación, rastreo y métricas significativas

Para encontrar bloqueos rápidamente, necesito Correlación continua. Asigno identificadores de solicitud (por ejemplo, traceparent) al edge, al servidor web, a la aplicación y a la base de datos y los escribo en los registros. Esto me permite ver si una solicitud falla en el WAF, está esperando en el servidor web, está atascada en la cola del FPM o está bloqueada en la base de datos. Trabajo con Histogramas en lugar de valores medios puros y controlo la latencia P95/P99, las conexiones abiertas, la cola de aceptación, la longitud de la cola FPM, las sesiones activas de la base de datos y los códigos de error del backend. También utilizo comprobaciones sintéticas para separar claramente los efectos del lado del cliente de los del lado del servidor.

Para las anomalías utilizo un Desglose-El procedimiento: primero los logs de edge/WAF, luego el balanceador de carga, luego los accesos/errores del servidor web, luego los logs de app y FPM y finalmente los logs de DB y sistema. Esta ruta me muestra exactamente dónde se pierde el tiempo y en qué límite se detiene la solicitud. Con métricas específicas por capa, evito las corazonadas y reduzco drásticamente el tiempo hasta la causa raíz.

Guía y lista de control de la puesta a punto

En la práctica, tengo un libro de jugadas compacto que adapto al entorno:

• Reproducibilidad: Anote el escenario (ruta, método, tamaño, cliente), la fecha y hora de registro y los ID.
• Comprobar capa por capaNavegador/Extensiones, CORS/Preflight, WAF-Hits, LB-Stats, Webserver-Status, FPM-Queue, DB-Active/Locks.
• Hacer visibles las colasBacklog Accept/SYN, cola de escucha FPM, backlog proxy, pool de conexiones DB.
• Sincronizar límitesWorker/threads, somaxconn, nofile, max_connections, stream limits for H2/H3, body/header limits, timeouts.
• Reducir el tiempo de ocupaciónAcelere las consultas, evite los bloqueos de sesión, reduzca la E/S, comprima las respuestas y guárdelas en caché de forma razonable.
• Armonizar las estrategiasDuración Keep-Alive, parametrización HTTP/2/3, priorización de rutas críticas.
• Ajustar la seguridadExclusión selectiva de reglas WAF en lugar de debilitamiento global; registro con identificadores de aciertos.
• EscalaDefina la concurrencia por turno, realice pruebas de carga, mida las reservas, aumente los límites sólo después de la optimización.
• FallbacksDisyuntor para backends lentos, política de reintentos con jitter, „stale-if-error“ para activos críticos.

Brevemente resumido

Las peticiones bloqueadas con CPU y RAM libres suelen deberse a límites, filtros y estrategias de conexión, no a una falta de rendimiento. Primero compruebo dónde se detiene la solicitud: navegador, WAF, servidor web, runtime o base de datos. Luego reduzco al mínimo los tiempos de ocupación por ranura, elimino las Cerraduras y establezco tiempos de espera realistas. Mantengo la seguridad alta, ajusto las reglas contra falsas alarmas y recojo pruebas en los registros. Con este enfoque, las peticiones HTTP siguen siendo accesibles de forma fiable, incluso cuando el tráfico aumenta y cada segundo cuenta.