Кэшируем Wordpress средствами Nginx. Кэширование с Nginx Кеширование с помощью акселератора php

HTTP заголовок Expires наряду с несколькими другими заголовками, такими как Cache-Control позволяет управлять кэшем, тем самым сообщая, как долго запрашиваемый контент будет актуален. После того как «время жизни» истекает, кэш перестает быть актуальным, и возникает необходимость запрашивать исходный ресурс, чтобы узнать были ли изменения в контенте. Заголовок Expires является стандартным заголовком, регламентированным в протоколе HTTP, и поддерживается практически любым кэшом. Что касается заголовка Cache-Control, то он был введен в HTTP/1.1 , позволив тем самым предоставить возможность веб-мастерам осуществлять больший контроль над контентом, а так же решить ограничения связанные с Expires. Чтобы использовать Cache-control эффективно, рекомендуется указывать время, по истечении которого кэш перестает быть актуальным.

В данном посту мы рассмотрим примеры настройки параметра expires в Nginx. Для начала попробуем в настройках выставить максимальный возможный срок хранения кэша.
Ставим кэш на максимальный срок

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires max; } ... }

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

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires 7d; } ... }

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

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires modified 3d; } ... }

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

Server { ... location ~* ^.+\.(jpg|gif|png)$ { expires off; } ... }

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

Nginx умеет кэшировать запросы самостоятельно. Преимущества использования Nginx cache в его простоте по сравнению с Varnish .

Что кешировать?

Суть серверного кеширования в том, чтобы не генерировать постоянно одни и те же скрипты (например, ленту постов Wordpress), что может иногда занимать целые секунды. Вместо этого, приложение генерирует страницу один раз, и результат сохраняется в память. Когда посетитель запросит ту же страницу второй раз, генерации уже не будет, а клиент получит сохраненную в памяти версию. Раз в какое-то время (называемое ttl), эта сохраненная версия будет удаляться и генерироваться новая, чтобы поддерживать актуальность данных.

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

Включение кеширования в Nginx

Прежде всего нужно определить максимальный размер кеша (общий размер всех страниц в кеше будет не более этого размера). Это делается в основном файле настроек (nginx.conf) в секции http:

Http { ... proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=all:32m max_size=1g ; ... }

# Устанавливаем размер кеша в 1G, сохранять его будем в папку /var/cache/nginx

Не забываем создать папку для кеша. mkdir /var/cache/nginx

Настройка хостов

Чтобы кеширование заработало, мы должны создать новый хост, который будет слушать 80 порт. А основной хост перенести на какой-то другой порт (например, 81). Кеширующий хост будет посылать запросы на основной либо отдавать данные из кеша.

Кеширующий хост

# Каждая страница будет сохраняться в кеш на 1 час

Основной хост

# Обычный конфиг только на 81 порту

Cookies и персонализация

Многие сайты используют различные персональные блоки на страницах. Технология SSI позволяет реализовать продвинутое кеширование в случаях большого количество персонализированных блоков. В простом случае, мы можем просто отключать кеш, если у пользователя установлены какие-то Cookies.

