Apache проти NGINX: який веб-сервер краще для WordPress?

Якщо ви тримаєте WordPress на власному VPS, і Apache, і NGINX добре обслуговуватимуть сайт, але йдуть на різні компроміси. NGINX зазвичай кращий варіант за замовчуванням для високої конкурентності, віддачі статики та опційного HTTP/3. Apache простіший, коли ваш стек WordPress залежить від .htaccess або від специфічних для Apache модулів.

Це порівняння Apache та NGINX зосереджене на відмінностях, важливих для WordPress: архітектура, обробка PHP, конфігурація, HTTP/3 і питання, чи варта запуск обох додаткової складності. LiteSpeed і Caddy лишаються поза межами теми.

Коротка відповідь: для самостійно керованого VPS із WordPress за замовчуванням обирайте NGINX. Обирайте Apache, якщо сайт або плагіни сильно залежать від .htaccess. Запускайте обидва лише тоді, коли вам справді потрібен NGINX спереду без відмови від сумісності з Apache.

Що таке Apache?

Apache — популярне веб-серверне програмне забезпечення з відкритим кодом, яке розробляє та підтримує американська неприбуткова організація Apache Software Foundation (ASF). Його також знають як Apache HTTP Server і HTTPD.

Сторінка завантаження Apache вказує версію 2.4.68, випущену в червні 2026 року, як поточний стабільний реліз.

Apache HTTP Server — модульний сервер з відкритим кодом і зрілою підтримкою покаталожних правил .htaccess, кількох мультипроцесних модулів (MPM), зворотного проксіювання, переписування URL, TLS і динамічно завантажуваних модулів. Для WordPress його головна практична перевага — сумісність конфігурацій, а не чиста швидкість.

Можливості Apache, які найбільше важать у цьому порівнянні: MPM prefork, worker та event; .htaccess; HTTP/2; зворотне проксіювання та балансування навантаження; підтримка FastCGI; динамічні модулі; переписування URL; і TLS.

Що таке NGINX?

NGINX («engine x») — це веб-сервер з відкритим кодом, зворотний проксі, кеш контенту, балансувальник навантаження, TCP/UDP-проксі та поштовий проксі, спершу написаний Ігорем Сисоєвим. Його робочі процеси використовують подієву модель, розраховану на обслуговування багатьох одночасних з'єднань із малими накладними витратами на кожне.

Сторінка завантаження NGINX lists the 1.30.x stable branch and the 1.31.x mainline branch.

Apache проти NGINX: ключові відмінності для WordPress

Apache та NGINX найпомітніше різняться в тому, як обробляють з'єднання, конфігурацію, PHP і підтримку протоколів. Поведінка Apache значною мірою залежить від використаного MPM, а NGINX працює на подієвих робочих процесах.

Apache проти NGINX: архітектура

Модель обробки запитів в Apache залежить від того, який MPM ви використовуєте. Prefork побудований на процесах, а worker та event використовують потоки. NGINX працює на робочих процесах, збудованих навколо циклів подій. Тому звичне порівняння «процесний Apache проти подієвого NGINX» надто спрощує картину для сучасного встановлення Apache 2.4.

MPM event в Apache може передавати неактивні keep-alive з'єднання своєму потоку-слухачу замість того, щоб займати під кожне окремий робочий потік. За дуже великої кількості одночасних з'єднань NGINX і далі зазвичай має нижчі накладні витрати на з'єднання, але архітектурний розрив значно вужчий, ніж випливає зі старих порівнянь часів prefork.

Apache проти NGINX: продуктивність

Перевага NGINX у продуктивності проявляється передусім за високої конкурентності та на статиці. Його подієві робочі процеси тримають багато відкритих з'єднань із відносно малими накладними витратами на кожне. MPM event в Apache помітно скорочує цей розрив порівняно зі старими конфігураціями prefork.

З динамічними запитами WordPress картина інша. NGINX зазвичай передає PHP у FastCGI, найчастіше в PHP-FPM. Apache теж може працювати з PHP-FPM через FastCGI або виконувати PHP через модуль Apache.

