Как настроить nginx для wordpress

Руководство по настройке блога WordPress на nginx.

Данное руководство рассчитано на вебмастеров, стремящихся решить проблему недостаточной производительности сайтов, построенных на платформе WordPress. В нем описана пошаговая настройка сервера с ограниченными ресурсами (1 ядро, 512 RAM на примере минимального тарифа Flops.ru) для использования в связке LEMP (Linux + nginx + MySQL + PHP). Для комфортного использования материала вы должны иметь общие представления о работе сайтов и серверов на базе Linux.

Данное руководство рассчитано на вебмастеров, стремящихся решить проблему недостаточной производительности сайтов, построенных на платформе WordPress. В нем описана пошаговая настройка сервера с ограниченными ресурсами (1 ядро, 512 RAM на примере минимального тарифа Flops.ru) для использования в связке LEMP (Linux + nginx + MySQL + PHP). Для комфортного использования материала вы должны иметь общие представления о работе сайтов и серверов на базе Linux.

Эволюция требований к хостингу при увеличении масштабов проекта.

Наиболее популярным решением для веб серверов по прежнему остается связка LAMP (Linux, Apache, MySQL, PHP). Подобный вариант легок в настройке, хорошо документирован, часто используется для небольших проектов. Но за простоту использования приходится платить чрезмерным потреблением ресурсов и высокими рисками даунтайма при увеличении нагрузки (возросшее число посетителей, большое количество материалов, тяжелые плагины).

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

Часто в качестве следующего шага развития используется LAMP за proxy сервером nginx, обеспечивающим быструю отдачу статики, тем самым снижая нагрузку на Apache. Подобное решение позволяет с минимальными усилиями и поддержкой специфических для Apache возможностей (например .htaccess) существенно повысить производительность. Для ускорения динамики в ход идут исполнение PHP в режиме CGI, средства кэширования байт-кода и SQL запросов. При этом в подобной связке все равно остается узкое место — производительность Apache.

Следующим витком эволюции в погоне за производительность стает полный отказ от Apache, использование FPM, полное кэширование страниц сайта.

Это руководство подробно рассказывает о настройке WordPress, выдерживающей нагрузки в несколько сотен конкурентных запросов в секунду в условиях крайне ограниченных серверных ресурсов. Руководство описывает все шаги установки, включая первичную настройку сервера, обеспечивающую защиту от стандартных угроз, установку и настройку LEMP, настройку WordPress. Выполнение всех пунктов гарантирует получение работоспособного сервера.

ВАЖНО: В руководстве не описана процедура резервного копирования, так как Flops.ru обеспечивает создание резервных копий и снэпшотов, а использование сторонних мест хранения сугубо индивидуально.

ВАЖНО: Набор предустановленных пакетов у разных хостинг-провайдеров может варьироваться. Руководство подразумевает наличие схожих с Flops.ru пакетов.

ЗАМЕЧАНИЕ: В интернете гуляет множество статей по использованию в подобной связке Varnish, но nginx отдает статику не хуже, а конфигурация, представленная ниже, преимущественно будет работать именно со статикой, так что не вижу смыла усложнять проект еще одной прослойкой, тем более сильно отягчающей жизнь проектам, использующим SSL. Для формирования статической выдачи будет использоваться плагин WP Super Cache.

Требования к серверу.

В руководстве приводятся примеры конфигурации для сервера VPS с одним ядром, 512Mb Ram, SSD. Тестовые сервера были развернуты у хостинг-провайдера Flops.ru, но вы можете воспользоваться любыми другими. Так как приведенные ниже настройки рассчитаны на максимальное использование кэшированных на дисках объектов, наиболее важным параметром будет производительность дисковой подсистемы.

Для установки сервера был выбран дистрибутив Debian 7 x86, так как в микроинстялляциях он обеспечивает более экономное использование памяти по сравнению с x64 версиями.

Подготовка серверного окружения.

После установки сервера установим с ним соединение по ssh.

Сразу после установки не назначены локали по умолчанию. Укажем основной локалью en_US.UTF-8.

Для того, чтобы изменения вступили в силу, необходимо завершить сеанс SSH и начать его заново.

Обновим ПО сервера.

Установим и настроим sudo.

Добавим нового пользователя, под которым будем получать доступ по SSH.

Теперь перелогинимся под новым пользователем и убедимся, что все хорошо. Если проблем не возникло ограничим доступ root пользователю к SSH.