Server { listen 80; location / { if ($http_cookie ~* ".+") { set $do_not_cache 1; } proxy_cache_bypass $do_not_cache; proxy_pass http://127.0.0.1:81/; proxy_cache all; proxy_cache_valid any 1h; } }

Ошибки

Имеет смысл также включить кеширование ошибочных запросов на какое-то короткое время. Это позволит избежать частых повторных попыток обратиться к неработающей части сайта.

Server { listen 80; location / { if ($http_cookie ~* ".+") { set $do_not_cache 1; } proxy_cache_bypass $do_not_cache; proxy_pass http://127.0.0.1:81/; proxy_cache all; proxy_cache_valid 404 502 503 1m; proxy_cache_valid any 1h; } }

Кеширование fastcgi

Nginx позволяет кешировать ответы от fastcgi. Для включения этого кеша, необходимо также объявить его параметры (в секции http файла nginx.conf):

Fastcgi_cache_path /var/cache/fpm levels=1:2 keys_zone=fcgi:32m max_size=1g; fastcgi_cache_key "$scheme$request_method$host$request_uri";

# Установим максимальный размер кеша в 1G

Не забываем создать папку mkdir /var/cache/fpm

В конфигурации основного хоста, добавляем правила кеширования:

Server { listen 80; location ~ \.php$ { fastcgi_pass unix:/var/run/php5-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_cache fcgi; fastcgi_cache_valid 200 60m; } }

# В данном случае мы будем кешировать ответы с кодом 200 на 60 минут

Самое важное

Пользуйтесь преимуществами кеширования. Довольно просто в настройке, зато может дать десятикратное ускорение сайта и экономию ресурсов.

Кеширование (caching) — это технология или процесс создания копии данных на быстродоступных носителях информации (кеш, cash). Проще говоря и применяя к реалиям сайтостроения, это может быть создание статической html-копии страницы или её части, которая генерируется с помощью PHP-скриптов (или иных других, как-то Perl, ASP.net), смотря на каком языке написан CMS сайта) и сохраняется на диске, в оперативной памяти или даже частично в браузере (рассмотрим подробнее ниже). Когда произойдёт запрос страницы от клиента (браузера), вместо того, чтобы заново собирать её скриптами, браузер получит её готовую копию, что намного экономнее по затратам ресурсов хостинга, и быстрее, так как передать готовую страницу занимает меньше времени (порой значительно меньше), чем её создание заново.

Зачем использовать кеширование на сайте

• Для снижения нагрузки на хостинг
• Для быстрой отдачи содержимого сайта браузеру

Оба аргумента, думаю, в комментариях не нуждаются.

Недостатки и отрицательный эффект от кеширования сайта

Как ни странно, у кеширования сайта есть и свои минусы. В первую очередь это касается сайтов, содержание которых динамично изменяется при взаимодействии с ним. Зачастую, это сайты, которые выдают содержимое или его часть с помощью AJAX. В общем-то, кеширование AJAX тоже возможно и даже нужно, но это тема для отдельного разговора и не касается традиционно используемых технологий, о которых пойдёт речь далее.
Также, проблемы могут возникнуть у зарегистрированных пользователей, для которых постоянный кеш может стать проблемой при взаимодействии с элементами сайта. Тут, как правило, кеш отключается, либо используется объектное кеширование отдельных элементов сайта: виджетов, меню и тому подобных.

Как настроить кеширование у себя на сайте

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

Кеширование на стороне сервера

Кеширование с помощью NGINX

Кеширование с помощью htaccess (Apache)

Если у вас есть доступ только к.htaccess , и рабочий сервер только Apache, то вы можете использовать такие приёмы, как сжатие gzip и выставление заголовков Expires , чтобы использовать браузерный кеш.

Включаем сжатие gzip для соответствующих MIME-типов файлов

AddOutputFilterByType DEFLATE text/plain text/html AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE text/javascript application/javascript application/x-javascript AddOutputFilterByType DEFLATE text/xml application/xml application/xhtml+xml application/rss+xml AddOutputFilterByType DEFLATE application/json AddOutputFilterByType DEFLATE application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon

Включаем заголовки Expires для статичных файлов сроком на 1 год (365 дней)

ExpiresActive on ExpiresDefault "access plus 365 days"

Кеширование с помощью Memcached

Кеширование с помощью акселератора php

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

• Windows Cache Extension for PHP
• XCache
• Zend OPcache

В PHP версии 5.5 и выше уже встроен акселератор Zend OPcache , поэтому чтобы включить акселератор, вам достаточно просто обновить версию PHP

Кеширование на стороне сайта

Как правило, тут подразумевается возможность CMS сайта создавать статические html-копии страниц. Такой возможностью обладают большинство популярных движков и фреймворков. Лично я работал со Smarty, WordPress, поэтому могу заверить, что они отлично справляются со своей работой. В оригинальном WordPress из коробки нет кеширующих возможностей, которые необходимы любому малость нагруженному проекту, зато есть множество популярных плагинов для кеширования:

1. , который как раз и занимается генерацией статических страниц сайта;
2. Hyper Cache, который по сути работает так же, как и предыдущий плагин;
3. DB Cache. Суть работы — кеширование запросов к базе данных. Тоже очень полезная функция. Можно использовать в связке с двумя предыдущими плагинами;
4. W3 Total Cache. Оставил его на десерт, это мой любимый плагин в WordPress. С ним сайт преображается, превращаясь из неповоротливого автобуса в гоночный болид. Его огромным преимуществом является огромный набор возможностей, как то несколько вариантов кеширования (статика, акселераторы, Memcached, запросы к базе данных, объектное и страничное кеширование), конкатенация и минификация кода (объединение и сжатие файлов CSS, Javascript, сжатие HTML за счёт удаления пробелов), использование CDN и многое другое.

Что тут скажешь — используйте правильные CMS, и качественное кеширование будет доступно практически из коробки.

Кеширование на стороне браузера (клиента), заголовки кеширования

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

• Expires;
• Cache-Control: max-age;
• Last-Modified;
• ETag.

Благодаря им пользователи, которые неоднократно заходят на сайт, тратят крайне мало времени на загрузку страниц. Заголовки кеширования должны применяться ко всем кешируемым статическим ресурсам: файлы шаблона, картинок, файлы javascript и css, если есть, PDF, аудио и видео, и так далее.
Рекомендуется выставлять заголовки так, чтобы статика хранилась не менее недели и не более года, лучше всего год.

Expires

Заголовок Expires отвечает за то, как долго кеш является актуальным, и браузер может использовать кешированные ресурсы, не запрашивая у сервера их новую версию. Является сильным и крайне желательным к использованию, так как действует в обязательном порядке. В заголовке рекомендуется указывать срок от недели до года. Больше года лучше не указывать, это является нарушением правил RFC.

Например, чтобы настроить Expires в NGINX для всех статических файлов на год (365 дней), в конфигурационном файле NGINX должен присутствовать код

Location ~* ^.+\.(jpg|jpeg|gif|png|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|swf)$ { expires 365d; }

Cache-Control: max-age;

Cache-Control: max-age отвечает за то же самое.
Более предпочтительно использование Expires, нежели Cache-Control ввиду большей распространённости. Однако, если Expires и Cache-Control будут присутствовать в заголовках одновременно, то приоритет будет отдан Cache-Control.

В NGINX Cache-Control включается так же, как и Expires , директивой expires: 365d;

Last-Modified и ETag

Эти заголовки работают по принципу цифровых отпечатков. Это означает, что для каждого адреса URL в кеше будет устанавливаться свой уникальный id. Last-Modified создаёт его на основе даты последнего изменения. Заголовок ETag использует любой уникальный идентификатор ресурса (чаще всего это версия файла или хеш контента). Last-Modified – «слабый» заголовок, так как браузер применяет эвристические алгоритмы, чтобы определить, запрашивать ли элемент из кеша.

В NGINX для статичных файлов ETag и Last-Modified включены по умолчанию. Для динамических страниц их либо лучше не указывать, либо это должен делать скрипт, генерирующий страницу, либо, что лучше всего, использовать правильно настроенный кеш, тогда NGINX сам позаботится о заголовках. Например, для WordPress, вы можете воспользоваться .

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

Одновременное использование Expires и Cache-Control: max-age избыточно, так же, как избыточно одновременное использование Last-Modified и ETag. Используйте в связке Expires + ETag либо Expires + Last-Modified.

Включить GZIP сжатие для статичных файлов

Конечно, сжатие GZIP не относится к кешированию как таковому напрямую, однако, весьма экономит трафик и увеличивает скорость загрузки страниц.

Как включить GZIP для статики в server { .... gzip on; gzip_disable "msie6"; gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript; } Как включить GZIP для статики в Чтобы включить сжатие gzip в.htaccess, нужно в начало файла вставить следующий код: AddOutputFilterByType DEFLATE text/plain AddOutputFilterByType DEFLATE text/html AddOutputFilterByType DEFLATE text/xml AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xhtml+xml AddOutputFilterByType DEFLATE application/rss+xml AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE application/x-javascript

Wordpress далеко не самая производительная платформа для ведения блогов, и крупные сайты, как правило, используют кэширование для ускроения его работы. Для wordpress, есть много популярных дополнений реализующих кэширование, но все они на мой взгляд довольно осложненные, и, как правило, требуют либо установки дополнительного программного обеспечения, такого как, например, Varnish или memcached, либо перекладывают кэширование на плечи PHP который тоже производительным не назовешь. В этом посте я расскажу как настроить кэширование wordpress средствами nginx , без установки дополнительного ПО.

В nginx есть FastCGI модуль который предоставляет директивы, позволяющие кэшировать ответ от fastcgi. Использование данного модуля избавляет нас от необходимости использовать сторонние средства кэширования. Модуль так же позволяет нам не кэшировать часть ресурсов опираясь на различные параметры запроса, такие как, например: тип (GET, POST), куки, адрес страницы и другие. Сам модуль умеет исключительно добавлять в кэш, но не умеет его очищать или удалять отдельные записи из него. Без очистки кэша при добавлении, редактировании и добавлении комментария к посту кэш не будет обновляться, и сделанные изменения будут видны только с большой задержкой, поэтому для очистки кэша мы будем использовать сторонний nginx модуль - nginx_cache_purge .

Настройка nginx

В большинстве современных дистрибутивов nginx уже собран с модулем ngx_cache_purge , но на всякий случай проверим, что он присутствует. В консоли выполним:

nginx -V 2>& 1 | grep -o nginx-cache-purge

Если после выполнения команды вы видите nginx-cache-purge , то значит можно продолжать. Если после выполнения команды ничего не появилось, то у вас вероятно какой-то из старый дистрибутивов ubuntu, в котором nginx собран без поддержки этого модуля. В данном случае необходимо переустановить nginx из стороннего ppa:

sudo add-apt-repository ppa:rtcamp/nginx sudo apt-get update sudo apt-get remove nginx* sudo apt-get install nginx-custom

Настроим nginx. Откроем файл с настройками виртуального хоста, и приведем его к примерно такому содержимому:

fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m ; fastcgi_cache_key " $scheme$request_method$host$request_uri" ; fastcgi_cache_use_stale error timeout invalid_header http_500 ; fastcgi_ignore_headers Cache-Control Expires Set-Cookie ; # Upstream to abstract backend connection(s) for php upstream php { server unix:/var/run/php5-fpm.sock fail_timeout=0 ; } server { listen 80 ; server_name .example.com ; root /var/www/example.com/html ; index index.php ; error_log /var/www/example.com/log/error.log ; access_log /var/www/example.com/log/access.log ; set $skip_cache 0 ; # POST requests and urls with a query string should always go to PHP if ($request_method = POST) { set $skip_cache 1 ; } if ($query_string != "") { set $skip_cache 1 ; } # Don"t cache uris containing the following segments if ($request_uri ~ * "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml") { set $skip_cache 1 ; } # Don"t use the cache for logged in users or recent commenters if ($http_cookie ~ * "comment_author|wordpress_+|wp-postpass|wordpress_no_cache|wordpress_logged_in") { set $skip_cache 1 ; } location / { try_files $uri $uri/ /index.php? $args ; } location ~ \.php$ { try_files $uri = 404 ; include fastcgi_params ; fastcgi_pass php ; fastcgi_cache_bypass $skip_cache ; fastcgi_no_cache $skip_cache ; fastcgi_cache WORDPRESS ; fastcgi_cache_valid 60m ; } location ~ /purge(/.*) { allow 127 .0.0.1 ; deny all ; fastcgi_cache_purge WORDPRESS " $scheme$request_method$host$1" ; } location ~ * ^.+\.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|rss|atom|jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi|wav|bmp|rtf) $ { access_log off ; log_not_found off ; expires max ; } location ~ /\. { deny all ; access_log off ; log_not_found off ; } location = /favicon.ico { log_not_found off ; access_log off ; } location = /robots.txt { allow all ; log_not_found off ; access_log off ; } # Deny access to uploads that aren’t images, videos, music, etc. location ~ * ^/wp-content/uploads/.*.(html|htm|shtml|php|js|swf) $ { deny all ; } # Deny public access to wp-config.php location ~ * wp-config.php { deny all ; } }

Разумеется, параметры root , server_name , access_log , error_log необходимо исправить согласно тому, как у вас все настроенно. В строке fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m; мы говорим nginx, что хранить кэш нужно в директории /var/run/nginx-cache/ , зону памяти называем WORDPRESS , максимальный размер кэша устанавливаем в 100 мегабайт и таймер сброса из-за неактивности устанавливаем в 60 минут. Приятным бонусом подобной конфигурации является то, что если по каким-то причинам наш PHP бекэнд перестает работать, nginx продолжит отдавать закэшированные страницы.

Настройка Wordpress

Сам nginx не знает, когда нужно очищать кэш, поэтому необходимо установить дополнение для wordpress, которое будет автоматически очищать кэш после изменений. Ставим дополнение nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

И если все хорошо - перезагружаем его:

systemctl reload nginx

Заходим на любую страницу, и проверяем что nginx добавил её в кэш:

ls -la /var/run/nginx-cache

Дополнительно: помещаем кэш nginx в ramdisk (tmpfs)

Сейчас у нас кэширование настроено, но кэш хранится на жестком диске, что не является хорошим решение. Оптимальнее будет смонтировать директорию с кэшем nginx в память. Для этого откроем /etc/fstab , и добавим туда:

tmpfs /var/run/nginx-cache tmpfs nodev,nosuid,size= 110M 0 0

Если в настройках nginx вы указали больший размер кэша, то параметр size необходимо изменить в соответствии с указанным размером кэша, плюс небольшой запас.
Сразу смонтируем директорию в память:

Теперь при каждой загрузке системы, директория /var/run/nginx-cache будет помещаться в память, что должно уменьшить время отдачи страницы.

Заключение

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

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

Nginx часто применяется в веб-проектах не в малой степени потому, что позволяет временно сохранять контент сайтов. В Nginx кэширование настраивается очень просто (по сравнению с другими хранилищами) и является хорошим средством оптимизации работы веб-сервера.

Используется при больших нагрузках. Кэширование позволяет быстрее отдавать контент при втором и последующих обращениях к сайту. В блоге Nginx про кэширование .

Также кэширующие сервера легко кластеризуются

Чтобы кэширование nginx работало корректно в конфигурационном файле nginx.conf определяется путь к каталогу, в который будут складываться закэшированные на стороне сервера данные и задается его размер.

Рассматривается серверное кэширование и использование Nginx как хранилища. задается проще.

Запускается веб-сервер в двух экземплярах на разных портах, обычно на разных машинах.

Кэширующий веб-сервер дает снижение нагрузки. Страница, один раз сгенерированная, сохраняется в кэш и отдается клиентам из него пока не истечет установленный TTL (time to live). Когда он истечет страница вновь будет сгенерирована и загружена в кэш — это требуется для того, чтобы посетитель сайта получал актуальную информацию.

Nginx кэширование: настройка

В примере закэшированные данные будут складываться на сервере 123.123.123.123 в каталог /var/cache/nginx . Максимальный размер файлов в кэше — 128 Мб, если этого буфера будет не хватать самые редко запрашиваемые данные будут вытесняться

mcedit /etc/nginx/nginx.conf

http {
proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=all:128m;
}

Каталог /var/nginx/cache нужно создать

mkdir -p /var/nginx/cache

Настройка виртуального хоста

Все, что здесь требуется — принимать запросы на выбранном для кэширующего Nginx, затем проксировать их на основной сервер.

server {
listen *:80;

server_name example.com;
access_log /var/log/nginx/access.log;

location / {

proxy_pass http://124.124.124.124:80/;
proxy_set_header Host $host;
proxy_buffering on;
proxy_cache all;
proxy_cache_valid any 30m;
proxy_cache_valid 200 1d;
proxy_cache_use_stale error timeout invalid_header updating http_500 http_502 http_503 http_504;

}

В конфигурационном файле указано, что кэшировать нужно все содержимое, TTL установлен в 30 минут.

Виртуальный хост активируется

На основном Nginx сервере с адресом 124.124.124.124:

Никаких изменений здесь вносить не требуется — можно при необходимости запустить веб-сервер на альтернативном порту.

mcedit /etc/nginx/sites-availible/example.com

server {
listen *:80;
server_name example.com;
proxy_read_timeout 200s;
access_log off;

root /var/www/sites/example.com/;

location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;

}

}

ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled

Конфигурация может быть любой: Nginx + PHP-FPM или как в примере.

Добавляем файл index.php для того чтобы проверить кэширование

mcedit /var/www/sites/example.com/index.php