Я отримую цю помилку при спробі отримати доступ до localhost через браузер.

AH01630: client denied by server configuration

Я перевірив дозволи на папки свого сайту, використовуючи:

sudo chmod 777 -R *

Ось мій файл конфігурації:

<VirtualHost *:80>
ServerAdmin webmaster@localhost

DocumentRoot /home/user-name/www/myproject
<Directory />
    Options FollowSymLinks
    AllowOverride all
    Allow from all
</Directory>

<Location />
  Allow from all
  Order Deny,Allow
</Location>

<Directory  /home/user-name/www/myproject/>
    Options Indexes FollowSymLinks MultiViews
    AllowOverride all
    Order allow,deny
    Allow from all
</Directory>

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
    AllowOverride all
    Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
    Order allow,deny
    Allow from all
</Directory>

ErrorLog ${APACHE_LOG_DIR}/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog ${APACHE_LOG_DIR}/access.log combined

Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
    Options Indexes MultiViews FollowSymLinks
    AllowOverride all
    Order deny,allow
    Deny from all
    Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>

Якщо ви використовуєте Apache 2.4

Ви повинні перевірити правила дозволу та заборони

Перевірте http://httpd.apache.org/docs/2.4/upgrading.html#access

В 2.2 контроль доступу на основі імені клієнта, IP-адреси та інших характеристик запитів клієнтів здійснювався за допомогою директив «Порядок», «Дозволити», «Заборонити» та «Задовольнити».

У 2.4 такий контроль доступу здійснюється так само, як і інші перевірки авторизації, використовуючи новий модуль mod_authz_host.

Нова директива вимагає :

2.2 конфігурація:

Order allow,deny
Allow from all

2.4 конфігурація:

Require all granted

