Блог компании 3v-Hosting
12 мин.
WordPress долгое время воспринимался как инструмент для быстрого запуска сайтов, ведь достаточно было выбрать подходящую тему, поставить пару плагинов, активировать кеширование и всё, проект уже работает. Но по мере роста посещаемости становится очевидным, что настоящая производительность определяется не PHP-кодом темы и даже не настройками базы данных, а серверной конфигурацией. Именно веб-сервер, в нашем случае Nginx, задаёт предел пропускной способности проекта, так как именно он определяет маршрутизацию запросов, скорость ответа, эффективность кеширования и устойчивость к высоким нагрузкам.
Если сайт получает хотя бы несколько тысяч визитов в сутки, то любые непроработанные Nginx директивы начинают проявляться в виде ошибок, задержек и другого непредсказуемого поведения. Правильно настроенный сервер, наоборот, позволяет WordPress работать стабильно, быстро и с большим запасом по производительности. В этой статье мы рассмотрим полный набор конфигураций, которые превращают обычный VPS сервер в готовую платформу для серьёзного WordPress-проекта.
PHP-FPM - это ядро обработки динамических запросов в WordPress. От его настройки зависит, насколько быстро будет срабатывать бекенд сайта и какая нагрузка ляжет на CPU и RAM. Ошибки в конфигурации PHP-FPM часто выглядят как «тормоза сайта», хотя сама PHP-логика может работать идеально.
Основная проблема - это использование дефолтных параметров пула. Например, конфигурация pm = dynamic со слишком низкой величиной pm.max_children создаёт эффект, когда сервер выглядит «полупустым», а WordPress обслуживает очередь запросов. Правильная настройка процессов позволяет равномерно распределить нагрузку и предотвратить зависания под пиковыми нагрузками.
Чтобы вам было проще подобрать необходимые именно вам параметры, ниже мы приводим простую ориентировочную таблицу.
Таблица - подбор параметров PHP-FPM
| RAM | pm.max_children | pm.start_servers | pm.min_spare_servers | pm.max_spare_servers |
|---|---|---|---|---|
| 1 ГБ | 3-4 | 1 | 1 | 2 |
| 2 ГБ | 6-8 | 2 | 2 | 4 |
| 4 ГБ | 10-15 | 3 | 3 | 6 |
Если всё-же вы задались целью определить точные значения, тогда необходимо наблюдать за процессами. Для этого вы можете воспользоваться данной командой:
ps aux | grep php-fpm journalctl -u php8.2-fpm top -Hp $(pidof php-fpm)
Выводы сделать достаточно просто: если процессы достигают максимума - увеличиваем лимиты, а если заканчивается оперативная память - тогда уменьшаем.
Для работы с Nginx лучше использовать Unix-сокет:
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
Он работает быстрее и стабильнее TCP соединений, особенно на слабых VPS. Такое улучшение даёт ощутимый прирост производительности и снижает задержки между Nginx и PHP-FPM.
WordPress в своей работе использует фронт-контроллер, где почти все запросы попадают в index.php. Это позволяет гибко управлять URL-структурой вашего сайта, ЧПУ - человеко-понятными урлами, кастомными пост-типами и REST API. Но такая схема работает только в том случае, если директива try_files настроена корректно.
Одной строки достаточно, чтобы либо обеспечить стабильную работу сайта, либо полностью сломать его маршрутизацию. Ошибки при описании try_files являются причиной огромного количества некорректных 404, неработающих плагинов и неправильных редиректов. Базовая правильная конфигурация выглядит так:
try_files $uri $uri/ /index.php?$args;
Часто неопытные администраторы совершают ошибки, которые могут привести ко множеству неприятных последствий. В таблице ниже мы привели самые частые из них и описали последствия этих ошибок.
Таблица - ошибки в конфигурации инструкции try_files
| Ошибка | Последствие |
|---|---|
Нет параметра $args |
Ломается пагинация, а также поиск и фильтры WooCommerce |
| Порядок аргументов изменён | Некоторые страницы начинают отдаются как статические |
| Дублирование в нескольких location | Разные плагины могут маршрутизироваться по-разному |
Проброс только /index.php |
Часть URL работает без GET-параметров |
Для проверки корректности обработки URL вы можете использовать такую команду:
curl -I https://site.com/test/ curl -I https://site.com/page/2/?filter=color
Если сервер отдаёт 404 там, где не должен - значит ошибка в try_files.
WordPress динамически генерирует только HTML-часть страницы. Всё остальное, в том числе изображения, таблицы стилей, шрифты и JavaScript - может и должен отдавать именно Nginx, без участия PHP-FPM. Это существенно снижает нагрузку на ваш сервер.
Правильно подобранные заголовки кеширования позволяют браузеру и CDN почти полностью исключить повторные запросы статических ресурсов. Вот простой пример конфигурации кеширования:
location ~* \.(jpg|jpeg|png|gif|svg|css|js|ico|woff2?)$ {
expires 30d;
add_header Cache-Control "public, no-transform";
}
Таблица - Зависимость срока кеширования от типа файла
| Тип файла | Рекомендуемый срок |
|---|---|
| CSS, JS | 30-90 дней |
| WOFF2 | 180 дней |
| PNG/JPG/SVG | 30-180 дней |
| Файлы темы | 7-30 дней (если обновляется часто) |
Приведенные в данной таблице сроки всё-же являются ориентировочными и мы рекомендуем вам самостоятельно их подбирать в зависимости от стиля управления контентом или от преобладающего типа размещаемого контента на вашем сайте. Грамотное кеширование позволяет уменьшить долю запросов к PHP с 70% до 5-10% от общего числа поступающих на сервер запросов.
Компрессия - это пожалуй один из самых недооценённых инструментов оптимизации. Она существенно уменьшает объём пакета ответа сервера и тем самым ускоряет загрузку сайта. Большинство конфигураций ограничиваются использованием gzip, хотя Brotli в некоторых случаях обеспечивает лучшее сжатие и уже давно поддерживается почти всеми браузерами.
Для сайтов, где особенно много CSS и JS, Brotli способен снизить вес ответа на 20-25% сильнее, чем gzip.
gzip on; gzip_min_length 1024; gzip_types text/plain text/css application/json application/javascript application/xml;
brotli on;
brotli_comp_level 5;
brotli_min_length 1024;
brotli_types text/plain text/css application/javascript application/json application/xml+rss application/xml application/font-woff application/font-woff2 image/svg+xml;
ВАЖНО! Brotli не является панацеей и есть как минимум несколько случаев, когда не стоит его использовать:
WordPress позволяет загружать большие изображения, PDF, архивы и другие тяжёлые файлы. Если настройки Nginx не учитывают этот факт, то пользователи могут столкнутся с ошибками и невозможностью загрузить контент.
По умолчанию Nginx позволяет загружать только файлы размером до 1 МБ, что делает WordPress практически неработоспособным. Поэтому рекомендуется сразу, по умолчанию, увеличивать этот лимит до 64МБ:
client_max_body_size 64M;
Однако, при работе с WooCommerce, импортом CSV или видеоконтентом этот лимит стоит увеличивать до 100-200 МБ. Также при загрузке больших файлов рекомендуется отключать буфферизацию, так как это снижает нагрузку на диск во время загрузки крупных файлов.:
proxy_request_buffering off;
Современный интернет требует обязательного использования HTTPS. В связи с тем, что WordPress на данный момент является безспорным лидером среди CMS - он особенно уязвим для ботов, сканеров и перехвата данных. Поэтому сервер должен обеспечивать безопасное и корректное шифрование.
Неправильная конфигурация HTTPS может вызвать редирект-петли, проблемы с mixed content и снижение скорости.
Начнём с обязательного заголовка:
add_header Strict-Transport-Security "max-age=31536000" always;
Этот заголовок включает механизм HTTP Strict Transport Security (HSTS) - одну из ключевых технологий, повышающих безопасность сайта, работающего по HTTPS.
Также есть несколько необязательных, но желательных заголовков. Например:
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
Что делает каждый из них:
| Заголовок | Назначение |
|---|---|
| X-Frame-Options DENY | Полностью запрещает открывать сайт внутри iframe, что является хорошей защитой от clickjacking |
| X-Content-Type-Options nosniff | Предотвращает MIME-sniffing и загрузку опасных файлов |
| Referrer-Policy strict-origin | Передаёт только домен, но не полный URL при переходах, что улучшает приватность |
| X-XSS-Protection | Включает встроенную фильтрацию XSS в старых браузерах |
| Permissions-Policy | Явно запрещает ненужные API, такие как геолокация, микрофон, камера и др. |
Минимальная SSL-конфигурация - это набор настроек, который не пытается «выжать максимум баллов в тестах», но даёт адекватный баланс между безопасностью, совместимостью и простотой поддержки. Для большинства проектов на WordPress достаточно включить современные протоколы, безопасные шифры и регулярно обновлять сертификаты, чтобы быть спокойным за безопасность своего проекта. Ниже мы приведем базовую конфигурацию SSL в Nginx, а также дадим развёрнутое описание того, что делает каждый из параметров и как вписать это в рабочую конфигурацию вашего веб-сервера.
Итак, базовый блок в server (для 443 порта) может выглядеть примерно так:
server {
listen 443 ssl http2;
server_name example.com www.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
# Остальная конфигурация сайта...
}
Давайте разберём ключевые параметры детальнее:
ssl_protocols TLSv1.2 TLSv1.3;Эта директива задаёт, какие версии TLS разрешены для подключения к сайту.
Если сайт ориентирован на очень старые устройства, такие как старые Android или старые встроенные браузеры, то придётся оценивать статистику и уже от неё плясать, но для современных проектов связка 1.2 + 1.3 - это вполне разумный минимум.
ssl_ciphers HIGH:!aNULL:!MD5;Эта директива отвечает за набор шифров (cipher suites), которые сервер разрешает использовать.
HIGH - включает только сильные шифры;!aNULL - запрещает шифры без аутентификации (anonymous key exchange), которые уязвимы и не дают гарантий подлинности;!MD5 - исключает шифры, использующие MD5, так как MD5 считается криптографически небезопасным.Фактически, эта строка фильтрует список возможных шифров до набора, который обеспечивает нормальную безопасность без экзотических и слабых комбинаций.
ssl_prefer_server_ciphers on;По умолчанию клиент (браузер) может пытаться навязать серверу шифр из списка поддерживаемых. Включение данной опции прямо говорит Nginx:
В итоге именно сервер контролирует безопасность, а не полагается на возможные странности на стороне клиента.
Современные WordPress-сайты всё чаще полагаются на REST API. Через него работают интернет-магазины на WooCommerce, интеграции с внешними сервисами, SPA-приложения на React/Vue и любые headless-архитектуры. REST API обрабатывает динамические запросы, поэтому важно, чтобы Nginx направлял их в WordPress корректно и не пытался интерпретировать как обычные файлы. Если этого не делать, то API-маршруты могут возвращать код 404, работать медленно или конфликтовать с другими правилами маршрутизации.
Чтобы Nginx гарантированно пропускал запросы к REST API в WordPress-ядро, используется отдельный блок:
location /wp-json/ {
try_files $uri /index.php?$args;
}
Эта конструкция принудительно отправляет все запросы к API в index.php, обеспечивая корректную обработку маршрутов, работу WooCommerce и внешних интеграций.
Теперь перейдём к XML-RPC.
XML-RPC - это старый механизм удалённого доступа к WordPress, который использовался до появления REST API. Его сегодня применяют только отдельные приложения (например, мобильные приложения на WordPress), а также некоторые старые интеграции. Однако сам файл xmlrpc.php является одной из самых часто атакуемых точек входа, когда через него злоумышленники отправляют тысячи запросов для перебора пароля.
Если проект не использует XML-RPC, то безопаснее будет его отключить:
location = /xmlrpc.php { deny all; }
Это снижает нагрузку на сервер, уменьшает риск brute force-атак и делает систему безопаснее, не влияя на функциональность большинства современных сайтов.
Даже идеальный WordPress может «лечь», если на него за минуту отправляют сотни запросов к wp-login.php или XML-RPC. Ограничение частоты запросов позволяет смягчить такие атаки и предотвратить перегрузку PHP-FPM. За это в WordPress отвечают так называемые лимиты или Rate limits. Вот пример базовой настройки лимитов, который подойдёт для большинства проектов:
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
limit_req zone=one burst=20 nodelay;
Таблица - Рекомендации по лимитам
| Тип сайта | Рекомендуемый лимит |
|---|---|
| Блог | 10–15 r/s |
| Новостник | 20–30 r/s |
| E-commerce | 30–50 r/s |
| Корпоративный сайт | 10 r/s |
Проверить-же срабатывание установленных лимитов можно просмотрев лог, командой:
grep "limiting requests" /var/log/nginx/error.log
Выше мы уже коснулись темы кеширования статических файлов. Но кешировать можно не только статику.
FastCGI cache - это один из самых мощных инструментов ускорения WordPress на сегодняшний день. Он позволяет Nginx отдавать HTML-страницы без обращения к PHP, что многократно снижает нагрузку и увеличивает скорость ответа сервера.
В отличие от плагинов кеширования, FastCGI работает на уровне веб-сервера и намного эффективнее при высокой посещаемости ресурса.
Базовый пример конфига FastCGI выглядит примерно так:
fastcgi_cache_path /var/cache/nginx 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 http_503;
ВАЖНО! Использовать FastCGI cache можно не со всеми компонентами, есть исключения, обусловленные логикой работы этих компонентов.
Даже корректно настроенный сервер может столкнуться с ошибками в конфигурации, нехваткой ресурсов или неверными путями. Умение быстро диагностировать проблему - это важная часть эксплуатации WordPress-проекта его администратором или владельцем. Поэтому ниже мы привели несколько команд, которые существенно облегчают эту задачу.
Проверка конфига Nginx:
nginx -t
Просмотр ошибок в логе:
tail -f /var/log/nginx/error.log
Проверка ответа сервера:
curl -I https://site.com/
Простое нагрузочное тестирование:
ab -n 1000 -c 50 https://site.com/
Чаще всего PHP-FPM упирается в слишком маленькое значение pm.max_children. В этом случае запросы становятся в очередь, и сайт тормозит, даже если процессор «пустой». Увеличьте лимит процессов и проверьте нагрузку заново.
Посмотрите заголовки ответа:
curl -I https://site.com/
Если кеш настроен правильно, появится X-FastCGI-Cache: HIT или MISS.
Отсутствие заголовка означает, что кеш не применяется или не настроен.
Обычно неверно указан путь к сокету. Проверьте:
ls /run/php/
и сравните с директивой:
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
Если пути совпадают, убедитесь, что PHP-FPM запущен.
Да, если ваш проект генерирует предварительно сжатые .gz версии файлов (например, сборщики фронтенда).
Если таких файлов нет, то параметр можно не включать, он ничего не меняет.
Самый простой и эффективный способ - это банально ограничить частоту запросов:
limit_req zone=one burst=5 nodelay;
Либо разрешить доступ только определённым IP, если логин используется редко.
Если вы не используете мобильное приложение WordPress или старые интеграции, то да, лучше отключить:
location = /xmlrpc.php { deny all; }
Это снижает риск brute force-атак и уменьшает нагрузку на сервер.
Производительность WordPress - это не только плагины и оптимизация темы. Основные составляющие скорости, такие как обработка PHP, корректная маршрутизация, эффективное кеширование, безопасность и контроль нагрузки - обеспечиваются именно на уровне веб-сервера.
Следуя описанным в данной статье настройкам - вы можете превратить обычный недорогой VPS в надёжную платформу, способную выдерживать серьёзные проекты и высокие нагрузки. Такой сервер обеспечит стабильность, улучшит SEO-метрики вашего проекта, а также снизит потребление ресурсов и повышысит общую отзывчивость сайта. Для бизнеса это означает более быструю загрузку страниц, лучшую конверсию и устойчивость к сезонным и суточным всплескам трафика.
Вероятно, никто не будет возражать, что наличие надежного и эффективного веб-хостинга имеет первостепенное значение как для бизнеса, так и для частных лиц, учас...
В сфере системного администрирования Linux мониторинг процессов и управление ими является важнейшим аспектом поддержания стабильности и эффективности системы. К...
Компьютерная онлайн игра - Minecraft получила небывалую популярность среди детей и молодежи за счёт предоставления игроку полной свободы действий. А популярнейш...
Эффективные стратегии резервного копирования Docker-приложений: как защищать тома, данные и конфигурации, избегая при этом типичных ошибок, а также быстро восст...
Подробно разбираем, для чего используется VPS: реальные кейсы, примеры инфраструктуры, разработка, VPN, CI/CD и бизнес-сервисы. Поможет выбрать оптимальный серв...
Принципы SOLID помогают создавать гибкий, масштабируемый и поддерживаемый код. Разбираем SRP, OCP, LSP, ISP и DIP с примерами и практическими рекомендациями.
