8 способів виправити помилку 403 Forbidden на вашому сайті

Помилка 403 Forbidden — це HTTP-код стану, який повертає веб-сервер, коли він розуміє запит клієнта, але активно відмовляється його виконати через недостатні права доступу. На відміну від 404 (ресурс не знайдено), 403 підтверджує, що ресурс існує — сервер просто не дозволяє до нього доступ. Ця відмінність надзвичайно важлива при діагностиці першопричини.

Помилка може виникати на різних рівнях: права доступу до файлової системи, директиви .htaccess, блоки конфігурації на рівні сервера, правила заборони IP, політики CDN або WAF, або навіть несправний плагін WordPress. Цей посібник розглядає всі можливі способи виправлення в порядку ймовірності, з точними командами, фрагментами конфігурації та граничними випадками, які більшість інструкцій пропускає.

Що спричиняє помилку 403 Forbidden

Перш ніж застосовувати будь-яке виправлення, корисно зрозуміти дерево рішень, якому слідує веб-сервер. Коли Apache або NGINX отримує запит, він оцінює:

1. Права доступу до файлової системи — чи має процес сервера права на читання файлу?
2. Власність — чи належить файл правильному користувачу (зазвичай www-data, apache або nginx)?
3. Директиви конфігурації сервера — чи явно забороняють доступ блоки <Directory>, <Location> або server {}?
4. Правила .htaccess — чи є директиви Deny, Require або Options, що перевизначають налаштування за замовчуванням?
5. Правила на рівні застосунку — чи перехоплює запит плагін CMS, WAF або модуль безпеки?
6. Блокування на рівні IP — чи є IP-адреса запитувача у списку заборонених?

Визначення відповідального рівня скорочує час усунення несправностей вдвічі.

Виправлення 1: Коригування прав доступу до файлів і каталогів

Неправильні права доступу UNIX є найпоширенішою причиною помилок 403 у середовищах спільного та VPS-хостингу. Процес веб-сервера повинен мати щонайменше права на читання (r) для файлів і права на читання + виконання (rx) для кожного каталогу в шляху до запитуваного ресурсу.

Стандартні значення прав доступу:

Критичний граничний випадок: Якщо будь-який батьківський каталог у шляху не має права на виконання (x) для користувача сервера, кожен файл всередині нього повертатиме 403 — навіть якщо сам файл має правильні права доступу. Завжди перевіряйте весь шлях, а не лише цільовий файл.

Щоб рекурсивно виправити права доступу через SSH:

# Fix directory permissions
find /var/www/html -type d -exec chmod 755 {} ;

# Fix file permissions
find /var/www/html -type f -exec chmod 644 {} ;

# Fix ownership (replace www-data with your server user)
chown -R www-data:www-data /var/www/html

Щоб перевірити, від імені якого користувача працює ваш веб-сервер:

ps aux | grep -E 'apache|nginx|httpd' | grep -v grep | awk '{print $1}' | sort -u

Якщо ви користуєтесь планом VPS-хостингу з root-доступом, ви можете виконувати ці команди безпосередньо. На спільному хостингу використовуйте файловий менеджер панелі керування або FTP-клієнт, наприклад FileZilla, клацніть правою кнопкою миші на файлі або каталозі та виберіть «Змінити права доступу».

Виправлення 2: Діагностика та відновлення файлу .htaccess

Apache зчитує файли .htaccess на кожному рівні каталогу від кореня сайту до запитуваного ресурсу. Одна неправильна директива — або директива, додана плагіном безпеки — може заблокувати доступ до цілого розділу вашого сайту.

Крок 1: Визначте, чи є .htaccess причиною

Перейменуйте файл, щоб тимчасово вимкнути його:

mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

Перезавантажте сторінку. Якщо помилка 403 зникла, файл .htaccess є причиною.

Крок 2: Визначте проблемну директиву

Поширені директиви .htaccess, що спричиняють помилки 403:

# Overly broad IP deny rule
Deny from all

# Missing Allow directive paired with Deny
Order deny,allow
Deny from all
# (Allow from all is absent)

# Incorrect Options directive
Options -Indexes -ExecCGI
# This is fine, but the following blocks everything:
Options None

# Require directive blocking all (Apache 2.4+)
Require all denied

Крок 3: Згенеруйте чистий .htaccess для WordPress

Перейдіть до Налаштування > Постійні посилання в панелі керування WordPress і натисніть Зберегти зміни, нічого не змінюючи. WordPress згенерує дійсний .htaccess. Стандартний .htaccess WordPress виглядає так:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Крок 4: Перевірте AllowOverride в основній конфігурації сервера