Щойно PHP починає виконувати WordPress, код плагінів, запити до бази, об'єктний чи сторінковий кеш і кількість PHP-воркерів можуть важити більше, ніж веб-сервер спереду. Якщо плагін виконує десяток важких запитів до бази на кожен запит, перехід з Apache на NGINX не усуне саму причину.

Apache проти NGINX: підтримка HTTP/3 і QUIC

HTTP/3 — поточна версія протоколу, і вона працює поверх QUIC замість TCP. Чи зможе ваш сайт взагалі його запропонувати, залежить від веб-сервера спереду, і це єдиний пункт порівняння, де два сервери не поруч.

NGINX постачає модуль HTTP/3 починаючи з версії 1.25.0. За замовчуванням він не збирається, і збірці потрібен параметр --with-http_v3_module.

Документація модуля HTTP/3 в NGINX досі називає модуль «experimental, caveat emptor applies».

Apache 2.4 не постачає власного модуля HTTP/3 чи QUIC; вбудована підтримка протоколів завершується на mod_http2.

Практичний наслідок для власника сайту: звичайне встановлення Apache 2.4 не віддає HTTP/3. У продакшені робочий варіант і далі такий: термінувати HTTP/3 на зворотному проксі або CDN із підтримкою HTTP/3 перед Apache. Якщо протокол потрібен, один із варіантів — поставити NGINX перед Apache і дати NGINX термінувати клієнтські з'єднання, саме та схема, яку розібрано нижче.

Apache проти NGINX: безпека

Ані Apache, ані NGINX не є беззастережно «безпечнішим». Обидва проєкти зрілі, з активним супроводом безпеки, і захищеність продакшену залежить радше від оновлень, увімкнених модулів, налаштування TLS, контролю доступу, обмеження запитів і самого застосунку за сервером.

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

Apache проти NGINX: конфігурація

Покаталожні файли .htaccess в Apache працюють там, де це дозволяє AllowOverride. Для WordPress це зручно, бо правила переписування можна змінювати, не чіпаючи глобальну конфігурацію сервера.

Ця зручність має свою ціну. Власна документація Apache рекомендує тримати правила в основній конфігурації сервера, якщо у вас є root-доступ: файли .htaccess перевіряються під час запитів, а їх увімкнення додає і питання продуктивності, і питання безпеки.

У NGINX немає аналога .htaccess. Його конфігурація централізована, тож WordPress не може сам записати правила переписування на рівні сервера. Правила постійних посилань і серверні директиви, які вимагають плагіни, адміністратор додає до конфігурації NGINX і потім перезавантажує її.

Apache проти NGINX: модулі та розширюваність

В Apache зріла підтримка динамічних спільних об'єктів (DSO): модулі можна зібрати окремо й підключити через LoadModule. NGINX теж підтримує динамічно завантажувані модулі через load_module, але двійкова сумісність зі встановленою версією NGINX та її конфігурацією збірки важить більше, щойно ви берете нестандартні сторонні модулі.

Отже, Apache попереду, якщо ви залежите від нетипових сторонніх модулів. Для звичайного хостингу WordPress ця відмінність зазвичай важить менше, ніж .htaccess, робота з PHP та вже звичні вам інструменти.

Apache проти NGINX: підтримка платформ

Apache працює на Linux, Windows, macOS і багатьох Unix-подібних системах. NGINX теж доступний на основних платформах, але його нативна збірка під Windows має серйозні обмеження. NGINX і далі називає версію для Windows бетою, попереджає, що не варто очікувати високої продуктивності та масштабування, зазначає, що реально працює лише один воркер, і не підтримує ні UDP, ні QUIC. Для продакшену з NGINX практичним вибором лишається Unix-подібна операційна система.

Apache проти NGINX: обробка запитів

Apache зазвичай відображає URL запиту на файлову систему під DocumentRoot, а його система конфігурації вміє застосовувати ще й локації за URI, переписування та правила проксіювання. NGINX спершу обирає блок server, потім блок location, здебільшого за URI запиту, і лише потім вирішує, віддати файл чи передати запит далі.

