Налаштування хостинг-сервера з нуля: рецепт, який працює швидше за ваш ранковий еспресо

Уявіть: ви купили новенький сервер. Потужний, з гарними характеристиками, з блискучим SSD. Запустили його - і нічого не сталось. Сайт відкривається 8 секунд, SSH-з'єднання обривається, а логи виглядають так, ніби їх писав п'яний поет. Знайомо? Це як купити Ferrari та їздити на першій передачі, бо ніхто не пояснив, де решта. Правильне налаштування хостинг-сервера - це та різниця між «працює» та «літає». І сьогодні ми розберемо кожен крок, щоб ваш сервер став саме тим Ferrari, яким він мав бути.

Перші 30 хвилин після запуску: що робити, поки сервер ще «голий»

Коли ви щойно отримали доступ до свіжого VPS або виділеного сервера, перші дії визначають все. Це як перший день на новій роботі - помилки зараз будуть переслідувати вас місяцями.

Перші 30 хвилин - це вікно безпеки, коли ваш сервер найбільш вразливий. Він стоїть у мережі з дефолтними налаштуваннями, і сканери ботів знаходять такі машини за лічені хвилини.

1. Оновіть систему. apt update && apt upgrade -y для Debian/Ubuntu або dnf update -y для CentOS/AlmaLinux. Без цього ви працюєте на коді, в якому вже знайшли десятки дірок.
2. Створіть нового користувача замість root. Назвіть його як завгодно, але дайте sudo-права. Працювати постійно під root - це як ходити з ключами від усіх дверей на шиї в людному місці.
3. Змініть порт SSH. Стандартний 22 порт атакують тисячі ботів щодня. Перенесіть на 2222, 4848 або інший вільний порт вище 1024.
4. Налаштуйте SSH-авторизацію за ключами та вимкніть парольний вхід. Це одна команда в /etc/ssh/sshd_config, але вона зупиняє 99% brute-force атак.
5. Увімкніть файрвол. UFW для Ubuntu, firewalld для CentOS. Відкрийте тільки потрібні порти: SSH, HTTP (80), HTTPS (443). Все інше - закрити.

Ці п'ять кроків займають 20-30 хвилин. Але саме вони відрізняють сервер, який зламають через тиждень, від сервера, який працюватиме роками.

Веб-сервер: Nginx, Apache чи може обоє разом?

Класичне питання, яке розділяє адмінів на два табори з 2004 року. Давайте без фанатизму подивимось на цифри.

Мій досвід за 15 років: якщо ви налаштовуєте сервер під один-два сайти на WordPress або Laravel - ставте чистий Nginx. Він жере менше ресурсів і працює швидше з PHP-FPM. Якщо у вас десятки клієнтських сайтів з різними .htaccess - зв'язка Nginx як reverse proxy перед Apache дасть і швидкість, і сумісність.

«Nginx was written specifically to address the performance limitations of Apache web servers. It can handle over 10,000 simultaneous connections with a low memory footprint.» - W3Techs, Web Server Survey 2024

Порада: встановлюючи Nginx, одразу налаштуйте gzip-стиснення та кешування статики. Два блоки в конфігурації - і ваш сайт «схудне» на 60-70% у трафіку.

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

Веб-сервер без правильно налаштованого бекенду - це красива вітрина порожнього магазину. Ось три компоненти, які треба «подружити» між собою.

PHP-FPM - ваш головний виконавець. Стандартні налаштування розраховані на сервер з 512 МБ RAM та трьома відвідувачами. Якщо у вас 4-8 ГБ RAM, відкрийте www.conf і змініть:

• pm = dynamic замість ondemand (швидший відгук)
• pm.max_children - порахуйте за формулою: (RAM - 1 ГБ) / 40 МБ. Для 4 ГБ це приблизно 75
• pm.max_requests = 500 - запобігає витокам пам'яті в довгоживучих процесах
• OPcache - обов'язково увімкніть. Це як кешувати переклад книги замість перекладати кожну сторінку щоразу заново

MySQL/MariaDB - тут найбільше помилок. Дефолтний my.cnf зазвичай виділяє під InnoDB buffer pool жалюгідні 128 МБ. Для сервера з 4 ГБ RAM виставте innodb_buffer_pool_size = 1G. Це єдиний параметр, який може прискорити базу даних на 200-300%.

