Помилка 403 Forbidden на хостингу: чому сервер вас не впізнає і як це виправити за 15 хвилин
Уявіть: ви спокійно п'єте каву, відкриваєте свій сайт - і бачите білий екран з холодним написом 403 Forbidden. Серце падає. Ви перевіряєте ще раз. Те саме. Відкриваєте телефон - те саме. Клієнти вже пишуть у чат: «У вас все зламалось». І ви навіть не розумієте, що саме зламалось, бо нічого не міняли. Або так вам здається. За 12 років роботи з хостингами я бачив цю помилку сотні разів - і в 90% випадків причина банальніша, ніж ви думаєте. Але ці банальні причини можуть коштувати вам грошей, репутації і нервів. Давайте розберемо 403-ю помилку так, щоб ви більше ніколи не панікували.
Що насправді каже вам сервер, коли показує 403
Більшість людей плутають 403 з 404. Але різниця принципова. 404 - це «я не знайшов те, що ви шукаєте». 403 - це зовсім інша історія: «Я знайшов, але вам не дам». Сервер бачить ваш запит. Він знає, де лежить файл. Але вирішив, що у вас немає права його отримати. Це як підійти до дверей клубу, де вас знають в обличчя, а охоронець каже: «Сьогодні не ваш день».
Технічно це означає, що веб-сервер (Apache, Nginx, LiteSpeed - неважливо) перевірив ваші дозволи і відмовив у доступі. Причин може бути з десяток, але на практиці їх можна звести до п'яти основних категорій.
П'ять справжніх причин, через які ваш сайт видає 403
Я не буду перераховувати 30 теоретичних можливостей із документації Apache. Натомість - реальні ситуації, які я бачив на живих проектах.
- Неправильні дозволи файлів (chmod) - найчастіша причина. Хтось виставив 000 або 600 на каталог, і веб-сервер не може його прочитати. Це трапляється після міграції, відновлення з бекапу або невдалого оновлення плагіна.
- Відсутній index-файл і заборонений лістинг - якщо у каталозі немає index.html або index.php, а опція Options -Indexes увімкнена, сервер відповість 403 замість того, щоб показати вміст папки.
- Правила .htaccess блокують доступ - один рядок типу Deny from all може закрити весь сайт. Часто це робить плагін безпеки, і ви навіть не знаєте.
- ModSecurity або файрвол хостингу - ваш запит виглядає підозріло для системи захисту. Наприклад, ви передаєте в URL символи, які схожі на SQL-ін'єкцію.
- IP-блокування - ваш хостинг або CDN (Cloudflare, Sucuri) заблокував вашу IP-адресу. Іронія: ви самі себе заблокували, додавши правило в файрвол і забувши додати свій IP у білий список.
«Більшість помилок 403 - це не атака і не збій серверу. Це конфлікт між тим, що хоче користувач, і тим, що дозволяє конфігурація. У 70% випадків достатньо перевірити дозволи файлів і .htaccess» - Даніель Стенберг, автор curl і експерт з HTTP-протоколів.
Покрокова діагностика: знаходимо причину за 5 хвилин
Не треба одразу писати в підтримку хостингу. Спочатку зробіть три прості перевірки.
Крок 1: Перевірте, чи проблема тільки у вас. Відкрийте сайт через мобільний інтернет (не Wi-Fi) або скористайтесь сервісом downforeveryoneorjustme.com. Якщо сайт працює для інших - вас заблокували за IP. Якщо не працює ні для кого - проблема на сервері.
Крок 2: Перевірте .htaccess. Зайдіть через файловий менеджер у cPanel або через FTP. Перейменуйте .htaccess у .htaccess_backup. Оновіть сторінку. Якщо сайт запрацював - причина в цьому файлі. Тепер відновіть його і шукайте проблемний рядок.
Крок 3: Перевірте дозволи. Ось таблиця, яку я тримаю під рукою вже роками:
| Тип об'єкта | Правильний chmod | Що буде при 403 | Як виправити |
|---|---|---|---|
| Каталоги | 755 | Веб-сервер не може увійти в папку | find /path -type d -exec chmod 755 {} ; |
| Файли (.php, .html) | 644 | Сервер не може прочитати файл | find /path -type f -exec chmod 644 {} ; |
| .htaccess | 644 | Конфігурація не читається або блокує все | chmod 644 .htaccess |
| wp-config.php | 600 або 640 | Зазвичай не викликає 403 (але краще перевірити) | chmod 640 wp-config.php |
Якщо жоден із цих кроків не допоміг - переходьте до логів.
Серверні логи: ваш детектив, який знає все
Ось де починається магія. Файл error.log (в Apache) або error_log (у cPanel) покаже вам точну причину відмови. Не приблизну. Не «щось пішло не так». А конкретний рядок конфігурації, який заблокував доступ.
Де шукати логи:
- cPanel: розділ «Metrics» - «Errors» або файл /home/username/logs/error.log
- Plesk: «Logs» у налаштуваннях домену
- SSH-доступ: tail -50 /var/log/apache2/error.log (або /var/log/nginx/error.log)
Типовий запис виглядає так: client denied by server configuration: /home/user/public_html/wp-admin/. Бачите? Сервер прямо каже: «Я заблокував доступ до wp-admin через конфігурацію». Тепер ви знаєте, де копати.
Золоте правило: ніколи не гадайте причину 403. Завжди читайте лог. Це економить години.
ModSecurity: коли захист стає ворогом
Окрема біль - це ModSecurity. Цей модуль стоїть на більшості shared-хостингів і працює як параноїдальний охоронець. Він аналізує кожен HTTP-запит і блокує все, що хоч трохи нагадує атаку. Проблема в тому, що легітимні дії теж іноді схожі на атаку.
Наприклад, ви редагуєте сторінку в WordPress і вставляєте фрагмент HTML-коду. ModSecurity бачить тег <script> і думає: «Це XSS-атака!» Результат - 403. Ви втрачаєте весь текст, який набирали. Знайоме?
Що робити:
- У cPanel знайдіть пункт «ModSecurity» і тимчасово вимкніть його для вашого домену (тільки для діагностики!)
- Подивіться в логи ModSecurity - там буде ID правила, яке спрацювало
- Попросіть хостинг-провайдера додати виключення саме для цього правила, а не вимикати весь захист
- Розгляньте перехід на хостинг, де ModSecurity налаштований тонше (не за принципом «блокуй усе підозріле»)
Один мій клієнт - інтернет-магазин з Братислави - втрачав 15-20 замовлень на тиждень, бо ModSecurity блокував форму оплати. Там у полі «адреса доставки» люди писали апостроф (O'Brien, наприклад), і система вважала це спробою SQL-ін'єкції. Рішення зайняло 5 хвилин: одне виключення в правилах. А магазин страждав три місяці.
Профілактика: як зробити так, щоб 403 більше не поверталась
Виправити помилку - це половина справи. Друга половина - зробити так, щоб вона не повторилась. Ось мій чеклист, який я даю кожному клієнту:
- Автоматизуйте перевірку дозволів. Налаштуйте cron-задачу, яка раз на добу перевіряє chmod ключових каталогів. Якщо щось змінилось - ви отримаєте лист.
- Тримайте копію робочого .htaccess. Не в бекапі десь на диску, а прямо поруч - .htaccess_working. Якщо плагін зламає оригінал, ви відновите його за секунди.
- Білий список IP для адмін-панелі. Якщо ви обмежуєте доступ до /wp-admin/ або /administrator/ за IP - використовуйте динамічний DNS або VPN з фіксованою адресою. Інакше заблокуєте самі себе.
- Моніторинг HTTP-кодів. Безкоштовний UptimeRobot не тільки перевіряє доступність - він розрізняє 403, 500, 502. Ви дізнаєтесь про проблему раніше за клієнтів.
- Оновлюйте плагіни по одному. Масове оновлення - лотерея. Один плагін може переписати .htaccess або змінити дозволи, і ви не зрозумієте, хто саме це зробив.
Головна думка цієї статті: 403 Forbidden - це не катастрофа. Це повідомлення. Сервер намагається вам щось сказати. Ваша задача - навчитися слухати.
Більшість власників сайтів при появі 403 одразу біжать до підтримки хостингу і чекають відповідь 2-4 години. За цей час сайт не працює, клієнти йдуть, Google знижує позиції. А вирішити проблему можна було за 15 хвилин самостійно - якщо знати, куди дивитись.
Тепер ви знаєте. Питання тільки одне: коли наступного разу ваш сайт покаже 403 - ви будете панікувати чи спокійно відкриєте лог?