Cómo interactúan la caché del navegador y las rutas proxy
Entiende las claves de caché HTTP, los cambios de ruta, los límites entre cachés privadas y compartidas y una forma segura de diagnosticar respuestas almacenadas.
Quieres la documentación estructurada de Red?
Este artículo forma parte de la biblioteca editorial. Para pasos de configuración, material de referencia y actualizaciones continuas, entra en la sección de docs.
Cambiar la ruta proxy no vacía automáticamente la caché HTTP del navegador. Si la solicitud sigue coincidiendo con la clave y la respuesta continúa siendo válida, el navegador puede reutilizarla después del cambio. El proxy afecta la ruta de una solicitud nueva, pero no reescribe una entrada ya guardada. Esta diferencia importa en QA regional, pruebas autorizadas de cuentas y comparaciones por rutas distintas.
La regla práctica es separar tres capas: caché del navegador, ruta proxy y caché del origen o intermediario. Decide qué capa es dueña de cada respuesta, registra la ruta que la obtuvo y comprueba la frescura antes de sacar conclusiones. Cambiar de ruta es un cambio de red; no es una orden de invalidación.
Qué guarda la caché del navegador
RFC 9111 define la caché HTTP. El navegador puede conservar una respuesta y reutilizarla cuando una solicitud posterior es compatible. La caché no es una segunda base de datos de páginas: contiene representaciones, metadatos y reglas de frescura que se consultan antes de acceder a la red.
El método y el URI son el inicio de la búsqueda. Una respuesta GET suele ser almacenable si las directivas lo permiten; una respuesta POST necesita reglas explícitas. El estado, Vary, autorización, validadores, directivas de frescura y el modo de caché solicitado pueden cambiar el resultado. El navegador también aplica particionado y expulsión por presión de almacenamiento.
Cache-Control: max-age y Expires indican una vida útil. Cuando termina, el navegador puede revalidar con If-None-Match o If-Modified-Since; un 304 Not Modified permite conservar el cuerpo guardado. no-store pide no conservar, mientras que no-cache exige revalidar antes de usar una entrada. No son sinónimos.
El encabezado Vary añade encabezados de solicitud a la clave. Una respuesta que varía por Accept-Language o Accept-Encoding no debe servir para otro valor. Vary no obliga a variar por la IP de salida. Si el origen sirve contenido regional, debe declarar esa dimensión mediante directivas adecuadas, URL versionadas u otro diseño compatible con la caché. Una ruta proxy por sí sola no es una clave de caché.
La caché privada del navegador pertenece a un perfil; una caché compartida de CDN o de proxy puede atender a muchos clientes y debe respetar reglas de autorización y privacidad. Una respuesta apta para una caché privada no siempre es apta para una compartida. La guía de caché HTTP de MDN explica esta diferencia.
Por qué una ruta nueva puede mostrar la respuesta anterior
Después de cargar una URL mediante el proxy A, el navegador puede tener una respuesta fresca. Si el contexto pasa al proxy B y se navega a la misma URL, la caché privada puede responder sin enviar nada a B. Mostrar el contenido obtenido por A no demuestra que el cambio de proxy haya fallado.
Cuando la entrada está obsoleta, la revalidación puede salir por B. Un 304 mantiene el cuerpo anterior; una respuesta completa lo reemplaza. El proxy cambia el camino de la revalidación o del fallo de caché, mientras que la caché decide si esa operación de red ocurre.
Un CDN o proxy de reenvío puede tener otra caché. El navegador puede fallar y el intermediario acertar, o el navegador puede acertar sin contactar al intermediario. Redirecciones, subrecursos y service workers añaden respuestas y almacenes independientes. Para una comparación regional, registra la secuencia completa y quién entregó cada recurso.
La respuesta recibida por B puede tener metadatos distintos de la recibida por A. Si la clave no distingue las representaciones, el navegador puede reutilizar una para la otra. El origen debe declarar las dimensiones que cambian su representación; el proxy no puede reparar una dimensión ausente después de guardar la respuesta.
Claves de caché, identidad y límites de la ruta
Separa cuatro preguntas: qué solicitud se busca, qué almacén hace la búsqueda, qué ruta llevaría una solicitud de red y quién puede recibir la respuesta. La URL no responde a todo. El método y algunos encabezados forman la clave; la partición y el perfil delimitan la propiedad del estado; el proxy decide el camino solo cuando existe una solicitud.
Una respuesta autenticada requiere cuidado. Authorization suele impedir compartirla salvo permiso explícito. Las cookies también pueden seleccionar una representación aunque no aparezcan en Vary, por lo que los datos de cuenta deben usar directivas privadas apropiadas. Reutilizar un perfil entre cuentas puede trasladar respuestas antiguas aunque cambie la ruta.
Asigna un dueño de caché a cada propósito de prueba. Un contexto de una cuenta no debe reciclarse para otra cuenta o región sin que el caso cubra expresamente esa continuidad. Un nuevo BrowserContext normalmente tiene cookies, almacenamiento y caché separados; cambiar su proxy no reinicia esos datos.
Un cambio de IP de salida no es por sí mismo un límite de privacidad. No elimina cookies, localStorage, IndexedDB, service workers ni la caché HTTP. Borrar la caché tampoco cambia el proxy, el resolver DNS o la cuenta. Consulta modelo de almacenamiento del navegador y configuración de proxy para mantener estos controles explícitos.
Para contenido regional, usa una página de prueba controlada que muestre una etiqueta de región y un identificador de representación. Registra URL, modo de caché, Age si existe, ETag, Cache-Control y la ruta de cualquier solicitud de red. No guardes el cuerpo privado ni credenciales.
Invalidación segura y diagnóstico
Empieza con una comprobación poco invasiva. Abre una página nueva en el mismo contexto y revisa el registro. Si la solicitud aparece como servida desde memoria o disco, el proxy no participó. Para observar la ruta, usa el modo de recarga documentado que revalida; no asumas que toda recarga implica una solicitud de red.
Para una comparación limpia, crea un BrowserContext nuevo con el proxy esperado y sin estado importado. Verifica la ruta en un recurso que controle tu organización y luego pide la URL de prueba, capturando solo estado, encabezados elegidos y la observación de ruta. Si el contexto nuevo difiere, el estado anterior probablemente influyó; si coincide, examina el origen o el intermediario.
Cuando una respuesta no debe persistir, el origen debe enviar la directiva Cache-Control correcta. El borrado del cliente ayuda durante una prueba, pero no arregla una política del servidor que coloca datos privados en una caché compartida. Prefiere URL versionadas o validadores para recursos, y directivas privadas o no-store para datos de cuenta.
Comprueba estos límites en orden:
- Navegador: ¿la entrada era fresca, se revalidó o la sirvió un service worker? ¿Ya estaba en el contexto?
- Proxy: ¿salió una solicitud por la ruta elegida? ¿Un intermediario añadió
Ageo su propio resultado de caché? - Origen: ¿declara las dimensiones que cambian la representación? ¿Son coherentes
Vary, autorización, cookies y directivas? - Prueba: ¿se comparan contextos, URL, métodos y encabezados equivalentes?
No intentes envenenamiento de caché, extracción de contenido privado ni inspección sin autorización. Usa solo recursos y cuentas que controle tu organización y detén la prueba si no está claro quién es dueño de la ruta o del estado.
Registro de comprobación
Conserva un registro breve: contexto, etiqueta de ruta, modo de caché, identificador de representación, estado de caché y el resultado de una solicitud de red conocida. Guarda únicamente encabezados necesarios y elimina cookies, credenciales y cuerpos privados. Si la observación sigue siendo inesperada en un contexto nuevo, entrega el registro al responsable del origen para revisar la política de caché en lugar de borrar estado repetidamente.
Encaje y límites de BotBrowser
BotBrowser puede dar a cada BrowserContext una sesión aislada y una ruta proxy documentada. Así, un equipo autorizado puede comparar cachés en contextos separados y asociar cada solicitud de red con su ruta. El proxy por contexto y el aislamiento del contexto mantienen juntos el estado y la ruta del caso de prueba. BotBrowser no puede controlar Cache-Control ni Vary del origen, no puede ordenar a una caché privada, CDN o intermediario que olvide una respuesta y no garantiza que cambiar de ruta invalide cachés del navegador, service worker, CDN o proxy. La propiedad e invalidación de la caché siguen siendo responsabilidad de la aplicación y de la prueba. Consulta la documentación de proxy por contexto y la configuración de proxy.
El propietario del origen debe decidir la política de retención del intermediario.
Una respuesta nueva puede cambiar su etiqueta de entidad, su edad o sus directivas. Compara esos campos antes de atribuir el cambio a la ruta.
Una respuesta obsoleta no es necesariamente inútil: puede validarse y conservar el cuerpo anterior cuando el servidor responde 304.
El modo de caché de una solicitud forma parte de la condición de prueba y debe registrarse junto con el método.
Un resultado de memoria o disco indica que no hubo solicitud de red para ese recurso.
Un service worker puede responder desde Cache Storage antes de que intervenga la caché HTTP.
La activación y la versión del service worker deben quedar en el registro cuando afectan a la prueba.
Las redirecciones tienen respuestas propias y pueden conservarse de forma independiente del documento final.
Cada imagen, script, fuente y llamada de API puede tener una decisión de caché distinta.
Un CDN puede entregar una respuesta compartida aunque el navegador no tenga una entrada local.
El encabezado Age ayuda a identificar una respuesta almacenada por un intermediario.
La ausencia de Age no demuestra que no haya intervenido un intermediario.
Una captura de pantalla no identifica quién entregó cada recurso de la página.
Las solicitudes en vuelo pueden terminar por la ruta anterior después de cambiar el proxy.
Espera a que termine la navegación antes de usarla como evidencia de la ruta nueva.
Pausa las tareas periódicas ligadas a la ruta antigua durante la transición.
Un contexto nuevo suele separar cookies, almacenamiento y caché del contexto anterior.
Cambiar el proxy de un contexto existente conserva su estado guardado.
Borrar la caché no borra necesariamente cookies ni el almacenamiento de la aplicación.
Borrar todos los datos del sitio cambia más condiciones que una invalidación HTTP.
Usa un origen de prueba controlado para comprobar la ruta sin exponer datos de clientes.
Una etiqueta de representación es más útil que conservar el cuerpo de una página.
Redacta valores de autorización, cookies y parámetros secretos antes de compartir un registro.
El propietario del origen debe declarar cada dimensión que cambia una representación.
Una cookie puede seleccionar una variante aunque no aparezca en Vary.
Los datos personalizados necesitan directivas que impidan su reutilización compartida.
Una caché privada no convierte en privada la caché de un proxy.
No repitas una operación que cambia el estado del servidor hasta conocer su resultado.
Un identificador de solicitud puede evitar un segundo envío accidental.
Un 404 puede ser una respuesta negativa almacenable y un 5xx puede proceder de varias capas.
El código de estado debe acompañarse del estado de caché y de la ruta observada.
Si la primera capa que difiere no está clara, detén la prueba y pide revisión al responsable.
Fuentes públicas
Para pruebas que incluyen cookies, consulta la documentación de gestión de cookies.
Artículos Relacionados
Lleva BotBrowser de la investigación a producción
Usa estas guías para entender el modelo y después avanzar hacia validación multiplataforma, contextos aislados y despliegue de navegador preparado para escalar.