Налаштування хостинг-сервера з нуля: 7 речей, які відрізняють стабільний сайт від вічного пожежогасіння

Уявіть: ви орендували нову квартиру. Є стіни, є дах, навіть вікна на місці. Але немає замків на дверях, бойлер не підключений, а електрика тримається на скрутках з ізолентою. Жити можна? Формально так. Безпечно і комфортно? Ні. Саме так виглядає свіжовстановлений хостинг-сервер, який ніхто не налаштовував. Він працює - але це ілюзія. І більшість власників сайтів живуть у цій ілюзії місяцями, поки перший серйозний інцидент не витягне їх з-під ковдри о третій ночі.

Ця стаття - не для тих, хто хоче «трошки підкрутити». Вона для тих, хто хоче зрозуміти, як правильно налаштувати хостинг-сервер від першого підключення до стану, коли він працює надійно, швидко і безпечно. Без магії. Без тисячі команд на пам'ять. З конкретикою і здоровим глуздом.

Перший логін: що робити в перші 30 хвилин після отримання доступу

Ви щойно отримали email з IP-адресою, логіном root та паролем. Що далі? Більшість людей одразу кидаються ставити WordPress або панель керування. Це приблизно те саме, що вмикати газ у квартирі, де ще не перевірили труби.

Перші 30 хвилин на сервері визначають 80% його подальшої безпеки. Ось що потрібно зробити одразу:

1. Змінити пароль root на складний (мінімум 20 символів, генератор паролів вам у допомогу).
2. Створити окремого користувача з правами sudo і заборонити прямий SSH-вхід для root.
3. Оновити всі пакети - apt update && apt upgrade -y на Debian/Ubuntu або dnf update -y на AlmaLinux.
4. Налаштувати SSH - змінити порт з дефолтного 22, увімкнути автентифікацію за ключами, вимкнути вхід за паролем.
5. Увімкнути базовий фаєрвол - UFW або firewalld, дозволити лише потрібні порти.

П'ять кроків. 30 хвилин. Після цього ваш сервер вже безпечніший за 70% машин у дикому інтернеті. Я не жартую - за статистикою Shodan, десятки тисяч серверів працюють із дефолтним SSH на 22 порту і дозволяють root-логін за паролем. Це запрошення для ботів.

Вебсервер: Apache, Nginx чи гібрид - і чому це питання складніше, ніж здається

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

На практиці для більшості сайтів на WordPress, Laravel або іншому PHP-фреймворку Nginx як reverse proxy перед Apache - золотий стандарт. Nginx блискавично віддає статику (картинки, CSS, JS), а Apache обробляє PHP через mod_php або PHP-FPM. Це дає виграш у 2-3 рази по швидкості порівняно з голим Apache під навантаженням.

Але якщо ваш проєкт - це Node.js, Go або Python-додаток, Apache вам не потрібен взагалі. Nginx або навіть Caddy впораються самостійно.

PHP, бази даних і кешування: трикутник продуктивності

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

PHP-FPM - це перше, що варто налаштувати після встановлення PHP. Дефолтний пул з 5 воркерами здатний обслуговувати хіба що ваш власний браузер. Для сервера з 4 GB RAM і середнім WordPress-сайтом оптимальна конфігурація виглядає приблизно так:

• pm = dynamic
• pm.max_children = 20
• pm.start_servers = 5
• pm.min_spare_servers = 3
• pm.max_spare_servers = 10

Для баз даних (MySQL/MariaDB) ключовий параметр - innodb_buffer_pool_size. Емпіричне правило: виділяйте під нього 50-70% доступної RAM, якщо сервер обслуговує переважно базу даних. На 4 GB машині - це 2-2.8 GB.

«Найпоширеніша помилка системних адміністраторів - залишати конфігурацію MySQL у стані за замовчуванням. Дефолтний innodb_buffer_pool_size у 128 MB на продакшн-сервері - це як поставити двигун від скутера в вантажівку.» - Percona Performance Blog, 2024

Тепер кешування. Redis або Memcached? Для більшості задач Redis виграє: він вміє зберігати дані на диск, підтримує складні структури і відмінно працює як сесійний бекенд. Встановіть Redis, підключіть його до вашого CMS або фреймворку - і спостерігайте, як TTFB (Time to First Byte) падає з 800 мс до 150-200 мс. Різниця відчутна неозброєним оком.