Якщо AllowOverride None встановлено в httpd.conf або блоці віртуального хосту, Apache повністю ігнорує файли .htaccess — але деякі директиви з основної конфігурації можуть все одно застосовуватися і конфліктувати з очікуваною поведінкою.

grep -r "AllowOverride" /etc/apache2/

Для роботи .htaccess вам потрібно щонайменше:

<Directory /var/www/html>
    AllowOverride All
</Directory>

Виправлення 3: Деактивація плагінів і тем WordPress

Плагіни безпеки (Wordfence, iThemes Security, Sucuri) часто додають правила блокування на основі IP, директиви mod_security або власні записи .htaccess, що спричиняють помилки 403 — іноді блокуючи доступ самому власнику сайту.

Масова деактивація всіх плагінів через FTP або SSH:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Якщо помилка зникла, повторно активуйте плагіни по одному, перейменовуючи папку назад, а потім переміщуючи окремі каталоги плагінів туди і назад, поки не буде знайдено винуватця.

Помилки 403, пов’язані з темою, трапляються рідше, але виникають, коли хук functions.php теми втручається в обробку запитів або коли тема вимагає авторизації на певних сторінках. Для перевірки перейдіть на стандартну тему WordPress (Twenty Twenty-Four) через phpMyAdmin, якщо ви не можете отримати доступ до панелі керування:

UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';

Виправлення 4: Очищення кешу браузера та файлів cookie

Браузери агресивно кешують HTTP-відповіді, включно з відповідями про помилки. Помилка 403, отримана одного разу, може бути закешована та відтворюватися навіть після усунення основної проблеми. Це особливо актуально, коли перед вашим сервером стоїть CDN або зворотний проксі (Cloudflare, Varnish).

Виправлення на рівні браузера:

Відкрийте інструменти розробника браузера (F12), перейдіть на вкладку Мережа, клацніть правою кнопкою миші на проблемному запиті та виберіть Очистити кеш браузера — або виконайте примусове оновлення:

• Windows/Linux: Ctrl + Shift + R
• macOS: Cmd + Shift + R

Виправлення на рівні CDN/проксі:

Якщо ви використовуєте Cloudflare, очистіть кеш для конкретного URL у панелі керування Cloudflare в розділі Кешування > Очищення кешу > Вибіркове очищення.

Важливий нюанс: Якщо помилку 403 повертає сам Cloudflare (ви побачите «Error 1020» або сторінку помилки з брендингом Cloudflare), блокування застосовується на рівні CDN через правило брандмауера або блокування за репутацією IP — а не вашим сервером-джерелом. Виправлення прав доступу на сервері в цьому випадку не матиме жодного ефекту. Перевірте журнал Безпека > Події в Cloudflare для підтвердження.

Виправлення 5: Перегляд правил заборони IP та блокувань брандмауера

Помилки 403 на основі IP поширені, коли плагіни безпеки, fail2ban або ручні правила iptables блокують легітимну IP-адресу — включно з вашою власною.

У cPanel (блокувальник IP):

1. Увійдіть до cPanel.
2. Перейдіть до Безпека > Блокувальник IP.
3. Перегляньте список заблокованих IP і видаліть записи, яких там не повинно бути.

В Apache .htaccess або httpd.conf:

# Apache 2.2 syntax
Order deny,allow
Deny from 203.0.113.45

# Apache 2.4 syntax
<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

Через fail2ban (поширено у VPS-середовищах):

# List all jails
fail2ban-client status

# Check if your IP is banned in the apache-auth jail
fail2ban-client status apache-auth

# Unban an IP address
fail2ban-client set apache-auth unbanip 203.0.113.45

Через iptables:

# List rules with line numbers
iptables -L INPUT -n --line-numbers

# Remove a specific DROP rule (replace 5 with the actual line number)
iptables -D INPUT 5

На виділеному сервері, де ви керуєте всім мережевим стеком, завжди перевіряйте правила брандмауера як на рівні застосунку, так і на рівні ядра, перш ніж робити висновок, що проблема у конфігурації веб-сервера.

Виправлення 6: Вимкнення або переналаштування захисту від хотлінкінгу

Захист від хотлінкінгу працює шляхом перевірки HTTP-заголовка Referer. Якщо запит надходить із Referer, якого немає у списку дозволених, сервер повертає 403. Цей механізм може спрацьовувати помилково в кількох сценаріях:

• Прямий доступ за URL — деякі конфігурації блокують запити без заголовка Referer, що характерно для користувачів, які вводять URL безпосередньо, переходять за посиланнями з поштових клієнтів або використовують браузери, орієнтовані на конфіденційність, що видаляють заголовки реферера.
• Переходи з HTTPS на HTTP — браузери не надсилають заголовок Referer при переході зі сторінки HTTPS до ресурсу HTTP, через що захист від хотлінкінгу блокує запит.
• Доступ через API або скрипт — програмні запити часто взагалі не містять заголовка Referer.

