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>
chmod 777
jest bardzo złym nawykiem, nawet jeśli (podobno) jest używany tylko w przykładach.Odpowiedzi:
Jeśli używasz Apache 2.4
Musisz zaznaczyć opcję „zezwalaj i odmawiaj”
Sprawdź http://httpd.apache.org/docs/2.4/upgrading.html#access
Nowa dyrektywa wymaga :
Konfiguracja 2.2:
Konfiguracja 2.4:
Nie zapomnij również zrestartować serwera Apache po tych zmianach (
# service httpd restart
)źródło
DocumentRoot
i<Directory>
ścieżki.Order allow,deny ...
iRequire all granted
. To nie zadziała Musi to być tylko jeden z nich w zależności od wersji. Na początku powstrzymywało mnie to od rozwiązania problemu.Dla wszystkich katalogów pisz
Require all granted
zamiastAllow from all
Aktualizacja
Jeśli powyższe nie działa, usuń również poniższy wiersz:
źródło
Order allow,deny
linię.<Location /media> Require all granted </Location>
nadefault-ssl.conf
na mój CSS być załadowany. (Mój problem polegał na tym, że strona logowania była dostępna, ale nie załadowano CSS ani innych plików multimedialnych ...)Allow from All
przeszli na emeryturę, ponieważ ... powody ...)Sprawdź dokładnie, czy ścieżka DocumentRoot jest poprawna. Może to spowodować ten błąd.
źródło
<Directory>
bloku. Miałem też pewne różnice w sprawach. Kiedy stworzyłem te dwie wartości, kopie siebie (bez ukośnika), działało to doskonale.apache/logs/error.log
:AH00112: Warning: DocumentRoot [E:/xampp/htdocs/website/frontend/web] does not exist
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.
źródło
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.
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.
źródło
Problem jest w VirtualHost, ale prawdopodobnie nie jest
Potwierdź Twój config jest poprawna, tutaj jest poprawna próbka
źródło
<Directory ...> ... </Directory>
wierszy działało dla mnie, ponieważ korzystałem ze ścieżki do katalogu, która nie była wcześniej zdefiniowana w konfiguracjach Apache wcześniej.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ł ...
Potem ogon i patrz ...
źródło
LogLevel debug
do VirtualHost, jest to dobra rada, ponieważ zobaczysz wiersze takie jak „Wymagaj wszystkich odmów: odmowa” i „<RequireAny>: odmowa” (tj. Znacznie bardziej przydatne niż tylko „klient odmówiony przez konfigurację serwera”, jak to faktycznie mówi, która konfiguracja!)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ć
<VirtualHost *:80>
Opcje Indeksy FollowSymLinks
AllowOverride all
Allow from all
potem w końcu właśnie uruchomiłem vm ..
źródło
Czy ktoś myślał o tym, że domyślny serwer Wamp nie zawiera
httpd-vhosts.conf
pliku. Moje podejście polega na usunięciu poniższej notatkiw
httpd.conf
pliku To wszystko.źródło
conf/extra/httpd-vhosts.conf
plik i zastąpić w nimRequire local
zRequire all granted
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.
wszystko, co musisz zrobić, zastąp nazwę MainProjectFolderName dokładną nazwą ProjectFolderName.
źródło
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:
źródło
Jeśli używasz Apache 2.4 w WampServer w systemie operacyjnym Windows.
Musisz otworzyć plik https-vhosts.conf w notatniku.
Jeśli nie możesz znaleźć powyższego pliku. sprawdź zrzut ekranu poniżej
W powyższym kodzie Zamień
z
I zapisz to. Uruchom ponownie usługę Apache i spróbuj ponownie.
źródło
Dla mnie zaktualizowałem reguły Zezwól i Odmów w oparciu o standard 2.4.
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)
źródło
Jeśli masz hosta https, nie zapomnij też wprowadzić
Require all granted
zmian w konfiguracji ssl.Czasami warto sprawdzić uprawnienia jako użytkownik apache:
źródło
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
z
Ma to zastosowanie, jeśli
httpd.conf
maszźródło
Podczas korzystania z Ubuntu sprawdź, czy moduł CGI jest włączony. Jeśli nie:
źródło
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
Sites
określonym jako mójUserDir
w/private/etc/apache2/extra/httpd-userdir.conf
. Jednak zabroniono mi dostępu do punktu końcowegohttp://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 przezhttp://localhost/
. To sugeruje, że nie mam uprawnień do przeglądania~jwork
użytkownika. Ale o ile mogę powiedzieć przezps aux | egrep '(apache|httpd)'
ilsof -i :80
, Apache został uruchomiony dlajwork
uż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
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
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
źródło
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.źródło
Oprócz brakujących
Order
iAllow
dyrektyw wymienionych w innych odpowiedziach należy pamiętać, żeDirectoryMatch
ten 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 zgodnedlatego nawet poprawna konfiguracja dostępu może powodować ten błąd.
źródło
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
/media
katalog w swojej witrynie i przepisujesz coś takiego:Jeśli masz
/media
katalog 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.źródło
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.
źródło
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.
źródł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/httpd
pliki 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”:
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:
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.
źródło
Rozwiązałem ten problem, dodając dostęp do katalogu do wpisu: 80.
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.
źródło
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
.trusted
dzięki magii wyrażenia regularnego „?!” negacja.źródło
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_evasive
aktywny, 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_evasive
jest 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)źródło