Блог компанії 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 з прикладами та практичними рекомендаціями...
