Изменение внесено, но на сайте по-прежнему видна старая версия — классический симптом проблемы с кешем, но причина не всегда очевидна с первого взгляда, поскольку в Битриксе одновременно работает несколько независимых уровней кеширования. Разберём, что проверять по порядку, когда штатная очистка кеша не помогает.
Уровень 1: управляемый кеш и кеш компонентов
Настройки → Инструменты разработчика → Управление кешем — первое место для полной очистки кеша данных и компонентов. Если после этой очистки изменения по-прежнему не видны, проблема не в этом уровне кеша, и стоит проверять дальше, а не повторять очистку того же самого раздела снова и снова в надежде на иной результат.
Уровень 2: HTML-кеш композитного сайта
Если на проекте включён композитный сайт, статически закешированный HTML хранится отдельно от управляемого кеша данных и требует собственной, отдельной очистки — обычная очистка кеша компонентов не затрагивает уже сгенерированные статические HTML-страницы композита. Раздел настроек композитного сайта содержит собственную кнопку очистки, которую легко упустить, ограничившись только общим разделом управления кешем.
Нужна помощь с Битрикс?
Уровень 3: кеш opcache PHP
<?php
opcache_reset();
Изменения в самом PHP-коде (не в контенте, а именно в файлах
логики) могут не подхватываться немедленно, если включён
opcache с длительным временем валидации файлов
(opcache.validate_timestamps отключён или установлен
редкий интервал проверки) — сервер продолжает выполнять
закешированную версию скомпилированного кода, даже если сам файл
на диске уже изменён. Сброс через opcache_reset()
или перезапуск PHP-FPM решает эту проблему.
Уровень 4: браузерный кеш и CDN
Если изменения касаются статических ресурсов (CSS, JS, изображения), кешироваться может не только сервер, но и браузер посетителя, и, если используется, CDN между сервером и посетителем — оба уровня требуют отдельного внимания: browser cache обходится через жёсткое обновление страницы (Ctrl+F5) для проверки, а CDN требует явной инвалидации через панель управления CDN-сервиса, поскольку серверная очистка кеша Битрикса не имеет представления о том, что закешировано на стороне внешнего CDN.
Уровень 5: кеш reverse-proxy на уровне сервера
На высоконагруженных проектах перед PHP-FPM иногда стоит дополнительный слой кеширования на уровне nginx или отдельного reverse-proxy (Varnish и аналоги) — эти механизмы кешируют ответ сервера ещё до того, как запрос дойдёт до PHP и, соответственно, до логики Битрикса вообще, и требуют собственной инвалидации на уровне конфигурации этого промежуточного слоя.
Систематическая диагностика: с какого уровня начинать
Порядок диагностики стоит выстраивать от ближайшего к пользователю уровня к самому дальнему — сначала проверить браузерный кеш (жёсткое обновление), затем CDN, затем управляемый кеш Битрикса, затем opcache, и в последнюю очередь — reverse-proxy сервера, если он вообще присутствует в инфраструктуре конкретного проекта. Такой порядок отсекает наиболее вероятные и простые причины раньше, чем переходить к более редким и сложным для диагностики уровням.
Проверка через инкогнито-режим браузера
Быстрый способ исключить браузерный кеш из числа подозреваемых — открыть страницу в режиме инкогнито или в другом браузере, где точно нет накопленного локального кеша, — если проблема сохраняется и там, причина точно не в браузере посетителя, а где-то на стороне сервера или промежуточных уровней кеширования.
Частые ошибки
- Проверяется только управляемый кеш, но не HTML-кеш композита. Оба уровня требуют раздельной очистки.
- Не учтён opcache при изменении PHP-кода. Сервер продолжает выполнять устаревшую скомпилированную версию кода.
- CDN не инвалидируется отдельно от серверного кеша. Очистка на стороне Битрикса не затрагивает то, что закешировано во внешнем CDN.
Итог
На проекте с полным набором механизмов кеширования (управляемый кеш, HTML-кеш композита, opcache, CDN, возможный reverse-proxy) диагностика "почему изменения не видны" требует последовательной проверки каждого уровня от ближайшего к пользователю к самому дальнему, а не одной попытки очистки только основного раздела управления кешем в административной панели.