4. Режим «Через сервер» (Apache и nginx)

Что это и зачем

В режиме «Через роутинг» каждую страницу из кеша всё равно отдаёт PHP. В режиме «Через сервер» страницу отдаёт сам веб-сервер (программа Apache или nginx) прямо из файла: PHP и Webasyst при этом не запускаются. Это самый быстрый способ.

Цена: плагин не может сам настроить ваш веб-сервер. Он готовит текст правил, а вы (или ваш администратор, или поддержка хостинга) вставляете этот текст в настройки сервера. 🔧

Не торопитесь. Если вы никогда не правили .htaccess или конфигурацию nginx, начните с режима «Через роутинг» (быстрый старт). Серверный режим можно включить позже, в любой момент. Откат безопасен (ниже).

Что вам потребуется

Для Apache	Для nginx
Доступ к файлу `.htaccess` в корне сайта (через файловый менеджер хостинга или FTP)	Доступ к конфигурации сайта (файл вида `nginx.conf` или файл сайта) и право перезагрузить nginx; на обычном виртуальном хостинге этого нет, нужна поддержка хостинга или VPS
Включённые модули `mod_rewrite` и `mod_alias` (и `mod_headers`, если включён диагностический заголовок)	—
Опция Webasyst `mod_rewrite` включена (`wa-config/SystemConfig`)	—

Какой у вас сервер, покажет строка «Веб-сервер» в сводке настроек и пункт «Веб-сервер» в «Проверке конфигурации». Если там написано, что PHP не определил сервер (например, мешает прокси перед сервером), спросите у хостинга. Бывает связка «nginx впереди, Apache позади»: в этом случае тип определите у поддержки хостинга, чтобы вставить правила в нужное место.

Шаги

Выберите «Через сервер (самый быстрый вариант)», отметьте «Включить кеширование» и нажмите «Сохранить». Правила создаются при сохранении.
Откройте вкладку «Правила сервера». Под галочкой «Сконфигурировать правила сервера» появится текст правил на зелёном фоне. (Галочка после каждого сохранения снимается сама: если вы позже поменяли настройки и хотите получить новый текст, отметьте её и сохраните ещё раз.) Нажмите «Скопировать правила» (в блоке «Как включить кеш») либо выделите текст вручную и скопируйте.

Вкладка «Правила сервера» при Apache (снимок 3.4.3):

При nginx вместо одной подсказки показаны четыре шага; правила начинаются с блока про исполняемые файлы (снимок 3.4.3):
🔧 Apache. Сначала сохраните копию текущего .htaccess под другим именем (например, .htaccess.bak): она понадобится для отката. Откройте .htaccess в корне сайта (там же, где index.php и wa-config). Вставьте правила в самое начало файла, выше всех существующих строк (в том числе выше блока, который создал Webasyst). Сохраните файл. Перед вставкой убедитесь, что в файле нет старого блока «Start supercache rules»: он должен остаться один.

🔧 nginx. Сначала сохраните копию конфигурации. В блоке server { ... } вашего магазина перед директивой try_files вставьте переменные и условия из вкладки; затем в начало директивы try_files добавьте $super_cache. Проверьте конфигурацию командой nginx -t и перезагрузите nginx. 4. Вернитесь в настройки и обновите страницу (F5): блок «Проверка конфигурации» заново прочитает .htaccess (для nginx прочитать конфигурацию он не может и всегда оставит пункт «проверить вручную»). 5. Запустите «Проверку кеша». Ожидается «Кешируется: MISS, затем HIT». 6. Только после такого HIT блок состояния покажет «Прямой серверный HIT подтверждён»: «веб-сервер отдаёт сохранённую страницу без PHP». Сами по себе правила этого статуса не дают: нужен именно проверочный HIT.

Пока HIT не получен, блок состояния показывает «Требуется настройка: Через сервер: прямой серверный HIT не подтверждён…»; после HIT, полученного при действующих правилах, — «Прямой серверный HIT подтверждён». Если после шага 5 статус не изменился, правила не работают: см. таблицу «Если не получилось» ниже.

Снимки 3.4.3: слева направо по ходу настройки.

В режиме «Через сервер» блок «Как включить кеш» показывает кнопку «Скопировать правила»:

Если не получилось

Симптом	Вероятная причина	Что делать
Всегда MISS, «Страница сохранена, но не отдаётся из кеша»	Правила не вставлены, вставлены не в то место или Apache их не применяет	Сверьте текст в `.htaccess` с текстом вкладки. Пункт «Правила сервера действуют» в «Проверке конфигурации» покажет результат проверки
«Блок отличается от того, что создают текущие настройки»	После смены настроек вы не заменили блок в `.htaccess`	Сохраните настройки, скопируйте правила заново и замените весь блок «Start supercache rules … End supercache rules». Старый блок должен исчезнуть, дубликаты вредны
«Включите модуль mod_rewrite»	В Apache модуль выключен	🔧 Попросите хостинг; см. шаблон письма ниже
Все файлы `.htaccess` плагина игнорируются (проверка с ответом 200 для `lib/…`)	На хостинге `AllowOverride None`	🔧 Попросите хостинг разрешить `.htaccess` либо вставить блок `DirectoryMatch` в конфигурацию виртуального хоста (текст есть в проверке)
nginx: после правки сайт не открывается	Ошибка в конфигурации	Откатите правку; выполните `nginx -t`, чтобы увидеть строку с ошибкой
Перед сайтом CDN или кеширующий прокси	Ответы могут приходить из его кеша, а не из правил	Проверки показывают, что правила за ним не доказаны. Если прокси кеширует HTML, он должен хранить отдельные копии для телефонов и компьютеров, иначе посетители могут получить копию не своего устройства

