Кеш показывает чужой язык или регион: как найти причину

Посетитель выбирает Казань, открывает каталог, а после обновления снова видит московский телефон. У другого пользователя русская страница внезапно оказывается английской. Разработчик открывает тот же адрес и получает правильный результат. Ошибка может зависеть от сохранённой копии страницы: приложение умеет выбирать вариант, но промежуточный кеш объединяет запросы, которым положены разные ответы.

Проверять это нужно на собственном сайте и на заранее подготовленных вариантах. Статья посвящена публичным страницам с языком или регионом. Если вместо этого обнаружены чужие персональные сведения, такое поведение требует отдельного разбора доступа и ограничения выдачи. Не продолжайте эксперимент с реальными данными посетителей ради красивого подтверждения гипотезы.

Начните с правила выбора версии

До просмотра настроек запишите, что именно определяет результат. Язык может задаваться частью пути, выбором посетителя, настройкой профиля или предпочтением браузера. Регион может выбираться вручную либо предлагаться по предварительному определению местоположения. Эти механизмы нельзя считать взаимозаменяемыми: сохранённый явный выбор и первоначальная подсказка способны иметь разный приоритет.

Для учебного каталога установим простое правило: выбранный город действует до следующего изменения, а язык указан в адресе. Это придуманная модель проверки, не обязательная архитектура сайта. В ней повторное открытие русской страницы после выбора Казани должно сохранить город. Если команда не согласовала такого правила, сначала нужно устранить неопределённость требований, иначе один и тот же ответ будут одновременно считать правильным и ошибочным.

Разделите также содержимое самой страницы и сведения, подгружаемые позже. Заголовок города может приходить в HTML, а контакты — отдельным запросом. Поэтому снимок правильного заголовка не доказывает правильности всего блока. Зафиксируйте два или три проверяемых элемента: название региона, телефон филиала и выбранный язык описания. Не используйте только цвет кнопки переключателя как свидетельство результата.

Что общего у запросов, которые нельзя объединять

Кешу нужен способ решить, допустимо ли повторно использовать сохранённый ответ. В HTTP правила выбора описаны в RFC 9111, в частности в разделе 4.1 о Vary. Заголовок Vary связывает выбор сохранённой версии с указанными заголовками запроса. Он не описывает автоматически все решения приложения и не заменяет проверку настроек промежуточного сервера.

Для владельца полезнее сформулировать вопрос через результат: какие два посетителя могут получить одинаковую сохранённую страницу без ошибки? Если язык уже различается в пути, это одна ситуация. Если по одному адресу меняется региональный текст, надо выяснить, как такое различие учтено при хранении ответа. Сам факт наличия переключателя города ничего об этом не говорит.

Обратная крайность тоже нежелательна: включить в различение всё содержимое каждого запроса. Тогда одинаковые публичные варианты могут дробиться на множество отдельных копий. Решение выбирают по нужному содержимому: одинаковым ответам разрешают совместное использование, различным обеспечивают разделение либо отказываются от общего кеширования соответствующей части. Здесь нет универсального списка заголовков, подходящего любому сайту.

Матрица вместо случайных обновлений

Используйте два контролируемых профиля браузера, обозначенные А и Б. Это не реальные клиенты. Для обоих заранее известны выбранный город и адрес страницы. Сначала проверьте вариант А, затем Б, затем снова А. После этого поменяйте порядок и повторите наблюдение в согласованном тестовом окружении. Если результат зависит от того, кто открыл страницу первым, это полезный признак для дальнейшего анализа, но ещё не окончательный диагноз.

Не добавляйте к каждому URL случайный параметр без согласования методики. Он может создать другой ключ, изменить обработку запроса и скрыть исходную проблему. Аналогично режим без кеша в инструментах браузера не является доказательством отключения всех промежуточных копий. У каждой проверки должно быть записано, какой именно слой она затрагивает и каким наблюдением это подтверждено.

Разведите четыре места, где мог появиться неверный ответ

Первое место — само приложение. Оно получает запрос и уже выбирает неправильный город. Второе — общий кеш перед приложением. Третье — отдельный источник данных для блока страницы. Четвёртое — состояние конкретного браузера. Порядок исследования зависит от архитектуры; задача состоит в сопоставлении результатов на границах, а не в обязательном обходе четырёх серверов, которых у проекта может не быть.

