CDN кеширует корзину: как исключить персональные страницы из cache rules

Кеширование корзины опаснее устаревшей цены: edge может отдать одному посетителю HTML или API-ответ другого пользователя. Причина часто в слишком широком Cache Everything, игнорировании cookies или ошибочном Cache-Control от приложения. Исправление требует закрыть персональные маршруты на всех уровнях и очистить уже сохраненные ответы.

Немедленно включите bypass для корзины, checkout, аккаунта и персональных API, затем purge соответствующих URL. Проверьте ответ из двух чистых сессий и убедитесь, что CDN показывает BYPASS/DYNAMIC, а origin отправляет private, no-store там, где есть пользовательские данные.

Что проверить в первую очередь

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

• Проверьте cf-cache-status или аналогичный заголовок на корзине и API.
• Сравните HTML и cookies из двух независимых браузерных сессий.
• Просмотрите порядок cache rules: более позднее правило может перекрывать bypass.
• Проверьте Cache-Control, Vary и Set-Cookie на origin.

Почему возникает проблема

Внешний симптом часто появляется не в том компоненте, где возникла первичная ошибка. Интерфейс может показывать неверное состояние из-за backend, очереди, кеша, прав доступа или внешнего API. Полезно проследить данные от источника до результата и найти первую точку расхождения. Это надежнее, чем исправлять последнее сообщение об ошибке или бесконечно перезапускать сервис.

• Правило Cache Everything применяется ко всему домену раньше исключений.
• Путь корзины имеет несколько вариантов, язык или query, не покрытые шаблоном.
• CDN игнорирует cookie сессии или кеширует ответ с Set-Cookie.
• Приложение ошибочно ставит public/max-age на персональный API.
• Service worker или reverse proxy добавляет второй независимый слой кеша.

Пошаговая диагностика

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

• Сделайте запросы без cookie, с двумя разными cookie и после добавления разных товаров.
• Запишите cache key и проверьте, входят ли host, path, query и нужные заголовки.
• Проверьте каждый слой: браузер, service worker, CDN, Nginx/Varnish и приложение.
• Найдите варианты URL: slash, uppercase, locale, mobile и AJAX endpoints.
• Проверьте, не кешируется ли GraphQL POST или JSON корзины отдельным правилом.

Какие страницы нельзя кешировать как общие

Любой ответ, зависящий от авторизации, cookie, персональной цены, региона пользователя или содержимого заказа, не должен попадать в общий edge cache без специально спроектированного ключа и строгого доказательства безопасности.

• Cart, checkout, account, orders и password recovery всегда bypass.
• Персональные API и GraphQL-операции не кешируются общим ключом.
• Страница товара может кешироваться, если персональные блоки загружаются отдельно безопасным API.
• Set-Cookie на публичном HTML требует проверки, не превращает ли ответ пользователя в общий.
• Vary: Cookie редко является хорошим способом кешировать бесконечное число сессий на edge.

Как исправить проблему

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

• Создайте приоритетные bypass rules по путям, cookies и авторизации.
• Исправьте origin headers на private, no-store для персональных ответов.
• Очистите edge cache по всем вариантам URL после изменения.
• Разделите публичный HTML и персональные фрагменты, если нужна производительность каталога.
• Добавьте автоматический тест двух сессий на отсутствие смешивания данных.

Безопасный порядок внедрения

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

Как проверить результат

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

• Корзина и личный кабинет всегда показывают BYPASS/DYNAMIC.
• Две сессии одновременно видят только свои товары, цены и заказы.
• Публичные страницы продолжают получать HIT после прогрева.
• Purge не является обязательным условием корректности персональных страниц.

Типичные ошибки при исправлении

• Добавить query-параметр как временный обход и оставить общий кеш.
• Кешировать персональный ответ по полному Cookie, создавая утечку и взрыв ключей.
• Исправить только HTML, забыв AJAX/API корзины.
• Проверять в одном браузере, где локальный кеш скрывает edge-поведение.

Как предотвратить повторение

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

• Храните cache policy рядом с кодом и проверяйте после каждого изменения маршрутов.
• Добавьте security-тест из двух пользователей в CI или мониторинг.
• Контролируйте долю HIT/BYPASS отдельно для публичных и приватных путей.
• Документируйте все уровни кеша и владельца каждого правила.

Что подготовить для технического разбора

• Описание ожидаемого и фактического поведения с точной последовательностью действий.
• Время проблемы, идентификатор тестового объекта и версии затронутых компонентов.
• Фрагменты журналов до и после ошибки без секретов и персональных данных.
• Перечень последних изменений и уже выполненных проверок.
• Безопасный доступ к тестовой среде либо способ воспроизвести сбой без влияния на клиентов.

Частые вопросы

Можно ли кешировать корзину по cookie сессии?

Технически возможно, но обычно дорого и рискованно. Надежнее не кешировать персональный ответ на CDN.

Почему после bypass все еще видна старая корзина?

Очистите ранее сохраненный edge cache и проверьте browser/service worker/reverse proxy: правило влияет на новые запросы, но старый объект может оставаться.

Когда нужна помощь специалиста

Если CDN показывает чужую корзину или кеширует личный кабинет, я могу срочно закрыть персональные маршруты, очистить edge, проверить все слои кеша и сохранить ускорение публичных страниц.