Вебсервери
Apache httpd: оригінальний веб-сервер, який все ще завойовує своє місце
Apache httpd забезпечив роботу Інтернету протягом трьох десятиліть, і ера Apache Running After Maturity є реальною: подія MPM зробила робочі навантаження класу mod_php одночасними, модулі охоплюють усе, від автентифікації до кешування на стороні сервера, а .htaccess забезпечує керованість спільного хостингу. Його стереотип застарів з точки зору продуктивності, але точний з точки зору торгівлі, і знання компромісів робить Apache законним варіантом, а не вибаченням.
Головне
- Подія MPM є сучасною платформою: фіксований пул робочих потоків асинхронно подає підключення для підтримки активності, тому поточний Apache більше не руйнується під час паралелізму, як старі тести prefork; prefork підходить лише для небезпечних потоків модулів і залишається навмисним винятком.
- Поверхня модуля — це функції: mod_ssl, mod_security (стандартний WAF), mod_rewrite, mod_proxy плюс вентилятори балансування та модулі автентифікації для кожної епохи; Модулі можуть бути скомпільовані або завантажені за допомогою інструментів класу a2enmod із перевизначеннями для кожного хоста, тому спільний хостинг все ще запускає Apache спочатку.
- .htaccess — це двостороння культурна функція: перевизначення на рівні каталогу дає користувачам повну конфігурацію (перенаправлення на сайт, прапорці PHP, божевілля безпеки), але кожен запит оплачує пошук і розбір файлової системи; де продуктивність має значення, а правила стабільні, перемістіть правила htaccess у конфігурацію сервера.
- Зворотне проксі є реальним, але вторинним: варіанти mod_proxy/AJP і mod_pagespeed-class існують, хоча для периферійної роботи проксі nginx/caddy/traefik-class зазвичай виграють; поширеною сучасною формою є Apache, що стоїть за швидшим фронтом для застарілих додатків (і спільного хостингу WordPress, де htaccess має навантаження).
- Дисципліна конфігурації, перевірена на практиці: apachectl configtest після змін, окремі віртуальні хости на сайт, modsecurity не просто встановлений, а налаштований набір правил (за замовчуванням Paranoia Level 1), модулі в стилі mod_evasive/limitreq для обробки флудів і помилок журналювання, а також доступ із полями швидкості для рівнів аналізу журналу.
- Чесний вердикт у 2026 році: Apache — чудовий сервер додатків і посередній крайовий проксі; Запустіть його там, де його модулі та перевизначення каталогу несуть робоче навантаження, забезпечте його мінімальним зворотним проксі, коли це потрібно масштабу, і ніколи не дозволяйте скануванням htaccess залишатися без моніторингу (вони є постійною поверхнею для використання на спільному хостингу).
Польова нотатка
Хостинг WordPress, який ми взяли під контроль, керував Apache із 1700 файлами .htaccess на різних сайтах, деякі з них суперечливі. Ми перемістили стабільні правила в конфігурації vhost, зберегли перевизначення для кожного сайту там, де це було потрібно власникам, і затримка спільного хосту p99 скоротилася на третину, не купуючи нічого.
Часті запитання
Чи ми продовжимо працювати з Apache у 2026 році?
Так, і з поважних причин: екосистема .htaccess (спільний хостинг класу WordPress/Drupal), зрілість mod_security та охоплення модуля для застарілих стеків. Заміна оптом — це рішення, пов’язане з роботою, а не модне.
Який MPM ми повинні запустити?
Подія для будь-чого сучасного, prefork навмисно для застарілих модулів, що не є потокобезпечними (деякі стеки розширень PHP і старіші бібліотеки); worker на даний момент здебільшого історія. Вимірюйте власний трафік після будь-якого перемикання MPM.
Чи є .htaccess поганим?
Непогано, це коштує продуктивності за запит і розширює зону атаки на загальному хостингу, але це вся причина, по якій спільний хостинг взагалі працює; Дисципліна полягає в перенесенні стабільних правил до конфігурації vhost і спостереженні за замінами на рівні каталогу.
Як mod_security відповідає стеку безпеки?
Це найпоширеніший відкритий рівень WAF, який чудово фільтрує очевидні класи експлойтів (шаблони SQLi, обхід шляху, зонди адміністратора), але шумить без налаштування; поєднайте його з журналами та винятками для кожного сайту (перегляньте нашу статтю про конфігурацію брандмауера для доповнення на стороні сервера).
Допомога Kinetikatech: вебсервери
Ось у чому річ: Налаштування, оптимізація й безпека вебсерверів у виробничих і тестових середовищах. Передайте це службі Оптимізація швидкості сайтів та Адміністрування серверів, і все буде закрито: грамотна оцінка, чисте впровадження, цілодобовий нагляд.