Разработчик должен показать, что приложение сформировало для тестового запроса до промежуточного хранения, а затем сравнить это с полученным результатом. Если исходный ответ уже неверен, изменение срока хранения проблему не исправит. Если исходный ответ верен, а посетитель получает другой вариант, появляется основание исследовать повторное использование копии. Сравнение делается разрешёнными средствами команды, без открытия внутренних адресов для посторонних.

Для небольшого журнала достаточно времени, условного профиля, адреса, ожидаемого города, фактического города и места наблюдения. Технические заголовки прикладывает специалист с пояснением их назначения. Сохранять целиком пользовательские cookie и закрытые ответы в общей задаче не нужно. Участникам важна воспроизводимость, а не максимальный объём дампа.

Почему одной строки Vary может оказаться недостаточно

Одинаковый HTTP-заголовок нельзя оценивать в отрыве от продукта, версии и правил конфигурации. Например, действующая документация Cloudflare описывает настройку обработки Vary и действия normalize, passthrough и bypass. Поэтому совет из старого обсуждения о том, что конкретный CDN всегда игнорирует такой заголовок, нужно перепроверить по актуальной документации и рабочей конфигурации.

Для приёмки попросите специалиста объяснить две вещи: какое различие запросов меняет результат приложения и как именно это различие учитывается на вашем пути доставки. Объяснение «мы добавили Vary» не отвечает на второй вопрос без проверки. При нескольких промежуточных слоях сопоставляют каждый участвующий механизм, а не только панель внешнего поставщика.

Особенно внимательно проверяют нормализацию. Если система объединяет несколько исходных значений в одну группу, содержимое должно оставаться подходящим для всей группы. Например, бизнес может различать две региональные версии одного языка. Тогда сокращение различия до общего языка способно противоречить требованиям. Это условный пример проверки архитектуры, а не утверждение о настройках вашего поставщика.

Очистка помогает повторить тест, но не описывает исправление

После очистки первым сохранится новый ответ. Если правило объединения осталось прежним, следующий посетитель может снова получить чужую версию. Поэтому разовое исчезновение ошибки после очистки не является достаточным результатом. Нужно повторить исходную последовательность с разными вариантами и проверить, что неправильный обмен содержимым больше не возникает.

Старые копии также учитывают отдельно от новых правил. Команда должна объяснить, что произойдёт с уже сохранённым содержимым после изменения конфигурации. Не обещайте, что любое сохранение настройки автоматически очищает все уровни. Объём и порядок очистки устанавливают по документации используемых средств, влиянию на нагрузку и принятому плану работ.

Если на время диагностики требуется обход кеширования, это ограниченная мера с наблюдением за сервером. До её включения оценивают, какой поток запросов попадёт в приложение и как остановить проверку при росте нагрузки. Нельзя превращать локальный разбор одного регионального блока в бесконтрольное отключение ускорения всего магазина. Изменения проводят по согласованному охвату и сохраняют исходные правила для возврата.

Проверка результата для владельца

Попросите показать матрицу до и после исправления с теми же адресами и ожидаемыми вариантами. В ней должны присутствовать повторное посещение, смена города, обратный порядок открытия и обновление регионального содержимого. Дополнительно проверьте страницы без региональных различий: исправление не должно случайно менять их поведение или создавать отдельную копию для каждого посетителя без причины.

Критерий готовности сформулируйте через содержание: каждый контролируемый профиль получает свой согласованный вариант, источник контактов совпадает с выбранным городом, а повторные запросы не меняют его из-за чужого посещения. Приложите объяснение границы исправления. Если отдельный устаревший клиент требует дополнительного действия, это должно быть отражено явно, а не скрыто за общим статусом «готово».

Проблему со старым сайтом после изменения адресных записей разбирают по другому порядку проверки DNS и кеша. Здесь итогом должен стать понятный набор вариантов публичной страницы и подтверждение, что каждый из них хранится и выдаётся согласованно. Это позволяет проверять следующие обновления каталога по той же модели, не возвращаясь каждый раз к случайным очисткам.