Я получаю эту ошибку при попытке доступа к 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>
chmod 777
это очень плохая привычка, даже если (предположительно) используется только в примерах.Ответы:
Если вы используете Apache 2.4
Вы должны проверить разрешить и запретить правила
Проверьте http://httpd.apache.org/docs/2.4/upgrading.html#access
Новая директива - Требовать :
2.2 конфигурация:
Конфигурация 2.4:
Также не забудьте перезапустить сервер apache после этих изменений (
# service httpd restart
)источник
DocumentRoot
и<Directory>
пути.Order allow,deny ...
и другоеRequire all granted
. Это не сработает. Это должен быть только один из них в зависимости от вашей версии. Это то, что мешало мне сначала решить мою проблему.Для всех каталогов напишите
Require all granted
вместоAllow from all
Обновить
Если вышеупомянутое не работает тогда, также удалите эту ниже упомянутую строку:
источник
Order allow,deny
линию.<Location /media> Require all granted </Location>
наdefault-ssl.conf
для моего CSS должны быть загружен. (Моя проблема заключалась в том, что страница входа была доступна, но не загружались ни CSS, ни другие медиа-файлы ...)Allow from All
был на пенсии, потому что .... причины ...)Дважды проверьте правильность пути DocumentRoot. Это может вызвать эту ошибку.
источник
<Directory>
блоке. У меня также были некоторые отличия. Как только я сделал эти два значения точными копиями друг друга (без косой черты), все заработало отлично.apache/logs/error.log
:AH00112: Warning: DocumentRoot [E:/xampp/htdocs/website/frontend/web] does not exist
Я сделал те же изменения, которые предложил ravisorg для OSX 10.10 Yosemite, которая обновляет Apache до версии 2.4. Ниже приведены изменения, которые были добавлены в http.conf.
источник
Это сводило меня с ума в течение полутора дней, но я нашел решение, если все другие решения были испробованы безуспешно.
Это для macOS.
В этот момент я сразу перестал получать ошибки 403, и все начало работать как ожидалось. Странно то, что мне даже не нужно было перезапускать Apache, он просто работал, я думаю, он перезапустился сам, когда я перешел на мой локальный хост, я, честно говоря, не знаю, но я предполагаю, что проблема в том, что Apache фактически не перезапускается при использовании apachectl restart, или остановить или начать. Надеюсь, это кому-нибудь поможет.
источник
Проблема в VirtualHost, но, вероятно, нет
Подтвердите, что ваш конфиг правильный, вот правильный пример
источник
<Directory ...> ... </Directory>
линий работало для меня, так как я использовал путь к каталогу, который ранее не определялся в конфигурациях Apache.Если вы подключите журнал ошибок и перезагрузите страницу, вы должны увидеть больше информации о точной проблеме.
Захватите переменные окружения, чтобы $ {APACHE_LOG_DIR} действительно работал ...
Тогда хвост и смотреть ...
источник
LogLevel debug
в VirtualHost это хороший совет, вы увидите строки типа «Требовать все отказано: отказано» и «<RequireAny>: отказано» (т. Е. Гораздо полезнее, чем просто «клиент отклонен конфигурацией сервера», как это на самом деле говорит вам, какая конфигурация!)Я решил себя после того, как провел пару часов.
Я установил Apache / 2.4.7 (Ubuntu) через coookbook в vagrant vm.
Файл /etc/apache2/apache2.conf
<VirtualHost *:80>
по умолчанию не имеет элемента.Я сделал два изменения, чтобы сделать это
<VirtualHost *:80>
параметры индексы FollowSymLinks
AllowOverride all
Allow from all
тогда, наконец, я просто загрузил вм ..
источник
Кто-нибудь думал о том, что сервер wamp по умолчанию не включает
httpd-vhosts.conf
файл. Мой подход состоит в том, чтобы удалить примечание нижев
httpd.conf
файле. Это все.источник
conf/extra/httpd-vhosts.conf
файл и заменить егоRequire local
наRequire all granted
в моем случае,
Я использую MacOS Mojave (Apache / 2.4.34). Возникла проблема в настройках виртуального хоста в файле /etc/apache2/extra/httpd-vhosts.conf. после добавления необходимого тега каталога моя проблема исчезла.
Требовать все предоставленные
Надеюсь, что полная структура установки виртуального хоста спасет вас.
все, что вам нужно сделать, заменить MainProjectFolderName на точное ProjectFolderName.
источник
Это сводило меня с ума. Наконец выяснил, в чем проблема: я использовал прямые пути для журнала ошибок, и они были не правы.
Почему Apache выдает неопределенное (и неправильное) сообщение об ошибке? Вместо этого используйте правильное и полезное сообщение об ошибке, например: путь для директивы ErrorLog "/wrong/path/and/filename.log" недопустим.
В любом случае, чтобы исправить это, убедитесь, что директивы журнала ошибок выглядят примерно так:
источник
Если вы используете Apache 2.4 в WampServer на ОС Windows.
Вам нужно открыть файл https-vhosts.conf в блокноте.
Если вы не можете найти вышеуказанный файл. проверьте скриншот ниже
В приведенном выше коде заменить
с
И сохрани это. Перезапустите службу Apache и попробуйте снова.
источник
Для меня я фактически обновил правила Разрешить и Запретить на основе стандарта 2.4.
Однако это все еще заставляло меня получать ту же ошибку AH01630. Я нашел другой поток, и он предложил переустановить apache2. Как-то это сработало! Если кто-нибудь захочет объяснить почему, это было бы полезно.
Кредит: AH01630: клиент отклонен из-за конфигурации сервера, но требует, чтобы все предоставленные были установлены (Apache 2.4, CentOs)
источник
Если у вас есть хост https, не забудьте также внести
Require all granted
изменения в конфигурацию ssl.Кроме того, иногда полезно проверить права доступа как пользователь apache:
источник
Для Wamp 3 (Apache 2.4) помимо включения сервера, как описано в других ответах, в файле Virtual Hosts
conf/extra/httpd-vhosts.conf
вам может потребоваться заменить
с
Это применимо, если у
httpd.conf
вас естьисточник
При использовании Ubuntu проверьте, включен ли модуль 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
Этот конфиг совершенно корректен. Однако я обнаружил, что моя пользовательская конфигурация не была включена:
/private/etc/apache2/extra/httpd-userdir.conf
Обратите внимание, что это путь по умолчанию к файлу userdir conf, но, как вы увидите ниже, он настраивается в
httpd.conf
. Убедитесь, что включены следующие строки:/private/etc/apache2/httpd.conf
источник
Для тех, кто застрял на этой ошибке, как я, и ничто не помогло сверху: проверьте, действительно ли на вашем сервере существует проблемная папка из error.log. Мой был автоматически сгенерирован Django в неправильном месте (затем был испорчен статическим корнем
manage.py collectstatic
). Понятия не имею, почему нельзя правильно назвать ошибки.источник
Кроме отсутствующих
Order
иAllow
упомянутых в других ответах директив, имейте в виду, что несоответствующее регулярное выражениеDirectoryMatch
директивы также может вызывать эту ошибку.Если запрошенный путь является следующим,
/home/user-foo1bar/www/myproject/
совпадение не будет совпадатьтаким образом, даже допустимая конфигурация доступа может вызвать эту ошибку.
источник
Одной неясной (только что с ней разобранной), но возможной причиной, является внутреннее правило mod_rewrite в основном файле конфигурации (не .htaccess), которое записывает путь, который существует в корне файловой системы сервера. Скажем, у вас есть
/media
каталог на вашем сайте, и вы переписываете что-то вроде этого:Если у вас есть
/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, указывающую, что действует «Требовать все отказано»:
В ходе слепого тестирования я переместил файл в корень корневого веб-каталога и обнаружил, что могу получить к нему доступ по адресу https://example.com/file.svg .., поэтому он не удалось открыть только в папке «images». Это привело меня к файлу .htaccess в папке с изображениями, о котором я даже не подозревал.
Оказывается, Zen Cart 1.5 поставляется с файлом images / .htaccess, который имеет:
Это было очень раздражающим, и я надеюсь, что это может напомнить другим, чтобы они проверяли файлы .htaccess на каждом уровне файловой системы, приводя к файлу, к которому у вас возникли проблемы с доступом в случае, если происходит такая глупость.
источник
На самом деле я решил эту проблему, добавив доступ к каталогу к записи: 80.
Прежде чем все получат всю «безопасность» от меня, в моих конкретных обстоятельствах это не проблема безопасности.
Если вы используете удаленный ресурс, я бы порекомендовал вместо этого убедиться, что ваш запрос CURL проходит через HTTPS / TLS, тогда эта запись каталога идет через порт 443.
источник
Эта «ошибка» на самом деле является новым нормальным поведением Apache 2.4. В моем случае у меня было очень конкретное правило, запрещающее доступ к любой папке или файлу с именем, начинающимся с «.», Поэтому мне пришлось установить исключение для конкретной общедоступной папки, для которой требуется такое нечетное имя.
Для записи мое конкретное правило перезаписи:
RewriteRule "(?!\.trusted)(^|/)\." - [F]
Это правило [F] относится ко всему, начинающемуся с "." но
.trusted
, благодаря магии регулярных выражений "?!" отрицание.источник
Поскольку этот поток - первое, что появляется при поиске упомянутой ошибки, я хотел бы добавить еще одну возможную причину этой ошибки: у вас может быть
mod_evasive
активность, и клиент, увидевший эту ошибку, просто превысил пределы, настроенные в вашемmod_evasive.conf
Это особенно важно, если вы вдруг получаете эту ошибку для клиента, у которого раньше не было проблем и ничего больше не изменилось.
(если это
mod_evasive
является причиной, то ошибка исчезнет сама собой, если клиент просто временно прекратит попытки доступа к сайту; однако это может быть признаком того, что вы настроили слишком жесткие ограничения)источник
Для меня все предложенные решения не сработают. Это может помочь, если вы используете cgi, fastcig или fpm в качестве прокси-сервера, вы должны добавить местоположение в ваш vhost, чтобы избежать этой проблемы. Это позволяет 404 быть сквозным прокси.
источник