Чому мій сайт лежить, а хостер каже «все працює»: гід по конфліктах з техпідтримкою, які можна вирішити самому
Уявіть ситуацію. П'ятниця, вечір. Ви перевіряєте сайт перед вихідними - і бачите білий екран. Або 502. Або сторінка вантажиться так, ніби на дворі 2003 рік і у вас dial-up. Ви пишете в підтримку. Через годину отримуєте відповідь: «З нашого боку все працює нормально. Перевірте ваш код». І ось ви сидите, дивитесь на екран і думаєте: хто тут збожеволів - я, мій браузер чи вся ця індустрія? Ця стаття - про ту сіру зону між «проблема на сервері» і «проблема у вашому коді», де губиться 90% звернень до хостинг-підтримки. І про те, як самостійно розібратися, хто насправді винен.
Коли хостер правий, а ви ні - і навпаки
Перше, що варто прийняти як факт: техпідтримка хостингу не бачить ваш сайт так, як бачите його ви. Їхні моніторингові системи відстежують конкретні параметри - навантаження CPU, обсяг RAM, доступність порту 80/443, статус веб-сервера. Якщо Apache або Nginx відповідає на запити, а диск не переповнений - з їхнього боку справді «все ок».
Але «сервер відповідає» і «сайт працює для користувача» - це дві абсолютно різні речі. Ваш WordPress може повертати 200-й статус із порожньою сторінкою через фатальну помилку PHP. Ваш інтернет-магазин може працювати, але з часом відповіді 8 секунд через перевантажену базу даних. Технічно - працює. Практично - мертвий.
Ось проста шпаргалка, щоб не гаяти час на марні суперечки:
| Симптом | Ймовірно проблема хостера | Ймовірно ваша проблема |
|---|---|---|
| Сайт повністю недоступний (connection timeout) | Так - мережа або сервер лежить | Рідко - хіба що DNS ще не оновився |
| 502 Bad Gateway | Можливо - PHP-FPM впав | Можливо - ваш скрипт з'їв всю пам'ять |
| 500 Internal Server Error | Рідко | Майже завжди - помилка в коді або .htaccess |
| Сайт повільний | Можливо - «шумні сусіди» на shared | Часто - неоптимізовані запити до БД |
| SSL не працює | Можливо - автопродовження зламалось | Можливо - mixed content у вашому коді |
Діагностика за 5 хвилин: інструменти, які зніматимуть всі питання
Замість писати емоційний тікет «ЧОМУ НЕ ПРАЦЮЄ???», витратьте п'ять хвилин на базову діагностику. Серйозно - це змінить все. І підтримка поважатиме вас більше, і рішення знайдеться швидше.
- ping і traceroute - відкрийте термінал (або cmd на Windows) і введіть ping vashdomen.com. Якщо пакети не доходять - проблема на рівні мережі або DNS. Це аргумент для хостера.
- Перевірка HTTP-статусу - використайте httpstatus.io або curl -I vashdomen.com. Код 200 означає, що сервер відповідає. 5xx - серверна помилка. 4xx - щось не так з вашим запитом або конфігурацією.
- Логи помилок - зайдіть у панель керування, знайдіть error_log. Там буде конкретна причина: який файл, який рядок, яка помилка. Це золото, яке більшість власників сайтів ігнорує.
- Перевірка з іншої локації - downforeveryoneorjustme.com покаже, чи сайт лежить глобально, чи тільки для вас. Можливо, проблема у вашого інтернет-провайдера.
- PHP info та ресурси - створіть файл з phpinfo() і перевірте ліміти пам'яті, версію PHP, увімкнені модулі. Часто виявляється, що хостер оновив PHP, а ваш код цього не пережив.
Головне правило: ніколи не пишіть у підтримку без конкретних даних. «Мій сайт не працює» - це як прийти до лікаря й сказати «мені погано». Чим точніший опис симптомів, тим швидше діагноз.
Помилки .htaccess: тихий вбивця, якого ви створили самі
Знаєте, яка найчастіша причина 500-ї помилки на shared-хостингу? Ні, не перевантаження сервера. Не хакерська атака. Файл .htaccess з кривими правилами. Я бачив це десятки разів: людина копіює шматок коду зі StackOverflow, вставляє в .htaccess, і сайт миттєво лягає.
Проблема в тому, що .htaccess обробляється Apache на кожному запиті. Одна синтаксична помилка - і весь сайт повертає 500. При цьому в логах Apache буде щось на кшталт "Invalid command 'RewriteRulе'" - зверніть увагу, іноді навіть кирилична літера «е» замість латинської «e» ламає все.
Що перевірити перед тим, як звинувачувати хостера:
- Перейменуйте .htaccess на .htaccess_backup і перезавантажте сайт - якщо запрацював, проблема там
- Перевірте кодування файлу - має бути UTF-8 без BOM
- Переконайтесь, що модуль mod_rewrite увімкнений (у логах буде пряма вказівка, якщо ні)
- Не змішуйте правила для Apache 2.2 і 2.4 - синтаксис різний
«Більшість інцидентів, які клієнти кваліфікують як проблему хостингу, насправді спричинені конфігураційними файлами, які останнім часом редагували самі клієнти. Ми бачимо це в 60-70% тікетів із категорією 'сайт не працює'.» - зі звіту технічної підтримки HostAdvice за 2024 рік
Ліміти хостингу, про які вам не сказали при покупці
Ось де починається найцікавіше. Ви купили тарифний план із «необмеженим» місцем і трафіком. Але ваш сайт все одно падає під навантаженням. Як так?
Секрет простий: на shared-хостингу обмежено не диск і не трафік, а процесорний час, кількість одночасних процесів і обсяг оперативної пам'яті. І ці ліміти часто сховані глибоко в Terms of Service, які ніхто не читає. Це як «безлімітний» мобільний тариф, де після 10 ГБ швидкість падає до рівня поштового голуба.
Типові приховані ліміти, які потрібно знати:
| Параметр | Shared-хостинг (типово) | VPS (типово) |
|---|---|---|
| Одночасні PHP-процеси | 5-15 | Залежить від RAM |
| RAM на процес | 128-256 МБ | Все, що виділено |
| CPU-час на добу | 60-300 секунд ядра | Гарантовані ядра |
| Кількість MySQL-з'єднань | 15-30 | 50-150+ |
| Максимальний час виконання скрипта | 30-60 секунд | Налаштовується |
Якщо ваш WooCommerce-магазин генерує звіт, що виконується 45 секунд, а ліміт - 30, процес буде вбитий. Сайт покаже помилку. А хостер скаже: «все працює». Бо сервер дійсно працює - він просто вбив ваш процес за правилами.
Рішення: перед покупкою хостингу запитайте про ліміти CPU, RAM per process і max execution time. Не про гігабайти диска. Диск - останнє, що закінчиться на нормальному тарифі.
Як правильно писати в підтримку, щоб вам реально допомогли
Після 15 років у цій індустрії я можу безпомилково відрізнити тікет, на який відповідатимуть годину, від тікета, що отримає відповідь за 10 хвилин. Різниця не в тарифі і не в пріоритеті. Різниця в тому, як сформульовано запит.
Поганий тікет: «Сайт впав, полагодіть терміново!!!»
Гарний тікет: «Домен example.com повертає 502 Bad Gateway з 14:30 UTC. curl -I показує 502. В error_log бачу 'upstream timed out'. Нічого не змінював останні 3 дні. Прошу перевірити стан PHP-FPM.»
Відчуваєте різницю? Другий тікет - це подарунок для саппорта. Він дає їм конкретну точку входу, економить час і показує, що ви - адекватний клієнт, якому варто допомогти якнайшвидше.
- Вкажіть точний час початку проблеми
- Додайте HTTP-статус і повідомлення про помилку
- Перелічіть, що ви вже перевірили самостійно
- Зазначте, чи змінювали щось перед появою проблеми
- Прикріпіть скріншот або фрагмент логу
Коли точно час міняти хостинг, а не воювати з підтримкою
Іноді проблема не в конкретному інциденті, а в паттерні. Якщо ви щомісяця витрачаєте по 3-4 години на листування з підтримкою - це червоний прапор. Ваш час коштує грошей. Порахуйте: 4 години помножити на вашу годинну ставку - чи не дорожче це за різницю між дешевим shared і нормальним VPS?
Ознаки того, що потрібно мігрувати, а не чекати:
- Проблеми з доступністю повторюються частіше, ніж раз на місяць
- Підтримка регулярно відповідає шаблонами без реального розбору
- Вам відмовляють у базовій діагностиці, посилаючись на «не наша зона відповідальності»
- Ви вже переросли shared, але вам продовжують продавати «апгрейд» того ж тарифу
Хостинг - це фундамент. Ви ж не будете безкінечно ремонтувати фундамент, якщо він тріщить щомісяця? Простіше знайти нормальну ділянку.
А тепер чесне питання до вас: скільки годин цього місяця ви витратили на з'ясування стосунків зі своїм хостером - і скільки з цих проблем могли б вирішити самі за п'ять хвилин із правильними інструментами? Можливо, варто не воювати, а навчитися дивитися в логи раніше, ніж натискати кнопку «створити тікет».