Redis або Memcached - фінальний штрих. Redis зараз популярніший, бо вміє зберігати дані на диск і підтримує складніші структури. Для WordPress з плагіном Redis Object Cache різниця відчутна: час генерації сторінки падає з 800 мс до 150-200 мс. Це не магія. Це просто правильне кешування.

SSL, HTTP/2 та безпека: не просто «замочок у браузері»

У 2025 році сайт без SSL - це як магазин без дверей. Google прямо каже: HTTPS - фактор ранжування. Але просто встановити сертифікат - це половина справи.

Let's Encrypt + Certbot вирішують питання безкоштовних сертифікатів за 2 хвилини. Одна команда certbot --nginx -d yourdomain.com - і готово. Але після цього зайдіть у конфігурацію Nginx та додайте:

• Заголовки безпеки: Strict-Transport-Security (HSTS), X-Content-Type-Options, X-Frame-Options
• HTTP/2 - просто додайте http2 в директиву listen. Паралельне завантаження ресурсів дає приріст швидкості 15-30%
• Вимкніть застарілі протоколи TLS 1.0 та 1.1. Залиште тільки TLS 1.2 і 1.3
• Налаштуйте fail2ban - він автоматично блокує IP-адреси після кількох невдалих спроб входу

Перевірте свій SSL на ssllabs.com. Оцінка нижче A - привід для занепокоєння. Оцінка A+ - ваша мета. Різниця між ними - буквально 10 рядків конфігурації.

Моніторинг та автоматичні бекапи: страховка, яку ніхто не купує, поки не пізно

Знаєте, що спільного між бекапами та парашутами? Коли вони потрібні, а їх немає - вже пізно шукати. Я бачив десятки випадків, коли бізнеси втрачали місяці роботи через одну збійну команду rm -rf в неправильній директорії.

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

1. Щоденний бекап бази даних через cron + mysqldump. Зберігайте останні 7 копій.
2. Щотижневий повний бекап файлів за допомогою rsync на зовнішній сервер або S3-сумісне сховище.
3. Снепшоти сервера у вашого хостинг-провайдера - увімкніть, навіть якщо це коштує додатково $2-3 на місяць.
4. Тестуйте відновлення хоча б раз на квартал. Бекап, з якого неможливо відновитись - це не бекап, а самозаспокоєння.

Для моніторингу навантаження встановіть хоча б htop і Netdata (безкоштовний, з гарним веб-інтерфейсом). Вони покажуть, коли CPU, RAM або диск наближаються до критичних значень - до того, як ваші відвідувачі побачать білий екран.

Тонке налаштування ядра Linux: де ховаються останні 20% швидкості

Коли все вже встановлено та працює, залишається фінальний шар оптимізації - параметри ядра в /etc/sysctl.conf. Це як тюнінг двигуна: зовні нічого не змінилось, але відчуття зовсім інші.

Ключові параметри для хостинг-сервера:

• net.core.somaxconn = 65535 - збільшує чергу з'єднань. Дефолтні 128 - це смішно для будь-якого реального навантаження
• vm.swappiness = 10 - система почне використовувати swap тільки коли RAM заповнена на 90%. За замовчуванням ядро починає свопити надто рано, і це вбиває продуктивність
• net.ipv4.tcp_tw_reuse = 1 - дозволяє перевикористовувати TIME_WAIT сокети, що критично при великій кількості з'єднань

Після зміни параметрів виконайте sysctl -p та протестуйте навантаження за допомогою ab (Apache Benchmark) або wrk. Порівняйте час відповіді до та після. Зазвичай виграш складає 15-25% при високому трафіку.

Головне правило: змінюйте по одному параметру за раз та замірюйте результат. Інакше ви ніколи не дізнаєтесь, що саме допомогло, а що зламало.

Налаштування хостинг-сервера - це не разова подія, а безперервний процес. Ваш сервер - живий організм, який потребує уваги, оновлень та періодичної діагностики. Але от що цікаво: більшість адмінів витрачають 80% часу на початкове налаштування і 0% на подальшу оптимізацію. А ви? Коли останнього разу ви перевіряли, чи не з'їдає ваш сервер більше ресурсів, ніж потрібно?