SSL, HTTP/2 і заголовки безпеки: те, що бачить і Google, і хакер

Let's Encrypt зробив SSL-сертифікати безкоштовними у 2015 році. Минуло десять років. І досі існують сервери без HTTPS. Це вже навіть не халатність - це сміливість на межі з абсурдом.

Налаштування SSL через Certbot займає буквально 5 хвилин:

1. Встановити Certbot: apt install certbot python3-certbot-nginx
2. Отримати сертифікат: certbot - nginx -d yourdomain.com
3. Перевірити автоматичне оновлення: certbot renew - dry-run

Але SSL - це тільки початок. Справжній захист починається з HTTP-заголовків безпеки, і їх ігнорують навіть досвідчені адміністратори:

• Strict-Transport-Security - примушує браузер використовувати тільки HTTPS
• X-Content-Type-Options: nosniff - блокує MIME-type sniffing
• X-Frame-Options: SAMEORIGIN - захист від clickjacking
• Content-Security-Policy - контролює, звідки можна завантажувати скрипти, стилі, шрифти

Перевірити свій сервер можна на securityheaders.com - безкоштовно і за 10 секунд. Більшість сайтів отримують оцінку D або F. Після додавання згаданих заголовків - A або A+. Різниця між цими оцінками - 15 хвилин вашого часу.

Моніторинг: як дізнатися про проблему до того, як зателефонує клієнт

Знаєте, яка найдорожча фраза в IT? «А що, воно лежало?» Якщо ви дізнаєтесь про падіння сервера від користувача або від Google Search Console через три дні - ви вже втратили гроші, позиції і довіру.

Мінімальний моніторинг, який повинен бути на кожному хостинг-сервері:

• Uptime-моніторинг - UptimeRobot (безкоштовний план на 50 моніторів), Hetrixtools, або Better Stack
• Серверні метрики - Netdata (встановлюється одним рядком, дає реальний час по CPU, RAM, диску, мережі)
• Сповіщення - Telegram-бот, email або Slack. Головне - щоб ви побачили алерт протягом 5 хвилин

Для серйозніших інсталяцій варто дивитись у бік Prometheus + Grafana. Так, налаштування займе кілька годин. Але коли у вас дашборд, де видно навантаження за останні 30 днів, ви починаєте розуміти свій сервер, а не просто реагувати на пожежі.

Автоматизація рутини: ansible, скрипти і здоровий глузд

Якщо ви налаштовуєте кожен новий сервер вручну - ви не адміністратор, ви археолог, який щоразу заново винаходить колесо. Один сервер - ще терпимо. Два - вже незручно. П'ять - і ви потонете в нотатках «що я там поміняв минулого разу».

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

Типовий плейбук для початкового налаштування сервера включає:

1. Створення користувача і налаштування SSH-ключів
2. Встановлення і конфігурація Nginx + PHP-FPM
3. Встановлення MariaDB з безпечними дефолтами
4. Налаштування UFW з потрібними портами
5. Встановлення Certbot і отримання SSL
6. Розгортання Netdata для моніторингу

Один раз написали - і кожен наступний сервер налаштовується за 10 хвилин замість 4 годин. Більше того, ваша конфігурація стає документацією сама по собі. Через рік ви відкриєте плейбук і точно знатимете, що і як налаштовано.

Навіть якщо Ansible здається надмірним - напишіть хоча б bash-скрипт з базовими командами. Це краще, ніж нічого. Набагато краще.

А ваш сервер готовий до наступного понеділка?

Понеділок - день, коли трафік повертається. Коли боти активізуються. Коли клієнт вирішує оновити каталог на 10 000 товарів. Чи витримає ваш сервер? Чи налаштований він так, щоб не просто «працювати», а працювати передбачувано?

Налаштування хостинг-сервера - це не разова задача. Це процес, який починається з першого логіну і ніколи повністю не закінчується. Але різниця між адміном, який витратив 2 дні на початкове налаштування, і тим, хто одразу почав заливати файли на голий сервер - це різниця між спокійним сном і нічними дзвінками.

Що з вашого списку ви ще не зробили? Можливо, саме час відкрити термінал.