Ця відмінність впливає на те, як ви пишете конфігурацію, але сама по собі не доводить, що NGINX передає дані швидше.

Коротке порівняння NGINX та Apache

Ось як два сервери співвідносяться за переліченими вище пунктами, плюс підтримка протоколів і поточна версія кожного.

Використання Apache та NGINX разом

Так, можна запустити обидва. Поширена гібридна схема ставить NGINX спереду як звернений до клієнтів зворотний проксі, а Apache позаду. NGINX уміє термінувати TLS і HTTP/2, а також HTTP/3, коли його експериментальний модуль HTTP/3 зібрано й увімкнено. Ще він може сам віддавати частину статики, передаючи запити застосунку до Apache.

Головне застереження — кому належать правила. Запит, який NGINX віддає сам, до Apache взагалі не доходить, тож правила .htaccess до нього не застосовуються. Дві конфігурації мають узгоджуватися щодо переписувань, кешування, передавання IP клієнта, поведінки TLS і того, який сервер відповідає за який шлях.

Ціна в тому, що тепер у вас працюють два веб-сервери. Дві конфігурації, які мають узгоджуватися, два цикли оновлень і ще одне місце, куди доведеться зазирнути, коли запит поверне щось несподіване. На одному невеликому сайті цей клопіт зазвичай переважує вигоду; він починає окуповуватися, коли вам потрібен HTTP/3 або швидша віддача статики без відмови від поведінки .htaccess, на яку розраховують ваші плагіни.

Чи простіший NGINX за Apache?

Жоден із них не простіший в усіх випадках. NGINX простіший, якщо вам ближча одна централізована конфігурація і ви спокійно правите блоки server. Apache простіший, коли WordPress або сторонні плагіни розраховують на правила .htaccess, адже ці правила діють на рівні каталогу й не потребують зміни глобальної конфігурації сервера.

На сервері, який ви контролюєте, «простіше» зводиться здебільшого до того, яку модель конфігурації ваш стек уже передбачає.

Коли обирати Apache замість NGINX?

Обирайте Apache, коли ваш стек WordPress залежить від .htaccess, коли плагіни або інструменти панелі керування розраховують на директиви переписування Apache, або коли вам потрібен конкретний модуль Apache. Розумно й лишити Apache на наявному сайті, який і так добре працює: міняти веб-сервер заради теоретичного виграшу в бенчмарку рідко варте пов'язаного з цим клопоту.

Коли обирати NGINX замість Apache?

Обирайте NGINX, коли чекаєте багато одночасних з'єднань, хочете сильний шар віддачі статики чи зворотного проксіювання, віддаєте перевагу централізованій конфігурації або хочете мати змогу ввімкнути HTTP/3. Для WordPress платою буде те, що правила переписування та серверні директиви плагінів стають задачею адміністратора, а не тим, що WordPress може записати в .htaccess.

NGINX проти Apache: який веб-сервер краще для WordPress?

Беріть NGINX. Для сайту на WordPress на сервері, який ви контролюєте, це кращий варіант за замовчуванням: невеликі накладні витрати на з'єднання за високої конкурентності, ефективна віддача статики й доступний HTTP/3, якщо він вам потрібен.

Виняток — .htaccess, і він вагомий. WordPress уміє писати правила переписування для Apache, коли .htaccess увімкнено, але змінити конфігурацію NGINX він не може. Якщо плагін очікує директив переписування, безпеки чи кешування, вам знадобляться його інструкції для NGINX або рівнозначне правило в блоці server, а потім перезавантаження NGINX. Якщо ви не хочете брати на себе цю експлуатаційну відповідальність, для WordPress простіший Apache. На сайті зі звичайним трафіком продуктивність радше обмежать PHP, база даних і кешування, ніж сам веб-сервер.

Під усім цим лежить одне припущення: сервер має бути вашим і змінюваним. На керованому хостингу WordPress веб-сервер обирає хостер, і відповідь на це питання — просто те, що в нього вже працює. Це порівняння для того, хто має root-доступ до власної машини.