У cPanel (захист від хотлінкінгу):

1. Перейдіть до Безпека > Захист від хотлінкінгу.
2. Переконайтеся, що ваш домен (варіанти http:// і https://) є у списку URL-адрес з дозволеним доступом.
3. Для тестування тимчасово натисніть Вимкнути і перевірте, чи зникає помилка 403.

Безпосередньо в .htaccess:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www.)?yourdomain.com/ [NC]
RewriteRule .(jpg|jpeg|png|gif|webp|svg)$ - [F,L]

Щоб дозволити прямий доступ (порожній Referer), видаліть рядок RewriteCond %{HTTP_REFERER} !^$.

Виправлення 7: Коригування конфігурації сервера Apache або NGINX

Коли ви керуєте сервером — як на VPS з cPanel або виділеному сервері без панелі керування — неправильно налаштовані директиви віртуального хосту або серверного блоку є частою причиною помилок 403.

Конфігурація Apache

Поширена помилка конфігурації — відсутній Require all granted:

В Apache 2.4 модель авторизації суттєво змінилася. Стара директива Allow from all є застарілою. Без явного оператора Require Apache за замовчуванням забороняє доступ.

<VirtualHost *:80>
    ServerName yourdomain.com
    DocumentRoot /var/www/html

    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Перевірте Options -Indexes: Ця директива запобігає перегляду вмісту каталогу (повертаючи 403, якщо немає індексного файлу). Якщо в каталозі немає index.html або index.php, Apache повертає 403. Це навмисна поведінка безпеки — але якщо ви очікуєте перегляд вмісту каталогу, додайте Options +Indexes.

Перевірте конфігурацію та перезапустіть:

apachectl configtest
systemctl reload apache2

Конфігурація NGINX

Поширена помилка конфігурації — неправильний шлях root або відсутній індекс:

