{"id":20722,"date":"2026-08-17T08:35:37","date_gmt":"2026-08-17T06:35:37","guid":{"rendered":"https:\/\/webhosting.de\/nginx-worker-connections-skalierung-tausender-requests-trafficboost\/"},"modified":"2026-08-17T08:35:37","modified_gmt":"2026-08-17T06:35:37","slug":"escalabilidad-de-las-conexiones-de-los-trabajadores-de-nginx-para-miles-de-solicitudes-aumento-del-trafico","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/nginx-worker-connections-skalierung-tausender-requests-trafficboost\/","title":{"rendered":"Conexiones de los trabajadores de NGINX: escalabilidad de miles de solicitudes para un rendimiento m\u00e1ximo del alojamiento"},"content":{"rendered":"<p>Escalo los trabajadores de Nginx de forma espec\u00edfica para gestionar miles de solicitudes simult\u00e1neas con un bajo <strong>Latencia<\/strong> para su funcionamiento. La clave reside en una combinaci\u00f3n equilibrada de worker_processes, worker_connections, descriptores de archivo y <strong>Eventos<\/strong>.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<ul>\n  <li><strong>Capacidad<\/strong> = worker_processes \u00d7 worker_connections; en el caso de un proxy inverso, a menudo se trata de la conexi\u00f3n del cliente y la conexi\u00f3n upstream <strong>duplicado<\/strong>.<\/li>\n  <li><strong>Descriptores de archivos<\/strong> (worker_rlimit_nofile, ulimit) en funci\u00f3n de la carga de conexiones prevista <strong>ascensor<\/strong>.<\/li>\n  <li><strong>Eventos<\/strong>-Bloqueo con epoll, multi_accept y colas de espera del n\u00facleo ante una carga elevada <strong>recortar<\/strong>.<\/li>\n  <li><strong>Monitoreo<\/strong> mediante stub_status y pruebas de carga para iteraciones <strong>Personalizaci\u00f3n<\/strong>.<\/li>\n  <li><strong>Escala<\/strong> Combinar en vertical y en horizontal, configuraci\u00f3n <strong>desacoplar<\/strong>.<\/li>\n<\/ul>\n\n<h2>Arquitectura de NGINX: Master, Worker y eventos<\/h2>\n<p>NGINX se basa en un proceso maestro que inicia varios procesos de trabajo y los gestiona de forma eficiente con <strong>Eventos<\/strong> se gestiona. En lugar de hilos por solicitud, cada trabajador procesa numerosas conexiones de forma no bloqueante mediante un modelo basado en eventos con un bajo <strong>Sobrecarga<\/strong>. Establezco la directiva `worker_processes` en \u00abauto\u00bb para que NGINX aproveche los n\u00facleos de la CPU y cada unidad disponga de su propio proceso de trabajo. De este modo, distribuyo mejor las conexiones entrantes y mantengo la latencia bajo control durante los picos de carga. <strong>bajo<\/strong>. Para profundizar en la planificaci\u00f3n de los procesos, te remito a <a href=\"https:\/\/webhosting.de\/es\/configuracion-optima-de-los-procesos-de-trabajo-de-nginx-para-mejorar-el-rendimiento\/\">Optimizar los procesos de los trabajadores<\/a>, ya que una paralelizaci\u00f3n correcta determina la capacidad de conexi\u00f3n viable. Es fundamental que el par\u00e1metro \u00abworker_connections\u00bb se ajuste adecuadamente para cada trabajador, de modo que la multiplicaci\u00f3n por el n\u00famero de procesos d\u00e9 como resultado el valor esperado <strong>Carga m\u00e1xima<\/strong> cubre.<\/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\/08\/nginx-worker-rechenzentrum-7421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>F\u00f3rmula de capacidad: worker_processes \u00d7 worker_connections<\/h2>\n<p>Calculo la capacidad aproximada multiplicando worker_processes por worker_connections, aunque las solicitudes proxy suelen ocupar dos conexiones por cada acceso de usuario, lo que reduce a la mitad el n\u00famero efectivo. <strong>puede<\/strong>. Muchas instalaciones est\u00e1ndar comienzan con 512 conexiones por trabajador, lo que a menudo resulta insuficiente para las cargas de trabajo en producci\u00f3n <strong>es<\/strong>. Los valores iniciales m\u00e1s habituales oscilan normalmente entre 1024 y 4096, y dependen del perfil de tr\u00e1fico y del hardware. Yo calculo con un margen de seguridad, es decir, al menos el doble de la carga m\u00e1xima medida, para poder gestionar con seguridad los picos de tr\u00e1fico <strong>amortiguar<\/strong>. Sigue siendo importante la validaci\u00f3n mediante pruebas y m\u00e9tricas en tiempo real, para que las cifras no se conviertan en un mero juego te\u00f3rico <strong>convertirse en<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Escenario<\/strong><\/th>\n      <th><strong>procesos_trabajadores<\/strong><\/th>\n      <th><strong>conexiones_trabajadores<\/strong><\/th>\n      <th><strong>M\u00e1ximo te\u00f3rico:.<\/strong><\/th>\n      <th><strong>Efectivo (proxy)<\/strong><\/th>\n      <th><strong>FD por trabajador<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>P\u00e1gina web peque\u00f1a<\/td>\n      <td>2<\/td>\n      <td>1024<\/td>\n      <td>2048<\/td>\n      <td>~1024<\/td>\n      <td>\u22651024<\/td>\n    <\/tr>\n    <tr>\n      <td>API de carga media<\/td>\n      <td>4<\/td>\n      <td>2048<\/td>\n      <td>8192<\/td>\n      <td>~4096<\/td>\n      <td>\u22652048<\/td>\n    <\/tr>\n    <tr>\n      <td>Horarios de mayor afluencia en la tienda<\/td>\n      <td>8<\/td>\n      <td>4096<\/td>\n      <td>32768<\/td>\n      <td>~16384<\/td>\n      <td>\u22654096<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>HTTP\/1.1, HTTP\/2 y TLS: repercusiones en los trabajadores y la latencia<\/h2>\n<p>Los protocolos determinan el perfil de conexi\u00f3n. Con HTTP\/1.1, suelo observar muchas conexiones TCP simult\u00e1neas por cliente, mientras que HTTP\/2 las reduce a unos pocos flujos, que, en cambio, est\u00e1n m\u00e1s saturados. <strong>paquetes<\/strong>. Esto ahorra descriptores de archivo, pero traslada la carga a los b\u00faferes y a la gesti\u00f3n de prioridades. Con TLS, me aseguro de reutilizar las sesiones para que no haya que realizar costosos handshakes en cada solicitud <strong>reducir la velocidad<\/strong>. Una cach\u00e9 de sesiones compartida y unos tiempos de espera adecuados reducen los picos de carga de la CPU. Adem\u00e1s, no configuro el valor de \u00abkeepalive_requests\u00bb demasiado bajo, para que las conexiones de larga duraci\u00f3n puedan aportar sus ventajas <strong>reproducir<\/strong>. Para HTTP\/2, calculo una mayor concurrencia por conexi\u00f3n y me aseguro de que los b\u00faferes de env\u00edo y recepci\u00f3n sean lo suficientemente grandes, sin consumir memoria <strong>desperdiciar<\/strong>. En el caso de tr\u00e1fico mixto, realizo una planificaci\u00f3n conservadora y verifico los efectos por variante de protocolo en el <strong>Prueba<\/strong>.<\/p>\n\n<h2>Configurar correctamente los descriptores de archivo y ulimit<\/h2>\n<p>Cada conexi\u00f3n necesita al menos un descriptor de archivo; en el caso de los proxies inversos, a menudo se necesitan dos, por lo que unos valores bajos de ulimit suponen un gran <strong>L\u00edmites<\/strong> Configurar. Aumento el valor de `worker_rlimit_nofile` de tal forma que sea posible alcanzar `worker_processes \u00d7 worker_connections` y que quede margen para los registros, los sockets y las cach\u00e9s. A nivel de sistema, ajusto los archivos `limits.conf` y `fs.file-max` para que el sistema operativo permita el n\u00famero previsto de archivos abiertos y no se agote prematuramente <strong>frenos<\/strong>. Mediante \u00abulimit -n\u00bb y el par\u00e1metro de Systemd (LimitNOFILE), compruebo si la configuraci\u00f3n se mantiene y se adapta a NGINX. Quien ignore este ajuste, experimentar\u00e1, a pesar de un valor elevado de \u00abworker_connections\u00bb, conexiones rechazadas de forma repentina y un aumento de <strong>Latencias<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx_worker_connections_3894.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ajuste fino del bloque de eventos: epoll, multi_accept, backlogs<\/h2>\n<p>En Linux utilizo epoll, ya que este mecanismo gestiona de forma eficiente un gran n\u00famero de conexiones mediante <strong>Eventos<\/strong> gestiona. Con \u00abmulti_accept on\u00bb, un trabajador acepta varias conexiones nuevas por evento, lo que suaviza los picos de carga y reduce los retrasos en la aceptaci\u00f3n <strong>disminuye<\/strong>. Aumento los par\u00e1metros del kernel, como net.core.somaxconn y net.ipv4.tcp_max_syn_backlog, seg\u00fan sea necesario, para evitar que las colas de aceptaci\u00f3n se desborden durante las oleadas de tr\u00e1fico. Las optimizaciones de TIME_WAIT, como tcp_tw_reuse, reducen los cuellos de botella en los puertos y mantienen la curva de rendimiento. <strong>alta<\/strong>. Para obtener informaci\u00f3n m\u00e1s detallada sobre la ejecuci\u00f3n en paralelo y las colas, merece la pena echar un vistazo a <a href=\"https:\/\/webhosting.de\/es\/threadpool-servidor-web-apache-nginx-litespeed-optimizacion-configuracion\/\">Optimizaci\u00f3n del grupo de subprocesos<\/a>, aunque NGINX funcione principalmente por eventos y, por lo tanto, sea muy eficiente <strong>a escala<\/strong>.<\/p>\n\n<h2>C\u00f3mo distribuir correctamente los sockets de lista: reuseport, backlog y accept_mutex<\/h2>\n<p>Cuando hay muchas conexiones simult\u00e1neas, escalo activamente la ruta de recepci\u00f3n. Con <strong>reuseport<\/strong> Cada worker recibe su propio socket de escucha; de este modo, se elimina la competencia en la funci\u00f3n \u00abaccept\u00bb y la carga se distribuye de forma equitativa entre todos los n\u00facleos. Establezco expl\u00edcitamente el \u00ablisten-backlog\u00bb para absorber picos de tr\u00e1fico breves. En esta configuraci\u00f3n, el `accept_mutex` ya no es necesario. Sin embargo, sin `reuseport`, el `accept_mutex` <strong>ayudar<\/strong>, para mitigar los efectos de manada en Accept. Importante: los tama\u00f1os de la cola de espera en NGINX y el kernel (somaxconn) deber\u00edan <strong>encajar<\/strong>, de lo contrario, el efecto se desvanecer\u00e1.<\/p>\n<pre><code>events {\n    use epoll;\n    worker_connections 4096;\n    # accept_mutex on;   # con reuseport, normalmente no es necesario\n}\n\nserver {\n    listen 443 ssl http2 reuseport backlog=65535;\n    # ...\n}\n<\/code><\/pre>\n<p>Adem\u00e1s, asigno los trabajadores a los n\u00facleos de la CPU cuando es necesario (worker_cpu_affinity), para que las l\u00edneas de cach\u00e9 y la carga de IRQ se mantengan estables. En entornos con una fuerte arquitectura NUMA, esto reduce el <strong>Tr\u00e1fico transversal<\/strong> en la memoria.<\/p>\n\n<h2>Proxy inverso, servidores de origen y Keep-Alive<\/h2>\n<p>Como proxy inverso, NGINX suele mantener dos conexiones por cada solicitud: una con el cliente y otra con el backend, lo que permite una planificaci\u00f3n realista de la capacidad <strong>doble<\/strong> es importante. Activo Keep-Alive de forma adecuada para que las conexiones upstream puedan reutilizarse y la sobrecarga por solicitud <strong>disminuye<\/strong>. De este modo, reduzco la carga sobre PHP-FPM, el servidor de aplicaciones o los microservicios y consigo ranuras libres para nuevas sesiones de usuario. El equilibrio entre los tiempos de espera, el tiempo de inactividad y la reutilizaci\u00f3n determina la eficacia con la que se reciclan las conexiones <strong>convertirse en<\/strong>. Quien quiera consultar informaci\u00f3n b\u00e1sica al respecto, la encontrar\u00e1 en <a href=\"https:\/\/webhosting.de\/es\/http-conexiones-persistentes-utilizacion-del-servidor-web-rendimiento-red\/\">Conexiones persistentes<\/a> Consejos pr\u00e1cticos sobre la utilizaci\u00f3n de la red y c\u00f3mo mejorar el rendimiento de la red<strong>Utilice<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/nginx-worker-connections-scalability-2941.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Grupos de upstream, tiempos de espera y reintentos<\/h2>\n<p>Para que los \u00abworkers\u00bb no tengan que esperar a backends lentos, utilizo tiempos de espera reducidos y reintentos bien dosificados. Mantengo los grupos de \u00abkeepalive\u00bb de upstream lo suficientemente grandes como para que las conexiones se mantengan activas, pero no tan grandes como para que los descriptores de archivo inactivos ocupen memoria y ranuras <strong>vincular<\/strong>. Limito los reintentos a unos pocos intentos y solo cambio de ruta en caso de errores de transporte evidentes; as\u00ed evito el efecto \u00abthundering herd\u00bb ante breves interrupciones del backend.<\/p>\n<pre><code>upstream app_backend {\n    server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;\n    server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;\n    keepalive 64;  Conexiones upstream reutilizables #\n}\n\nserver {\n    location \/ {\n proxy_pass http:\/\/app_backend;\n proxy_connect_timeout   2s;\n        proxy_read_timeout 15s;\n proxy_send_timeout 15s;\n proxy_next_upstream     error timeout http_502 http_503;\n proxy_next_upstream_tries 2;\n    }\n}\n<\/code><\/pre>\n<p>Al mismo tiempo, ajusto los par\u00e1metros de Keep-Alive (tiempos de espera, solicitudes por conexi\u00f3n) para liberar r\u00e1pidamente los recursos de los clientes que rara vez est\u00e1n activos <strong>dar a conocer<\/strong>.<\/p>\n\n<h2>Planificar la escalabilidad de forma adecuada: combinar la escalabilidad vertical y horizontal<\/h2>\n<p>Para gestionar grandes vol\u00famenes de tr\u00e1fico, prefiero combinar el escalado vertical y el horizontal en <strong>Considerar<\/strong>. En cuanto a la escalabilidad vertical, utilizo m\u00e1s n\u00facleos de CPU, m\u00e1s RAM, discos SSD r\u00e1pidos y una configuraci\u00f3n de red optimizada para que cada worker funcione con fluidez <strong>funciona<\/strong>. Para la escalabilidad horizontal, utilizo nodos NGINX sin estado, una configuraci\u00f3n gestionada de forma centralizada y un registro distribuido, de modo que la capacidad total aumente de forma lineal <strong>crece<\/strong>. Las cach\u00e9s locales y las pol\u00edticas bien definidas a trav\u00e9s de Maps o la API permiten implementar los cambios r\u00e1pidamente. Esta separaci\u00f3n reduce los efectos secundarios y ayuda a gestionar nuevos patrones de tr\u00e1fico sin necesidad de realizar modificaciones en cada nodo. <strong>servir<\/strong>.<\/p>\n\n<h2>Perspectiva del alojamiento web: latencia, \u00edndices de error y experiencia del usuario<\/h2>\n<p>Un n\u00famero insuficiente de \u00abworker_connections\u00bb provoca que se rechacen conexiones, se produzcan tiempos de espera y un peor <strong>Experiencia del usuario<\/strong>. Las aplicaciones din\u00e1micas, como los CMS o las tiendas online, lo notan de inmediato, ya que cada visita a una p\u00e1gina genera varias solicitudes al backend y los slots se agotan m\u00e1s r\u00e1pido <strong>corto<\/strong> Por eso empiezo con valores moderados, como 1024 o 2048 por trabajador, y los voy aumentando gradualmente bas\u00e1ndome en mediciones reales. Al mismo tiempo, mantengo el rendimiento de los servicios de origen y me aseguro de que haya suficientes descriptores de archivo para que no se produzcan <strong>L\u00edmites<\/strong> aplicar. Las pruebas de rendimiento demuestran que las plataformas cuidadosamente optimizadas ofrecen ventajas reales en este \u00e1mbito y gestionan de forma fiable los picos de tr\u00e1fico <strong>interceptar<\/strong>.<\/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\/08\/nginx_worker_connections_performance_2394.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Memoria, almacenamiento en b\u00fafer y rutas de E\/S<\/h2>\n<p>Cada conexi\u00f3n ocupa memoria RAM para metadatos y b\u00faferes. Ajusto los valores de `proxy_buffers`, `client_body_buffer_size` y `large_client_header_buffers` de manera que quepan las solicitudes t\u00edpicas, sin destinar de forma generalizada demasiada RAM a los casos at\u00edpicos. <strong>vincular<\/strong>. En el caso de los contenidos est\u00e1ticos, \u00absendfile\u00bb y \u00abtcp_nopush\u00bb aceleran la entrega, mientras que \u00abtcp_nodelay\u00bb es adecuado para respuestas breves en las que la latencia es un factor cr\u00edtico <strong>Importante<\/strong> . Si los activos se encuentran en un almacenamiento m\u00e1s lento, \u00abaio threads\u00bb junto con \u00abthread_pool\u00bb ayudan a mitigar los efectos de bloqueo. Con \u00abopen_file_cache\u00bb reduzco los accesos a los archivos y las llamadas a \u00abstat()\u00bb, pero hay que tener en cuenta la necesidad adicional de descriptores de archivo (FD). Guardo los registros en b\u00fafer (access_log \u2026 buffer=\u2026 flush=\u2026), para que los picos de E\/S no afecten a los tiempos de respuesta <strong>influir<\/strong>.<\/p>\n\n<h2>Equilibrio entre seguridad y rendimiento de TLS<\/h2>\n<p>Los handshakes TLS consumen muchos recursos de la CPU. Combino la reutilizaci\u00f3n de sesiones con par\u00e1metros de clave moderados y activo optimizaciones acumulables, como cach\u00e9s de sesi\u00f3n y tickets, siempre que sea viable desde el punto de vista operativo <strong>ajuste<\/strong>. El equilibrio \u00f3ptimo entre seguridad y rendimiento mantiene estables las latencias sin sacrificar la calidad del cifrado. Bajo una carga m\u00e1s elevada, observo por separado los percentiles 95 y 99, ya que, de lo contrario, los picos de TLS quedar\u00edan ocultos tras los valores medios <strong>ocultar<\/strong>. HTTP\/2 reduce el n\u00famero de conexiones, pero exige un tratamiento cuidadoso del control de flujo y la compresi\u00f3n de encabezados para mantener bajo control los perfiles de CPU y memoria <strong>conservar<\/strong>.<\/p>\n\n<h2>Resiliencia ante la sobrecarga: l\u00edmites y liberaci\u00f3n gradual<\/h2>\n<p>Para mantener la latencia, es necesario realizar una <strong>Modelado<\/strong> Imprescindible en momentos de m\u00e1xima carga. Con \u00ablimit_conn\u00bb limito el n\u00famero de conexiones paralelas por clave (por ejemplo, IP o sesi\u00f3n), mientras que \u00ablimit_req\u00bb modera las picos de carga y protege los backends frente a las operaciones s\u00edncronas <strong>Asaltar<\/strong>. A\u00edslo los puntos cr\u00edticos con reglas m\u00e1s estrictas que los recursos est\u00e1ticos. Si se produce un pico de carga a corto plazo, devuelvo c\u00f3digos de error 429\/503 bien definidos con \u00abRetry-After\u00bb, en lugar de distribuir todas las solicitudes de manera uniforme <strong>morir de hambre<\/strong> Dejar que se mantengan. Detengo las conexiones persistentes (lingering_close) para liberar recursos de forma controlada y evitar patrones de tipo Slowloris. <strong>refutar<\/strong>. Este \u00abshedding\u00bb activo mantiene la latencia p95\/p99 dentro de los l\u00edmites aceptables, incluso cuando la demanda total supera temporalmente la capacidad nominal <strong>mentiras<\/strong>.<\/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\/08\/hosting-performance-9047.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Integraci\u00f3n de contenedores y sistemas: eliminar las limitaciones all\u00ed donde surgen<\/h2>\n<p>En los contenedores suelen aplicarse l\u00edmites m\u00e1s estrictos. Compruebo los l\u00edmites de cgroup (CPU, RAM), configuro ulimit -n adecuadamente dentro del contenedor e incorporo LimitNOFILE en la definici\u00f3n del servicio. Los par\u00e1metros de sysctl como somaxconn y tcp_max_syn_backlog deben establecerse en el <strong>Anfitri\u00f3n<\/strong> entren en vigor; los espacios de nombres no siempre a\u00edslan estos ajustes de forma transparente. En plataformas orquestadas, planifico la capacidad por pod\/nodo, asigno los trabajadores a los n\u00facleos asignados y me aseguro de que las rutas de red sean estables (por ejemplo, sin saltos NAT innecesarios), para que la curva de latencia <strong>tranquilo<\/strong> permanece. Acompa\u00f1o las actualizaciones continuas con worker_shutdown_timeout para que las conexiones existentes se cierren correctamente <strong>agotarse<\/strong>.<\/p>\n\n<h2>Seguimiento y optimizaci\u00f3n iterativa<\/h2>\n<p>Sin visibilidad, las medidas de ajuste siguen siendo <strong>Riesgo<\/strong>. Activo \u00abstub_status\u00bb u otras alternativas para supervisar de forma continua las conexiones activas, las tasas de aceptaci\u00f3n y los rechazos. En las pruebas de carga, simulo patrones de acceso realistas e identifico cuellos de botella en las colas de aceptaci\u00f3n, las latencias de upstream o la CPU-<strong>Saturaci\u00f3n<\/strong>. A continuaci\u00f3n, ajusto con cuidado el n\u00famero de conexiones de los trabajadores, los procesos, los l\u00edmites de archivos y los par\u00e1metros TCP, y vuelvo a comprobar el resultado. Este ciclo garantiza la fiabilidad de la plataforma y evita sorpresas en momentos inoportunos <strong>Times<\/strong>.<\/p>\n\n<h2>Configuraci\u00f3n de ejemplo y proceso de c\u00e1lculo<\/h2>\n<p>Supongamos que espero 2000 solicitudes simult\u00e1neas en curso durante las horas punta y utilizo un proxy inverso; en ese caso, calculo aproximadamente 4000 ranuras de conexi\u00f3n m\u00e1s <strong>Tamp\u00f3n<\/strong>. Si NGINX se ejecuta en cuatro n\u00facleos de CPU, suelo empezar con `worker_processes auto` y entre 1000 y 2000 conexiones por trabajador. Establezco el l\u00edmite de descriptores de archivo por trabajador a un valor lo suficientemente alto como para que las conexiones, los registros y los sockets internos tengan suficiente <strong>Lugar<\/strong> tengo. Configuro el bloque de eventos en epoll, activo multi_accept y aumento los backlogs del kernel en funci\u00f3n de mi tr\u00e1fico m\u00e1ximo. Un fragmento minimalista podr\u00eda tener este aspecto, que luego ajusto con pruebas de rendimiento <strong>Vote<\/strong>:<\/p>\n<pre><code>worker_processes  auto;\nworker_rlimit_nofile  65535;\n\nevents {\n    use epoll;\n    worker_connections  2048;\n    multi_accept on;\n}\n\nhttp {\n    keepalive_timeout   65;\n    sendfile on;\n    # otras opciones de proxy\/cach\u00e9...\n}\n<\/code><\/pre>\n<p>Adem\u00e1s, a\u00f1ado optimizaciones de listas y de upstream para perfeccionar la ruta de recepci\u00f3n y la ruta de backend bajo carga:<\/p>\n<pre><code>events {\n    use epoll;\n    worker_connections 4096;\n    # worker_cpu_affinity auto;  # asignar n\u00facleos fijos si es necesario\n}\n\nhttp {\n    # Optimizaciones de TLS y sesi\u00f3n a modo de ejemplo\n    ssl_session_cache    shared:SSL:50m;\n    ssl_session_timeout  1h;\n\n upstream app_backend {\n server 10.0.0.11:8080;\n server 10.0.0.12:8080;\n keepalive 64;\n    }\n\n    servidor {\n escuchar 443 ssl http2 reutilizar puerto backlog=65535;\n\n ubicaci\u00f3n \/ {\n proxy_pass http:\/\/app_backend;\n proxy_connect_timeout     2s;\n            proxy_read_timeout 15s;\n proxy_next_upstream error timeout http_502 http_503;\n proxy_next_upstream_tries 2;\n }\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\/08\/developer_desk_nginx_5823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>En resumen: valores orientativos concretos<\/h2>\n<p>Ajusto el valor de `worker_processes` en funci\u00f3n de los n\u00facleos de la CPU y, por lo general, configuro `worker_connections` entre 1024 y <strong>4096<\/strong>. En el caso del proxy inverso, preveo dos conexiones por solicitud y mantengo un margen de al menos el doble del pico medido\u2014<strong>Carga<\/strong>. Establezco los valores de `worker_rlimit_nofile` y los l\u00edmites del sistema a un nivel lo suficientemente alto como para que las cifras del archivo `nginx.conf` sigan siendo realmente \u00fatiles. Ajusto el bloque `events` a `epoll` y `multi_accept`, mientras que los backlogs del kernel gestionan breves picos de tr\u00e1fico <strong>amortiguar<\/strong>. Mediante el seguimiento y los ajustes progresivos, consigo crear un motor de tr\u00e1fico fiable que gestiona de forma ordenada el creciente n\u00famero de visitas <strong>lleva<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Descubre c\u00f3mo configurar correctamente las conexiones de los trabajadores de NGINX para escalar NGINX de forma segura y maximizar el rendimiento del alojamiento ante miles de solicitudes.<\/p>","protected":false},"author":1,"featured_media":20715,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20722","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":"124","_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 worker","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":"20715","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20722","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=20722"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20722\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20715"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20722"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20722"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20722"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}