# Mitigación de errores de upstream response buffered to a temporary file en Nginx con WordPress y Google Site Kit

- Link: https://binariocero.com/linux/mitigacion-de-errores-de-upstream-response-buffered-to-a-temporary-file-en-nginx-con-wordpress-y-google-site-kit
- Published: 2025-09-13T08:22:08+02:00
- Author: Juan José Fernández Durán

![Loading](https://binariocero.com/wp-content/plugins/page-views-count/ajax-loader-
2x.gif)

En entornos donde Nginx actúa como **proxy inverso** frente a aplicaciones web, 
es frecuente encontrar en el registro de errores advertencias como la siguiente:

    ```wp-block-code
    2025/09/11 07:38:05 [warn] 5253#5253: *68506 an upstream response is buffered to a temporary file /var/lib/nginx/proxy/1/80/0000007801 while reading upstream, client: 46.37.64.126, server: binariocero.com, request: "GET /wp-json/google-site-kit/v1/modules/pagespeed-insights/data/pagespeed?strategy=desktop..."
    ```

Este mensaje indica que la **respuesta del servidor backend (upstream)** es demasiado
grande para caber en los buffers configurados de Nginx. Como consecuencia, Nginx
vuelca la respuesta parcial a un **archivo temporal en disco** hasta poder transmitirla
al cliente.

Aunque no se trata de un error crítico —la petición se sirve correctamente— puede
tener efectos negativos:

 * **Incremento de latencia** en las respuestas.
 * **Carga de I/O en disco**, con riesgo de cuello de botella en servidores con 
   pocos recursos.
 * **Advertencias constantes en los logs**, que dificultan la detección de problemas
   reales.

## Causas más habituales

 1. **Buffers insuficientes**: los valores de `proxy_buffer_size`, `proxy_buffers` 
    o `proxy_busy_buffers_size` son demasiado pequeños.
 2. **Respuestas muy grandes**: APIs como Google Site Kit (`/wp-json/google-site-kit/...`)
    devuelven JSON voluminosos.
 3. **Diseño por defecto**: Nginx prioriza la eficiencia en memoria y, por defecto,
    utiliza disco como respaldo cuando la respuesta excede los buffers.

## Estrategias de solución

### 1. Desactivar el buffering para endpoints específicos (recomendado)

Si las advertencias provienen siempre de una ruta concreta (ej. la API de Google
Site Kit), lo más eficiente es **desactivar el buffering únicamente en ese `location`**.
De esta forma, Nginx transmite la respuesta en streaming directamente al cliente,
sin usar archivos temporales ni afectar al resto del tráfico.

    ```wp-block-code
    server {
        server_name example.com;

        # ... configuración general del sitio ...

        # Evitar buffering y cacheo en Google Site Kit
        location ~ ^/wp-json/google-site-kit/ {
            proxy_pass https://192.168.78.65:443;

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

            proxy_ssl_server_name on;

            # Clave: sin buffering
            proxy_buffering off;
            proxy_request_buffering off;

            # Evitar cachear estas respuestas
            proxy_no_cache 1;
            proxy_cache_bypass 1;

            # Aumentar el tiempo de espera por si la API tarda
            proxy_read_timeout 300;
        }
    }
    ```

**Ventajas:**

 * Reduce I/O en disco.
 * Mantiene el consumo de memoria controlado (no afecta a todo el tráfico).
 * Soluciona las advertencias sin cambios globales.

### 2. Ajustar los buffers de Nginx

Si el problema afecta a varias rutas o aplicaciones, otra opción es **aumentar los
buffers** para que las respuestas más grandes quepan en memoria sin volcarse a disco.

En el bloque `http {}` del `nginx.conf`:

    ```wp-block-code
    proxy_buffer_size       64k;
    proxy_buffers           16 64k;
    proxy_busy_buffers_size 128k;
    # Opcional para limitar escritura a disco:
    # proxy_temp_file_write_size 128k;
    ```

**Ventajas:**

 * Menos advertencias en los logs.
 * Reducción de escrituras a disco.

**Inconvenientes:**

 * Aumenta el consumo de RAM en cada conexión proxy.
 * Puede impactar negativamente en servidores con recursos limitados (ej. 2 GB de
   RAM).

### 3. Deshabilitar el uso de archivos temporales

Otra medida complementaria es forzar a Nginx a no utilizar archivos temporales en
disco:

    ```wp-block-code
    proxy_max_temp_file_size 0;
    ```

**Atención:** si se combina con buffers pequeños, las respuestas demasiado grandes
serán interrumpidas con error `502 Bad Gateway`. Por ello solo se recomienda si 
se han dimensionado adecuadamente los buffers.

## Validación de la configuración

Tras aplicar los cambios:

    ```wp-block-code
    nginx -t    # Validar sintaxis
    systemctl reload nginx
    ```

Para verificar, monitorizar los logs:

    ```wp-block-code
    tail -f /var/log/nginx/error.log | grep buffered
    ```

La ausencia de nuevos avisos confirma la mitigación.

## Conclusión

El warning _“an upstream response is buffered to a temporary file”_ en Nginx no 
es crítico, pero puede penalizar el rendimiento en servidores con recursos limitados.

La solución óptima en entornos WordPress con plugins como **Google Site Kit** consiste
en **desactivar el buffering para las rutas problemáticas**, manteniendo la eficiencia
y evitando un impacto global en memoria.

En casos donde múltiples aplicaciones generan respuestas grandes, puede ser necesario
complementar con **ajustes de buffers globales**.