# Monitorización ETag: una cabecera no-cache cambió nuestros resultados

Source: https://ipvolt.com/es/blog/etag-monitoring-cache-control
Markdown: https://ipvolt.com/es/blog/etag-monitoring-cache-control.md
Language: es

[Inicio de ipvolt](https://ipvolt.com/es.md) / [Blog](https://ipvolt.com/es/blog.md) / Monitorización ETag: una cabecera no-cache cambió nuestros resultados

Análisis
Publicado: 2026-09-11
Actualizado: 2026-09-11
Por ipvolt team
8 min de lectura

Una prueba real con proxy mostró que una cabecera de petición convirtió respuestas 304 en descargas completas. Revisa bytes medidos, políticas y datos reproducibles.

Antes de comprar más tráfico de proxy para un monitor de contenido, inspecciona las cabeceras que tu cliente envía realmente. En nuestro sitio web en producción, añadir `Cache-Control: no-cache` convirtió las comprobaciones de páginas sin cambios de respuestas `304` sin cuerpo en descargas `200` completas, aunque las peticiones llevaban el ETag coincidente.

En una comparación controlada, **12 peticiones condicionales sin esa cabecera adicional transfirieron cero bytes de cuerpo de respuesta; 12 con ella transfirieron 271.968 bytes de HTML sin cambios.** Las seis descargas iniciales necesarias para obtener los ETags costaron otros 135.984 bytes y están incluidas en los registros publicados.

Es un hallazgo sobre un sitio Next.js 16.3.4 desplegado y una política de peticiones concreta. No es un consejo para eliminar los requisitos de frescura de un monitor. La decisión útil es si cambiar la política del cliente, elegir una representación más pequeña o investigar el comportamiento de revalidación del servidor.

## La tarea: monitorizar contenido conocido sin descargarlo innecesariamente

Probamos dos artículos existentes de ipvolt: la [guía de benchmarks de proxy](/es/blog/what-a-proxy-benchmark-should-measure) y la [explicación de errores de proxy](/es/blog/proxy-status-codes-407-429-502), cada uno como HTML y como Markdown. Nuestro monitor vigilaba el título del artículo y dos encabezados de sección especificados. También comprobaba los tipos de medio y, para HTML, el título de la página y la URL canónica.

Esas comprobaciones establecen que la información vigilada está presente. No convierten a Markdown en un sustituto del diseño, del comportamiento de JavaScript ni de un flujo de registro funcional. Las aserciones exactas están en la [configuración del estudio](https://ipvolt.com/downloads/content-monitoring/main-study.json).

La recopilación usó conexiones de proxy de terceros autenticadas dirigidas a EE. UU., Reino Unido y Países Bajos. El experimento inicial también incluyó un control directo. Las respuestas de comprobación de país informaron de los países solicitados en los puntos de control; una dirección de salida cambió durante la ejecución inicial de EE. UU., así que se trata de observaciones de ruta y no de resultados de fiabilidad de IP fija o de todo un país. Se omite el proveedor de la conexión; esto no fue una prueba de un servicio de proxy de ipvolt disponible.

Los tres experimentos HTTP se ejecutaron el 11 de septiembre de 2026. Realizaron **234 peticiones y transfirieron 2.975.066 bytes de cuerpo de respuesta**, incluidas descargas iniciales, descargas de verificación e hipótesis fallidas. Todas las peticiones intentadas se completaron sin error de transporte de curl. Las sondas geográficas adicionales y el QA de navegador se registran por separado en la [nota de método](https://ipvolt.com/downloads/content-monitoring/method.json); quedan fuera de ese total del experimento HTTP.

## La primera descarga más pequeña no respondió a la pregunta sobre la caché

El experimento inicial solicitó gzip de forma consistente y midió los bytes de cuerpo recibidos. En doce observaciones iniciales por representación, los tamaños fueron:

| Representación del artículo | Bytes de cuerpo recibidos por petición inicial |
| --- | ---: |
| HTML del benchmark | 26.521 |
| Markdown del benchmark | 7.056–7.061 |
| HTML de la guía de errores | 18.807 |
| Markdown de la guía de errores | 5.081 |

Ambos endpoints HTML proporcionaron ETags. Ninguno de los endpoints Markdown proporcionó un validador ETag ni Last-Modified en este experimento. Las comprobaciones condicionales de HTML sin cabecera Cache-Control adicional devolvieron `304`; el ejecutor reutilizó el cuerpo coincidente aceptado previamente en lugar de interpretar la respuesta vacía como un documento nuevo.

La ejecución exploratoria realizó 144 peticiones: 120 respuestas `200` completas y 24 respuestas `304` aceptadas. Omitió 36 ranuras condicionales porque el Markdown no tenía validador o la página de inicio estaba marcada como `no-store`. Las peticiones omitidas no se cuentan como éxitos ni como observaciones de red de cero bytes.

Después ejecutamos cinco comprobaciones sucesivas por representación a través de cada una de las tres rutas de proxy. Cada comprobación enviaba explícitamente `Cache-Control: no-cache`, y el cliente conservaba los validadores elegibles entre comprobaciones. Las 60 peticiones devolvieron `200`, incluidas las 24 recomprobaciones de HTML que llevaban un ETag coincidente. La expectativa de que la validación repetida de HTML evitaría descargar el cuerpo no se cumplió bajo esta política.

## Aislar la cabecera que cambió la respuesta

Para investigar, mantuvimos constantes la URL, la configuración de ruta, Accept, el idioma, la preferencia de gzip y el ETag semilla exacto. Para cada una de las seis combinaciones ruta/artículo, hicimos una petición semilla y cuatro peticiones condicionales. El orden fue A/B/B/A o B/A/A/B, donde A omitía la cabecera Cache-Control adicional y B enviaba `no-cache`.

| Política de la petición condicional | Intentos | Respuestas | Bytes de cuerpo recibidos |
| --- | ---: | --- | ---: |
| If-None-Match coincidente; sin cabecera Cache-Control adicional | 12 | 12 × 304 | 0 |
| Mismo If-None-Match; Cache-Control: no-cache | 12 | 12 × 200 | 271.968 |

Las 24 observaciones condicionales coincidieron con los valores vigilados y el contenido decodificado de la semilla. Incluidas las seis semillas, este experimento controlado transfirió 407.952 bytes de cuerpo en 30 peticiones. Usó un orden equilibrado, no un muestreo aleatorio, y establece el comportamiento observado de estos endpoints durante esta breve ventana.

La implementación explica un mecanismo plausible. Comparamos los archivos de dependencias realmente desplegados con la instalación local de Next.js 16.3.4: los hashes de los archivos fuente relevantes coincidieron. Su helper de respuesta con ETag llama a `fresh` antes de devolver `304`; la comprobación de frescura incluida devuelve false cuando la petición contiene `no-cache`, antes de evaluar el ETag coincidente. Una prueba local independiente de la función reprodujo la misma rama. [Helper de respuesta de Next.js](https://github.com/vercel/next.js/blob/v16.3.4/packages/next/src/server/send-payload.ts), [implementación de fresh](https://github.com/jshttp/fresh/blob/v0.5.2/index.js).

Es un comportamiento específico del stack, coherente con los resultados en producción. HTTP no define `no-cache` como una instrucción universal para descargar un cuerpo completo. Recibir `304` tampoco demuestra que la petición llegara al origen y no a una caché que respondió. [Caché HTTP](https://www.rfc-editor.org/rfc/rfc9111.html).

## La optimización útil depende de la frescura que necesitas

Para el experimento de cinco comprobaciones que usó explícitamente `no-cache`, los totales reales fueron:

| Representación | Peticiones, incluidas las descargas iniciales | Bytes de cuerpo recibidos |
| --- | ---: | ---: |
| HTML | 30 | 679.920 |
| Markdown | 30 | 182.070 |
| Diferencia | Mismo número de peticiones | 497.850 |

**Markdown transfirió un 73,2 % menos de bytes de cuerpo de respuesta para el contenido vigilado bajo esa política.** No redujo el número de peticiones. Son diferencias de carga útil medidas, no un ahorro medido en la factura ni una previsión de tráfico mensual. La métrica de tamaño de descarga de curl excluye las cabeceras y otra sobrecarga de red. [Contabilidad de carga útil de curl](https://curl.se/libcurl/c/CURLINFO_SIZE_DOWNLOAD_T.html).

Hay otra opción cuando los requisitos de frescura lo permiten: las respuestas Markdown anunciaban `public, max-age=300, must-revalidate`. Una caché puede reutilizar una representación almacenada todavía fresca sin hacer una petición. La ausencia de validadores no la hace no cacheable. Nuestros ejecutores comprobaron deliberadamente a través de la red; no implementaron esa política de programación basada en la frescura. [Frescura y reutilización](https://www.rfc-editor.org/rfc/rfc9111.html#section-4).

Usa el resultado para elegir la siguiente acción:

| Tu requisito de monitorización | Acción respaldada por este caso |
| --- | --- |
| La reutilización dentro de la ventana de frescura del servidor es aceptable | Evalúa una caché local consciente de la frescura antes de programar otra descarga. |
| Pedir al servidor o a la caché que responde que valide cada comprobación | Prueba las cabeceras finales de la petición contra el endpoint real; no des por hecho que un ETag garantiza una respuesta sin cuerpo. |
| Necesitas el texto vigilado, y cada comprobación devuelve un cuerpo completo | Compara el HTML comprimido con una representación de texto o Markdown que contenga esos mismos datos. |
| Necesitas el diseño renderizado o un flujo interactivo | Mantén las comprobaciones con navegador; la representación de texto más pequeña no cubre esa tarea. |

No elimines `no-cache` solo para reproducir la fila de cero bytes. Las dos políticas de cabeceras pueden tener consecuencias distintas para la frescura. Establece qué debe detectar tu monitor y luego mide la implementación permitida.

## Reproduce el resultado y adapta la comprobación

Descarga [el script de análisis offline](https://ipvolt.com/downloads/content-monitoring/reproduce.py) y [las grabaciones saneadas](https://ipvolt.com/downloads/content-monitoring/recordings.zip) en el mismo directorio. Basta con Python 3.10 o posterior; este comando no realiza peticiones de red:

```sh
python3 reproduce.py recordings.zip
```

Recalcula los recuentos de intentos, los totales de cuerpo, la comparación de cabeceras y el porcentaje de Markdown. Compara su salida con [el resultado registrado](https://ipvolt.com/downloads/content-monitoring/results.json). El conjunto de datos incluye marcas de tiempo, políticas de petición, cabeceras de respuesta seleccionadas, comprobaciones de contenido y hashes. Las credenciales, las IP de salida, las cabeceras sin filtrar y las capturas de cuerpo sin procesar siguen siendo privadas; la reproducción verifica la aritmética publicada en lugar de autenticar de forma independiente las respuestas históricas.

Las [instrucciones de descarga](https://ipvolt.com/downloads/content-monitoring/README.md) enlazan los programas de recopilación exactos, las configuraciones y 27 pruebas offline superadas. Los programas en vivo requieren curl 8.4 o posterior, conservan la verificación TLS, acotan las peticiones y la transferencia de cuerpo, y pasan la autenticación del proxy de forma privada a través de la entrada de curl. Su lista de permitidos está restringida al sitio público de este caso; adapta tanto la lista de permitidos como las aserciones de contenido para una propiedad que operes.

No observamos una actualización real de contenido ni medimos el retraso de detección. El contenido decodificado se mantuvo estable en todos los endpoints probados; algunos flujos de bytes gzip difirieron a pesar de que el texto decodificado era idéntico. Eso es una razón para comparar el contenido que le importa a tu monitor, no una evidencia de que este estudio eliminara las falsas alertas operativas. Es un sitio, dos artículos y una breve ventana de observación, no una clasificación de proveedores ni un benchmark universal de caché.

*Método: recopilación y análisis asistidos por agente, con revisiones independientes de evidencia, editorial y de búsqueda. Todas las observaciones de red informadas se ejecutaron realmente; las pruebas offline ejercitan fixtures controlados y están etiquetadas por separado.*

[Avísame cuando se abra el acceso](/es/blog/etag-monitoring-cache-control#waitlist-blog-end). Un correo cuando se abra el acceso. Nada más.

## Fuentes

- [RFC 9110: If-None-Match and conditional requests](https://www.rfc-editor.org/rfc/rfc9110.html#section-13.1.2)
- [RFC 9111: request and response cache directives](https://www.rfc-editor.org/rfc/rfc9111.html)
- [curl: downloaded response-body size](https://curl.se/libcurl/c/CURLINFO_SIZE_DOWNLOAD_T.html)
- [Next.js 16.3.4: ETag response handling](https://github.com/vercel/next.js/blob/v16.3.4/packages/next/src/server/send-payload.ts)
- [fresh 0.5.2: request freshness evaluation](https://github.com/jshttp/fresh/blob/v0.5.2/index.js)

## Entérate cuando se abra el acceso a ipvolt.

Ya que estás aquí

ipvolt está en desarrollo. Deja tu correo y te avisaremos una sola vez cuando se abra el acceso.

Un correo cuando se abra el acceso. Nada más.

[Solicitar acceso anticipado](https://ipvolt.com/es/blog/etag-monitoring-cache-control#waitlist-blog-end)

[Privacidad](https://ipvolt.com/privacy)


## Artículos relacionados

- [Configurar proxies en MostLogin: añadir, probar y compartir](https://ipvolt.com/es/blog/mostlogin-proxy-setup.md) (Análisis, 17 sept 2026, 9 min de lectura): Añade un proxy a los perfiles de MostLogin paso a paso: protocolo, host y puerto, credenciales, comprobación de IP, acceso del equipo, importación masiva y errores.
- [Precios en Amazon: tu oferta frente a la Oferta Destacada](https://ipvolt.com/es/blog/amazon-offer-vs-featured-offer.md) (Análisis, 16 sept 2026, 7 min de lectura): Compara tu oferta de Amazon con la Oferta Destacada usando contexto emparejado, envío conocido y un modelo offline probado que conserva los datos ausentes.
- [Actualizaciones de listings en Amazon: aceptado no es activo](https://ipvolt.com/es/blog/amazon-listing-update-reconciliation.md) (Análisis, 14 sept 2026, 9 min de lectura): Diagnostica actualizaciones de listings de Amazon aceptadas separando atributos enviados, ofertas activas, inventario y comprabilidad, con una matriz de conciliación.

## Guías relacionadas

- [Usar un proxy con curl: -x, variables de entorno, SOCKS5 y auth](https://ipvolt.com/es/guides/curl-proxy-setup.md): Cómo usar un proxy con curl: la opción -x, las variables http_proxy y https_proxy, SOCKS5 con socks5h, autenticación del proxy y cómo leer los errores CONNECT y 407.
- [Proxy en Python Requests: diccionario proxies, auth, SOCKS5](https://ipvolt.com/es/guides/python-requests-proxy.md): Configura un proxy en Python Requests: el diccionario proxies, ajustes de Session, credenciales, SOCKS5 con requests[socks], variables de entorno y ProxyError.
- [Diagnostica los timeouts de proxy etapa por etapa](https://ipvolt.com/es/guides/proxy-timeout-troubleshooting.md): Separa los retrasos de DNS, TCP, CONNECT, TLS y respuesta del proxy con los tiempos de curl, define plazos por petición y decide si un reintento es seguro.

## Sobre ipvolt

Análisis técnico del equipo de ipvolt.

El acceso a ipvolt aún no está abierto.

[Leer el original en inglés](https://ipvolt.com/blog/etag-monitoring-cache-control.md)