{"id":20898,"date":"2026-08-22T15:04:55","date_gmt":"2026-08-22T13:04:55","guid":{"rendered":"https:\/\/webhosting.de\/nginx-cache-optimierung-fenster\/"},"modified":"2026-08-22T15:04:55","modified_gmt":"2026-08-22T13:04:55","slug":"ventana-de-optimizacion-de-la-cache-de-nginx","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/nginx-cache-optimierung-fenster\/","title":{"rendered":"Configurar de forma \u00f3ptima la cach\u00e9 de archivos abiertos de NGINX: as\u00ed sacar\u00e1s m\u00e1s rendimiento a tu servidor"},"content":{"rendered":"<p><strong>Cach\u00e9 de NGINX<\/strong> gana notablemente en velocidad cuando configuro espec\u00edficamente la cach\u00e9 de archivos abiertos: mantiene los metadatos de los archivos y los identificadores en la memoria y evita costosos accesos al sistema de archivos. Con los valores adecuados para <strong>m\u00e1x.<\/strong>, <strong>inactivo<\/strong>, <strong>v\u00e1lido<\/strong> y <strong>min_uses<\/strong> Optimizo la entrega de contenidos est\u00e1ticos para conseguir tiempos de respuesta r\u00e1pidos y una menor carga de E\/S.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>Cach\u00e9 de metadatos<\/strong>: almacena la existencia, el tama\u00f1o, los tiempos y los identificadores en lugar del contenido<\/li>\n  <li><strong>Dimensionamiento<\/strong>: Equilibrio entre el consumo de RAM, la tasa de aciertos y la tasa de cambios<\/li>\n  <li><strong>Contextos<\/strong>: ideal para im\u00e1genes, CSS y JS; evitar las rutas din\u00e1micas<\/li>\n  <li><strong>Validaci\u00f3n<\/strong>: Garantizar la vigencia con open_file_cache_valid<\/li>\n  <li><strong>Medici\u00f3n<\/strong>: Comprobar los efectos sobre las latencias, las E\/S y la tasa de errores<\/li>\n<\/ul>\n\n<h2>Lo que realmente almacena la cach\u00e9 de archivos abiertos<\/h2>\n\n<p>Yo guardo en cach\u00e9 con <strong>Abrir archivo<\/strong> No almacena en cach\u00e9 el contenido de los archivos, sino informaci\u00f3n estructurada: si existe un archivo, cu\u00e1l es su tama\u00f1o, cu\u00e1ndo se modific\u00f3 y qu\u00e9 descriptor est\u00e1 ya abierto. Esta informaci\u00f3n est\u00e1 disponible en la memoria y acorta el camino hasta la siguiente respuesta. Cada consulta al disco duro que se evita reduce el <strong>Carga de E\/S<\/strong> y ahorra tiempo de CPU, lo que resulta especialmente importante cuando hay muchos archivos peque\u00f1os. Seg\u00fan la documentaci\u00f3n de NGINX, esta funci\u00f3n abarca los descriptores abiertos, la informaci\u00f3n de los directorios y los errores de b\u00fasqueda. Esto acelera los escaneos de directorios y las rutas de acceso, que, de otro modo, tendr\u00edan que volver al disco duro con cada solicitud.<\/p>\n\n<p>Utilizo este mecanismo de forma deliberada para los directorios a los que se accede con frecuencia, como las bibliotecas multimedia y los recursos de compilaci\u00f3n. El efecto se nota especialmente en proyectos con muchos <strong>Activos<\/strong>, en las que, de otro modo, el sistema de archivos se convertir\u00eda en un cuello de botella. La cach\u00e9 reduce notablemente las llamadas al sistema como stat(), open() y readdir(). Al mismo tiempo, el control sigue siendo muy granular, ya que defino por separado el alcance y la validez de las entradas. De este modo, mantengo los datos actualizados sin perder la ventaja del almacenamiento en cach\u00e9.<\/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\/server-tuning-7234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Cu\u00e1ndo merece la pena utilizar la cach\u00e9 de archivos abiertos<\/h2>\n\n<p>Enciendo el <strong>Cache<\/strong> lo utilizo espec\u00edficamente para entregas est\u00e1ticas: im\u00e1genes, CSS, JavaScript, fuentes y descargas. En zonas din\u00e1micas, como p\u00e1ginas de inicio de sesi\u00f3n, carritos de la compra o rutas personalizadas, lo evito, ya que all\u00ed se aplican otras reglas. WordPress y las interfaces front-end \u00abheadless\u00bb se benefician enormemente de ello, ya que los temas, los plugins y los paquetes proporcionan muchos archivos. Cuanto m\u00e1s constantes sean los archivos, mejor funcionar\u00e1 la <strong>Tasa de aciertos<\/strong> de los metadatos. Si realizo implementaciones con mucha frecuencia, ajusto los intervalos de validaci\u00f3n para que sean m\u00e1s estrictos.<\/p>\n\n<p>La mejora es especialmente notable en la entrega de contenido a trav\u00e9s de SSD locales. Incluso con configuraciones SATA m\u00e1s antiguas o montajes NFS, ahorro tiempo con cada acceso. Me aseguro de activar el almacenamiento en cach\u00e9 solo en los contextos relevantes (http, servidor o ubicaci\u00f3n). De este modo, evito que los directorios inadecuados consuman memoria. Una separaci\u00f3n clara garantiza aqu\u00ed una configuraci\u00f3n ordenada y un comportamiento fiable.<\/p>\n\n<h2>Una configuraci\u00f3n inicial que funciona<\/h2>\n\n<p>Voy a empezar con una breve <strong>Base<\/strong>, y luego sigo midiendo y ajustando de forma controlada. Estos valores ofrecen buenos resultados iniciales en muchos servidores y minimizan el riesgo. Importante: primero comprueba con `nginx -t` y, a continuaci\u00f3n, ejecuta `reload`. Establezco las directivas deliberadamente a nivel de http, aunque, si es necesario, puedo utilizarlas de forma m\u00e1s espec\u00edfica en el bloque \u00ablocation\u00bb adecuado. De este modo, encuentro r\u00e1pidamente un buen equilibrio entre el consumo de memoria y <strong>Actuaci\u00f3n<\/strong>.<\/p>\n\n<pre><code>open_file_cache max=1000 inactive=20s;\nopen_file_cache_valid 30s;\nopen_file_cache_min_uses 2;\nopen_file_cache_errors off;<\/code><\/pre>\n\n<p>Con \u00abmax\u00bb limito el n\u00famero m\u00e1ximo de objetos almacenados en la cach\u00e9. \u00abinactive\u00bb elimina las entradas no utilizadas tras el tiempo seleccionado. \u00abvalid\u00bb controla la frecuencia con la que NGINX vuelve a comparar los metadatos con el sistema de archivos. \u00abmin_uses\u00bb garantiza que solo los archivos realmente utilizados se almacenen en la cach\u00e9. Utilizo las cach\u00e9s de errores con moderaci\u00f3n para evitar falsos positivos innecesarios.<\/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_cache_optimierung_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dimensionamiento correcto: max, inactive, min_uses<\/h2>\n\n<p>Determino el tama\u00f1o de la cach\u00e9 en funci\u00f3n de datos reales <strong>Datos de carga<\/strong> en lugar de basarme en suposiciones. \u00bfCu\u00e1ntos archivos est\u00e1ticos se consultan en las horas punta y c\u00f3mo se distribuye el tr\u00e1fico? A medida que aumenta el n\u00famero de archivos, voy incrementando el valor \u00abmax\u00bb gradualmente, normalmente en incrementos de 500 o 1000. Al principio, mantengo el valor \u00abinactive\u00bb bastante bajo, hasta que pueda evaluar con certeza el comportamiento. El valor \u00abmin_uses\u00bb limita el ruido de fondo, para que los archivos que se utilizan con poca frecuencia no bloqueen la memoria.<\/p>\n\n<p>En el caso de sitios web con una gran cantidad de recursos, suelo fijar el valor m\u00e1ximo entre 5.000 y 10.000. En proyectos peque\u00f1os, suele bastar con entre 500 y 1.500. Superviso la tasa de aciertos, la curva de RAM de los trabajadores de NGINX y la latencia en los recursos est\u00e1ticos. A continuaci\u00f3n, sigo ajustando los valores de \u00abmax\u00bb e \u00abinactive\u00bb hasta que la relaci\u00f3n sea la adecuada. Al mismo tiempo, analizo el lado de las conexiones y las escalo seg\u00fan sea necesario. <a href=\"https:\/\/webhosting.de\/es\/escalabilidad-de-las-conexiones-de-los-trabajadores-de-nginx-para-miles-de-solicitudes-aumento-del-trafico\/\">Escalar worker_connections<\/a>, para no saturar el sistema durante los picos de demanda.<\/p>\n\n<h2>Validaci\u00f3n y actualidad: open_file_cache_valid<\/h2>\n\n<p>Defino con <strong>v\u00e1lido<\/strong>, durante cu\u00e1nto tiempo NGINX considera fiables los metadatos. En muchas implementaciones, suelo ser bastante conservador, por ejemplo, entre 15 y 30 segundos. Cuando los cambios son poco frecuentes, puedo alargar este intervalo considerablemente, entre 60 y 300 segundos. Este intervalo influye en la frecuencia con la que NGINX vuelve a comprobar los atributos de los archivos, pero no afecta a la entrega de contenidos. De este modo, se mantiene la <strong>Actualidad<\/strong> alta, sin que sea necesario consultar el disco cada vez que se realiza una consulta.<\/p>\n\n<p>Evito valores extremos, ya que ambos tienen sus inconvenientes. Los intervalos demasiado cortos aumentan la carga de llamadas al sistema. Los intervalos demasiado largos conllevan el riesgo de que NGINX mantenga en memoria metadatos obsoletos durante demasiado tiempo. Me gu\u00edo por la frecuencia de modificaci\u00f3n de los archivos y por los ciclos de lanzamiento. En cuanto est\u00e9 lista la cadena de lanzamiento, ajustar\u00e9 \u00abvalid\u00bb al ritmo correspondiente.<\/p>\n\n<h2>Almacenar en cach\u00e9 los errores de forma adecuada: open_file_cache_errors<\/h2>\n\n<p>Puedo solucionar a corto plazo errores como \u201eArchivo no encontrado\u201c <strong>almacenar temporalmente<\/strong>, para aliviar la carga de las solicitudes err\u00f3neas repetidas. Esto resulta \u00fatil en caso de errores 404 recurrentes en rutas conocidas que no existen. Por eso, configuro \u00aberrors\u00bb en \u00abon\u00bb de forma selectiva y mantengo \u00abinactive\u00bb en un nivel moderado. En cambio, con archivos potencialmente ef\u00edmeros con ciclos de vida cortos, prefiero ser cauteloso. As\u00ed evito que los archivos temporales <strong>estados<\/strong> dar lugar a falsos negativos.<\/p>\n\n<p>Para los casos gen\u00e9ricos de error 404, recomiendo m\u00e1s bien un bloque \u00ablocation\u00bb espec\u00edfico con reglas claras. All\u00ed puedo gestionar las cach\u00e9s de errores por separado de la cach\u00e9 de archivos habitual. En directorios multimedia bien organizados, los errores suelen ser inexistentes. Esto ahorra memoria y evita malentendidos en an\u00e1lisis posteriores. Una separaci\u00f3n clara facilita aqu\u00ed la resoluci\u00f3n de problemas.<\/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-cache-optimierung-server-7419.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Sinergias: sendfile, b\u00fafer, compresi\u00f3n<\/h2>\n\n<p>Combino el Open File Cache con <strong>sendfile<\/strong> porque las transferencias de archivos a trav\u00e9s del n\u00facleo evitan el trabajo de copiar en el espacio de usuario. En el caso de los contenidos est\u00e1ticos, esto supone menos cambios de contexto y una entrega m\u00e1s fluida. Los b\u00faferes de salida adecuados reducen a\u00fan m\u00e1s las llamadas al sistema y mantienen estable el rendimiento. Gzip o Brotli comprimen los recursos basados en texto y reducen tanto el ancho de banda como la latencia. Al mismo tiempo, configuro el <a href=\"https:\/\/webhosting.de\/es\/configuracion-optima-de-los-procesos-de-trabajo-de-nginx-para-mejorar-el-rendimiento\/\">Procesos de trabajo<\/a> de tal manera que se adapten a la topolog\u00eda de la CPU.<\/p>\n\n<p>Adem\u00e1s, analizo estrategias de encabezados para el almacenamiento en cach\u00e9 del lado del cliente. Los tiempos largos de \u00abCache-Control\u00bb en paquetes que no cambian ahorran RTT, mientras que con los archivos que cambian con frecuencia prefiero ser cauteloso. Junto con los ETags o \u00abLast-Modified\u00bb, garantizo unas revalidaciones eficientes. De este modo, la cach\u00e9 del cliente, la cach\u00e9 de archivos abiertos y la compresi\u00f3n funcionan conjuntamente. Esto act\u00faa como un multiplicador para una <strong>Tiempos de respuesta<\/strong>.<\/p>\n\n<h2>Linux y el almacenamiento: la aportaci\u00f3n del hardware<\/h2>\n\n<p>Saco m\u00e1s partido al <strong>Cach\u00e9 de archivos<\/strong>, siempre que el almacenamiento y la configuraci\u00f3n del n\u00facleo sean los adecuados. Unos SSD m\u00e1s r\u00e1pidos, unos programadores de E\/S optimizados y suficiente RAM para la cach\u00e9 de p\u00e1ginas dan resultados inmediatos. Por el contrario, una elevada utilizaci\u00f3n de inodos y los sistemas de archivos fragmentados suponen una p\u00e9rdida de tiempo. Adem\u00e1s, vigilo el n\u00famero de descriptores abiertos y ajusto los l\u00edmites del sistema. De este modo, el sistema operativo constituye una base eficiente para un funcionamiento \u00e1gil <strong>Accede a<\/strong>.<\/p>\n\n<p>En los hosts de m\u00e1quinas virtuales tengo en cuenta los efectos de overcommit y \u00abnoisy neighbor\u00bb. Compruebo si las latencias de NFS o de red reducen la utilidad de la cach\u00e9 de archivos abiertos. Adem\u00e1s, los escenarios de contenedores con sistemas de archivos superpuestos se comportan de forma diferente seg\u00fan las capas. Por eso mido la carga real de producci\u00f3n, no solo pruebas en directorios vac\u00edos. As\u00ed detecto los cuellos de botella a tiempo y puedo reaccionar de forma espec\u00edfica.<\/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_performance_5793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Seguimiento y m\u00e9tricas: as\u00ed es como mido el impacto<\/h2>\n\n<p>Mido el impacto a trav\u00e9s de <strong>Latencias<\/strong>, llamadas al sistema, tiempos de espera de E\/S y recursos de los trabajadores. Herramientas como strace, perf, iostat y nginx-status me ayudan a visualizar el efecto. Observo el \u00abtime-to-first-byte\u00bb de las rutas est\u00e1ticas y comparo las situaciones de \u00abhit\u00bb y \u00abmiss\u00bb. A trav\u00e9s de los registros, identifico rutas 404 recurrentes o directorios \u00abcalientes\u00bb. Paralelamente, compruebo el <a href=\"https:\/\/webhosting.de\/es\/file-descriptor-limit-server-hosting-tuning-server-limits\/\">L\u00edmite de descriptores de archivo<\/a>, para que las operaciones abiertas no se vean interrumpidas por los l\u00edmites del proceso.<\/p>\n\n<p>Recopilo las m\u00e9tricas antes y despu\u00e9s del cambio. A continuaci\u00f3n, ajusto los valores \u00abmax\u00bb, \u00abinactive\u00bb y \u00abvalid\u00bb, y vuelvo a medir. A menudo bastan dos o tres iteraciones para alcanzar un valor objetivo claro. En los picos de tr\u00e1fico, compruebo si las curvas de carga son m\u00e1s uniformes. De este modo, no demuestro las mejoras de forma anecd\u00f3tica, sino con datos inequ\u00edvocos <strong>cifras<\/strong>.<\/p>\n\n<h2>Errores t\u00edpicos y c\u00f3mo evitarlos<\/h2>\n\n<p>Activo el <strong>Cache<\/strong> No de forma global para todo, sino solo all\u00ed donde resulte \u00fatil. Alivio la carga de los puntos finales din\u00e1micos de otra manera, por ejemplo, mediante cach\u00e9s de aplicaciones o estrategias de borde. No elijo valores m\u00e1ximos extremadamente altos al azar, porque en alg\u00fan momento se agotar\u00e1 la RAM. Unos valores de inactividad demasiado largos mantienen en la memoria elementos obsoletos que ya no necesita ninguna solicitud. Adem\u00e1s, los intervalos de validez prematuros generan llamadas al sistema innecesarias y merman la ventaja de velocidad.<\/p>\n\n<p>Establezco directrices para cada directorio y documento las responsabilidades. Tras las implementaciones, compruebo aleatoriamente que los archivos importantes est\u00e9n actualizados. Configuro los mensajes de error de forma clara para que los an\u00e1lisis de errores 404 no se pierdan entre el ruido. Para m\u00ed, las advertencias del registro de errores forman parte de la comprobaci\u00f3n peri\u00f3dica. Con un mantenimiento riguroso, la cach\u00e9 de archivos abiertos sigue siendo fiable y <strong>eficaz<\/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_file_cache_performance_6789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ejemplos pr\u00e1cticos: sitios web peque\u00f1os frente a sitios web grandes<\/h2>\n\n<p>Distingo las configuraciones seg\u00fan el n\u00famero de archivos, el tr\u00e1fico y la frecuencia de las modificaciones, y a partir de ah\u00ed deduzco <strong>Valores<\/strong> . Los proyectos m\u00e1s peque\u00f1os requieren pocas entradas, per\u00edodos de inactividad cortos y per\u00edodos de validez moderados. Los sitios de tama\u00f1o medio a grande utilizan valores m\u00e1ximos m\u00e1s altos e intervalos ajustados. Las implementaciones frecuentes justifican per\u00edodos de validez m\u00e1s cortos, mientras que las implementaciones poco frecuentes permiten per\u00edodos m\u00e1s largos. La tabla muestra los valores iniciales t\u00edpicos, que posteriormente verificar\u00e9 mediante mediciones.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Configurar<\/th>\n      <th>Archivos (aproximadamente)<\/th>\n      <th>m\u00e1x.<\/th>\n      <th>inactivo<\/th>\n      <th>v\u00e1lido<\/th>\n      <th>min_uses<\/th>\n      <th>Nota<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>P\u00e1gina web peque\u00f1a<\/td>\n      <td>200\u20131.000<\/td>\n      <td>500\u20131.500<\/td>\n      <td>20-30s<\/td>\n      <td>30-60 s<\/td>\n      <td>2<\/td>\n      <td><strong>Econ\u00f3mico<\/strong> iniciar, comprobar<\/td>\n    <\/tr>\n    <tr>\n      <td>Medio<\/td>\n      <td>1.000\u201310.000<\/td>\n      <td>2.000\u20136.000<\/td>\n      <td>30-60 s<\/td>\n      <td>60-120 s<\/td>\n      <td>2-3<\/td>\n      <td><strong>Tr\u00e1fico<\/strong>-Observar los picos<\/td>\n    <\/tr>\n    <tr>\n      <td>Grande<\/td>\n      <td>10.000+<\/td>\n      <td>6.000\u201310.000<\/td>\n      <td>45\u2013120 s<\/td>\n      <td>120\u2013300 s<\/td>\n      <td>3+<\/td>\n      <td>RAM y E\/S limitadas <strong>consulte<\/strong><\/td>\n    <\/tr>\n    <tr>\n      <td>Implementaciones frecuentes<\/td>\n      <td>variable<\/td>\n      <td>adaptado<\/td>\n      <td>20\u201345 s<\/td>\n      <td>15\u201360 s<\/td>\n      <td>2-3<\/td>\n      <td>Frescura ante <strong>Tasa de aciertos<\/strong><\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Lista de comprobaci\u00f3n para la implantaci\u00f3n<\/h2>\n\n<p>Estoy preparando un... <strong>Plan<\/strong> Primero: defino los directorios en los que resulta \u00fatil el almacenamiento en cach\u00e9 de metadatos y delimito las zonas din\u00e1micas. A continuaci\u00f3n, establezco unos valores iniciales conservadores y compruebo la configuraci\u00f3n con el comando \u00abnginx -t\u00bb. Reinicio NGINX, observo las latencias y reviso los registros y las m\u00e9tricas del sistema. A continuaci\u00f3n, ajusto los par\u00e1metros max, inactive, valid y min_uses en peque\u00f1os pasos. Por \u00faltimo, documento los valores definitivos para cada entorno y guardo los cambios con un n\u00famero de versi\u00f3n.<\/p>\n\n<p>Tengo preparada una opci\u00f3n de reversi\u00f3n por si los resultados no son los esperados. En el caso de las rutas 404 recurrentes, decido por separado si almaceno los errores en la cach\u00e9 de forma temporal. Describo las responsabilidades: qui\u00e9n modifica los valores, qui\u00e9n realiza las mediciones y qui\u00e9n aprueba las versiones. En las implementaciones con muchos medios, establezco puntos de referencia en funci\u00f3n del tr\u00e1fico m\u00e1ximo. As\u00ed procedo de forma planificada y consigo resultados sostenibles <strong>Resultados<\/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-cache-optimierung-1045.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Seleccionar correctamente el \u00e1mbito de aplicaci\u00f3n: http, servidor o ubicaci\u00f3n<\/h2>\n\n<p>Activo la cach\u00e9 de archivos abiertos all\u00ed donde se aprecia una mejora cuantificable. Aplicarla de forma global a nivel HTTP resulta c\u00f3modo, pero a menudo es demasiado general. Es mejor una <strong>Definici\u00f3n del alcance<\/strong> por servidor o ubicaci\u00f3n. De este modo, las \u00e1reas din\u00e1micas no se ven afectadas y los directorios est\u00e1ticos se benefician al m\u00e1ximo. Para las rutas de API o de administraci\u00f3n, desactivo la cach\u00e9; para las rutas de recursos, la activo y la configuro a medida.<\/p>\n\n<pre><code>http {\n    # Est\u00e1ndar: desactivado, para que las zonas din\u00e1micas permanezcan neutras\n    open_file_cache off;\n\n server {\n root \/var\/www\/site;\n\n        # Recursos est\u00e1ticos con perfil propio\n location ^~ \/assets\/ {\n open_file_cache max=6000 inactive=60s;\n open_file_cache_valid 120s;\n open_file_cache_min_uses 2;\n            open_file_cache_errors off;\n try_files $uri =404;\n }\n\n # Din\u00e1mico: no se necesita cach\u00e9 de archivos abiertos\n location \/api\/ {\n proxy_pass http:\/\/backend;\n }\n    }\n}<\/code><\/pre>\n\n<p>Empiezo con unas pocas ubicaciones bien definidas y voy ampliando poco a poco. De este modo, los efectos resultan comprensibles y evito interacciones no deseadas entre las reglas.<\/p>\n\n<h2>Arquitectura multiproceso: la RAM y los l\u00edmites a la vista<\/h2>\n\n<p>NGINX funciona con varios <strong>Trabajadores<\/strong>, y cada worker gestiona su propia cach\u00e9 de archivos abiertos. Esto significa que el n\u00famero m\u00e1ximo de entradas se multiplica por el n\u00famero de workers. Con cuatro workers y un m\u00e1ximo de 5.000 entradas, se pueden alcanzar potencialmente hasta 20.000 entradas en el espacio de procesos. Por lo tanto, tengo previsto utilizar RAM <em>por trabajador<\/em> y observa las curvas reales. Cada entrada genera unos cientos de bytes de metadatos y estructuras administrativas, adem\u00e1s de los costes de los descriptores abiertos.<\/p>\n\n<p>Adem\u00e1s, presento la <strong>L\u00edmites de descriptores de archivos<\/strong> ajustado (en todo el sistema y para el proceso de NGINX). Si el l\u00edmite no es suficiente, los manejadores abiertos pueden fallar y la cach\u00e9 deja de ser efectiva. Compruebo el valor de `ulimit -n` para el usuario de NGINX y, si es necesario, utilizo `worker_rlimit_nofile` para amortiguar los picos de forma segura. Compruebo el n\u00famero real de archivos abiertos con `lsof` o mediante las estad\u00edsticas de procesos, para no limitarme a hacer estimaciones, sino saberlo con certeza.<\/p>\n\n<h2>Enlaces simb\u00f3licos, alias y try_files: detalles con gran impacto<\/h2>\n\n<p>En la pr\u00e1ctica, a menudo se dan casos en los que <strong>Symlinks<\/strong>, \u00abalias\u00bb y \u00abtry_files\u00bb juntos. Me aseguro de utilizar \u00abalias\u00bb correctamente (con la sem\u00e1ntica adecuada de las barras) y de evitar los escollos. Los destinos de los enlaces simb\u00f3licos pueden cambiar entre versiones, mientras que NGINX sigue manteniendo los metadatos en la cach\u00e9. Esto es intencionado, siempre y cuando el intervalo \u00abvalid\u00bb sea lo suficientemente corto. En el caso de rutas sensibles, aplico una medida de seguridad adicional con \u00abdisable_symlinks if_not_owner\u00bb.<\/p>\n\n<pre><code>location \/media\/ {\n    El alias # debe ajustarse al estilo del directorio (\u00a1barra al final!)\n    alias \/mnt\/storage\/media\/;\n    disable_symlinks if_not_owner from=\/mnt\/storage;\n    open_file_cache max=8000 inactive=90s;\n    open_file_cache_valid 60s;\n    try_files $uri =404;\n}<\/code><\/pre>\n\n<p>En try_files establezco alternativas claras y evito las cadenas que provocan b\u00fasquedas m\u00faltiples. Las rutas coherentes (root\/alias) y una gesti\u00f3n clara de los errores reducen los resultados negativos innecesarios en la cach\u00e9. De este modo, las b\u00fasquedas siguen siendo r\u00e1pidas y transparentes.<\/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-cache-optimierung-1045.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Implementaciones sin reinicio en fr\u00edo: gestionar la actualidad<\/h2>\n\n<p>En <strong>Tiempo de inactividad cero<\/strong>-En las implementaciones, suelo cambiar un enlace simb\u00f3lico (p. ej., current \u2192 releases\/123). La cach\u00e9 de archivos abiertos conserva los metadatos antiguos hasta la siguiente validaci\u00f3n. Lo controlo de forma deliberada: o bien establezco un valor m\u00e1s corto para open_file_cache_valid (p. ej., entre 5 y 15 s) en torno al momento de la implementaci\u00f3n, o bien reinicio NGINX tras el cambio. Al reiniciar, se inician nuevos trabajadores que generan los metadatos actualizados, mientras que los trabajadores antiguos siguen procesando las solicitudes correctamente. De este modo, la entrega se mantiene estable y la <strong>Frescura<\/strong> alto.<\/p>\n\n<p>En el caso de conjuntos de activos muy grandes, puedo identificar las rutas m\u00e1s solicitadas posteriormente <em>calentar el motor<\/em> (por ejemplo, mediante un escaneo breve), para que las entradas m\u00e1s importantes se almacenen en la cach\u00e9 lo antes posible. Sin embargo, lo mantengo a un nivel m\u00ednimo para no generar picos de E\/S de forma artificial.<\/p>\n\n<h2>Opciones del sistema de archivos y de montaje: peque\u00f1os ajustes, gran impacto<\/h2>\n\n<p>Presto atenci\u00f3n a <strong>noatime\/nodiratime<\/strong> al montar vol\u00famenes locales. De este modo, los accesos evitan actualizaciones innecesarias del atributo \u00abatime\u00bb y reducen la E\/S. En NFS, la estrategia de cach\u00e9 de atributos (por ejemplo, \u00abactimeo\u00bb) influye en la <em>aparente<\/em> Actualidad: elijo valores que se ajusten a \u00abvalid\u00bb para evitar inconsistencias. Para los datos de producci\u00f3n, apuesto por sistemas de archivos maduros (como ext4 o xfs) y vigilo las reservas de inodos. Los vol\u00famenes desbordados o muy fragmentados suponen una p\u00e9rdida de tiempo, independientemente de NGINX.<\/p>\n\n<p>En contenedores con sistemas de archivos overlay, eval\u00fao el efecto de la cach\u00e9 de archivos abiertos <strong>bajo carga<\/strong>, no en modo inactivo. La organizaci\u00f3n en capas puede encarecer el acceso a los metadatos; por eso, ajusto los par\u00e1metros \u00abinactive\u00bb y \u00abvalid\u00bb de forma bastante conservadora y me centro en los \u00abhotsets\u00bb.<\/p>\n\n<h2>Compresi\u00f3n y variantes est\u00e1ticas: gzip_static, Brotli y Ranges<\/h2>\n\n<p>Siempre que puedo, utilizo, <strong>gzip_static<\/strong> (y, de forma an\u00e1loga, Brotli), para servir directamente archivos comprimidos previamente. La cach\u00e9 de archivos abiertos (Open File Cache) tambi\u00e9n almacena los metadatos para las variantes .gz\/.br; min_uses filtra los casos excepcionales poco comunes. Las solicitudes de rango se benefician de unos metadatos estables (tama\u00f1o, mtime), junto con sendfile y una configuraci\u00f3n adecuada de tcp_nopush\/tcp_nodelay.<\/p>\n\n<pre><code>location ~* \\.(?:css|js|svg|json|txt)$ {\n    gzip_static on;  # dar prioridad a los archivos .gz existentes\n    sendfile on;\n    tcp_nopush on;\n    open_file_cache max=4000 inactive=45s;\n    open_file_cache_valid 90s;\n    open_file_cache_min_uses 2;\n}<\/code><\/pre>\n\n<p>Mantengo la coherencia entre ETag y Last-Modified. De este modo, los clientes pueden revalidar de forma eficiente y NGINX tiene que acceder con menos frecuencia al sistema de archivos. La cach\u00e9 de archivos abiertos proporciona r\u00e1pidamente los metadatos necesarios para ello.<\/p>\n\n<h2>An\u00e1lisis en profundidad y resoluci\u00f3n de problemas: lo que compruebo concretamente<\/h2>\n\n<ul>\n  <li>Llamadas al sistema: A modo de prueba, conecto strace a un trabajador (por ejemplo, -e trace=open,stat) y comparo la frecuencia antes y despu\u00e9s de la activaci\u00f3n.<\/li>\n  <li>Carga de E\/S: la orden \u00abiostat -xz\u00bb, ejecutada a intervalos cortos, muestra si los tiempos de espera y la profundidad de las colas se reducen.<\/li>\n  <li>Rutas err\u00f3neas: los registros me indican si se producen errores 404 recurrentes. Estas rutas cumplen los requisitos para la activaci\u00f3n temporal de \u00aberrors on\u00bb, de forma puntual.<\/li>\n  <li>L\u00edmites de FD: lsof -p  | wc -l me da una cifra astron\u00f3mica del n\u00famero de descriptores abiertos.<\/li>\n  <li>Almacenamiento: Realizo un seguimiento de los RSS por trabajador y lo correlaciono con el valor m\u00e1ximo y la tasa de aciertos de las solicitudes est\u00e1ticas.<\/li>\n<\/ul>\n\n<p>Si se producen latencias inesperadas, lo primero que compruebo es si \u00abvalid\u00bb es demasiado corto (demasiados reinicios) o si \u00abinactive\u00bb es demasiado largo (archivos inactivos). Elimino de la cach\u00e9 los directorios problem\u00e1ticos y vuelvo a medir. As\u00ed consigo aislar r\u00e1pidamente las causas.<\/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_performance_5793.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Aspectos de seguridad y fronteras limpias<\/h2>\n\n<p>Separo <strong>borrar<\/strong> distingo entre rutas p\u00fablicas e internas y desactivo la autoindexaci\u00f3n. En el caso de los alias y los enlaces simb\u00f3licos, aplico variantes restrictivas (if_not_owner) para evitar recorridos no deseados. Solo activo el almacenamiento en cach\u00e9 de errores cuando comprendo perfectamente su comportamiento. En entornos multitenant, a\u00edslo las cach\u00e9s por vHost para evitar solapamientos. Unos l\u00edmites bien definidos tambi\u00e9n ayudan a la depuraci\u00f3n, ya que me permiten atribuir mejor los efectos a cada zona.<\/p>\n\n<h2>Pasos adicionales para el ajuste<\/h2>\n\n<p>Miro m\u00e1s all\u00e1 del <strong>Cach\u00e9 de archivos<\/strong> Adem\u00e1s, ajusto los par\u00e1metros de red y TLS. La configuraci\u00f3n de Keepalive, el uso de HTTP\/2 o HTTP\/3 y unos tiempos de espera razonables influyen significativamente en las latencias totales. Para archivos grandes, compruebo sendfile, aio y los tama\u00f1os de los b\u00faferes de salida. Establezco l\u00edmites razonables para los tama\u00f1os de los encabezados y el cuerpo, para que las solicitudes at\u00edpicas no lo bloqueen todo. Adem\u00e1s, mantengo el registro de forma selectiva para reducir al m\u00ednimo la sobrecarga. <strong>mantenga<\/strong>.<\/p>\n\n<p>En cuanto a las aplicaciones, organizo las cach\u00e9s est\u00e1ticas y din\u00e1micas de manera que no interfieran entre s\u00ed. El control de versiones de los activos a largo plazo mediante hash reduce las revalidaciones y permite que las cach\u00e9s de los clientes tengan una mayor duraci\u00f3n. Para las API, establezco reglas breves y claras, y ejecuto los archivos est\u00e1ticos por separado. Separo las instancias de NGINX por caso de uso cuando el aislamiento aporta ventajas. Mantener el orden en la configuraci\u00f3n ahorra tiempo tanto en el funcionamiento como en la resoluci\u00f3n de errores.<\/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_file_cache_performance_6789.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Brevemente resumido<\/h2>\n\n<p>Con un <strong>Abrir<\/strong> Con la cach\u00e9 de archivos reduzco los accesos al sistema de archivos, ahorro tiempo de CPU y sirvo los archivos est\u00e1ticos m\u00e1s r\u00e1pido. Empiezo con valores moderados, mido los efectos reales y luego voy ajustando gradualmente los par\u00e1metros \u00abmax\u00bb, \u00abinactive\u00bb, \u00abvalid\u00bb y \u00abmin_uses\u00bb. Los directorios est\u00e1ticos se benefician de ello, mientras que los puntos finales din\u00e1micos los dejo fuera. Junto con sendfile, el ajuste de b\u00faferes, la compresi\u00f3n y unos l\u00edmites del sistema bien definidos, mejoro notablemente el rendimiento general. De este modo, NGINX se convierte en un servidor fiable <strong>Base<\/strong> para una entrega r\u00e1pida y respetuosa con los recursos.<\/p>","protected":false},"excerpt":{"rendered":"<p>Configura correctamente la cach\u00e9 de archivos abiertos de NGINX y mejora el rendimiento de tu servidor con los mejores par\u00e1metros.<\/p>","protected":false},"author":1,"featured_media":20891,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[834],"tags":[],"class_list":["post-20898","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":"168","_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 Cache","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":"20891","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20898","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=20898"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20898\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20891"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20898"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20898"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20898"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}