Występuje ten błąd podczas próby uzyskania dostępu do hosta lokalnego za pośrednictwem przeglądarki.

AH01630: client denied by server configuration

Sprawdziłem uprawnienia do folderu witryny, używając:

sudo chmod 777 -R *

Oto mój plik konfiguracyjny:

<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>

Jeśli używasz Apache 2.4

Musisz zaznaczyć opcję „zezwalaj i odmawiaj”

Sprawdź http://httpd.apache.org/docs/2.4/upgrading.html#access

W 2.2 kontrola dostępu oparta na nazwie hosta klienta, adresie IP i innych cechach żądań klienta została przeprowadzona przy użyciu dyrektyw Order, Allow, Deny i Satisfy.

W 2.4 taka kontrola dostępu odbywa się w taki sam sposób, jak inne kontrole autoryzacji, przy użyciu nowego modułu mod_authz_host.

Nowa dyrektywa wymaga :

Konfiguracja 2.2:

Order allow,deny
Allow from all

Konfiguracja 2.4:

Require all granted

Nie zapomnij również zrestartować serwera Apache po tych zmianach ( # service httpd restart)

Dla wszystkich katalogów pisz Require all grantedzamiastAllow from all

Aktualizacja

Jeśli powyższe nie działa, usuń również poniższy wiersz:

Zamów dozwolone, odmawiaj

Sprawdź dokładnie, czy ścieżka DocumentRoot jest poprawna. Może to spowodować ten błąd.

Wprowadziłem te same zmiany, które ravisorg zasugerował dla OSX 10.10 Yosemite, który aktualizuje Apache do wersji 2.4. Poniżej znajdują się zmiany, które zostały dodane do http.conf.

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

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

Doprowadziło mnie to do szaleństwa przez półtora dnia, ale znalazłem rozwiązanie, jeśli wszystkie inne rozwiązania zostały wypróbowane bezskutecznie.

To jest dla macOS.

• Idź do Monitor aktywności (szukaj w centrum uwagi dla: aktywność)
• W monitorowaniu aktywności wyszukaj httpd, który jest usługą Apache
• Wybierz ten, który należy do roota i kliknij X w lewym górnym rogu, aby go zamknąć.

W tym momencie natychmiast przestałem otrzymywać błędy 403 i wszystko zaczęło działać zgodnie z oczekiwaniami. Dziwne jest to, że nawet nie musiałem ponownie uruchamiać apache, to po prostu działało, chyba zrestartowało się samo, kiedy poszedłem do mojego lokalnego hosta, szczerze mówiąc, nie wiem, ale chyba problem polega na tym, że Apache nie uruchamia się ponownie przy użyciu restartu apachectl lub stop lub start. Mam nadzieję, że to komuś pomoże.

Problem jest w VirtualHost, ale prawdopodobnie nie jest

Wymagaj wszystkich przyznanych

Potwierdź Twój config jest poprawna, tutaj jest poprawna próbka

Jeśli przejrzysz dziennik błędów i ponownie załadujesz stronę, powinieneś zobaczyć więcej informacji na temat dokładnego problemu.

Chwyć zmienne środowiskowe, aby $ {APACHE_LOG_DIR} faktycznie działał ...

source /etc/apache2/envvars

Potem ogon i patrz ...

tail -f ${APACHE_LOG_DIR}/error.log

Rozwiązałem się po kilku godzinach.

Zainstalowałem Apache / 2.4.7 (Ubuntu) poprzez coookbook w vagrant vm.

Plik /etc/apache2/apache2.conf <VirtualHost *:80>domyślnie nie ma elementu.

Zrobiłem dwie zmiany, aby to zrobić

1. dodany <VirtualHost *:80>
2. dodano
   Opcje Indeksy FollowSymLinks
   AllowOverride all
   Allow from all

potem w końcu właśnie uruchomiłem vm ..

Czy ktoś myślał o tym, że domyślny serwer Wamp nie zawiera httpd-vhosts.confpliku. Moje podejście polega na usunięciu poniższej notatki

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

w httpd.confpliku To wszystko.

w moim przypadku,

Używam macOS Mojave (Apache / 2.4.34). Wystąpił problem z ustawieniami hosta wirtualnego w pliku /etc/apache2/extra/httpd-vhosts.conf. po dodaniu wymaganego znacznika katalogu mój problem zniknął.

Wymagaj wszystkich przyznanych

Mam nadzieję, że pełna struktura konfiguracji wirtualnego hosta cię uratuje.

<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>

wszystko, co musisz zrobić, zastąp nazwę MainProjectFolderName dokładną nazwą ProjectFolderName.

Doprowadzało mnie to do szału. W końcu zorientowałem się, na czym polega problem: używałem bezpośrednich ścieżek do dziennika błędów i były one błędne.

Dlaczego Apache wyświetla niejasny (i zły) komunikat o błędzie? Zamiast tego użyj poprawnego i przydatnego komunikatu o błędzie, takiego jak: Ścieżka do dyrektywy ErrorLog „Nieprawidłowa ścieżka / nazwa pliku / nazwa pliku.log”

W każdym razie, aby to naprawić, upewnij się, że dyrektywy dziennika błędów wyglądają mniej więcej tak:

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

Jeśli używasz Apache 2.4 w WampServer w systemie operacyjnym Windows.

Musisz otworzyć plik https-vhosts.conf w notatniku.

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

Jeśli nie możesz znaleźć powyższego pliku. sprawdź zrzut ekranu poniżej

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

W powyższym kodzie Zamień

Require local

z

Require all granted

I zapisz to. Uruchom ponownie usługę Apache i spróbuj ponownie.

Dla mnie zaktualizowałem reguły Zezwól i Odmów w oparciu o standard 2.4.

Require all granted

Jednak nadal powodowało to, że otrzymywałem ten sam błąd AH01630. Znalazłem inny wątek i zasugerowałem ponowną instalację apache2. Jakoś to zadziałało! Jeśli ktoś chciałby wyjaśnić, dlaczego, to byłoby pomocne.

Kredyt dla: AH01630: klient odmówiony przez konfigurację serwera, ale wymaga, aby wszystkie przyznane zostały ustawione (Apache 2.4, CentOs)

Jeśli masz hosta https, nie zapomnij też wprowadzić Require all grantedzmian w konfiguracji ssl.

Czasami warto sprawdzić uprawnienia jako użytkownik 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

W przypadku Wamp 3 (Apache 2.4), oprócz przełączania serwera do trybu online zgodnie z opisem w innych odpowiedziach, w pliku Hostów wirtualnych conf/extra/httpd-vhosts.conf
może być konieczna wymiana

Require local

z

Require all granted

Ma to zastosowanie, jeśli httpd.confmasz

Include conf/extra/httpd-vhosts.conf

Podczas korzystania z Ubuntu sprawdź, czy moduł CGI jest włączony. Jeśli nie:

sudo a2enmod cgi

Upewnij się, że uwzględniono wszelkie konfiguracje specyficzne dla użytkownika!

Jeśli żadna z pozostałych odpowiedzi na tej stronie nie działa, oto, na co wpadłem po godzinach marszu.

Użyłem konfiguracji specyficznych dla użytkownika, z Sitesokreślonym jako mój UserDirw /private/etc/apache2/extra/httpd-userdir.conf. Jednak zabroniono mi dostępu do punktu końcowego http://localhost/~jwork/.

Widziałem, /var/log/apache2/error_logże dostęp do /Users/jwork/Sites/był blokowany. Mogłem jednak uzyskać dostęp do DocumentRoot przez http://localhost/. To sugeruje, że nie mam uprawnień do przeglądania ~jworkużytkownika. Ale o ile mogę powiedzieć przez ps aux | egrep '(apache|httpd)'i lsof -i :80, Apache został uruchomiony dla jworkużytkownika, więc coś było wyraźnie nie napisać o moim konfiguracji użytkownika.

Biorąc pod uwagę użytkownika jwork, oto mój plik konfiguracyjny:

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

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

Ta konfiguracja jest całkowicie poprawna. Stwierdziłem jednak, że moja konfiguracja użytkownika nie została uwzględniona:

/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

Zauważ, że jest to domyślna ścieżka do pliku conf userdir, ale jak zobaczysz poniżej, można ją skonfigurować w httpd.conf. Upewnij się, że następujące linie są włączone:

/private/etc/apache2/httpd.conf

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

# ...

LoadModule userdir_module libexec/apache2/mod_userdir.so

Dla tych, którzy utknęli na tym błędzie jak ja i nic nie pomogło z góry: sprawdź, czy folder problemów z error.log faktycznie istnieje na twoim serwerze. Mój został wygenerowany automatycznie przez Django w niewłaściwym miejscu (wtedy został pomieszany ze statycznym rootem manage.py collectstatic). Nie mam pojęcia, dlaczego nie można poprawnie nazwać błędów.

Oprócz brakujących Orderi Allowdyrektyw wymienionych w innych odpowiedziach należy pamiętać, że DirectoryMatchten błąd może również powodować niepasujące wyrażenie regularne dyrektywy.

Jeśli żądana ścieżka jest /home/user-foo1bar/www/myproject/dopasowująca, dopasowanie nie będzie zgodne

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

dlatego nawet poprawna konfiguracja dostępu może powodować ten błąd.

Jedną z niejasnych (dopiero co sobie z tym poradziłem), ale możliwą do tego przyczyn, jest wewnętrzna reguła mod_rewrite w głównym pliku konfiguracyjnym (nie .htaccess), która zapisuje ścieżkę istniejącą w katalogu głównym systemu plików serwera. Załóżmy, że masz /mediakatalog w swojej witrynie i przepisujesz coś takiego:

RewriteRule /some_image.png /media/some_other_location.png

Jeśli masz /mediakatalog w katalogu głównym serwera, nastąpi próba przepisania (co spowoduje błąd odmowy dostępu) zamiast katalogu w katalogu witryny, ponieważ katalog główny systemu plików jest sprawdzany najpierw przez mod_rewrite pod kątem istnienia pierwszego katalogu na ścieżce, przed katalogiem witryny.

Problemem może być to, że dyrektywa nie znajduje się w katalogu <Directory>

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

Do dyrektywy można się odwoływać w sekcji <Katalog>, <Pliki> lub <Lokalizacja>, a także w plikach .htaccess, aby kontrolować dostęp do określonych części serwera. Dostęp można kontrolować na podstawie nazwy hosta klienta lub adresu IP.

Mam inny, który może być komuś przydatny. Otrzymywał ten sam komunikat o błędzie po aktualizacji z PHP 5.6 => 7.0. Zmieniliśmy ustawienia przesyłania PHP i zapomnieliśmy zmienić po skopiowaniu. Mimo że w tym czasie nie przesyłałem zdjęć, Silverstripe (nasz CMS) odmówił zapisania i zgłasza ten błąd. Zwiększono rozmiar przesyłanego obrazu i od razu zadziałało.

Gdyby to pomogło komukolwiek googlować się tak jak ja, miałem ten komunikat o błędzie, próbując uzyskać dostęp do pliku SVG na moim serwerze, np . Https://example.com/images/file.svg . Inne typy plików wydawały się w porządku, tylko SVG zawiodły.

I polować wokół /etc/httpdpliki conf sprawdzana każdegorequire all denied rodzaju konfiguracji, i po prostu nie mógł znaleźć co config był o ten efekt.

Przekręciłem LogLevel do debugowania w konfiguracji VirtualHost i mogłem zobaczyć rejestrowanie mod_authz_core z podaniem, że obowiązuje „Wymagaj wszystkich odrzuconych”:

[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

Poprzez ślepe testy przeniosłem plik do katalogu głównego katalogu głównego i stwierdziłem, że mogę uzyskać do niego dostęp pod adresem https://example.com/file.svg .. więc nie udało się to tylko w folderze „images”. Doprowadziło mnie to do pliku .htaccess w folderze obrazów, o którym nie miałem pojęcia, że ​​tam jest.

Okazuje się, że Zen Cart 1.5 jest wyposażony w plik images / .htaccess, który ma:

# 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>

To było bardzo denerwujące i mam nadzieję, że może to przypomnieć innym, aby sprawdzali pliki .htaccess na każdym poziomie systemu plików prowadzącego do pliku, do którego masz problemy z dostępem, na wypadek, gdyby trwała taka głupota.

Rozwiązałem ten problem, dodając dostęp do katalogu do wpisu: 80.

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

Zanim wszyscy otrzymają ode mnie „bezpieczeństwo”, w moich szczególnych okolicznościach nie jest to kwestia bezpieczeństwa.

Jeśli używasz zdalnego zasobu, zalecam zamiast tego upewnić się, że twoje żądanie CURL przechodzi przez HTTPS / TLS, a następnie ten wpis katalogu idzie na port 443.

Ten „błąd” jest w rzeczywistości nowym normalnym zachowaniem Apache 2.4. W moim przypadku miałem bardzo szczegółową zasadę odmowy dostępu do dowolnego folderu lub pliku o nazwie zaczynającej się od „.”, Więc musiałem ustawić wyjątek dla określonego folderu publicznego, który wymaga tak nieparzystej nazwy.

Dla przypomnienia, moja szczególna zasada Przepisywania to:

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

Ta reguła [F] stosuje się do wszystkiego, zaczynając od „.” ale .trusteddzięki magii wyrażenia regularnego „?!” negacja.

Ponieważ ten wątek jest pierwszą rzeczą, która pojawia się podczas wyszukiwania wspomnianego błędu, chciałbym dodać kolejną możliwą przyczynę tego błędu: możesz być mod_evasiveaktywny, a klient widzący ten błąd po prostu przekroczył limity skonfigurowane w twoimmod_evasive.conf

Jest to szczególnie ważna przyczyna do zbadania, jeśli nagle pojawia się ten błąd dla klienta, który nie miał wcześniej problemów i nic się nie zmieniło.

(jeśli mod_evasivejest to przyczyną, błąd sam zniknie, jeśli klient chwilowo przestanie próbować uzyskać dostęp do witryny; może to jednak świadczyć o tym, że skonfigurowałeś zbyt wąskie limity)