Как кэш браузера взаимодействует с прокси
Разберите ключи HTTP-кэша, смену маршрута, границы частного и общего кэша и безопасную диагностику сохранённых ответов.
Нужна структурированная документация по теме Сеть?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
Смена прокси-маршрута сама по себе не очищает HTTP-кэш браузера. Если запрос по-прежнему совпадает с ключом и ответ считается свежим, браузер может использовать его после смены маршрута. Прокси меняет путь новой сетевой операции, но не переписывает уже сохранённую запись. Это важно для регионального QA, авторизованных проверок аккаунтов и сравнений нескольких маршрутов.
Практическое правило: рассматривайте кэш браузера, прокси-маршрут и кэш источника или посредника как отдельные слои. Укажите владельца ответа, запишите маршрут, через который он был получен, и проверьте свежесть до вывода. Смена маршрута меняет сеть, но не является командой инвалидирования кэша.
Что хранит кэш браузера
RFC 9111 определяет HTTP-кэширование. Браузер может сохранить ответ и использовать его для совместимого следующего запроса. Кэш не является второй базой страниц: это набор представлений, метаданных и сведений о свежести, который проверяется до обращения к сети.
Поиск начинается с метода и URI. Ответ GET обычно можно хранить, если это разрешают директивы; для POST нужны явные правила. На результат влияют статус, Vary, авторизация, валидаторы, директивы свежести и режим кэширования запроса. Браузер также применяет разделение хранилищ и удаление записей при нехватке места.
Cache-Control: max-age и Expires задают срок действия. После его окончания браузер может выполнить условную проверку через If-None-Match или If-Modified-Since; ответ 304 Not Modified оставляет прежнее тело. no-store просит не сохранять ответ, а no-cache разрешает хранение, но требует проверки перед повторным использованием. Эти директивы нельзя считать синонимами.
Заголовок Vary добавляет заголовки запроса к ключу. Ответ, зависящий от Accept-Language или Accept-Encoding, нельзя бездумно отдавать запросу с другим значением. Vary не добавляет автоматически IP выхода. Если источник отдаёт региональное представление, он должен явно описать это измерение в совместимой с кэшем политике. Один прокси-маршрут не является ключом кэша.
Частный кэш браузера принадлежит одному профилю. CDN или пересылающий прокси может обслуживать многих клиентов и поэтому обязан соблюдать правила общего кэша, авторизации и приватности. Ответ, допустимый в частном кэше, не всегда допустим в общем. Объяснение для браузеров есть в руководстве MDN по HTTP-кэшированию.
Почему новая маршрутизация показывает старый ответ
После загрузки URL через прокси A браузер может иметь свежую запись. Если контекст переключить на прокси B и открыть тот же URL, частный кэш может ответить без обращения к B. Показ представления, полученного через A, не доказывает ошибку смены прокси.
Для устаревшей записи браузер может провести проверку через B. Ответ 304 сохраняет прежнее тело, а полный ответ его заменяет. CDN или пересылающий прокси также может иметь собственный кэш: браузер может не найти запись, а посредник найти, или браузер может найти её и не связаться с посредником. Перенаправления, подресурсы и фоновый обработчик добавляют отдельные ответы и хранилища. В региональном сравнении проверяйте всю последовательность и источник каждого важного ресурса.
Ответ, полученный через B, может иметь другие Vary, Cache-Control или валидатор. Если ключ не различает представления, браузер может использовать одно вместо другого. Источник обязан объявить измерения, по которым меняется ответ; прокси не может добавить недостающее измерение после сохранения.
Ключи кэша, идентичность и границы маршрута
Разделяйте четыре вопроса: какой запрос ищется, какое хранилище выполняет поиск, через какой маршрут пошёл бы сетевой запрос и кому разрешено получить ответ. URL отвечает только на первый вопрос. Метод и отдельные заголовки участвуют в ключе; разделение и профиль определяют владельца состояния; прокси определяет путь только при отправке запроса.
Авторизованный ответ требует осторожности. Authorization часто делает его непригодным для общего кэша без явного разрешения. Cookie тоже может выбирать представление, даже если не указана в Vary, поэтому данные аккаунта должны получать подходящие частные директивы. Повторное использование профиля для разных аккаунтов может перенести старый ответ даже после смены маршрута.
Назначайте владельца кэша каждой цели теста. Контекст одного аккаунта нельзя бездумно использовать для другого аккаунта или региона, если перенос состояния не является частью проверки. Новый BrowserContext обычно имеет отдельные cookie, хранилище и кэш; смена прокси в существующем контексте эти данные не сбрасывает.
Другой адрес выхода сам по себе не создаёт границу приватности. Он не удаляет cookie, localStorage, IndexedDB, фоновый обработчик или HTTP-кэш. Очистка кэша также не меняет прокси, DNS-резолвер или аккаунт. Сопоставьте это с моделью хранения браузера и настройкой прокси.
Для регионального контента используйте контролируемую тестовую страницу с безопасной меткой региона и идентификатором представления. Записывайте URL, режим кэша, Age при наличии, ETag, Cache-Control и маршрут сетевого запроса. Не сохраняйте частное тело ответа или учётные данные.
Безопасная инвалидация и диагностика
Начните с малозатратной проверки. Откройте новую страницу в том же контексте и изучите журнал. Пометка о кэше памяти или диска означает, что прокси не участвовал. Для наблюдения маршрута используйте документированный режим перезагрузки с повторной проверкой; обычная перезагрузка не всегда означает сетевой запрос.
Для чистого сравнения создайте новый BrowserContext с нужным прокси и без импортированного состояния. Сначала проверьте маршрут на ресурсе своей организации, затем запросите тестовый URL и соберите только статус, выбранные заголовки и наблюдение маршрута. Отличие нового контекста указывает на старое состояние; совпадение направляет проверку к источнику или посреднику.
Когда ответ не должен сохраняться, источник обязан отправить подходящую директиву Cache-Control. Очистка на клиенте полезна во время теста, но не исправляет политику сервера, которая сохраняет частные данные в общем кэше. Для ресурсов используйте версионированные URL или валидаторы, а для данных аккаунта используйте private или no-store.
Проверяйте слои по порядку: был ли ответ попаданием браузера или фонового обработчика; отправлялся ли запрос через выбранный маршрут и добавил ли посредник Age; объявил ли источник все меняющие представление измерения; были ли контексты, URL, методы, заголовки и режимы кэша сопоставимы.
Не пытайтесь отравлять кэш, извлекать частные ответы или проверять чужое хранилище без разрешения. Используйте только ресурсы и аккаунты своей организации и останавливайтесь, если владелец маршрута или состояния неясен.
Журнал проверки
Сохраняйте короткую запись о контексте, метке маршрута, режиме кэша, идентификаторе представления, результате кэша и наблюдении для известного сетевого запроса. Оставляйте только нужные заголовки и удаляйте cookie, учётные данные и частное тело. Если новый контекст всё ещё даёт неожиданный результат, передайте запись владельцу источника для проверки политики вместо многократной очистки состояния.
Возможности и ограничения BotBrowser
BotBrowser может предоставить каждому BrowserContext изолированную сессию и задокументированный прокси-маршрут. Авторизованная команда сможет сравнить кэш в отдельных контекстах и связать каждый сетевой запрос с его маршрутом. Прокси на уровне контекста и изоляция контекста удерживают состояние и маршрут в одной тестовой единице. BotBrowser не управляет Cache-Control или Vary источника, не может приказать частному кэшу, CDN или посреднику забыть ответ и не гарантирует, что смена маршрута инвалидирует кэш браузера, фоновый обработчик, CDN или прокси. Владение и инвалидация кэша остаются задачами приложения и теста. См. документацию прокси контекста и настройку прокси.
Новый ответ может иметь другие ETag, возраст или директивы. Сравните эти поля, прежде чем связывать изменение с маршрутом.
Устаревшая запись всё ещё может быть полезной: проверка 304 сохраняет уже записанное тело.
Режим кэширования запроса является частью условия проверки и записывается вместе с методом.
Пометка о кэше памяти или диска означает, что для ресурса не отправлялся сетевой запрос.
Фоновый обработчик может ответить из отдельного кэша хранилища до участия HTTP-кэша.
Записывайте версию и состояние активации фонового обработчика, если они влияют на проверку.
Перенаправления имеют собственные ответы и могут храниться отдельно от итогового документа.
У каждого изображения, скрипта, шрифта и вызова API может быть своё решение о кэшировании.
CDN может выдать общий ответ, даже если в браузере нет локальной записи.
Заголовок Age помогает обнаружить ответ, сохранённый посредником.
Отсутствие Age не доказывает, что посредник не участвовал.
Снимок страницы не показывает, какой слой предоставил каждый ресурс.
Запросы в работе могут завершиться через прежний маршрут после смены прокси.
Дождитесь завершения навигации, прежде чем считать её свидетельством нового маршрута.
На время перехода приостановите периодические задачи, связанные со старым маршрутом.
Новый контекст обычно отделяет cookie, хранилище и кэш от предыдущего контекста.
Смена прокси в существующем контексте сохраняет его состояние.
Очистка кэша не обязательно удаляет cookie и состояние приложения.
Удаление всех данных сайта меняет больше условий, чем HTTP-инвалидация.
Для проверки маршрута используйте контролируемый источник без данных клиентов.
Идентификатор представления полезнее, чем сохранение тела страницы.
Перед передачей журнала удаляйте значения авторизации, cookie и секретные параметры.
Владелец источника должен объявить каждое измерение, меняющее представление.
Cookie может выбирать вариант, даже если его нет в Vary.
Для персональных ответов нужны директивы, запрещающие непреднамеренное общее использование.
Частный кэш браузера не делает частным кэш прокси.
Не повторяйте операцию, меняющую состояние сервера, пока не известен её результат.
Идентификатор запроса помогает не отправить операцию повторно.
Код 404 может быть сохраняемым отрицательным ответом, а 5xx может исходить от разных слоёв.
Сопоставляйте код состояния с результатом кэша и наблюдавшимся маршрутом.
Директивы no-cache и no-store описывают разные режимы обработки.
Успешная проверка может обновить метаданные без загрузки нового тела.
Возраст ответа меняется между запросами, поэтому время записывайте в одной временной зоне.
Если первый отличающийся слой неясен, остановите тест и попросите владельца провести проверку.
Публичные источники
Для тестов с cookie используйте документацию по управлению cookie.
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.