и заменим ее на

После внесения изменений перезагрузим OpenSSH.

Ограничим возможности потенциальных злоумышленников к подбору паролей SSH. Воспользуемся утилитой fail2ban. Также позже мы настроим fail2ban для блокирования возможности подбора пароля к WordPress.

Для нашей задачи дополнительные настройки fail2ban не требуются. Теперь при шестикратном неправильном вводе пароля ssh, пользователь будет блокироваться с помощью iptables на 600 секунд.

Настроим синхронизацию времени.

Настроим exim4 для отправки писем с сайта.

General type of mail configuration: Выберем верхний пункт internet site; mail is sent and received directly using SMTP.

System mail name: Укажем полное имя сервера, например admins.su.

IP-addresses to listen on for incoming SMTP connections: 127.0.0.1

Other destinations for which mail is accepted: Оставим пустым.

Domains to relay mail for: Оставим пустым.

Machines to relay mail for: Оставим пустым.

Keep number of DNS-queries minimal (Dial-on-Demand)? No

Delivery method for local mail: Любое значение.

Split configuration into small files? Yes

Резюме выполненных действий:

1. Создан пользователь webmaster для доступа по ssh.
2. Для повышения привилегий до root требуется дополнительный ввод пользователем webmaster пароля root.
3. Настроена защита от перебора пароля по ssh.
4. Настроена синхронизация времени.
5. Настроена почта для отправки писем с сайта.

Установка LEMP.

Мы будем использовать установку из пакетов для простого управления обновлениями. Для того, чтобы получить более свежий nginx (стандартно ставится nginx 1.2.1), мы подключим родной репозиторий nginx.

Скачаем и установим PGP ключ сервера nginx.

Источник

Как настроить Nginx для WordPress?

Правильная настройка Nginx’a может существенно увеличить производительность сайта, работающего на WordPress’e. Этот конфиг нужно положить в папку nginx/sites-enabled (в Debian’e – /etc/nginx/sites-enabled ):

Посмотрите также общие рекомендации по общей оптимизации Nginx’a.

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

Как перезапустить nginx после обновления конфигурации

Включение и использование log-файлов для проверки работы Nginx

Уменьшение размера картинок при сохранении качества

Как и зачем используется заголовок Cache-control

301 redirect в Nginx’e

Что такое Etag и как его настроить в Nginx

Как исправить ошибку 405 Not Allowed в Nginx

Причины и методы исправления ошибки Gateway Timeout, Nginx

Как настроить Nginx на максимальную эффективность

Где находится nginx.conf и пример настроек

Как использовать try_files в настройках Nginx’a

Основы оптимизации работы Web сервера

Работа приложения с несколькими бэкендами при помощи Nginx

Архитектурные принципы высоконагруженных приложений

Как пофиксить ошибку «110: connection timed out» while reading response header from upstream

Как исправить ошибку Primary script unknown в Nginx

Причины возникновения ошибки Ошибка 502 bad gateway в Nginx и методы исправления

Использование Nginx, как кэширующего сервера

Как решить ошибку upstream sent too big header while reading response header from upstream в Nginx

Примеры применения Javascript в Nginx’e

Как улучшить время получения первого байта и отзывчивость веб-сервера

Ошибка HTTP 413 (Request Entity Too Large Error) означает, что клиент отправил слишком большой запрос на сервер.

Как включить и использовать сжатие gzip в Nginx

Примеры использования Lua в Nginx для решения стандартных задач

Источник

Настройка nginx и PHP для работы WordPress

Краткая инструкция по настройки конфигурации виртуального хоста nginx для работы CMS WordPress с использованием постоянных ссылок, а также некоторые настройки PHP для корректной работы WordPress.

Всё дело в том, что nginx, в отличие от Apache, не понимает файл .htaccess, и поэтому для работы WordPress необходимо внести некоторые изменения в настройки виртуальных хостов.

Данная инструкция была опробована на ОС Gentoo GNU/Linux, но подойдёт для любых операционных систем Linux и FreeBSD.

Перед тем, как выполнить все действия, которые описаны ниже, необходимо установить и настроить стек LEMP. Выберите ОС, в которой он будет (или уже) развёрнут и перейдите по ссылке:

Затем открываем файл php.ini и при необходимости исправляем в нём следующие параметры:

max_execution_time — параметр максимального времени выполнения скрипта (по умолчанию 30 секунд) — если у вас сервер достаточной мощности, можно оставить по умолчанию, если нет — увеличиваем время до 60 или даже до 120 секунд