Як перевірити, що у вас працює: Apache чи NGINX?

Якщо це ваш власний VPS, перевірте запущені служби напряму:

systemctl status nginx
systemctl status apache2   # Debian/Ubuntu
systemctl status httpd     # RHEL/Fedora-family systems

Для чужого сайту, який ви не контролюєте, заголовок відповіді HTTP Server може бути підказкою, але не доказом. Зворотний проксі або CDN може показувати власне серверне ПЗ замість того, що стоїть на origin, а сам заголовок можна приховати чи змінити.

Розміщення Apache або NGINX на VPS

Якщо VPS ваш, обидва сервери запускаються без складнощів. Добирайте розмір машини під увесь стек WordPress, а не лише під Apache чи NGINX: PHP-воркери, база даних, кешування, трафік і фонові задачі зазвичай з'їдають більше ресурсів, ніж сам веб-сервер.

Хоч який сервер ви оберете, конфігурація, оновлення, TLS, резервні копії та моніторинг лишаються на вас. Запуск обох додає ще одну конфігурацію і ще один шлях оновлень, тож беріться за гібридну схему лише за конкретної причини.

NGINX VPS від Cloudzy — це самостійно керований Linux VPS із повним root-доступом, тож конфігурація сервера лишається вашою.

Образ Apache HTTP Server у нашому маркетплейсі встановлюється так само, в один клік, тож підняти будь-який із серверів чи одразу обидва не починається зі складання з вихідних кодів.

ЧИТАЙ

Caddy проти Nginx на VPS: порівняння файлів конфігурації

Часті запитання

Чи кращий Apache за NGINX?

Жоден не кращий в усіх випадках. NGINX зазвичай сильніший варіант за замовчуванням, коли вам важливі висока конкурентність, віддача статики, зворотне проксіювання чи HTTP/3. Apache зазвичай простіший, коли ваш стек WordPress залежить від .htaccess або від специфічних для Apache модулів.

Чому NGINX швидший за Apache?

NGINX уміє обробляти безліч з'єднань усередині циклу подій кожного воркера, що тримає низькі накладні витрати на з'єднання за високої конкурентності. MPM event в Apache теж обробляє з'єднання асинхронно, тож розрив менший, ніж випливає зі старих порівнянь із prefork. У WordPress PHP, запити до бази й кешування можуть важити більше, ніж різниця між веб-серверами.

Що використовувати для WordPress: Apache чи NGINX?

Для самостійно керованого VPS із WordPress NGINX — сильний варіант за замовчуванням, якщо ви готові самі вести правила в блоках server. Обирайте Apache, якщо спираєтеся на .htaccess або на плагіни, що очікують правил переписування Apache, і хочете, щоб вони працювали з меншим обсягом ручного налаштування сервера.

Чому NGINX такий популярний?

NGINX поєднує ефективну обробку запитів за високої конкурентності зі зворотним проксіюванням, балансуванням навантаження, кешуванням, підтримкою FastCGI та термінуванням TLS. Завдяки цьому він корисний і як основний веб-сервер, і як фронтальний проксі.

Чому Apache досі використовують?

Apache лишається широко вживаним завдяки екосистемі модулів, підтримці .htaccess, зрілим інструментам, широкій підтримці платформ і сумісності з хостинговими процесами та панелями керування, збудованими навколо нього.

Яка різниця між Apache та apache2?

У Debian та Ubuntu apache2 — це назва пакета й служби для Apache HTTP Server. У системах родини RHEL і Fedora цю службу зазвичай називають httpd. Це не різні веб-сервери: обидві назви означають Apache HTTP Server. Поточна стабільна гілка Apache — 2.4, останній випуск у ній 2.4.68.

Чи підтримує Apache HTTP/3?

Початково ні. Apache HTTP Server 2.4 не постачається з модулем HTTP/3 чи QUIC; вбудована підтримка протоколів завершується на HTTP/2. Якщо HTTP/3 потрібен у продакшені, ви можете термінувати його на зворотному проксі або CDN із підтримкою HTTP/3 перед Apache.