server {
    listen 80;
    server_name yourdomain.com;
    root /var/www/html;
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

Якщо директива root вказує на шлях, якого не існує або який не може прочитати користувач процесу nginx, кожен запит повертатиме 403.

Перевірте журнали помилок NGINX для визначення точної причини:

tail -n 50 /var/log/nginx/error.log

Помилка 403 від NGINX майже завжди генерує запис у журналі на кшталт:

2024/01/15 10:23:45 [error] 1234#0: *1 "/var/www/html/index.html" is forbidden (13: Permission denied)

Код помилки 13 означає Відмовлено в доступі на рівні ОС — поверніться до Виправлення 1 і перевірте права доступу до файлової системи та власність.

Перевірте та перезавантажте NGINX:

nginx -t
systemctl reload nginx

Порівняння усунення несправностей 403: Apache проти NGINX

Виправлення 8: Перевірка SSL-сертифіката та конфігурації перенаправлення HTTPS

Це виправлення відсутнє в більшості посібників з помилки 403, проте є реальною та часто overlooked причиною. Неправильно налаштовані правила перенаправлення SSL можуть спричиняти помилки 403 у певних сценаріях.

Сценарій 1: Примусове використання HTTPS до того, як сертифікат є дійсним

Якщо перенаправлення .htaccess спрямовує весь трафік на HTTPS, але SSL-сертифікат ще не виданий або закінчився, деякі конфігурації сервера повертають 403 замість помилки сертифіката.

# Problematic if SSL is not configured on the server
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Переконайтеся, що ваш сертифікат активний і правильно встановлений, перш ніж застосовувати перенаправлення HTTPS.

Сценарій 2: Вимога клієнтського SSL-сертифіката mod_ssl

Якщо ваша конфігурація Apache вимагає клієнтських SSL-сертифікатів для автентифікації, а браузер їх не надає, Apache повертає 403:

<Directory /var/www/secure>
    SSLVerifyClient require
    SSLVerifyDepth 1
</Directory>

Якщо ви навмисно не впровадили взаємний TLS (mTLS), видаліть цю директиву або встановіть SSLVerifyClient none.

Сценарій 3: Попереднє завантаження HSTS з неправильним ланцюжком перенаправлень

Цикл перенаправлень, спричинений конфліктуючими заголовками HSTS і правилами перенаправлення з HTTP на HTTPS, може проявлятися як помилка 403 у певних комбінаціях браузер/проксі. Перевірте повний ланцюжок перенаправлень за допомогою:

curl -I -L --max-redirs 10 http://yourdomain.com

Систематична діагностика: читання журналів помилок

Кожне з наведених вище виправлень слід поєднувати з моніторингом журналів у реальному часі. Здогадки без читання журналів — марна трата часу.

Apache — перегляд журналу помилок у реальному часі:

tail -f /var/log/apache2/error.log | grep 403

NGINX — перегляд журналу помилок у реальному часі:

tail -f /var/log/nginx/error.log | grep 403

Середовища cPanel — доступ до журналів через:

tail -f /usr/local/apache/logs/error_log

Запис у журналі майже завжди точно вказує, який файл спричинив помилку 403 і чому — відмовлено в доступі, відсутній індексний файл або явне правило заборони.

Матриця рішень: вибір правильного виправлення

Використовуйте цю матрицю для визначення найбільш ймовірного виправлення на основі ваших симптомів:

Ключові технічні висновки

• Завжди читайте журнал помилок сервера першим — він за лічені секунди точно вказує на файл і причину помилки 403.
• В Apache 2.4+, Require all granted є обов’язковим у кожному блоці <Directory>. Його відсутність є найпоширенішою причиною помилки 403 при нових налаштуваннях сервера.
• Прав доступу до файлів недостатньо — власність повинна відповідати користувачу процесу веб-сервера (www-data, apache, nginx).
• Помилка 403, що повертається CDN (Cloudflare, Fastly), повністю відрізняється від помилки 403, що повертається вашим сервером-джерелом. Виправлення одного не впливає на інше.
• На сайтах WordPress завжди тестуйте з масово вимкненими плагінами, перш ніж витрачати час на діагностику на рівні сервера.
• Якщо ви керуєте власною інфраструктурою на VPS або виділеному сервері, враховуйте журнали fail2ban та правила iptables — вони працюють нижче рівня веб-сервера і невидимі для інструментів налагодження на рівні застосунку.
• Правила захисту від хотлінкінгу, що блокують порожні заголовки Referer, впливатимуть на легітимних користувачів браузерів, орієнтованих на конфіденційність, та на переходи за посиланнями з електронної пошти — завжди додавайте виняток для порожніх реферерів.

FAQ

У чому різниця між помилкою 403 Forbidden і помилкою 401 Unauthorized?

Помилка 401 Unauthorized означає, що сервер вимагає автентифікації, а клієнт не надав дійсних облікових даних — повторна автентифікація може вирішити проблему. Помилка 403 Forbidden означає, що сервер визначив, хто ви є (або не вимагає автентифікації), але явно відмовляє в доступі незалежно від цього. Надання облікових даних не допоможе при помилці 403.

Чи може помилка 403 вплинути на SEO-рейтинг мого сайту?

Так. Якщо Googlebot отримує помилку 403 при сканування сторінки, він не може її проіндексувати. Постійні помилки 403 на важливих URL-адресах призведуть до їх зникнення з результатів пошуку. Використовуйте інструмент перевірки URL у Google Search Console, щоб перевірити, чи може Googlebot отримати доступ до ваших сторінок, і відстежуйте звіт про охоплення на наявність помилок сканування, пов’язаних з 403.

Чому я отримую помилку 403 лише для певних типів файлів (зображень, PDF)?

Це майже завжди вказує на захист від хотлінкінгу (Виправлення 6) або правило для певного MIME-типу в .htaccess. Перевірте наявність директив FilesMatch або RewriteRule, що націлені на певні розширення. Також переконайтеся, що каталог, який містить ці файли, має права доступу 755 і належить правильному користувачу сервера.

Як виправити помилку 403, якщо у мене немає доступу через SSH або FTP?

Використовуйте веб-файловий менеджер вашого хостинг-провайдера (доступний у cPanel, Plesk або DirectAdmin) для перегляду та зміни прав доступу до файлів і файлів .htaccess. Для проблем, пов’язаних з WordPress, інструмент WP-CLI (якщо доступний через термінал панелі керування) або прямий доступ до бази даних через phpMyAdmin може допомогти деактивувати плагіни та змінити теми без SSH.

Чи означає помилка 403, що мій сайт зламано?

Не обов’язково, але це може бути симптомом. Шкідливе програмне забезпечення іноді впроваджує правила заборони у файли .htaccess або змінює права доступу до файлів, щоб заблокувати доступ. Якщо ви не можете визначити причину помилки 403 на рівні конфігурації, перевірте файли на несанкціоновані зміни за допомогою такого інструменту, як rkhunter, Wordfence (якщо ви можете отримати доступ до WordPress) або сканера шкідливого програмного забезпечення вашого хостинг-провайдера. Порівняйте хеші файлів з відомими справними резервними копіями, якщо вони доступні.