{"id":21151,"date":"2026-08-29T18:19:12","date_gmt":"2026-08-29T16:19:12","guid":{"rendered":"https:\/\/webhosting.de\/nginx-buffering-performance-speicher-proxy\/"},"modified":"2026-08-29T18:19:12","modified_gmt":"2026-08-29T16:19:12","slug":"nginx-almacenamiento-en-bufer-rendimiento-memoria-proxy","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/nginx-buffering-performance-speicher-proxy\/","title":{"rendered":"Almacenamiento en cach\u00e9 del proxy de NGINX: optimizaci\u00f3n del rendimiento y la memoria"},"content":{"rendered":"<p><strong>Almacenamiento en b\u00fafer de NGINX<\/strong> determina la rapidez con la que tu proxy recibe las respuestas del servidor de origen, las almacena en el b\u00fafer y las env\u00eda a los clientes, sin saturar la memoria. Te mostrar\u00e9 c\u00f3mo reducir la latencia, liberar las conexiones al backend lo antes posible y el <strong>Memoria<\/strong> mantenerlo bajo control.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<p>Los siguientes aspectos fundamentales me ayudan a equilibrar adecuadamente el rendimiento y el consumo de memoria.<\/p>\n<ul>\n  <li><strong>Desacoplamiento<\/strong> La comunicaci\u00f3n entre el cliente y el backend reduce el tiempo de conexi\u00f3n y aumenta el rendimiento.<\/li>\n  <li><strong>Tama\u00f1os de los b\u00faferes<\/strong> Selecciona \u00abexactamente\u00bb para ahorrar RAM y evitar operaciones de E\/S de disco.<\/li>\n  <li><strong>b\u00faferes ocupados<\/strong> limitar la memoria activa durante la transmisi\u00f3n.<\/li>\n  <li><strong>Excepciones en el streaming<\/strong> utilizarlo de forma fluida sin buffering.<\/li>\n  <li><strong>Monitoreo<\/strong> y las pruebas de carga garantizan la seguridad de cada modificaci\u00f3n.<\/li>\n<\/ul>\n\n<h2>C\u00f3mo funciona el almacenamiento en b\u00fafer de proxy en NGINX<\/h2>\n<p>Utilizo el modo activo <strong>Almacenamiento en b\u00fafer<\/strong>, para que NGINX recoja r\u00e1pidamente las respuestas del servidor de origen y, a continuaci\u00f3n, las env\u00ede de forma aut\u00f3noma a los clientes. Esta separaci\u00f3n reduce la <strong>Latencia<\/strong> en el backend, ya que la aplicaci\u00f3n se procesa m\u00e1s r\u00e1pido y cierra su conexi\u00f3n antes. Mientras los clientes se cargan a una velocidad variable, la capa proxy regula el env\u00edo desde la memoria RAM. Si los datos no caben por completo en la RAM, NGINX puede recurrir temporalmente a archivos y, de este modo, seguir transmitiendo la respuesta de forma fiable. Es precisamente este comportamiento el que estabiliza los sistemas sometidos a una gran carga con muchos usuarios simult\u00e1neos <strong>Conexiones<\/strong>.<\/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-proxy-buffering-4082.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cu\u00e1ndo es mejor optar por el almacenamiento en b\u00fafer activo<\/h2>\n<p>En el caso de aplicaciones web cl\u00e1sicas, API con respuestas de tama\u00f1o medio o pilas de WordPress, ofrece <strong>Almacenamiento en b\u00fafer<\/strong> obtiene regularmente los mejores resultados. Libero el backend antes, mientras que NGINX se encarga del resto de la transferencia a redes de clientes que suelen ser heterog\u00e9neas. De este modo, aumenta la eficacia <strong>Rendimiento<\/strong>, sobre todo cuando hay muchas solicitudes en curso al mismo tiempo. Quien agrupe varios servicios detr\u00e1s de un proxy inverso se beneficia adem\u00e1s de una distribuci\u00f3n controlada de la carga. Para cuestiones de arquitectura relacionadas con los proxies, me resulta \u00fatil una <a href=\"https:\/\/webhosting.de\/es\/proxy-inverso-configuraciones-webhosting-arquitectura-proxyhosting\/\">Arquitectura de proxy inverso<\/a>, que separa claramente los roles y los l\u00edmites.<\/p>\n\n<h2>Almacenamiento frente a E\/S: el presupuesto adecuado<\/h2>\n<p>Equilibro la memoria RAM y los accesos al disco duro, porque unos b\u00faferes demasiado peque\u00f1os provocan <strong>E\/S de disco<\/strong> y unos b\u00faferes demasiado grandes hacen que la memoria por conexi\u00f3n se sature. Son factores decisivos los tama\u00f1os t\u00edpicos de las respuestas, las solicitudes en paralelo y la <strong>Velocidad del cliente<\/strong>. Lo ideal es que las respuestas peque\u00f1as permanezcan \u00edntegramente en la RAM, lo que permite a NGINX transmitirlas sin tiempos de espera a los destinatarios m\u00e1s lentos. Los cuerpos de gran tama\u00f1o pueden almacenarse en el disco, pero en ese caso me aseguro de utilizar unidades r\u00e1pidas y de establecer l\u00edmites para evitar un uso excesivo de E\/S. Este equilibrio mantiene la <strong>Tiempos de respuesta<\/strong> baja y protege el sistema contra la presi\u00f3n de acumulaci\u00f3n.<\/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_proxy_meeting_8574.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Resumen de las directivas y los valores de referencia<\/h2>\n<p>Configurar\u00e9 de forma espec\u00edfica los par\u00e1metros principales para controlar la memoria y el comportamiento de env\u00edo. El primer b\u00fafer para los encabezados de respuesta se adjunta a <strong>proxy_buffer_size<\/strong>; evita errores debidos a encabezados demasiado grandes y evita transferencias innecesarias a la memoria externa. Los datos de respuesta propiamente dichos los distribuyo a trav\u00e9s de <strong>proxy_buffers<\/strong> como pares de \u00abn\u00famero por tama\u00f1o\u00bb, para que los cuerpos permanezcan \u00edntegramente en la RAM, siempre que sea factible. Con <strong>proxy_busy_buffers_size<\/strong> Limito la cantidad de b\u00faferes ya asignados para el env\u00edo, con el fin de reducir el consumo de memoria activa. Para determinar los tama\u00f1os habituales, me baso en las p\u00e1ginas de memoria (4-32 KB) y en los perfiles de respuesta conocidos de mis aplicaciones.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th><strong>directiva<\/strong><\/th>\n      <th><strong>Efecto<\/strong><\/th>\n      <th><strong>Valores t\u00edpicos<\/strong><\/th>\n      <th><strong>Notas<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>proxy_buffering<\/td>\n      <td><strong>Encendido\/Apagado<\/strong> del almacenamiento en b\u00fafer<\/td>\n      <td>activado (por defecto)<\/td>\n      <td>Mantener activado para las aplicaciones web est\u00e1ndar; comprobarlo para la retransmisi\u00f3n en directo<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_buffer_size<\/td>\n      <td><strong>B\u00fafer de encabezado<\/strong><\/td>\n      <td>8k\u201316k<\/td>\n      <td>Si es demasiado peque\u00f1o, se produce el error \u201eupstream sent too big header\u201c.\u201c<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_buffers<\/td>\n      <td><strong>Amortiguador corporal<\/strong><\/td>\n      <td>8 de 16k, 16 de 16k<\/td>\n      <td>Vincular a los par\u00e1metros de respuesta y al paralelismo<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_busy_buffers_size<\/td>\n      <td><strong>L\u00edmite del b\u00fafer de env\u00edo<\/strong><\/td>\n      <td>32 k\u2013128 k<\/td>\n      <td>Suficiente rendimiento sin ocupar memoria RAM<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_max_temp_file_size<\/td>\n      <td><strong>L\u00edmite de disco<\/strong><\/td>\n      <td>0\u20131 g<\/td>\n      <td>0 desactiva los archivos temporales<\/td>\n    <\/tr>\n    <tr>\n      <td>proxy_temp_path<\/td>\n      <td><strong>Ruta<\/strong> para archivos temporales<\/td>\n      <td>Ruta del SSD<\/td>\n      <td>Guardar en un soporte de datos de alta velocidad<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Perfiles orientados a la pr\u00e1ctica y ejemplos de c\u00e1lculos<\/h2>\n<p>Calculo el espacio de almacenamiento necesario por conexi\u00f3n activa, a grandes rasgos, como la suma de <strong>proxy_buffer_size<\/strong> m\u00e1s (N \u00d7 tama\u00f1o del b\u00fafer) de proxy_buffers. Con 8 b\u00faferes de 16 k m\u00e1s 16 k de encabezado, llegamos a unos 144 KB por solicitud, siempre y cuando todo permanezca en la RAM. Por lo tanto, con 5.000 solicitudes simult\u00e1neas, calculo unos 720 MB de ocupaci\u00f3n pura del b\u00fafer, m\u00e1s la sobrecarga de la <strong>Procesos<\/strong>. A medida que aumenta el tr\u00e1fico, tambi\u00e9n lo hace la demanda; por eso establezco los m\u00e1rgenes de seguridad de tal forma que se adapten a las respuestas habituales, sin convertir en casos normales las respuestas at\u00edpicas con cuerpos de tama\u00f1o excesivo. Cuando es necesario, limito las excepciones con <strong>L\u00edmites de disco<\/strong>, para absorber los picos de demanda de almacenamiento.<\/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-proxy-optimization-4285.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cu\u00e1ndo desactivo deliberadamente el almacenamiento en b\u00fafer<\/h2>\n<p>Las API en tiempo real, los eventos enviados por el servidor o el v\u00eddeo en directo requieren una conexi\u00f3n directa <strong>Rendimiento<\/strong> sin almacenamiento en b\u00fafer adicional. En esos casos, desactivo proxy_buffering y apuesto por un <strong>Transmisi\u00f3n<\/strong>. El proxy transmite los datos de inmediato, lo que evita picos de latencia en los datos en tiempo real, pero mantiene abierta la conexi\u00f3n con el backend durante m\u00e1s tiempo. Para estos patrones, merece la pena echar un vistazo a <a href=\"https:\/\/webhosting.de\/es\/http-response-streaming-hosting-performance-chunks\/\">Flujo de respuesta<\/a>, incluyendo un ajuste adecuado de los par\u00e1metros de keepalive y timeout. Es importante tener en cuenta el mayor consumo de recursos por conexi\u00f3n y establecer los l\u00edmites correspondientes.<\/p>\n\n<h2>Configurar los \u00abBusy Buffers\u00bb de forma selectiva<\/h2>\n<p>Con <strong>proxy_busy_buffers_size<\/strong> Con ello controlo la cantidad de memoria \u201elista para el env\u00edo\u201c que permanece bloqueada al mismo tiempo. Si el l\u00edmite es demasiado bajo, la entrega se ralentiza; si es demasiado alto, aumentan los picos de uso de la RAM. Por lo tanto, elijo un valor que corresponda a entre 1 y 2 veces el tama\u00f1o del b\u00fafer, para que NGINX env\u00ede los paquetes r\u00e1pidamente sin consumir demasiada <strong>Memoria<\/strong> . En el caso de los clientes lentos, acepto un poco m\u00e1s de \u00abbusy-space\u00bb para reducir el riesgo de cambios de contexto frecuentes. Las redes r\u00e1pidas se benefician de valores m\u00e1s bajos, que <strong>Memoria necesaria<\/strong> mantenerlo dentro de lo previsible.<\/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_proxy_buffering_opt_7823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Archivos temporales: ruta, tama\u00f1o, l\u00edmites<\/h2>\n<p>Activo las <strong>Archivos<\/strong> solo cuando los \u00abbodies\u00bb son de gran tama\u00f1o o la memoria RAM es escasa. Si los archivos temporales se almacenan en un SSD, los tiempos de respuesta siguen siendo aceptables; en un disco m\u00e1s lento, las operaciones de E\/S ralentizan r\u00e1pidamente todo el <strong>Cadena de respuestas<\/strong>. Con la opci\u00f3n `proxy_max_temp_file_size` me protejo contra un uso excesivo del espacio; en caso de duda, establezco un l\u00edmite estricto. Si se producen muchas respuestas grandes en paralelo, preveo espacio suficiente y superviso la carga real. Cuando hay RAM disponible, prefiero utilizar b\u00faferes m\u00e1s grandes y mantengo las partes cr\u00edticas en el <strong>Memoria<\/strong>.<\/p>\n\n<h2>Ajuste iterativo, m\u00e9tricas y pruebas<\/h2>\n<p>Empiezo con conservador <strong>Valores<\/strong>, mide, ajusta y repite el ciclo. Las m\u00e9tricas importantes son la latencia, la tasa de errores, los picos de RAM, los tiempos de espera de E\/S y la carga de <strong>Trabajador<\/strong>. Las pruebas de carga revelan efectos que pasan desapercibidos en el d\u00eda a d\u00eda, como picos en los encabezados debidos a las cookies o respuestas masivas poco frecuentes. Adem\u00e1s, ajusto los par\u00e1metros de conexi\u00f3n y de los trabajadores de forma conjunta, por ejemplo, <a href=\"https:\/\/webhosting.de\/es\/escalabilidad-de-las-conexiones-de-los-trabajadores-de-nginx-para-miles-de-solicitudes-aumento-del-trafico\/\">Conexiones entre trabajadores<\/a> y Keepalive. Compruebo cada cambio de forma controlada para poder evaluar el impacto de la <strong>Tamp\u00f3n<\/strong> puedo asignarlo claramente.<\/p>\n\n<h2>Almacenamiento en b\u00fafer de solicitudes y subidas<\/h2>\n<p>Los b\u00faferes de respuesta son solo la mitad de la verdad. En el lado de entrada controla <strong>proxy_request_buffering<\/strong>, si NGINX almacena en el b\u00fafer los cuerpos de los clientes (por ejemplo, las subidas) hasta que est\u00e9n completos o los transmite directamente al servidor de origen. En el caso de las API que reciben archivos de gran tama\u00f1o, suelo desactivar el almacenamiento en b\u00fafer de las solicitudes: el servidor de origen recibe el flujo antes, se reducen los tiempos de espera y NGINX no tiene que almacenar temporalmente en disco los cuerpos de gran tama\u00f1o. La desventaja es que la conexi\u00f3n con el servidor de origen permanece abierta durante m\u00e1s tiempo y depende en mayor medida de la velocidad del cliente. En el caso de formularios cl\u00e1sicos o solicitudes JSON m\u00e1s peque\u00f1as, mantengo activado el almacenamiento en b\u00fafer de solicitudes para suavizar los picos de tr\u00e1fico y controlar mejor los recursos del servidor. Lo combino con <strong>client_max_body_size<\/strong> y una que vaya a juego <strong>client_body_buffer_size<\/strong>, para que los valores at\u00edpicos se descarten desde el principio o se amortig\u00fcen adecuadamente.<\/p>\n\n<h2>Control de Pro-Response: X-Accel-Buffering, Chunked y longitudes<\/h2>\n<p>Para un control m\u00e1s preciso, desactivo el almacenamiento en b\u00fafer por respuesta a trav\u00e9s de <strong>X-Accel-Buffering<\/strong> Del c\u00f3digo fuente: el encabezado \u201eX-Accel-Buffering: no\u201c indica a NGINX que transmita la respuesta directamente, incluso si la opci\u00f3n \u00abproxy_buffering\u00bb est\u00e1 activada globalmente. Lo utilizo para SSE, long polling o flujos de diagn\u00f3stico, sin sacrificar la configuraci\u00f3n general. Adem\u00e1s, me aseguro de que la configuraci\u00f3n sea correcta <strong>Longitud del contenido<\/strong>, siempre que sea posible: si NGINX conoce la longitud, planifica los b\u00faferes y los archivos temporales de forma m\u00e1s predecible que si se utilizara exclusivamente <strong>troceado<\/strong> se transmite. Cuando se desconoce la longitud (por ejemplo, en transmisiones en directo), calculo las necesidades de forma conservadora y aseguro las operaciones de E\/S con l\u00edmites. En el caso de p\u00e1ginas de error o respuestas JSON peque\u00f1as, mantengo el almacenamiento en b\u00fafer activado de forma estricta, para que el enlace ascendente quede libre cuanto antes.<\/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_proxy_optimization_7381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compresi\u00f3n y protocolos: HTTP\/2\/3 al detalle<\/h2>\n<p>La compresi\u00f3n y el almacenamiento en b\u00fafer deben considerarse conjuntamente. \u00bfEs <strong>gzip<\/strong> O, si Brotli est\u00e1 activo, la compresi\u00f3n se beneficia de los bloques de datos contiguos en la RAM. Unos b\u00faferes demasiado peque\u00f1os pueden limitar el rendimiento, ya que el compresor tiene que cambiar de contexto con mayor frecuencia. Por eso elijo tama\u00f1os de b\u00fafer que agrupen bien los segmentos de respuesta t\u00edpicos, sin que la RAM se sature en cada conexi\u00f3n. En <strong>HTTP\/2<\/strong> y <strong>HTTP\/3<\/strong> Con el multiplexado y el control de flujo, la velocidad de env\u00edo var\u00eda seg\u00fan cada flujo; el almacenamiento en b\u00fafer estabiliza el lado del backend, mientras que NGINX sincroniza los flujos de forma precisa. Importante: en rutas muy sensibles a la latencia, reducir ligeramente el \u201ebusy space\u201c puede ayudar a mitigar los efectos \u00abhead-of-line\u00bb; en conexiones \u00abpotentes\u00bb con ventanas grandes, asigno un poco m\u00e1s de \u00abbusy space\u00bb para mantener el m\u00e1ximo rendimiento de env\u00edo.<\/p>\n\n<h2>Cach\u00e9 de proxy y solicitudes de rango: interacci\u00f3n con los b\u00faferes<\/h2>\n<p>Qui\u00e9n <strong>proxy_cache<\/strong> Si se utiliza NGINX, el presupuesto para los b\u00faferes y los archivos temporales debe estar bien coordinado. NGINX puede almacenar en cach\u00e9 las respuestas y entregarlas a los clientes al mismo tiempo; disponer de suficiente memoria RAM para los b\u00faferes acorta la duraci\u00f3n de la conexi\u00f3n con el backend, mientras que la coincidencia en la cach\u00e9 desacopla por completo las solicitudes posteriores. Limito los archivos temporales de forma m\u00e1s estricta cuando la cach\u00e9 est\u00e1 \u00abcaliente\u00bb y los habilito mientras se est\u00e1 acumulando la tasa de aciertos. En <strong>Solicitudes de gama<\/strong> (Descargas parciales): decido si las sirvo directamente desde la cach\u00e9 o si primero las dejo cargar por completo en la memoria intermedia. Los rangos frecuentes de archivos grandes se benefician de tama\u00f1os de memoria intermedia cuidadosamente equilibrados y de respuestas segmentadas opcionalmente, para que ni las E\/S de disco ni la RAM se descontrolen.<\/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-optimierung-server-4573.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Clientes lentos: c\u00f3mo controlar el rendimiento sin agotar la memoria RAM<\/h2>\n<p>La mayor parte de los efectos de almacenamiento en b\u00fafer solo se aprecian con clientes muy lentos. Yo utilizo <strong>send_timeout<\/strong> y opcionalmente <strong>limit_rate<\/strong>\/<strong>limit_rate_after<\/strong>, para proteger a los destinatarios reticentes sin ocupar en exceso a los trabajadores. Si se aplica una limitaci\u00f3n muy estricta, los b\u00faferes de \u00abbusy\u00bb deben aumentar; de lo contrario, se corre el riesgo de que se produzcan bloqueos; al mismo tiempo, controlo el n\u00famero de conexiones paralelas por IP para mitigar los patrones an\u00f3malos. Para descargas con una combinaci\u00f3n de clientes (m\u00f3vil, wifi, fibra \u00f3ptica), resultan \u00fatiles unos valores moderados de \u00abBusy\u00bb y unos \u00abBody Buffers\u00bb algo m\u00e1s generosos, de modo que NGINX env\u00ede datos de forma lineal mientras el servidor de origen ya est\u00e1 ocupado con la siguiente solicitud.<\/p>\n\n<h2>Operaciones en contenedores y orquestaci\u00f3n<\/h2>\n<p>Lo planifico en contenedores <strong>proxy_temp_path<\/strong> A tener en cuenta: o bien un volumen de host r\u00e1pido (SSD) o bien un tmpfs, si hay suficiente RAM disponible. Los l\u00edmites de los contenedores (memoria\/CPU\/almacenamiento ef\u00edmero) afectan directamente a los b\u00faferes y a los archivos temporales; mantengo un margen suficiente para los picos y regulo el n\u00famero de trabajadores y conexiones en paralelo en consecuencia. Siguen siendo importantes <strong>ulimit -n<\/strong> (descriptores de archivos) y las cuotas del Orchestrator: si la memoria ef\u00edmera es demasiado peque\u00f1a, los archivos temporales generan errores; si la RAM es insuficiente, los trabajadores se bloquean bajo la presi\u00f3n de OOM. Dimensiono los b\u00faferes de tal forma que los picos de carga t\u00edpicos se mantengan estables dentro de los l\u00edmites del contenedor, y superviso continuamente el espacio real que ocupan los directorios temporales.<\/p>\n\n<h2>Valores iniciales y plantilla para aplicaciones web habituales<\/h2>\n<p>Como punto de partida fiable, utilizo un perfil breve que luego perfecciono con los valores de medici\u00f3n. Ejemplo:<\/p>\n<pre><code>location \/ {\n    proxy_http_version 1.1;\n    proxy_set_header Connection \"\";\n    proxy_buffering on;\n\n    # B\u00faferes de encabezado y cuerpo\n    proxy_buffer_size 16k;\n    proxy_buffers 16 16k;\n    proxy_busy_buffers_size 64k;\n\n    # Archivos temporales solo como medida de seguridad\n    proxy_max_temp_file_size 256m;\n    proxy_temp_path \/var\/cache\/nginx\/proxy_temp 1 2;\n\n    # Tiempos de espera y env\u00edo\n    proxy_read_timeout 60s;\n    send_timeout 30s;\n\n # Opcional: transmisi\u00f3n de archivos en la subida, seg\u00fan la API\n    # proxy_request_buffering off;\n}\n<\/code><\/pre>\n<p>De este modo, las respuestas de tama\u00f1o medio permanecen \u00edntegramente en la RAM, el \u00abupstream\u00bb queda libre pronto y los archivos temporales solo se utilizan en caso de valores at\u00edpicos. En la segunda ronda, adapto el n\u00famero de b\u00faferes al paralelismo real; si las respuestas son breves y frecuentes, aumente ligeramente el tama\u00f1o de \u00abbusy\u00bb si es necesario, y limito m\u00e1s estrictamente los archivos temporales en cuanto la tasa de aciertos de la cach\u00e9 sea suficiente.<\/p>\n\n<h2>Supervisi\u00f3n y registro: hacer visible el impacto<\/h2>\n<p>Mido de forma sistem\u00e1tica: <strong>1TP4Hora_petici\u00f3n<\/strong> y <strong>$upstream_tiempo_respuesta<\/strong> en el registro de acceso se puede comprobar si el enlace ascendente se desconecta prematuramente. <strong>1 TP4 Tbytes_enviados<\/strong> y <strong>$body_bytes_sent<\/strong> ayudan a ajustar los perfiles de b\u00fafer al tr\u00e1fico real. Si la diferencia entre el tiempo de upstream y la duraci\u00f3n total disminuye, los b\u00faferes funcionan correctamente. Relaciono esto con los picos de RAM, la espera de E\/S y la ocupaci\u00f3n del <strong>proxy_temp_path<\/strong>. En las pruebas de estr\u00e9s, var\u00edo las velocidades de los clientes, los niveles de respuesta y la carga de los encabezados (por ejemplo, las cookies) para detectar casos extremos. Solo cuando las m\u00e9tricas de los registros y los valores del sistema se mantienen estables dentro de mi rango objetivo, congelo el perfil y documento los l\u00edmites, as\u00ed como las v\u00edas de escalaci\u00f3n (buferajes mayores, otra pol\u00edtica de temperatura, r\u00e9plicas adicionales).<\/p>\n\n<h2>Problemas habituales y c\u00f3mo solucionarlos<\/h2>\n<p>El mensaje \u201e<strong>Se ha enviado un encabezado demasiado grande en la direcci\u00f3n de origen<\/strong>\u201cLo soluciono aumentando el valor de `proxy_buffer_size` y, si es necesario, el de los `proxy_buffers`. Si se producen tiempos de espera en dispositivos lentos, aumento moderadamente los tiempos de espera de env\u00edo y dejo un poco de margen a los b\u00faferes ocupados. Si se llena el directorio temporal, reduzco el tama\u00f1o m\u00e1ximo o aumento los b\u00faferes de RAM, en funci\u00f3n de la relaci\u00f3n coste-beneficio. Si la entrega se ralentiza, compruebo si hay cuellos de botella en la E\/S, saturaci\u00f3n de la CPU y la distribuci\u00f3n de los <strong>Tamp\u00f3n<\/strong>. Cuando se producen situaciones de escasez, siempre las abordo primero bas\u00e1ndome en datos medidos, no con duplicaciones generales.<\/p>\n\n<h2>Conclusi\u00f3n: mis puntos clave sobre el almacenamiento en cach\u00e9 del proxy de NGINX<\/h2>\n<p>En primer lugar, defino los t\u00edpicos <strong>Tama\u00f1os de respuesta<\/strong>, la carga m\u00e1xima y los perfiles de cliente, antes incluso de ajustar los b\u00faferes. A continuaci\u00f3n, configuro un b\u00fafer de encabezado lo suficientemente grande como para evitar errores innecesarios. Dimensiono los b\u00faferes de cuerpo de tal manera que las respuestas habituales permanezcan en la RAM y solo las excepciones se almacenen en <strong>Disco<\/strong> caen. Configuro los \u00abBusy Buffers\u00bb de tal forma que las transferencias se realicen con fluidez, sin malgastar memoria. Por \u00faltimo, lo compruebo todo con pruebas de carga y supervisi\u00f3n hasta que la latencia, el rendimiento y los requisitos de memoria se sit\u00faen en un nivel fiable <strong>Windows<\/strong> mentira.<\/p>","protected":false},"excerpt":{"rendered":"<p>Explicaci\u00f3n del almacenamiento en cach\u00e9 del proxy de NGINX: c\u00f3mo optimizar el rendimiento, el consumo de memoria y la configuraci\u00f3n del proxy inverso en la pr\u00e1ctica.<\/p>","protected":false},"author":1,"featured_media":21144,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-21151","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":"139","_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 Buffering","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":"21144","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21151","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=21151"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21151\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21144"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21151"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21151"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21151"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}