Client denied by server configuration mac os

клиент apache запрещен конфигурацией сервера после обновления Mac OS X до Yosemite

Я знаю, что это похоже на другие вопросы, но Yosemite, похоже, изменил что-то в конфигурации apache с обновлением. В моем журнале ошибок написано: «Клиент отклонен из-за конфигурации сервера: /Users/douglas/Sites/testpatient.php»

Версия Apache: MacBook-Pro: apache2 douglas $ apachectl -v Версия сервера: Apache / 2.4.9 (Unix) Сервер построен: 9 сентября 2014 14:48:20 Мой файл douglas.conf имеет 644 root / wheel и следующее:

мой http.conf имеет следующее:

Все будет оценено. Я попытался откатиться к предыдущему файлу http.conf, но есть ряд различий в том, что модули должны быть загружены. Вполне возможно, что я пропустил модуль, но в журнале нет жалоб.

В вашем пользователе .conf (douglas.conf) замените:

Разница в том, как apache 2.4 обрабатывает разрешения

У меня тоже была такая же проблема, и я исправил ее так:

Загрузите модуль userdir, найдя следующие строки в httpd.conf и раскомментировав его: LoadModule userdir_module libexec/apache2/mod_userdir.so Include /private/etc/apache2/extra/httpd-userdir.conf

Отредактируйте extra / httpd-userdir.conf , найдите и раскомментируйте следующую строку: Include /private/etc/apache2/users/*.conf

Отредактируйте users / *. Conf , добавьте Require local и добавьте + (или — ) символ перед всеми опциями в строке опций, например так: Options +Indexes +MultiViews +FollowSymLinks +SymLinksIfOwnerMatch +ExecCGI AllowOverride All Require local Order allow,deny Allow from all

Я испытал то же самое, но на Mavericks после применения обновления для системы безопасности пару дней назад. Mavericks по-прежнему использует Apache 2.2, поэтому проблема chrisMc не упоминалась, но похоже, что он прав, и вам тоже нужно это изменить.

В моем случае я сначала решил основную проблему, комментируя ранее добавленную строку модуля Homebrew PHP 5.4. В httpd.conf :

И вместо этого выбрал модуль PHP по умолчанию, который я закомментировал ранее:

Это исправило это, но что касается версии Homebrew , я думаю, что, возможно, системная библиотека, с которой она была скомпилирована, была обновлена ​​в обновлении безопасности. Когда я побежал, php -v я получил предупреждение о icu4c библиотеке, которая не была загружена.

Итак, я просто перекомпилировал PHP и он снова заработал. В моем случае я просто сделал

Тогда модуль Homebrew может быть снова включен.

Так как я никогда не использовал доморощенный, я в конечном итоге следовал этому руководству. Настройка для личного развития .

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

В httpd.conf комментариях:

И в /etc/apache2/extra/httpd-userdir.conf комментариях:

Затем перезапустите Apache.

Ответы выше работают, на стоковой установке. Если нет, то несколько вещей, которые могут помочь:

В вашей файловой системе папка должна быть точно Sites с заглавной буквы S (имя папки жестко задано в модуле userdir, оно не может быть другим). Ее разрешения должны быть:

Конфигурация применяется поверх него, поэтому он должен соответствовать имени папки точно, в том числе и в случае (мы идём от Linux . ).

Разрешения /etc/apache2/users/username.conf файла:

Поэтому убедитесь, что строка относится именно к нужной папке с правильным именем пользователя (с пользователем, совпадающим с именем файла конфигурации), включая регистр, и Sites папка действительно существует точно как есть, включая регистр.

Источник

Apache2: ‘AH01630: клиент отклонен конфигурацией сервера’

Я получаю эту ошибку при попытке доступа к localhost через браузер.

Я проверил права доступа к папке моего сайта, используя:

Вот мой файл конфигурации:

27 ответов

Если вы используете Apache 2.4

Вы должны проверить разрешающие и запрещающие правила

В 2.2 управление доступом на основе имени хоста клиента, IP-адреса и других характеристик клиентских запросов осуществлялось с помощью директив Order, Allow, Deny и Satisfy.

В 2.4 такой контроль доступа осуществляется так же, как и другие проверки авторизации, с использованием нового модуля mod_authz_host.

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

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

Обновить

Если вышеперечисленное не работает, удалите также эту строку ниже:

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

Я внес те же изменения, что ravisorg предложил OSX 10.10 Yosemite, которая обновляет Apache до версии 2.4. Ниже приведены изменения, которые были добавлены в http.conf.

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

• Перейти к монитору активности (поиск в центре внимания: активность)
• В мониторе активности найдите httpd, который является службой Apache
• Выберите тот, который принадлежит корню, и нажмите X в левом верхнем углу, чтобы закрыть его.

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

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

Подтвердите , что ваша конфигурация верна, вот правильный образец

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

Возьмите переменные среды, чтобы $ действительно работал .

Тогда следи и смотри .

Я решил сам, потратив пару часов.

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

Файл /etc/apache2/apache2.conf по умолчанию не содержит элемента .

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

1. добавил
2. добавлено
   Индексы опций FollowSymLinks
   AllowOverride все
   Разрешить от всех

То наконец я просто загрузил vm ..

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

В файле httpd.conf . Это все.

Я использую 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 и попробуйте еще раз.

Что касается меня, я фактически обновил правила Allow и Deny на основе стандарта 2.4.

Однако из-за этого я все еще получал ту же ошибку AH01630. Я нашел другой поток, и он предложил переустановить apache2. Каким-то образом это сработало! Если кому-то захочется объяснить почему, это будет полезно.

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

Если у вас есть хост https, не забудьте также внести изменения в конфигурацию ssl Require all granted .

Кроме того, иногда полезно проверить разрешения как пользователь apache:

Для Wamp 3 (Apache 2.4), помимо подключения сервера к сети, как описано в других ответах, в файле виртуальных хостов conf/extra/httpd-vhosts.conf
вам может потребоваться заменить

Это применимо, если в httpd.conf у вас есть

При использовании Ubuntu проверьте, включен ли модуль CGI. Если не:

Убедитесь, что включены все пользовательские конфигурации!

Если ни один из других ответов на этой странице вам не подходит, вот с чем я столкнулся после нескольких часов блужданий.

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

Я видел в /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

Обратите внимание, что это путь по умолчанию к файлу conf userdir, но, как вы увидите ниже, его можно настроить в httpd.conf . Убедитесь, что включены следующие строки:

/private/etc/apache2/httpd.conf

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

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

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

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

Помимо отсутствующих директив Order и Allow , упомянутых в других ответах, имейте в виду, что несовпадающее регулярное выражение директивы DirectoryMatch также может вызывать эту ошибку.

Если запрошенный путь /home/user-foo1bar/www/myproject/ , следующее сопоставление не будет соответствовать

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

Одна непонятная (только что разобравшись с этим), но возможная причина этого — внутреннее правило mod_rewrite в основном файле конфигурации (не .htaccess), которое записывает по пути, который существует в корне файловой системы сервера. Допустим, у вас есть каталог /media на вашем сайте, и вы переписываете что-то вроде этого:

Если у вас есть каталог /media в корне вашего сервера, будет предпринята попытка перезаписи этого каталога (что приведет к ошибке отказа в доступе), а не каталога вашего сайта, поскольку корень файловой системы сначала проверяется mod_rewrite, для существования первого каталога в пути перед каталогом вашего сайта.

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

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

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

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

Я поискал файлы конфигурации /etc/httpd , проверил все типы конфигурации 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 , благодаря магии регулярного выражения «?!» отрицание.

Источник