Я получаю эту ошибку при попытке доступа к 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-адреса и других характеристик клиентских запросов осуществлялось с использованием директив Order, Allow, Deny и Satisfy.

В версии 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
• Выберите тот, который принадлежит root и нажмите X в левом верхнем углу, чтобы закрыть его.

В этот момент я сразу перестал получать ошибки 403, и все начало работать как ожидалось. Странно то, что мне даже не нужно было перезапускать Apache, он просто работал, я думаю, он перезапустился сам, когда я перешел на мой локальный хост, я, честно говоря, не знаю, но я предполагаю, что проблема в том, что Apache фактически не перезапускается при использовании apachectl restart, или остановить или начать. Надеюсь, это кому-нибудь поможет.

Проблема в VirtualHost, но, вероятно, нет

Требовать все предоставленные

Подтвердите, что ваш конфиг правильный, вот правильный пример

Если вы подключите журнал ошибок и перезагрузите страницу, вы должны увидеть больше информации о точной проблеме.

Захватите переменные окружения, чтобы $ {APACHE_LOG_DIR} действительно работал ...

source /etc/apache2/envvars

Тогда хвост и смотреть ...

tail -f ${APACHE_LOG_DIR}/error.log

Я решил себя после того, как провел пару часов.

Я установил Apache / 2.4.7 (Ubuntu) через coookbook в vagrant vm.

Файл /etc/apache2/apache2.conf <VirtualHost *:80>по умолчанию не имеет элемента.

Я сделал два изменения, чтобы сделать это

1. добавленной <VirtualHost *:80>
2. добавлены
   параметры индексы FollowSymLinks
   AllowOverride all
   Allow from all

тогда, наконец, я просто загрузил вм ..

Кто-нибудь думал о том, что сервер 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.

Кроме того, иногда полезно проверить права доступа как пользователь 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 conf, но, как вы увидите ниже, он настраивается в 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упомянутых в других ответах директив, имейте в виду, что несоответствующее регулярное выражение DirectoryMatchдирективы также может вызывать эту ошибку.

Если запрошенный путь является следующим, /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 на наличие первого каталога в пути, перед каталогом вашего сайта.

Проблема может заключаться в том, что директива не находится в <Directory>

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

На директиву можно ссылаться в разделе <Directory>, <Files> или <Location>, а также в файлах .htaccess для управления доступом к определенным частям сервера. Доступ можно контролировать на основе имени хоста клиента или IP-адреса.

У меня есть еще один, который может быть полезен для кого-то. Получал то же сообщение об ошибке после обновления с PHP 5.6 => 7.0. Мы изменили настройки загрузки PHP и забыли изменить их после копирования. Несмотря на то, что я не загружал изображения в то время, Silverstripe (наша CMS) отказывалась сохранять и выдавала эту ошибку. Увеличен размер загружаемого изображения, и это сработало сразу.

На случай, если это поможет кому-нибудь, как я, погуглить, у меня появилось это сообщение об ошибке при попытке получить доступ к файлу SVG на моем сервере, например, https://example.com/images/file.svg . Другие типы файлов казались хорошими, только SVG терпели неудачу.

Я /etc/httpdискал файлы conf и проверял каждый 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>

Это было очень раздражающим, и я надеюсь, что это может напомнить другим, чтобы они проверяли файлы .htaccess на каждом уровне файловой системы, приводя к файлу, к которому у вас возникли проблемы с доступом в случае, если происходит такая глупость.

На самом деле я решил эту проблему, добавив доступ к каталогу к записи: 80.

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

Прежде чем все получат всю «безопасность» от меня, в моих конкретных обстоятельствах это не проблема безопасности.

Если вы используете удаленный ресурс, я бы порекомендовал вместо этого убедиться, что ваш запрос CURL проходит через HTTPS / TLS, тогда эта запись каталога идет через порт 443.

Эта «ошибка» на самом деле является новым нормальным поведением Apache 2.4. В моем случае у меня было очень конкретное правило, запрещающее доступ к любой папке или файлу с именем, начинающимся с «.», Поэтому мне пришлось установить исключение для конкретной общедоступной папки, для которой требуется такое нечетное имя.

Для записи мое конкретное правило перезаписи:

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

Это правило [F] относится ко всему, начинающемуся с "." но .trusted, благодаря магии регулярных выражений "?!" отрицание.

Поскольку этот поток - первое, что появляется при поиске упомянутой ошибки, я хотел бы добавить еще одну возможную причину этой ошибки: у вас может быть mod_evasiveактивность, и клиент, увидевший эту ошибку, просто превысил пределы, настроенные в вашемmod_evasive.conf

Это особенно важно, если вы вдруг получаете эту ошибку для клиента, у которого раньше не было проблем и ничего больше не изменилось.

(если это mod_evasiveявляется причиной, то ошибка исчезнет сама собой, если клиент просто временно прекратит попытки доступа к сайту; однако это может быть признаком того, что вы настроили слишком жесткие ограничения)

Для меня все предложенные решения не сработают. Это может помочь, если вы используете cgi, fastcig или fpm в качестве прокси-сервера, вы должны добавить местоположение в ваш vhost, чтобы избежать этой проблемы. Это позволяет 404 быть сквозным прокси.

<Location />
require all granted
</Location>