memory_limit — ограничение оперативной памяти для выполнения скрипта (по умолчанию 128 MB) — если скрипты тяжёлые — лучше увеличить, например 256 или 512 MB

upload_max_filesize — максимальный размер файла, который может быть загружен с использованием PHP (по умолчанию 2 MB) — при использовании WordPress выставить значение хотя-бы 20 MB

По окончании необходимо будет перезапустить службу php-fpm.

Теперь открываем файл конфигурации виртуального хоста nginx и дописываем и/или изменяем следующие параметры:

также и для SSL.

На выходе конфигурация виртуального хоста должна выглядеть примерно так:

Готово! Теперь WordPress должен работать без проблем.

Если не получилось — пишите в комментариях, разберёмся.

Источник

Автоматизируем установку WordPress с NGINX Unit и Ubuntu

Есть множество материалов по установке WordPress, поиск в Google по ключевым словам «WordPress install» выдаст порядка полумиллиона результатов. Но тем не менее фактически среди них весьма мало годных руководств, по которым можно установить и настроить WordPress и нижележащую операционную систему так, чтобы они были способны к поддержке в течение длительного периода времени. Возможно, правильные настройки сильно зависят от конкретных потребностей, или же это связано с тем, что подробное объяснение делает статью тяжелой для чтения.

В этой статье мы постараемся собрать лучшее из двух подходов, предоставляя скрипт на bash для автоматической установки WordPress на Ubuntu, а также пройдемся по нему, поясняя, что делает каждый его кусочек, а также на какие компромиссы мы пошли при его разработке. Если вы опытный пользователь — можете пропустить текст статьи и просто взять скрипт для модификации и использования в ваших окружениях. На выходе скрипта получается настраиваемая установка WordPress с поддержкой Lets Encrypt, работающая на NGINX Unit и пригодная для промышленного применения.

Разработанная архитектура для развертывания WordPress с использованием NGINX Unit описана в более старой статье, сейчас мы также дополнительно настроим вещи, которые там не были охвачены (как и во многих других руководствах):

• WordPress CLI
• Let’s Encrypt и сертификаты TLS\SSL
• Автоматическое обновление сертификатов
• Кэширование NGINX
• Сжатие NGINX
• Поддержка HTTPS и HTTP/2
• Автоматизация процесса

В статье будет описана установка на одном сервере, на котором будут размещены одновременно сервер обработки статики, сервер обработки PHP, база данных. Установка с поддержкой множества виртуальных хостов и сервисов — потенциальная тема на будущее. Хотите, чтобы мы написали о чем-то, чего нет в этих статьях — пишите в комментариях.

Требования

Обзор архитектуры

Архитектура такая же, как было описано ранее, трехуровневое web-приложение. Оно состоит из скриптов PHP, исполняемых на обработчике PHP, и статических файлов, обрабатываемых веб-сервером.

Общие принципы

Установка переменных окружения

Установите следующие переменные окружения, прежде чем запускать скрипт:

• WORDPRESS_DB_PASSWORD — пароль к базе данных WordPress
• WORDPRESS_ADMIN_USER — имя администратора WordPress
• WORDPRESS_ADMIN_PASSWORD — пароль администратора WordPress
• WORDPRESS_ADMIN_EMAIL — email администратора WordPress
• WORDPRESS_URL — полный URL сайта WordPress, начиная с https:// .
• LETS_ENCRYPT_STAGING — пустая по-умолчанию, но, выставив значение в 1, вы будете использовать staging сервера Let’s Encrypt, необходимые для частого запроса сертификатов при тестировании ваших настроек, иначе Let’s Encrypt может временно заблокировать ваш ip-адрес из-за большого числа запросов.

Скрипт проверяет, что эти связанные с WordPress переменные выставлены, и завершает работу, если нет.
Строки скрипта 572-576 проверяют значение LETS_ENCRYPT_STAGING .

Установка производных переменных окружения

Скрипт в строках 55-61 выставляет следующие переменные окружения, либо в некоторое жестко заданное значение, либо с применением значения, полученного из переменных, установленных в предыдущем разделе:

