{"id":21459,"date":"2026-09-16T15:03:59","date_gmt":"2026-09-16T13:03:59","guid":{"rendered":"https:\/\/webhosting.de\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/"},"modified":"2026-09-16T15:03:59","modified_gmt":"2026-09-16T13:03:59","slug":"optimizar-las-solicitudes-keepalive-de-nginx-ajuste-del-rendimiento-del-servidor-web","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/nginx-keepalive-requests-optimieren-webserver-performance-tuning\/","title":{"rendered":"Optimizaci\u00f3n de las solicitudes Keepalive de NGINX: m\u00e1ximo rendimiento del servidor web mediante un ajuste espec\u00edfico"},"content":{"rendered":"<p>Con <strong>nginx keepalive<\/strong> Reduzco los costes de establecimiento de conexi\u00f3n, minimizo los intercambios de datos iniciales y acelero notablemente los tiempos de respuesta. Los tiempos de espera ajustados de forma espec\u00edfica, los l\u00edmites de solicitudes por conexi\u00f3n y la reutilizaci\u00f3n de sockets de upstream proporcionan mejoras cuantificables en el rendimiento sin necesidad de nuevo hardware.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>Tiempos muertos<\/strong> Elegir con sensatez: el tiempo de inactividad debe ser tan breve como sea necesario y tan largo como resulte \u00fatil.<\/li>\n  <li><strong>Solicitudes<\/strong> Limitar por conexi\u00f3n: sockets duraderos, sin bloqueos.<\/li>\n  <li><strong>Grupos de upstream<\/strong> Activar: Conexiones persistentes con el backend por trabajador.<\/li>\n  <li><strong>Trabajador<\/strong> y ajustar las conexiones: suficientes ranuras para los clientes inactivos y activos.<\/li>\n  <li><strong>Monitoreo<\/strong> Establecer: supervisar la tasa de conexi\u00f3n, la latencia y los errores.<\/li>\n<\/ul>\n\n<h2>NGINX Keepalive: efectos y costes<\/h2>\n\n<p>Mantengo abiertas las conexiones TCP a prop\u00f3sito porque <strong>Apretones de manos<\/strong> son costosas y predominan en muchas solicitudes peque\u00f1as. Los sockets persistentes no solo ahorran RTT, sino que tambi\u00e9n suavizan la carga de la CPU, ya que la criptograf\u00eda para TLS se activa con menos frecuencia. Sin embargo, cada conexi\u00f3n abierta ocupa <strong>Recursos<\/strong>, como los descriptores de archivo y los b\u00faferes, a los que debo prestar atenci\u00f3n. El secreto est\u00e1 en encontrar el equilibrio: suficiente reutilizaci\u00f3n para garantizar la velocidad y suficiente \u00abpresupuesto\u00bb para nuevas conexiones en los picos de carga. Quien logre este equilibrio conseguir\u00e1 valores de TTFB constantemente bajos y una experiencia de usuario \u00e1gil.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-keepalive-optimierung-4271.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>HTTP\/2 y HTTP\/3: el multiplexado se une al \u00abkeepalive\u00bb<\/h2>\n\n<p>Con <strong>HTTP\/2<\/strong> y <strong>HTTP\/3<\/strong> Se reduce el n\u00famero de conexiones necesarias por cliente, ya que varios flujos se transmiten a trav\u00e9s de una misma l\u00ednea. No obstante, la funci\u00f3n \u00abKeepalive\u00bb sigue siendo importante: es necesario que al menos una conexi\u00f3n permanezca abierta de forma fiable; de lo contrario, la ventaja del multiplexado se esfuma debido a las frecuentes reconexiones.<\/p>\n<p>Presto atenci\u00f3n a los par\u00e1metros de inactividad espec\u00edficos de los protocolos modernos y me aseguro de que los valores se ajusten a los tiempos de espera de mis clientes. Para las pruebas, empiezo con valores moderados y los voy aumentando cuando la carga se estabiliza, hasta que la tasa de reconexiones disminuye y las latencias se mantienen constantes.<\/p>\n\n<pre><code>http {\n    # HTTP\/2: tiempo de inactividad para flujos abiertos pero no utilizados\n    http2_idle_timeout 60s;\n\n    # HTTP\/3\/QUIC: l\u00f3gica similar para conexiones basadas en UDP\n    http3_idle_timeout 60s;\n\n    # La reanudaci\u00f3n de TLS reduce el coste del protocolo de enlace en las nuevas conexiones\n    ssl_session_cache shared:SSL:50m;\n    ssl_session_timeout 1d;\n    ssl_session_tickets off;\n}\n<\/code><\/pre>\n\n<p>El multiplexado reduce el n\u00famero necesario de conexiones TCP\/QUIC paralelas, pero no la importancia de las <strong>tiempos de espera correctos<\/strong>. Quienes utilizan HTTP\/2\/3 suelen poder establecer tiempos de espera del cliente algo m\u00e1s amplios, ya que muchos recursos peque\u00f1os circulan por el mismo canal. Importante: hay que poder seguir midi\u00e9ndolos <em>Tiempo hasta el primer byte<\/em>, \u00edndices de error y flujos abiertos por conexi\u00f3n.<\/p>\n\n<h2>Configurar correctamente el \u00abclient keepalive\u00bb<\/h2>\n\n<p>En el caso de los clientes de navegador, gestiono la reutilizaci\u00f3n a trav\u00e9s de <strong>tiempo de espera de keepalive<\/strong> y <strong>keepalive_requests<\/strong>, para que los sockets permanezcan activos el tiempo suficiente sin bloquearse indefinidamente. Como punto de partida, utilizo un tiempo de espera de entre 30 y 60 segundos y entre 100 y 300 solicitudes por conexi\u00f3n; despu\u00e9s, lo ajusto en funci\u00f3n de las m\u00e9tricas. En este enlace se ofrece una explicaci\u00f3n detallada: <a href=\"https:\/\/webhosting.de\/es\/http-keepalive-timeout-server-performance-configuration\/\">Gu\u00eda sobre el tiempo de espera de Keepalive<\/a>, que explica las repercusiones en la latencia y los recursos del servidor. Los tiempos de espera m\u00e1s cortos son adecuados cuando hay un gran n\u00famero de llamadas breves, mientras que los plazos m\u00e1s largos resultan \u00fatiles en el caso de accesos peri\u00f3dicos a la API. Para empezar, establezco unos valores predeterminados claros y mido el efecto sobre las conexiones abiertas y los tipos de error.<\/p>\n\n<pre><code>http {\n    # Conexiones inactivas con el cliente\n    keepalive_timeout 60s;\n    # L\u00edmite m\u00e1ximo de solicitudes por conexi\u00f3n TCP\n    keepalive_requests 200;\n\n    # Opcional: desactivar Keep-Alive para determinados clientes (errores heredados)\n    # keepalive_disable msie6;\n}\n<\/code><\/pre>\n\n<h2>Keepalive de upstream en el proxy inverso<\/h2>\n\n<p>Entre NGINX y las aplicaciones de backend utilizo sockets upstream persistentes, ya que la conexi\u00f3n con PHP-FPM, Node.js o los servicios de Python tambi\u00e9n <strong>Latencia<\/strong> cuesta. Para ello, activo en el pool de upstream un n\u00famero adecuado de conexiones reutilizables por cada worker. Es importante utilizar HTTP\/1.1 en la direcci\u00f3n de salida y un encabezado \u201eConnection\u201c vac\u00edo; de lo contrario, la solicitud \u00abclose\u00bb del cliente interrumpe la persistencia del backend. Me baso en el n\u00famero de solicitudes simult\u00e1neas y configuro el pool de tal forma que apenas se produzcan nuevas conexiones. De este modo, se reduce el tiempo de conexi\u00f3n del backend y toda la cadena ofrece un rendimiento m\u00e1s \u00e1gil. <strong>Respuestas<\/strong>.<\/p>\n\n<pre><code>upstream backend {\n    server 127.0.0.1:9000;\n    keepalive 64; # N\u00famero de conexiones persistentes de upstream por trabajador\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/backend;\n        proxy_http_version 1.1;\n proxy_set_header Connection \"\";\n # Keepalive TCP para sockets de upstream a nivel del sistema operativo\n proxy_socket_keepalive on;\n    }\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_optimierung_miniature_4891.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionamiento del grupo y presupuesto de conexiones<\/h2>\n\n<p>Calculo los pools de forma realista: el n\u00famero de conexiones persistentes de origen se obtiene a partir de <strong>worker_processes \u00d7 keepalive<\/strong> por cada servidor de origen. Si se utilizan 8 trabajadores y un keepalive de 64, se mantienen abiertos hasta 512 sockets por servidor de origen, por cada instancia. Detr\u00e1s de un equilibrador de carga o con varios servidores de origen, esto puede sumar r\u00e1pidamente.<\/p>\n<p>Mi objetivo: disponer de suficientes sockets abiertos para que la mayor parte de las solicitudes <em>sin el nuevo Connect<\/em> se atiende, pero a\u00fan hay margen para picos. Superviso la m\u00e9trica \u201enuevas conexiones de salida por segundo\u201c y la reduzco hasta que un aumento adicional del tama\u00f1o del pool ya no suponga una mejora apreciable de la latencia.<\/p>\n<p>Tambi\u00e9n tengo en cuenta <strong>Equidad<\/strong>: Las piscinas demasiado grandes pueden perjudicar a los clientes que acaban de llegar, ya que las ranuras de los trabajadores quedan ocupadas por conexiones inactivas. Un l\u00edmite moderado con supervisi\u00f3n activa suele ser m\u00e1s r\u00e1pido que establecer valores m\u00e1ximos a ciegas.<\/p>\n\n<h2>Ajuste preciso: tiempos de espera y l\u00edmites de solicitudes<\/h2>\n\n<p>Combino el tiempo de espera y el l\u00edmite de solicitudes de tal forma que las conexiones se reutilicen de manera efectiva sin llegar al <strong>Esquiador de fondo<\/strong> . Los valores altos en ambos ejes minimizan las conexiones, pero aumentan el riesgo de que los sockets se cuelguen en caso de problemas de red. Los valores bajos garantizan conexiones frescas, pero requieren m\u00e1s intercambios de datos. Voy avanzando poco a poco, observo los errores y realizo ajustes a intervalos regulares. La siguiente tabla muestra rangos iniciales recomendados para diferentes patrones de uso y ofrece una visi\u00f3n general compacta <strong>Orientaci\u00f3n<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Escenario<\/th>\n      <th>tiempo de espera de keepalive<\/th>\n      <th>keepalive_requests<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Muchas visitas breves a la p\u00e1gina<\/td>\n      <td>10-30 s<\/td>\n      <td>100-300<\/td>\n      <td>Reutilizaci\u00f3n r\u00e1pida, bajo consumo en reposo<\/td>\n    <\/tr>\n    <tr>\n      <td>P\u00e1gina web t\u00edpica<\/td>\n      <td>60-120 s<\/td>\n      <td>200\u2013400<\/td>\n      <td>Un buen t\u00e9rmino medio para Assets y HTML<\/td>\n    <\/tr>\n    <tr>\n      <td>API con llamadas peri\u00f3dicas<\/td>\n      <td>60-120 s<\/td>\n      <td>300\u20131000<\/td>\n      <td>Mayor tasa de reutilizaci\u00f3n para los clientes<\/td>\n    <\/tr>\n    <tr>\n      <td>Servicios internos \/ Pasarelas<\/td>\n      <td>30-90 s<\/td>\n      <td>500\u20131000+<\/td>\n      <td>La constancia es m\u00e1s importante que las conexiones m\u00ednimas<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Ajuste de los trabajadores y conexiones<\/h2>\n\n<p>Puse <strong>procesos_trabajadores<\/strong> en \u00abauto\u00bb o en el n\u00famero de n\u00facleos de la CPU, y aseg\u00farate de que haya suficientes <strong>conexiones_trabajadores<\/strong> porque los sockets inactivos ocupan ranuras. Unos l\u00edmites demasiado bajos impiden que se acepten nuevas conexiones, aunque a\u00fan quede capacidad de CPU disponible. Quien utilice pools de keepalive grandes necesita suficientes descriptores y ranuras de eventos por cada worker. Una buena introducci\u00f3n la ofrece \u201e<a href=\"https:\/\/webhosting.de\/es\/escalabilidad-de-las-conexiones-de-los-trabajadores-de-nginx-para-miles-de-solicitudes-aumento-del-trafico\/\">Escalar las conexiones de los trabajadores<\/a>\u201c, que explica las relaciones entre eventos, conexiones y carga. Unos valores bien definidos garantizan que la reutilizaci\u00f3n en estado inactivo y las nuevas conexiones puedan coexistir.<\/p>\n\n<pre><code>worker_processes auto;\n\nevents {\n    worker_connections 4096;\n    # Opcional: reuseport puede mejorar la distribuci\u00f3n a nivel del kernel\n    # multi_accept on;\n}\n\nhttp {\n    keepalive_timeout 60s;\n    keepalive_requests 200;\n\n upstream backend {\n server 127.0.0.1:9000;\n keepalive 64;\n    }\n}\n<\/code><\/pre>\n\n<h2>Optimizaci\u00f3n del sistema operativo y de los sockets<\/h2>\n\n<p>Compruebo los l\u00edmites del sistema para que Keepalive pueda desarrollar todo su potencial. Un n\u00famero insuficiente de descriptores o colas de sockets demasiado limitadas provocan <strong>cuellos de botella artificiales<\/strong>. Adem\u00e1s de \u00abulimit\u00bb y \u00abworker_rlimit_nofile\u00bb, los l\u00edmites del n\u00facleo son fundamentales.<\/p>\n\n<pre><code># Valores de sysctl de ejemplo (ajustar con precauci\u00f3n y tras realizar pruebas)\nfs.file-max = 1000000\nnet.core.somaxconn = 65535\nnet.core.netdev_max_backlog = 16384\nnet.ipv4.ip_local_port_range = 1024 65000\nnet.ipv4.tcp_fin_timeout = 15\nnet.ipv4.tcp_tw_reuse = 1\nnet.ipv4.tcp_max_syn_backlog = 262144\n<\/code><\/pre>\n\n<p>Ajusto estos valores en funci\u00f3n del entorno: muchas conexiones de corta duraci\u00f3n se benefician de un rango de puertos m\u00e1s amplio y de tiempos FIN\/TIME_WAIT m\u00e1s cortos. En el caso del keepalive de upstream, reduzco <em>Neuconnects<\/em>, lo que reduce los picos de TIME_WAIT. Adem\u00e1s, tengo en cuenta <strong>NAT<\/strong>-Dispositivos entre el proxy y el backend: unos tiempos de espera en reposo demasiado agresivos en la red cortan las conexiones de forma imprevista. Un l\u00edmite moderado de peticiones por socket y los keepalives de TCP (<code>proxy_socket_keepalive on;<\/code>) evitan las conexiones \u201eobsoletas\u201c.<\/p>\n\n<h2>Configurar correctamente los encabezados y la versi\u00f3n HTTP<\/h2>\n\n<p>Presto atenci\u00f3n a <strong>HTTP\/1.1<\/strong> al backend, ya que Upstream-Keepalive solo funciona as\u00ed. Adem\u00e1s, elimino el control activo de conexiones mediante encabezados, para que NGINX gestione la persistencia de forma aut\u00f3noma. En el lado del cliente, dejo que Keep-Alive funcione seg\u00fan el est\u00e1ndar y limito su duraci\u00f3n mediante el tiempo de espera (timeout) y el l\u00edmite de solicitudes. Adem\u00e1s, compruebo los tiempos de espera de inactividad del backend y los configuro ligeramente por encima de los de NGINX para evitar errores de reinicio. Unos encabezados limpios garantizan la <strong>Reutilice<\/strong> sin cierres involuntarios.<\/p>\n\n<pre><code>Ejemplo de #: ubicaci\u00f3n de proxy con encabezados correctos\nlocation \/api\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx-keepalive-optimization-7123.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diferencias: HTTP Keep-Alive frente a TCP Keep-Alive<\/h2>\n\n<p>Hago una distinci\u00f3n estricta entre <strong>HTTP Keep-Alive<\/strong> (varias solicitudes HTTP por conexi\u00f3n) y <strong>TCP-Keepalive<\/strong> (Pruebas a nivel del sistema operativo para detectar terminales inactivos). Controlo el Keep-Alive de HTTP con <code>tiempo de espera de keepalive<\/code> y <code>keepalive_requests<\/code>, mientras que los \u00abkeepalives\u00bb de TCP, dependiendo de la pila, se realizan a trav\u00e9s de <code>proxy_socket_keepalive on;<\/code> y los par\u00e1metros del sistema. Para los backends que utilizan redes inestables, activo los \u00abkeepalives\u00bb de TCP para liberar m\u00e1s r\u00e1pidamente los sockets bloqueados.<\/p>\n\n<h2>Aplicaciones de larga duraci\u00f3n y casos especiales: WebSockets, SSE, gRPC<\/h2>\n\n<p>Los WebSockets y los eventos enviados por el servidor son <strong>Esquiador de fondo<\/strong>, que mantienen una conexi\u00f3n abierta durante mucho tiempo; en este caso, el \u00abReuse\u00bb cl\u00e1sico desempe\u00f1a un papel secundario. Yo me encargo de encontrar las opciones adecuadas <code>proxy_read_timeout<\/code> y prot\u00e9geme con <code>send_timeout<\/code> contra <em>Slowloris<\/em>-Efectos. En el caso de gRPC (basado en HTTP\/2), hay que tener en cuenta las consideraciones relativas al multiplexado; configuro los tiempos de espera por inactividad de tal forma que los flujos no se cierren innecesariamente.<\/p>\n\n<pre><code>location \/ws\/ {\n    proxy_pass http:\/\/backend;\n    proxy_http_version 1.1;\n    proxy_set_header Upgrade $http_upgrade;\n    proxy_set_header Connection \"upgrade\";\n    proxy_read_timeout 300s;\n    send_timeout 30s;\n}\n<\/code><\/pre>\n\n<h2>Seguimiento y m\u00e9tricas<\/h2>\n\n<p>Mido el \u00e9xito a trav\u00e9s de indicadores como la tasa de nuevas conexiones upstream, <strong>hora_de_conexi\u00f3n_arriba<\/strong> y el porcentaje de conexiones abiertas por trabajador. Una disminuci\u00f3n de las tasas de conexi\u00f3n, con un n\u00famero de solicitudes constante o en aumento, indica que la reutilizaci\u00f3n se est\u00e1 llevando a cabo con \u00e9xito. Los tiempos de espera o los reinicios de conexi\u00f3n an\u00f3malos se\u00f1alan tiempos de espera contradictorios entre NGINX y el backend. Adem\u00e1s, superviso la memoria, los descriptores de archivos y las colas de eventos bajo carga. Quien realice comprobaciones peri\u00f3dicas detectar\u00e1 las tendencias a tiempo y evitar\u00e1 costosas <strong>Fallas<\/strong>.<\/p>\n\n<h2>Mejoras en el registro para una mayor transparencia en la reutilizaci\u00f3n<\/h2>\n\n<p>Para obtener m\u00e1s informaci\u00f3n, ampl\u00edo el registro de acceso con datos sobre las conexiones. As\u00ed puedo ver con qu\u00e9 frecuencia se reutiliza una conexi\u00f3n TCP y c\u00f3mo evolucionan los tiempos de conexi\u00f3n.<\/p>\n\n<pre><code>log_format keepalive_fmt\n  '$remote_addr $host \"$request\" $status $body_bytes_sent '\n  '$request_time $upstream_connect_time '\n  'conn:$connection reqs:$connection_requests';\n\naccess_log \/var\/log\/nginx\/access_keepalive.log keepalive_fmt;\n<\/code><\/pre>\n\n<p>Analizo los valores de la mediana y de P95\/P99 de <em>hora_de_conexi\u00f3n_arriba<\/em> as\u00ed como la distribuci\u00f3n de <em>$_solicitudes_de_conexi\u00f3n<\/em>. Un aumento en el n\u00famero de repeticiones con una latencia estable indica que los grupos y los tiempos de espera se han seleccionado adecuadamente.<\/p>\n\n<h2>Obst\u00e1culos t\u00edpicos y soluciones<\/h2>\n\n<p>Las colas demasiado grandes ocupan ranuras de conexi\u00f3n mientras los nuevos clientes esperan, por lo que mantengo los tama\u00f1os moderados y los mido. Los diferentes tiempos de espera en inactividad entre el proxy y el backend provocan reinicios, as\u00ed que configuro el backend con un valor m\u00ednimamente superior a <strong>NGINX<\/strong>. Un \u201eConnection: close\u201c olvidado en el encabezado del proxy interrumpe la persistencia, por lo que vac\u00edo el encabezado de forma sistem\u00e1tica. La negociaci\u00f3n TLS puede suponer una carga para la CPU cuando se establecen muchas conexiones nuevas, lo que mitigo aumentando la proporci\u00f3n de reutilizaci\u00f3n. En caso de fallos espor\u00e1dicos de red, resulta \u00fatil establecer un l\u00edmite moderado de solicitudes por socket, de modo que las antiguas <strong>Sesiones<\/strong> No vivimos para siempre.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_keepalive_optimierung_4723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configuraciones pr\u00e1cticas<\/h2>\n\n<p>Para sitios web con mucho tr\u00e1fico, elijo un tiempo de espera corto y un l\u00edmite de solicitudes medio-alto, para que los recursos funcionen de forma eficiente. En el caso de las API con llamadas recurrentes, aumento el l\u00edmite para reducir a\u00fan m\u00e1s los handshakes TCP y TLS. Dimensiono los grupos de servidores de origen en funci\u00f3n de la paralelizaci\u00f3n prevista y los pruebo con tr\u00e1fico realista. Cada entorno se comporta de forma diferente, por lo que, tras realizar cambios, compruebo la latencia y los patrones de error. Dos ejemplos lo ilustran: <strong>Valores iniciales<\/strong>, que luego perfecciono con m\u00e9tricas.<\/p>\n\n<pre><code># Escenario 1: Sitio web con mucho tr\u00e1fico\nhttp {\n    keepalive_timeout 30s;\n    keepalive_requests 300;\n\n upstream app {\n server 127.0.0.1:8080;\n        keepalive 32;\n    }\n\n server {\n listen 443 ssl http2;\n Control del tiempo de inactividad de HTTP\/2 en #\n http2_idle_timeout 45s;\n    }\n}\n<\/code><\/pre>\n\n<pre><code>Escenario # 2: API con llamadas peri\u00f3dicas\nhttp {\n    keepalive_timeout 75s;\n    keepalive_requests 1000;\n\n    upstream api_backend {\n server 127.0.0.1:9001;\n keepalive 64;\n    }\n\n    server {\n listen 443 ssl http2;\n # Ventana de inactividad algo m\u00e1s larga para llamadas recurrentes\n http2_idle_timeout 75s;\n    }\n}\n<\/code><\/pre>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/serverraum-nginx-3721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Lista de comprobaci\u00f3n para la optimizaci\u00f3n iterativa<\/h2>\n\n<p>Empiezo con un an\u00e1lisis de la situaci\u00f3n actual: los patrones de tr\u00e1fico, los tiempos de respuesta y la tasa de errores marcan el ritmo. A continuaci\u00f3n, configuro el tiempo de espera del cliente y el l\u00edmite de solicitudes con valores iniciales s\u00f3lidos y activo los grupos de servidores upstream. Configuro los tiempos de espera de inactividad del backend un poco m\u00e1s altos que en NGINX, para evitar que se produzcan <strong>Restablecimientos<\/strong> aparecen. A continuaci\u00f3n, superviso las tasas de conexi\u00f3n, el tiempo de conexi\u00f3n y los sockets abiertos por trabajador. Quien quiera profundizar en el grado de reutilizaci\u00f3n encontrar\u00e1 sugerencias sobre <a href=\"https:\/\/webhosting.de\/es\/conexion-http-reutilizacion-keepalive-optimizacion-serverperf-boost\/\">Reutilizaci\u00f3n de conexiones<\/a> y l\u00edmites m\u00e1ximos razonables.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/nginx_keepalive_opt_5731.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Diagn\u00f3stico adicional: desajustes y comportamiento temporal<\/h2>\n\n<p>Cuando las conexiones se interrumpen aparentemente \u201esin motivo\u201c, busco <strong>Desajustes<\/strong> en la cadena: inactividad del cliente frente a tiempo de espera de NGINX frente a inactividad del backend y NAT\/gateways intermedios. Aumento ligeramente el tiempo de espera del backend por encima del valor de NGINX, compruebo los c\u00f3digos de reinicio en el registro de errores y observo si <em>hora_de_conexi\u00f3n_arriba<\/em> muestra picos. A menudo basta con un peque\u00f1o margen (por ejemplo, +10\u201320%) en el tiempo de espera del backend para eliminar los reinicios.<\/p>\n<p>Adem\u00e1s, tengo en cuenta que \u201e<em>acercamiento prolongado<\/em>\u201cFases de cierre: al cerrar una conexi\u00f3n, NGINX deja que los datos entrantes se descarguen brevemente, lo que ocupa recursos de los trabajadores. Un gran n\u00famero de cierres simult\u00e1neos puede bloquear eventos. En tales casos, calibro los intervalos de cierre y mantengo equilibrado el n\u00famero total de conexiones abiertas mediante valores de keepalive adecuados.\u00bb.<\/p>\n\n<h2>Resumen: El \u00abkeepalive\u00bb como factor clave para mejorar el rendimiento<\/h2>\n\n<p>Utilizo Keepalive de forma espec\u00edfica porque reduce los costes de establecimiento de conexi\u00f3n, disminuye la latencia y alivia la carga de la CPU. La combinaci\u00f3n de un tiempo de espera adecuado, un l\u00edmite de peticiones bien definido y unos grupos de servidores de origen adecuados aporta mejoras notables <strong>Velocidad<\/strong>. Sin un seguimiento, el potencial queda sin aprovechar, por lo que reviso continuamente los indicadores y ajusto los valores paso a paso. Quien necesite reservas adicionales debe prestar atenci\u00f3n al n\u00famero de trabajadores, a los slots de conexi\u00f3n y al tratamiento correcto de los encabezados. Las configuraciones profesionales, por ejemplo, en <strong>webhoster.de<\/strong>, aprovechan al m\u00e1ximo estas posibilidades y ofrecen servicios r\u00e1pidos y fiables.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprende a optimizar las solicitudes Keepalive de NGINX para mejorar notablemente el rendimiento de tus servidores web. Con ajustes pr\u00e1cticos para keepalive_timeout, keepalive_requests, Upstream-Keepalive y el ajuste de los workers, incluyendo un enfoque especial en el Keepalive de NGINX como factor clave.<\/p>","protected":false},"author":1,"featured_media":21452,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21459","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-plesk-webserver-plesk-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"110","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"nginx keepalive","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21452","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21459","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=21459"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21459\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21452"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21459"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21459"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21459"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}