Что отправить в поддержку хостинга

Скопируйте и подставьте своё. Чем конкретнее письмо, тем быстрее ответят.

Здравствуйте. Для сайта <домен> (Webasyst Shop-Script) мне нужно подключить кеш страниц плагином SuperCache напрямую через веб-сервер. Прошу:

Сообщить тип веб-сервера для этого сайта (Apache, nginx или связка) и версию PHP (нужна 8.2 или новее).

Если Apache: подтвердить, что включены модули mod_rewrite, mod_alias (и mod_headers) и что для сайта разрешены файлы .htaccess (AllowOverride All или FileInfo).

Если nginx: добавить в блок server нашего сайта приложенный текст (я скопирую его со страницы настроек плагина) и в начало try_files добавить $super_cache; проверить nginx -t и перезагрузить nginx. Также закрыть от публичного доступа папки wa-apps/*/plugins/supercache/lib, templates, locale (две строки есть на странице «Проверка конфигурации»).

Подтвердить, что сервер может обращаться по HTTP(S) к собственному домену (плагин проверяет себя запросом с сервера).

Подсказать, как добавить задание cron: */10 * * * * /usr/bin/php -q <путь к сайту>/cli.php shop SupercachePluginStorage.

Приложение: текст правил (со вкладки «Правила сервера»).

Текст правил на вкладке меняется от настроек, поэтому берите его после окончательного сохранения настроек.

Когда правила нужно менять заново

Правила зависят от некоторых настроек. Если вы изменили любую из них, сохраните настройки, скопируйте правила заново и замените ими старые. Плагин напоминает об этом под каждой такой настройкой:

«Стратегия кеширования», «Локализация»;
«Как работать с query string» и «Список разрешённых query string»;
«Сжатие в gzip»;
настройки роботов («Поисковые роботы» и остальные);
«Профиль правил сервера», «Диагностический заголовок X-Supercache»;
«Адаптивные изображения PRO»;
«Разрешить обход кеша для администратора» (для nginx — добавить |supercache_bypass= в список cookie).

После смены стратегии, локализации, query string и gzip нужно ещё и очистить кеш.

Версия 3.4.3: правила нужно заменить

В новом тексте появились условия для сжатия (при включённом «Сжатии в gzip»): Apache отдаёт .gz-копию только клиенту с Accept-Encoding: gzip, nginx использует gzip_static on; и gzip_vary on; (снимки 3.4.3):

В 3.4.3 текст правил изменился. Если вы обновились и работаете «Через сервер», действие обязательно:

Откройте вкладку «Правила сервера», отметьте «Сконфигурировать правила сервера», нажмите «Сохранить». Вкладка до сохранения показывает текст, сохранённый в прошлый раз, поэтому без сохранения вы увидите старые правила.
Скопируйте новый текст. Apache: замените весь блок «Start supercache rules … End supercache rules» в корневом .htaccess. nginx: замените весь блок правил в server { } (в старом тексте есть gzip_static always;), затем nginx -t и перезагрузка.
Запустите «Проверку кеша».

Пока правила не заменены, магазин работает, но сохраняются дефекты веб-сервера, исправленные в 3.4.3: nginx мог отдать gzip-страницу клиенту, не принимающему gzip; в Apache при редком состоянии, когда остаётся только .gz-копия, клиент без gzip мог получить её. Исправления на стороне PHP действуют сразу. Режим «Через роутинг» правил не требует. «Проверка конфигурации» для Apache покажет, что блок отличается от текущих настроек, пока вы его не замените; для nginx она читать конфигурацию не умеет и подскажет, на что смотреть.

Откат

Если что-то пошло не так, шаги этого отката безопасны:

Выберите «Через роутинг» и нажмите «Сохранить»: страницы снова отдаёт PHP.
🔧 Удалите строки SuperCache из .htaccess или из блока server nginx, перезагрузите nginx.
Один раз нажмите «Очистить кеш» (отметьте галочку и сохраните).
Запустите «Проверку кеша».

Чтобы остановить кеширование совсем, снимите «Включить кеширование», сохраните и тоже удалите правила. После отката обязательно запустите «Проверку кеша»: блок состояния сам не заметит, что вы вручную убрали правила, пока вы не измените настройки или не повторите проверку.

Apache и nginx: коротко о различиях

	Apache	nginx
Куда вставлять	`.htaccess` в корне сайта, в самое начало	В блок `server` сайта, перед `try_files`, плюс `$super_cache` в `try_files`
Нужна перезагрузка	Нет, `.htaccess` читается на лету	Да
Работает ли «Проверка конфигурации»	Читает файл и сравнивает с текущими правилами	Не может прочитать конфигурацию, всегда «проверить вручную»
Типичный хостинг	Обычный виртуальный хостинг	VPS, облако, продвинутые тарифы

⚠️ Что не проверено

Правила проверялись автотестами и на изолированных стендах (Apache 2.4 и nginx 1.27, PHP 8.2). Не проверялись: реальный боевой nginx и Windows-хостинг; сервер с CDN или прокси перед ним; панели хостинга, переписывающие заголовок Accept-Encoding.