• DEBIAN_FRONTEND=»noninteractive» — сообщает приложениям, что они запускаются в скрипте и нет возможности взаимодействия с пользователем.
• WORDPRESS_CLI_VERSION=»2.4.0″ — версия приложения WordPress CLI.
• WORDPRESS_CLI_MD5= «dedd5a662b80cda66e9e25d44c23b25c» — контрольная сумма исполняемого файла WordPress CLI 2.4.0 (версия указывается в переменной WORDPRESS_CLI_VERSION ). Скрипт на 162 строке использует это значение для проверки, что был скачан корректный файл WordPress CLI.
• UPLOAD_MAX_FILESIZE=»16M» — максимальный размер файла, который может быть закачан в WordPress. Эта настройка используется в нескольких местах, так что проще задавать ее в одном месте.
• TLS_HOSTNAME= «$(echo $ | cut -d’/’ -f3)» — hostname системы, извлекаемый из переменной WORDPRESS_URL. Используется для получения соответствующих TLS/SSL сертификатов от Let’s Encrypt, а также для внутренней проверки WordPress.
• NGINX_CONF_DIR=»/etc/nginx» — путь к каталогу с настройками NGINX, включая основной файл nginx.conf .
• CERT_DIR=»/etc/letsencrypt/live/$» — путь к сертификатам Let’s Encrypt для сайта WordPress, получаемый из переменной TLS_HOSTNAME .

Назначение hostname WordPress серверу

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

Добавление hostname в /etc/hosts

Дополнение WP‑Cron используется для запуска периодических задач, требует, чтобы WordPress мог получить доступ к самому себе через HTTP. Чтобы убедиться, что WP-Cron работает корректно на всех окружениях, скрипт добавляет строчку в файл /etc/hosts, так что WordPress может получить доступ к самому себе через интерфейс loopback:

Установка инструментов, требуемых для последующих шагов

Оставшаяся часть скрипта нуждается в некоторых программах и подразумевает, что репозитории актуальны. Мы обновляем список репозиториев, после чего устанавливаем нужные инструменты:

Добавление репозиториев NGINX Unit и NGINX

Скрипт устанавливает NGINX Unit и NGINX с открытым исходным кодом из официальных репозиториев NGINX, чтобы удостовериться, что используются версии с последними обновлениями безопасности и исправлениями ошибок.

Скрипт добавляет репозиторий NGINX Unit, а затем — репозиторий NGINX, добавляя ключ репозиториев и файлы настроек apt , задающих доступ к репозиториям через интернет.

Реальная установка NGINX Unit и NGINX происходит в следующем разделе. Мы предварительно добавляем репозитории, чтобы не обновлять метаданные несколько раз, что делает установку быстрее.

Установка NGINX, NGINX Unit, PHP MariaDB, Certbot (Let’s Encrypt) и их зависимостей

Как только все репозитории добавлены, обновляем метаданные и устанавливаем приложения. Пакеты, устанавливаемые скриптом, также включают расширения PHP, рекомендуемые при запуске WordPress.org

Настройка PHP для использования с NGINX Unit и WordPress

Скрипт создает файл настроек в каталоге conf.d. Тут задается максимальный размер загружаемых файлов для PHP, включается вывод ошибок PHP в STDERR, так что они будут записаны в журнал NGINX Unit, а также перезапускается NGINX Unit.

Задание настроек базы данных MariaDB для WordPress

Мы выбрали MariaDB вместо MySQL, поскольку у нее больше активность сообщества, кроме того, она, возможно, предоставляет более высокую производительность по умолчанию (вероятно, тут все проще: чтобы поставить MySQL, надо добавить еще один репозиторий, прим. переводчика).

Скрипт создает новую базу данных и создает учетные данные для доступа WordPress через интерфейс loopback:

Установка программы WordPress CLI

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

Установка и настройка WordPress

Скрипт устанавливает последнюю версию WordPress в каталог /var/www/wordpress , а также изменяет настройки:

• Соединение с базой данных работает через unix domain socket вместо TCP на loopback, чтобы сократить трафик TCP.
• WordPress добавляет префикс https:// к URL, если клиенты соединяются с NGINX по протоколу HTTPS, а также отправляет удаленный hostname (как это предоставляет NGINX) в PHP. Мы применяем кусочек кода, чтобы это настроить.
• WordPress нужно HTTPS для входа
• Структура URL по молчанию основывается на ресурсах
• Выставляются правильные права на файловой системе для каталога WordPress.

Настройка NGINX Unit

Скрипт настраивает NGINX Unit для запуска PHP и обработки путей WordPress, изолируя пространство имен процессов PHP и оптимизируя настройки производительности. Тут есть три функции, на которые стоит обратить внимание:

