Чому мій сайт лежить, а хостер каже «все працює»: гід по конфліктах з техпідтримкою, які можна вирішити самому

Уявіть ситуацію. П'ятниця, вечір. Ви перевіряєте сайт перед вихідними - і бачите білий екран. Або 502. Або сторінка вантажиться так, ніби на дворі 2003 рік і у вас dial-up. Ви пишете в підтримку. Через годину отримуєте відповідь: «З нашого боку все працює нормально. Перевірте ваш код». І ось ви сидите, дивитесь на екран і думаєте: хто тут збожеволів - я, мій браузер чи вся ця індустрія? Ця стаття - про ту сіру зону між «проблема на сервері» і «проблема у вашому коді», де губиться 90% звернень до хостинг-підтримки. І про те, як самостійно розібратися, хто насправді винен.

Коли хостер правий, а ви ні - і навпаки

Перше, що варто прийняти як факт: техпідтримка хостингу не бачить ваш сайт так, як бачите його ви. Їхні моніторингові системи відстежують конкретні параметри - навантаження CPU, обсяг RAM, доступність порту 80/443, статус веб-сервера. Якщо Apache або Nginx відповідає на запити, а диск не переповнений - з їхнього боку справді «все ок».

Але «сервер відповідає» і «сайт працює для користувача» - це дві абсолютно різні речі. Ваш WordPress може повертати 200-й статус із порожньою сторінкою через фатальну помилку PHP. Ваш інтернет-магазин може працювати, але з часом відповіді 8 секунд через перевантажену базу даних. Технічно - працює. Практично - мертвий.

Ось проста шпаргалка, щоб не гаяти час на марні суперечки:

Діагностика за 5 хвилин: інструменти, які зніматимуть всі питання

Замість писати емоційний тікет «ЧОМУ НЕ ПРАЦЮЄ???», витратьте п'ять хвилин на базову діагностику. Серйозно - це змінить все. І підтримка поважатиме вас більше, і рішення знайдеться швидше.

1. ping і traceroute - відкрийте термінал (або cmd на Windows) і введіть ping vashdomen.com. Якщо пакети не доходять - проблема на рівні мережі або DNS. Це аргумент для хостера.
2. Перевірка HTTP-статусу - використайте httpstatus.io або curl -I vashdomen.com. Код 200 означає, що сервер відповідає. 5xx - серверна помилка. 4xx - щось не так з вашим запитом або конфігурацією.
3. Логи помилок - зайдіть у панель керування, знайдіть error_log. Там буде конкретна причина: який файл, який рядок, яка помилка. Це золото, яке більшість власників сайтів ігнорує.
4. Перевірка з іншої локації - downforeveryoneorjustme.com покаже, чи сайт лежить глобально, чи тільки для вас. Можливо, проблема у вашого інтернет-провайдера.
5. 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 ГБ швидкість падає до рівня поштового голуба.

Типові приховані ліміти, які потрібно знати:

Якщо ваш 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.»

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

1. Вкажіть точний час початку проблеми
2. Додайте HTTP-статус і повідомлення про помилку
3. Перелічіть, що ви вже перевірили самостійно
4. Зазначте, чи змінювали щось перед появою проблеми
5. Прикріпіть скріншот або фрагмент логу

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

Іноді проблема не в конкретному інциденті, а в паттерні. Якщо ви щомісяця витрачаєте по 3-4 години на листування з підтримкою - це червоний прапор. Ваш час коштує грошей. Порахуйте: 4 години помножити на вашу годинну ставку - чи не дорожче це за різницю між дешевим shared і нормальним VPS?

Ознаки того, що потрібно мігрувати, а не чекати:

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

Хостинг - це фундамент. Ви ж не будете безкінечно ремонтувати фундамент, якщо він тріщить щомісяця? Простіше знайти нормальну ділянку.

А тепер чесне питання до вас: скільки годин цього місяця ви витратили на з'ясування стосунків зі своїм хостером - і скільки з цих проблем могли б вирішити самі за п'ять хвилин із правильними інструментами? Можливо, варто не воювати, а навчитися дивитися в логи раніше, ніж натискати кнопку «створити тікет».