Також не забудьте перезапустити сервер apache після цих змін ( # service httpd restart)

Для всіх каталогів пишіть Require all grantedзамістьAllow from all

Оновлення

Якщо вищезгадане не працює, тоді також видаліть цей рядок нижче:

Наказ дозволяють, заперечують

Двічі перевірте правильність шляху DocumentRoot. Це може спричинити цю помилку.

Я вніс ті самі зміни, які пропонував Ravisorg для OSX 10.10 Yosemite, який оновлює Apache до версії 2.4. Нижче наведено зміни, які були додані до http.conf.

<Directory />
    AllowOverride none
    Require all denied
</Directory>

<Directory /Volumes/Data/Data/USER/Sites/>
    AllowOverride none
    Require all granted
</Directory>

Це призвело до того, що я змусив мене абсолютно горіхи протягом півтора днів, але я знайшов рішення, якщо всі інші рішення були спробувані безуспішно.

Це для macOS.

• Перейдіть до монітора активності (пошук прожектора: діяльність)
• У моніторі активності шукайте httpd, який є сервісом Apache
• Виберіть той, що належить корінь, і натисніть X у верхньому лівому куті, щоб закрити його.

У цей момент я негайно перестав отримувати 403 помилки, і все почало працювати, як очікувалося. Дивна річ - це мені навіть не довелося перезапускати apache, він просто працював, я думаю, що він перезапустив себе, коли я перейшов до свого localhost, я, чесно кажучи, не знаю, але, мабуть, проблема полягає в тому, що Apache насправді не перезапускається при використанні перезапуску apachectl, або зупинити або почати. Сподіваюся, що це комусь допоможе.

Проблема в VirtualHost, але, ймовірно, ні

Потрібні всі надані

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

Якщо ви виправляєте журнал помилок і перезавантажуєте сторінку, вам слід побачити додаткову інформацію щодо точної проблеми.

Візьміть змінні середовища, щоб $ {APACHE_LOG_DIR} насправді спрацював ...

source /etc/apache2/envvars

Потім хвіст і дивіться ...

tail -f ${APACHE_LOG_DIR}/error.log

Я вирішив себе, витративши пару годин.

Я встановив Apache / 2.4.7 (Ubuntu) через кук-книгу в бродячому vm.

Файл /etc/apache2/apache2.conf <VirtualHost *:80>за замовчуванням не містить елемента.

Я зробив дві зміни, щоб це зробити

1. додано <VirtualHost *:80>
2. додано
   Параметри індексів FollowSymLinks
   AllowOverride all
   Allow from all

тоді нарешті я просто завантажив vm ..

Хто-небудь замислювався про те, що за замовчуванням сервера wamp не входить httpd-vhosts.confфайл. Мій підхід - видалити замітку нижче

 conf
  # Virtual hosts
  Include conf/extra/httpd-vhosts.conf

у httpd.confфайл. Це все.

в моєму випадку,

Я використовую macOS Mojave (Apache / 2.4.34). У файлі /etc/apache2/extra/httpd-vhosts.conf виникла настройка віртуального хоста. після додавання потрібного тегу каталогу моєї проблеми не було.

Потрібні всі надані

Сподіваємось, повна структура налаштування віртуального хоста врятує вас.

<VirtualHost *:80>
    DocumentRoot "/Users/vagabond/Sites/MainProjectFolderName/public/"
    ServerName project.loc

    <Directory /Users/vagabond/Sites/MainProjectFolderName/public/>
        Require all granted
    </Directory>

    ErrorLog "/Users/vagabond/Sites/logs/MainProjectFolderName.loc-error_log"
    CustomLog "/Users/vagabond/Sites/logs/MainProjectFolderName.loc-access_log" common
</VirtualHost>

все, що вам потрібно зробити, замініть MainProjectFolderName на ваше саме ProjectFolderName.

Це зводило мене з розуму. Нарешті з’ясував, у чому проблема: я використовував прямі шляхи для журналу помилок, і вони помилялися.

Чому Apache видає розпливчасте (і неправильне) повідомлення про помилку? Замість цього скористайтеся правильним та корисним повідомленням про помилку, наприклад: Недопустима директива "Шлях для ErrorLog" /wrong/path/and/filename.log ".

У будь-якому випадку, щоб переконатися, що ваші директиви журналу помилок виглядають приблизно так:

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

Якщо ви використовуєте Apache 2.4 в WampServer в ОС Windows.

Вам потрібно відкрити файл https-vhosts.conf у блокноті.

C:\wamp64\bin\apache\apache2.4.37\conf\extra\https-vhosts.conf 

Якщо ви не можете знайти вищезазначений файл. перевірте скріншот нижче

 <VirtualHost *:80>
     ServerName localhost
     DocumentRoot c:/wamp64/www
     <Directory  "c:/wamp64/www/">
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Require local
    </Directory>
</VirtualHost>

У наведеному вище коді Замінити

Require local

з

Require all granted

І збережіть це. Перезапустіть службу Apache та повторіть спробу.

Для мене я фактично оновив правила дозволу і заборонити на основі стандарту 2.4.

Require all granted

Однак це все-таки змусило мене отримати ту саму помилку AH01630. Я знайшов інший потік, і він запропонував перевстановити apache2. Якось це спрацювало! Якщо комусь цікаво пояснити чому, це було б корисно.

Кредит: AH01630: клієнту відмовлено в налаштуваннях сервера, але вимагається, щоб все було надано (Apache 2.4, CentOs)

Якщо у вас є хост https, тоді не забудьте зробити Require all granted зміни і для ssl config.

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

# ps -eFH | grep http # get the username used by httpd
...
apache   18837  2692  0 119996 9328   9 10:33 ?        00:00:00     /usr/sbin/httpd -DFOREGROUND
# su -s/bin/bash apache # switch to that user
bash-4.2$ whoami
apache
bash-4.2$ cd /home
bash-4.2$ ls
bash-4.2$ cd mysite.com
bash-4.2$ ls
bash-4.2$ cat file-which-does-not-work.txt

Для Wamp 3 (Apache 2.4), окрім розміщення сервера в Інтернеті, як описано в інших відповідях, у файлі Virtual Hosts conf/extra/httpd-vhosts.conf
вам може знадобитися замінити

Require local

з

Require all granted

Це застосовно, якщо у httpd.confвас є

Include conf/extra/httpd-vhosts.conf

Під час використання Ubuntu перевірте, чи включений модуль CGI. Якщо ні:

sudo a2enmod cgi

Переконайтеся, що будь-які налаштовані для користувача конфігурації включені!

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

Я використовував специфічні для користувача конфігурації, Sitesвказані як мій UserDirвхід /private/etc/apache2/extra/httpd-userdir.conf. Однак мені заборонили доступ до кінцевої точкиhttp://localhost/~jwork/ .

Я міг бачити, /var/log/apache2/error_logщо доступ до /Users/jwork/Sites/блокується. Однак мені було дозволено отримати доступ до DocumentRoot через http://localhost/. Це підказувало, що я не маю прав на перегляд ~jworkкористувача. Але наскільки я міг сказати ps aux | egrep '(apache|httpd)'і lsof -i :80, Apache балотувавсяjwork користувача, тож явно щось не було написано з моєю конфігурацією користувача.

З урахуванням імені користувача jwork, тут був мій файл конфігурації:

/private/etc/apache2/users/jwork.conf

<Directory "/Users/jwork/Sites/">
    Require all granted
</Directory>

Ця конфігурація цілком дійсна. Однак я виявив, що моя конфігурація користувача не включається:

/private/etc/apache2/extra/httpd-userdir.conf

## Note how it's commented out by default.
## Just remove the comment to enable your user conf.
#Include /private/etc/apache2/users/*.conf

Зауважте, що це шлях за замовчуванням до файлу конфіденційності userdir, але як ви побачите нижче, його можна налаштувати в httpd.conf. Переконайтеся, що такі рядки включені:

/private/etc/apache2/httpd.conf

Include /private/etc/apache2/extra/httpd-userdir.conf

# ...

LoadModule userdir_module libexec/apache2/mod_userdir.so

Для тих, хто зациклювався на цій помилці як я, і нічого не допомогло зверху: перевірте, чи проблема папки з error.log насправді існує на вашому сервері. Шахта генерувалася автоматично Django в неправильному місці (тоді був зіпсований зі статичним коренем manage.py collectstatic). Поняття не маю, чому не можна правильно називати помилки.

Окрім пропущених Orderта Allowдиректив, зазначених в інших відповідях, пам’ятайте, що невідповідний регулярний вираз aDirectoryMatch директиви також може спричинити цю помилку.

Якщо запитуваний шлях є /home/user-foo1bar/www/myproject/відповідним збіжком, він не збігається

<DirectoryMatch "/home/user-[a-z]+/www/myproject/">
...
</DirectoryMatch>

таким чином, навіть допустима конфігурація доступу може спричинити цю помилку.

Одне незрозуміле (щойно розібравшись із цим), але можливе, причиною цього є внутрішнє правило mod_rewrite в головному конфігураційному файлі (не .htaccess), який записує до шляху, який існує в корені файлової системи сервера. Скажіть, у вас є /mediaкаталог на вашому сайті, і ви переписуєте щось подібне:

RewriteRule /some_image.png /media/some_other_location.png

Якщо у вас є /mediaкорінь у вашому сервері, перезапис буде зроблено спробу цього (у результаті помилки в доступі заборонено), а не в каталозі вашого веб-сайту, оскільки корінь файлової системи спочатку перевіряється mod_rewrite, щоб існувати першого каталогу на шляху до каталогу вашого веб-сайту.

Проблема може полягати в тому, що директива не під <Каталог>

https://httpd.apache.org/docs/2.4/mod/mod_authz_host.html#requiredirectives

На директиву можна посилатися в розділі <Каталог>, <Файли> або <Місцезнаходження>, а також на файли .htaccess для контролю доступу до певних частин сервера. Доступ можна контролювати на основі імені клієнта або IP-адреси клієнта.

У мене з’явився ще один, який комусь може бути корисний. Отримувало те саме повідомлення про помилку після оновлення до PHP 5.6 => 7.0. Ми змінили налаштування завантаження PHP і забули змінити, як тільки скопіювали. Незважаючи на те, що я не завантажував зображення в той час, Silverstripe (наша CMS) відмовлялася зберігати та кидала цю помилку. Збільшився розмір завантаження зображення і воно працювало відразу.

У випадку, якщо це допомагає комусь із Google, як я, у мене з’явилося це повідомлення про помилку, намагаючись отримати доступ до файлу SVG на моєму сервері, наприклад https://example.com/images/file.svg . Інші типи файлів здалися чудовими, просто SVG вийшов з ладу.

Я полював навколо /etc/httpdконф-файлів і перевіряв коженrequire all denied тип конфігурації, і просто не міг знайти, який конфігурація має такий ефект.

Я повернув LogLevel, щоб налагодити конфігурацію VirtualHost, і міг побачити журнал mod_authz_core із зазначенням, що діє "Потрібно все відмовлено" на ділі:

[Mon Jun 10 13:09:54.321022 2019] [authz_core:debug] [pid 23459:tid 140576341206784] mod_authz_core.c(817): [client 127.0.0.1:54626] AH01626: authorization result of Require all denied: denied
[Mon Jun 10 13:09:54.321038 2019] [authz_core:debug] [pid 23459:tid 140576341206784] mod_authz_core.c(817): [client 127.0.0.1:54626] AH01626: authorization result of <RequireAny>: denied
[Mon Jun 10 13:09:54.321082 2019] [authz_core:error] [pid 23459:tid 140576341206784] [client 127.0.0.1:54626] AH01630: client denied by server configuration: /home/blah/htdocs/images/file.svg

Завдяки сліпому тестуванню я перемістив файл до кореня веб-корінця, і виявив, що зможу отримати доступ до нього за адресою https://example.com/file.svg .., тому він не вдався лише до папки "images". Це привело мене до .htaccess-файлу у папці із зображеннями, про який я не мав уявлення.

Виходить, Zen Cart 1.5 поставляється з файлом images / .htaccess, який містить:

# deny *everything*
 <FilesMatch ".*">
   <IfModule mod_authz_core.c>
     Require all denied
   </IfModule>
   <IfModule !mod_authz_core.c>
     Order Allow,Deny
     Deny from all
   </IfModule>
 </FilesMatch>

 # but now allow just *certain* necessary files:
 <FilesMatch "(?i).*\.(jpe?g|gif|webp|png|swf)$" >
   <IfModule mod_authz_core.c>
     Require all granted
   </IfModule>
   <IfModule !mod_authz_core.c>
     Order Allow,Deny
     Allow from all
   </IfModule>
 </FilesMatch>

Це дуже дратувало, і я сподіваюся, що це може нагадати іншим перевіряти.

Я фактично вирішив це, додавши доступ до каталогу до запису: 80.

 <Directory "c:/whatever-directory-you-use/">
    AllowOverride All
    Require all granted
</Directory>

Перш ніж кожен отримує всю «безпеку» на мене, при моїх конкретних обставинах це не питання безпеки.

Якщо ви використовуєте віддалений ресурс, рекомендую замість цього переконатися, що ваш запит CURL надходить через HTTPS / TLS, тоді ця запис у каталозі переходить на порт 443.

Ця "помилка" - це фактично нова нормальна поведінка Apache 2.4. У моєму випадку у мене було дуже специфічне правило, щоб заборонити доступ до будь-якої папки чи файлу з ім'ям, що починається з ".", Тому мені довелося встановити виняток для певної публічної папки, яка вимагає такого непарного імені.

Для запису моїм правилом Rewrite є:

RewriteRule "(?!\.trusted)(^|/)\." - [F]

Це правило [F] виконує обов'язки, починаючи з "". але .trusted, завдяки магії регексу "?!" заперечення.

Оскільки цей потік - це перше, що з’являється під час пошуку згаданої помилки, я хотів би додати ще одну можливу причину цієї помилки: у вас може бути mod_evasiveактивний і клієнт, який бачить цю помилку, просто переступив межі, налаштовані у вашійmod_evasive.conf

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

(якщо mod_evasiveце причина, то помилка сама по собі зникне, якщо клієнт просто тимчасово перестає намагатися зайти на сайт; проте це може бути ознакою того, що ви налаштували занадто жорсткі межі)