• Поддержка пространств имен определяется по условию, основана на проверке запуска скрипта в контейнере. Это нужно, поскольку большинство настроек контейнеров не поддерживают вложенный запуск контейнеров.
• Если есть поддержка пространств имен, отключается пространство имен network. Это нужно, чтобы позволить WordPress одновременно подключаться и к endpoints и быть доступным в интернете.
• Максимальное число процессов определяется следующим образом: (Доступная память для запущенных MariaDB и NGINX Uniy)/(предел по оперативной памяти в PHP + 5)
  Это значение устанавливается в настройках NGINX Unit.

Также это значение подразумевает, что всегда есть как минимум два запущенных процесса PHP, что важно, поскольку WordPress делает много асинхронных запросов к самому себе, а без дополнительных процессов запуск, к примеру, WP-Cron, сломается. Вы, возможно, захотите увеличить или уменьшить эти ограничения, основываясь на ваших локальных настройках, потому что созданные настройки здесь — консервативные. На большинстве производственных систем настройки находятся между 10 и 100.

Настройка NGINX

Настройка основных параметров NGINX

Скрипт создает каталог для кэша NGINX, а затем создает основной файл настройки nginx.conf . Обратите внимание на число процессов-обработчиков и задание максимального размера файла для загрузки. Также есть строка, на которой подключается файл настройки сжатия, определяемый в следующем разделе, далее идут настройки кэширования.

Настройка сжатия NGINX

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

Настройка NGINX для WordPress

Далее скрипт создает файл настройки для WordPress default.conf в каталоге conf.d. Здесь настраивается:

• Активация сертификатов TLS, полученных от Let’s Encrypt через Certbot (его настройка будет в следующем разделе)
• Настройка параметров безопасности TLS, основанная на рекомендациях от Let’s Encrypt
• Подключение кэширования пропускаемых запросов на 1 час по умолчанию
• Отключение журналирования доступа, а также журналирования ошибок, если файл не найден, для двух общих запрашиваемых файлов: favicon.ico и robots.txt
• Запрет доступа к скрытым файлам и некоторым файлам .php, чтобы предотвратить нелегальный доступ или непреднамеренный запуск
• Отключение журналирования доступа для статики и файлов шрифтов
• Задание заголовка Access-Control-Allow-Origin для файлов шрифтов
• Добавление маршрутизации для index.php и прочей статики.

Настройка Certbot для сертификатов от Let’s Encrypt и их автоматическое продление

Certbot — бесплатный инструмент от Electronic Frontier Foundation (EFF), с помощью которого можно получать и автоматически обновлять сертификаты TLS от Let’s Encrypt. Скрипт выполняет следующие действия, приводящие к настройке Certbot для обработки сертификатов от Let’s Encrypt в NGINX:

• Останавливает NGINX
• Скачивает рекомендуемые параметры TLS
• Запускает Certbot, чтобы получить сертификаты для сайта
• Перезапускает NGINX для использования сертификатов
• Настраивает ежедневный запуск Certbot в 3:24 ночи для проверки необходимости обновления сертификатов, а также, при необходимости, скачивания новых сертификатов и перезагрузки NGINX.

Дополнительная настройка вашего сайта

Мы выше рассказали о том, как наш скрипт настраивает NGINX и NGINX Unit для обслуживания готового к промышленной работе сайта с включенным TLS\SSL. Вы можете также, в зависимости от ваших нужд, добавить в будущем:

• Поддержку Brotli, улучшенное сжатие на лету по HTTPS
• ModSecurity с правилами для WordPress, чтобы предотвратить автоматические атаки на ваш сайт
• Резервное копирование для WordPress, подходящее вам
• Защиту с помощью AppArmor (на Ubuntu)
• Postfix или msmtp, чтобы WordPress мог отправлять почту
• Проверки вашего сайта, чтобы вы понимали, сколько трафика он может выдержать

Для еще более лучшей производительности сайта мы рекомендуем обновиться до NGINX Plus, наш коммерческий продукт корпоративного уровня, основанный на NGINX c открытым исходным кодом. Его подписчики получат динамически загружаемый модуль Brotli, а также (за дополнительную оплату) NGINX ModSecurity WAF. Мы также предлагаем NGINX App Protect, модуль WAF для NGINX Plus, основанный на технологии, ведущей в отрасли безопасности, от F5.

Источник