Прежде чем покупать больше прокси-трафика для монитора контента, проверьте заголовки, которые ваш клиент реально отправляет. На нашем живом сайте добавление Cache-Control: no-cache превратило проверки неизменившихся страниц из ответов 304 без тела в полные загрузки с 200, хотя запросы несли совпадающий ETag.
В контролируемом сравнении 12 условных запросов без этого переопределения передали ноль байт тела ответа; 12 запросов с ним передали 271 968 байт неизменившегося HTML. Шесть начальных загрузок, нужных для получения ETag, стоили ещё 135 984 байта и включены в опубликованные записи.
Это вывод об одном развёрнутом сайте на Next.js 16.3.4 и конкретной политике запросов. Это не совет убирать требования к свежести из монитора. Полезное решение — менять ли политику клиента, выбрать ли более компактное представление или исследовать поведение ревалидации на сервере.
Задача: следить за известным контентом, не скачивая его без нужды
Мы тестировали две существующие статьи ipvolt: руководство по бенчмарку прокси и объяснение ошибок прокси, каждую в виде HTML и Markdown. Наш монитор следил за заголовком статьи и двумя заданными заголовками разделов. Он также проверял медиатипы, а для HTML — заголовок страницы и канонический URL.
Эти проверки устанавливают, что отслеживаемая информация присутствует. Они не делают Markdown заменой вёрстке, поведению JavaScript или работающему сценарию регистрации. Точные утверждения приведены в конфигурации исследования.
Сбор шёл через аутентифицированные соединения стороннего прокси с выходом в США, Великобритании и Нидерландах. Начальный эксперимент также включал прямое контрольное соединение. Ответы проверки страны сообщали запрошенные страны на контрольных точках; во время начального прогона для США исходящий адрес менялся, поэтому это наблюдения за маршрутом, а не результаты надёжности фиксированного IP или целой страны. Провайдер соединения не указан; это не был тест доступного прокси-сервиса ipvolt.
Все три HTTP-эксперимента прошли 11 сентября 2026 года. Они выполнили 234 запроса и передали 2 975 066 байт тела ответов, включая начальные загрузки, проверочные загрузки и неподтвердившиеся гипотезы. Каждый выполненный запрос завершился без транспортной ошибки curl. Дополнительные географические пробы и браузерное QA записаны отдельно в заметке о методе; они не входят в этот итог по HTTP-экспериментам.
Меньшая первая загрузка не ответила на вопрос о кэшировании
Начальный эксперимент последовательно запрашивал gzip и измерял полученные байты тела. По двенадцати начальным наблюдениям на каждое представление размеры были такими:
| Представление статьи | Полученные байты тела на начальный запрос |
|---|---|
| Бенчмарк, HTML | 26 521 |
| Бенчмарк, Markdown | 7 056–7 061 |
| Руководство по ошибкам, HTML | 18 807 |
| Руководство по ошибкам, Markdown | 5 081 |
Обе HTML-точки отдавали ETag. Ни одна из Markdown-точек в этом эксперименте не отдавала валидатор ETag или Last-Modified. Условные проверки HTML без переопределения Cache-Control возвращали 304; раннер переиспользовал совпадающее, ранее принятое тело, вместо того чтобы трактовать пустой ответ как новый документ.
Разведочный прогон выполнил 144 запроса: 120 полных ответов 200 и 24 принятых ответа 304. Он пропустил 36 условных слотов, потому что у Markdown не было валидатора или главная страница была помечена no-store. Пропущенные запросы не считаются ни успехами, ни нулевыми сетевыми наблюдениями.
Затем мы выполнили по пять последовательных проверок на каждое представление через каждый из трёх прокси-маршрутов. Каждая проверка явно отправляла Cache-Control: no-cache, а клиент сохранял подходящие валидаторы между проверками. Все 60 запросов вернули 200, включая 24 повторные проверки HTML с совпадающим ETag. Ожидание, что повторная валидация HTML позволит не скачивать тело, при этой политике не подтвердилось.
Выделяем заголовок, который изменил ответ
Для расследования мы зафиксировали URL, конфигурацию маршрута, Accept, язык, предпочтение gzip и точный исходный ETag. Для каждой из шести комбинаций маршрут/статья мы делали один исходный запрос и четыре условных. Порядок был A/B/B/A или B/A/A/B, где A не содержал переопределения Cache-Control, а B отправлял no-cache.
| Политика условного запроса | Попытки | Ответы | Полученные байты тела |
|---|---|---|---|
| Совпадающий If-None-Match; без переопределения Cache-Control | 12 | 12 × 304 | 0 |
| Тот же If-None-Match; Cache-Control: no-cache | 12 | 12 × 200 | 271 968 |
Все 24 условных наблюдения совпали с отслеживаемыми значениями и декодированным контентом исходного запроса. С учётом шести исходных запросов этот контролируемый эксперимент передал 407 952 байта тела за 30 запросов. Он использовал сбалансированный порядок, а не случайную выборку, и устанавливает наблюдаемое поведение этих конечных точек в течение этого короткого окна.
Реализация объясняет правдоподобный механизм. Мы сверили реально развёрнутые файлы зависимостей с локальной установкой Next.js 16.3.4: хеши соответствующих исходников совпали. Его хелпер ответа с ETag вызывает fresh перед возвратом 304; встроенная проверка свежести возвращает false, когда запрос содержит no-cache, ещё до оценки совпадающего ETag. Отдельный локальный тест функции воспроизвёл ту же ветку. Хелпер ответа Next.js, реализация fresh.
Это поведение, специфичное для стека и согласующееся с живыми результатами. HTTP не определяет no-cache как универсальную инструкцию скачать полное тело. И получение 304 не доказывает, что запрос дошёл до origin-сервера, а не до ответившего кэша. Кэширование HTTP.
Полезная оптимизация зависит от нужной вам свежести
Для эксперимента с пятью проверками, который явно использовал no-cache, фактические итоги были такими:
| Представление | Запросы, включая начальные загрузки | Полученные байты тела |
|---|---|---|
| HTML | 30 | 679 920 |
| Markdown | 30 | 182 070 |
| Разница | Одинаковое число запросов | 497 850 |
Markdown передал на 73,2% меньше байт тела ответов для отслеживаемого контента при этой политике. Число запросов он не уменьшил. Это измеренные различия в объёме данных, а не измеренная экономия по счёту и не прогноз месячного трафика. Метрика размера загрузки в curl исключает заголовки и прочие сетевые накладные расходы. Учёт объёма данных в curl.
Есть и другой вариант, когда требования к свежести это позволяют: Markdown-ответы объявляли public, max-age=300, must-revalidate. Кэш может переиспользовать ещё свежее сохранённое представление, не делая запрос. Отсутствие валидаторов не делает его некэшируемым. Наши раннеры намеренно проверяли по сети; они не реализовывали такую политику планирования на основе свежести. Свежесть и переиспользование.
Используйте результат, чтобы выбрать следующее действие:
| Ваше требование к мониторингу | Действие, которое поддерживает этот случай |
|---|---|
| Переиспользование в пределах окна свежести сервера допустимо | Оцените локальный кэш с учётом свежести, прежде чем планировать очередную загрузку. |
| Нужно, чтобы отвечающий сервер или кэш валидировал каждую проверку | Протестируйте итоговые заголовки запроса на реальной конечной точке; не считайте, что ETag гарантирует ответ без тела. |
| Нужен отслеживаемый текст, а каждая проверка возвращает полное тело | Сравните сжатый HTML с текстовым или Markdown-представлением, содержащим те же факты. |
| Нужна отрендеренная вёрстка или интерактивный сценарий | Оставьте браузерные проверки; компактное текстовое представление эту задачу не покрывает. |
Не убирайте no-cache только ради воспроизведения строки с нулём байт. Две политики заголовков могут иметь разные последствия для свежести. Определите, что ваш монитор должен обнаруживать, а затем измерьте допустимую реализацию.
Воспроизведите результат и адаптируйте проверку
Скачайте офлайн-скрипт анализа и очищенные записи в один каталог. Достаточно Python 3.10 или новее; эта команда не делает сетевых запросов:
python3 reproduce.py recordings.zipОна пересчитывает число попыток, итоги по телу, сравнение заголовков и процент для Markdown. Сравните её вывод с записанным результатом. Набор данных включает отметки времени, политики запросов, выбранные заголовки ответов, проверки контента и хеши. Учётные данные, исходящие IP-адреса, нефильтрованные заголовки и сырые захваты тела остаются закрытыми; воспроизведение проверяет опубликованную арифметику, а не независимо аутентифицирует исторические ответы.
Инструкция по скачиванию ссылается на точные программы сбора, конфигурации и 27 проходящих офлайн-тестов. Живым программам нужен curl 8.4 или новее; они сохраняют проверку TLS, ограничивают запросы и передачу тела и передают аутентификацию прокси конфиденциально через ввод curl. Их список разрешённых адресов ограничен публичным сайтом из этого случая; адаптируйте и список, и утверждения о контенте под ресурс, которым вы управляете.
Мы не наблюдали реального обновления контента и не измеряли задержку обнаружения. Декодированный контент оставался стабильным для каждой протестированной конечной точки; несколько потоков байт gzip различались при идентичном декодированном тексте. Это повод сравнивать именно тот контент, который важен вашему монитору, а не свидетельство того, что это исследование устранило операционные ложные срабатывания. Это один сайт, две статьи и короткое окно наблюдения — не рейтинг провайдеров и не универсальный бенчмарк кэширования.
Метод: сбор и анализ с помощью агента, с отдельными проверками свидетельств, редактуры и поиска. Все сообщённые сетевые наблюдения были реально выполнены; офлайн-тесты работают на контролируемых фикстурах и помечены отдельно.
Сообщите мне, когда откроется доступ. Одно письмо, когда доступ откроется. Больше ничего.