Ich erhalte diese Fehlermeldung, wenn ich versuche, über einen Browser auf localhost zuzugreifen.

AH01630: client denied by server configuration

Ich habe die Berechtigungen meines Site-Ordners überprüft mit:

sudo chmod 777 -R *

Hier ist meine Konfigurationsdatei:

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

Wenn Sie Apache 2.4 verwenden

Sie müssen Zulassungs- und Verweigerungsregeln überprüfen

Überprüfen Sie http://httpd.apache.org/docs/2.4/upgrading.html#access

In 2.2 wurde die Zugriffssteuerung basierend auf dem Client-Hostnamen, der IP-Adresse und anderen Merkmalen von Client-Anforderungen mithilfe der Anweisungen Order, Allow, Deny und Satisfy durchgeführt.

In 2.4 erfolgt eine solche Zugriffskontrolle auf die gleiche Weise wie bei anderen Berechtigungsprüfungen mit dem neuen Modul mod_authz_host.

Die neue Richtlinie lautet Erforderlich :

2.2 Konfiguration:

Order allow,deny
Allow from all

2.4 Konfiguration:

Require all granted

Vergessen Sie auch nicht, den Apache-Server nach diesen Änderungen neu zu starten ( # service httpd restart)

Für alle Verzeichnisse schreiben Require all grantedstattAllow from all

Aktualisieren

Wenn dies nicht funktioniert, entfernen Sie auch die folgende Zeile:

Bestellung erlauben, verweigern

Überprüfen Sie, ob der DocumentRoot-Pfad korrekt ist. Das kann diesen Fehler verursachen.

Ich habe die gleichen Änderungen vorgenommen, die Ravisorg für OSX 10.10 Yosemite vorgeschlagen hat, um Apache auf Version 2.4 zu aktualisieren. Nachfolgend sind die Änderungen aufgeführt, die zu http.conf hinzugefügt wurden.

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

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

Das hat mich anderthalb Tage lang total verrückt gemacht, aber ich habe eine Lösung gefunden, wenn alle anderen Lösungen erfolglos ausprobiert wurden.

Dies ist für macOS.

• Gehen Sie zum Aktivitätsmonitor (Spotlight-Suche nach: Aktivität)
• Suchen Sie im Aktivitätsmonitor nach httpd, dem Apache-Dienst
• Wählen Sie diejenige aus, die zu root gehört, und klicken Sie oben links auf X, um sie zu schließen.

Zu diesem Zeitpunkt hörte ich sofort auf, 403 Fehler zu bekommen, und alles begann wie erwartet zu funktionieren. Seltsame Sache ist, dass ich Apache nicht einmal neu starten musste, es hat einfach funktioniert. Ich denke, es hat sich selbst neu gestartet, als ich zu meinem lokalen Host ging. Ich weiß es ehrlich gesagt nicht, aber ich denke, das Problem ist, dass Apache nicht wirklich neu gestartet wird, wenn Apachectl neu gestartet wird, oder stoppen oder starten. Hoffe das hilft jemandem.

Das Problem liegt in VirtualHost, ist es aber wahrscheinlich nicht

Benötigen Sie alle gewährt

Bestätigen Sie, dass Ihre Konfiguration korrekt ist. Hier ist das richtige Beispiel

Wenn Sie das Fehlerprotokoll beenden und die Seite neu laden, sollten Sie weitere Informationen zum genauen Problem sehen.

Holen Sie sich die Umgebungsvariablen, damit $ {APACHE_LOG_DIR} tatsächlich funktioniert ...

source /etc/apache2/envvars

Dann Schwanz und schau ...

tail -f ${APACHE_LOG_DIR}/error.log

Nachdem ich ein paar Stunden verbracht hatte, war ich selbst entschlossen.

Ich habe Apache / 2.4.7 (Ubuntu) über coookbook in vagrant vm installiert.

Die Datei /etc/apache2/apache2.conf enthält <VirtualHost *:80>standardmäßig kein Element.

Ich habe zwei Änderungen vorgenommen, um dies zu erreichen

1. hinzugefügt <VirtualHost *:80>
2. 
   Optionsindizes hinzugefügt FollowSymLinks
   AllowOverride all
   Allow from all

dann habe ich endlich vm gebootet ..

Hat jemand darüber nachgedacht, dass der Wamp-Server die httpd-vhosts.confDatei standardmäßig nicht enthält? Mein Ansatz ist es, den folgenden Hinweis zu entfernen

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

in httpd.confDatei. Das ist alles.

in meinem Fall,

Ich benutze MacOS Mojave (Apache / 2.4.34). In den Einstellungen des virtuellen Hosts unter /etc/apache2/extra/httpd-vhosts.conf ist ein Problem aufgetreten. Nach dem Hinzufügen des erforderlichen Verzeichnis-Tags war mein Problem behoben.

Benötigen Sie alle gewährt

Ich hoffe, die vollständige Setup-Struktur des virtuellen Hosts wird Sie retten.

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

Alles, was Sie tun müssen, ist, den MainProjectFolderName durch Ihren genauen ProjectFolderName zu ersetzen.

Das hat mich verrückt gemacht. Endlich herausgefunden, was das Problem war: Ich habe direkte Pfade für das Fehlerprotokoll verwendet und sie waren falsch.

Warum gibt Apache eine vage (und falsche) Fehlermeldung aus? Verwenden Sie stattdessen eine korrekte und nützliche Fehlermeldung wie: Pfad für die ErrorLog-Direktive "/wrong/path/and/filename.log" ist ungültig.

Um dies zu beheben, stellen Sie sicher, dass Ihre Fehlerprotokollanweisungen ungefähr so ​​aussehen:

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

Wenn Sie Apache 2.4 in WampServer unter Windows verwenden.

Sie müssen die Datei https-vhosts.conf im Editor öffnen .

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

Wenn Sie die obige Datei nicht finden können. Screenshot unten überprüfen

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

Im obigen Code Ersetzen

Require local

mit

Require all granted

Und speichere es. Starten Sie den Apache-Dienst neu und versuchen Sie es erneut.

Für mich hatte ich die Zulassungs- und Verweigerungsregeln basierend auf dem 2.4-Standard aktualisiert.

Require all granted

Dies führte jedoch immer noch dazu, dass ich denselben AH01630-Fehler erhielt. Ich habe einen anderen Thread gefunden und vorgeschlagen, Apache2 neu zu installieren. Irgendwie hat das geklappt! Wenn jemand erklären möchte, warum, wäre das hilfreich.

Gutschrift an: AH01630: Client wird von der Serverkonfiguration abgelehnt, erfordert jedoch, dass alle gewährten Werte festgelegt sind (Apache 2.4, CentOs).

Wenn Sie einen https-Host haben, vergessen Sie nicht, auch Require all grantedÄnderungen für die SSL-Konfiguration vorzunehmen.

Manchmal ist es auch nützlich, die Berechtigungen als Apache-Benutzer zu überprüfen:

# 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

Für Wamp 3 (Apache 2.4) müssen Sie den Server conf/extra/httpd-vhosts.conf
möglicherweise nicht nur wie in den anderen Antworten beschrieben online stellen, sondern auch in der Datei für virtuelle Hosts ersetzen

Require local

mit

Require all granted

Dies gilt, wenn httpd.confSie in haben

Include conf/extra/httpd-vhosts.conf

Überprüfen Sie bei Verwendung von Ubuntu, ob das CGI-Modul aktiviert ist. Wenn nicht:

sudo a2enmod cgi

Stellen Sie sicher, dass benutzerspezifische Konfigurationen enthalten sind!

Wenn keine der anderen Antworten auf dieser Seite für Sie funktioniert, ist mir nach stundenlangem Hin und Her Folgendes begegnet.

Ich benutzte benutzerspezifischen Konfigurationen, mit Siteswie mein angegeben UserDirin /private/etc/apache2/extra/httpd-userdir.conf. Der Zugriff auf den Endpunkt war mir jedoch verboten http://localhost/~jwork/.

Ich konnte sehen, /var/log/apache2/error_logdass der Zugang zu /Users/jwork/Sites/blockiert wurde. Ich durfte jedoch über auf DocumentRoot zugreifen http://localhost/. Dies deutete darauf hin, dass ich keine Rechte zum Anzeigen des ~jworkBenutzers hatte. Aber soweit ich konnte durch sagen ps aux | egrep '(apache|httpd)'und lsof -i :80, Apache wurde für den laufenden jworkBenutzer, so war etwas eindeutig nicht mit meiner Benutzerkonfiguration schreiben.

Bei einem benannten Benutzer jworkwar hier meine Konfigurationsdatei:

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

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

Diese Konfiguration ist vollkommen gültig. Ich stellte jedoch fest, dass meine Benutzerkonfiguration nicht enthalten war:

/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

Beachten Sie, dass dies der Standardpfad zur Benutzerdir-Konfigurationsdatei ist, aber wie Sie unten sehen werden, ist er in konfigurierbar httpd.conf. Stellen Sie sicher, dass die folgenden Zeilen aktiviert sind:

/private/etc/apache2/httpd.conf

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

# ...

LoadModule userdir_module libexec/apache2/mod_userdir.so

Für diejenigen, die wie ich an diesem Fehler festgehalten haben und von oben nichts geholfen hat: Überprüfen Sie, ob der Problemordner von error.log tatsächlich auf Ihrem Server vorhanden ist. Meins wurde automatisch von Django an der falschen Stelle generiert (wurde dann mit statischer Wurzel durcheinander gebracht manage.py collectstatic). Habe keine Ahnung warum man Fehler nicht richtig benennen kann.

Beachten Sie neben fehlenden Orderund Allowin anderen Antworten erwähnten Anweisungen, dass ein nicht übereinstimmender regulärer Ausdruck einer DirectoryMatchAnweisung auch diesen Fehler verursachen kann.

Wenn der angeforderte Pfad der folgende ist, /home/user-foo1bar/www/myproject/stimmt der Matcher nicht überein

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

Daher kann selbst eine gültige Zugriffskonfiguration diesen Fehler verursachen.

Eine obskure (gerade behandelte), aber mögliche Ursache hierfür ist eine interne mod_rewrite-Regel in der Hauptkonfigurationsdatei (nicht .htaccess), die in einen Pfad schreibt, der im Stammverzeichnis des Server-Dateisystems vorhanden ist. Angenommen, Sie haben ein /mediaVerzeichnis auf Ihrer Site und schreiben so etwas neu:

RewriteRule /some_image.png /media/some_other_location.png

Wenn Sie ein /mediaVerzeichnis im Stammverzeichnis Ihres Servers haben, wird versucht, das Verzeichnis neu zu schreiben (was zu dem Fehler führt, dass der Zugriff verweigert wird) und nicht das Verzeichnis in Ihrem Site-Verzeichnis, da das Stammverzeichnis des Dateisystems zuerst von mod_rewrite auf Existenz überprüft wird des ersten Verzeichnisses im Pfad vor Ihrem Site-Verzeichnis.

Das Problem kann sein, dass sich die Direktive nicht unter <Verzeichnis> befindet

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

Auf die Direktive kann in einem Abschnitt <Verzeichnis>, <Dateien> oder <Speicherort> sowie in .htaccess-Dateien verwiesen werden, um den Zugriff auf bestimmte Teile des Servers zu steuern. Der Zugriff kann basierend auf dem Client-Hostnamen oder der IP-Adresse gesteuert werden.

Ich habe eine andere, die für jemanden nützlich sein kann. Erhielt die gleiche Fehlermeldung nach dem Upgrade von PHP 5.6 => 7.0. Wir hatten die PHP-Upload-Einstellungen geändert und vergessen, sie nach dem Kopieren zu ändern. Obwohl ich zu diesem Zeitpunkt keine Bilder hochgeladen habe, weigerte sich Silverstripe (unser CMS), diesen Fehler zu speichern und zu werfen. Die Größe des Bild-Uploads wurde erhöht und es hat sofort funktioniert.

Für den Fall, dass dies jemandem beim Googeln hilft, hatte ich diese Fehlermeldung beim Versuch, auf eine SVG-Datei auf meinem Server zuzugreifen, z . B. https://example.com/images/file.svg . Andere Dateitypen schienen in Ordnung zu sein, nur SVG schlug fehl.

Ich /etc/httpdsuchte nach Conf-Dateien und überprüfte jede require all deniedArt von Konfiguration. Ich konnte einfach nicht herausfinden, welche Konfiguration diesen Effekt hatte.

Ich habe LogLevel zum Debuggen in der VirtualHost-Konfiguration verwendet und konnte sehen, dass in der Protokollierung mod_authz_core angegeben wurde, dass "Alle verweigert" aktiviert ist:

[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

Durch Blindtests habe ich die Datei in das Stammverzeichnis des Webstamms verschoben und festgestellt, dass ich dann unter https://example.com/file.svg darauf zugreifen kann. Daher ist sie nur im Ordner "images" fehlgeschlagen. Dies führte mich zu einer .htaccess-Datei im Bilderordner, von der ich keine Ahnung hatte, dass sie dort war.

Es stellt sich heraus, dass Zen Cart 1.5 eine images / .htaccess-Datei enthält, die Folgendes enthält:

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

Das war sehr ärgerlich und ich hoffe, dies könnte andere daran erinnern, .htaccess-Dateien auf jeder Ebene des Dateisystems zu überprüfen, was zu der Datei führt, auf die Sie nur schwer zugreifen können, falls diese Art von Tom-Dummheit vor sich geht.

Ich habe dieses Problem tatsächlich gelöst, indem ich den Verzeichniszugriff zum Eintrag: 80 hinzugefügt habe.

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

Bevor alle meine "Sicherheit" für mich erhalten, ist dies unter meinen besonderen Umständen kein Sicherheitsproblem.

Wenn Sie eine Remote-Ressource verwenden, würde ich empfehlen, stattdessen sicherzustellen, dass Ihre CURL-Anforderung über HTTPS / TLS erfolgt. Dieser Verzeichniseintrag wird dann über den 443-Port gesendet.

Dieser "Fehler" ist eigentlich das neue normale Verhalten von Apache 2.4. In meinem Fall hatte ich eine ganz bestimmte Regel, um den Zugriff auf Ordner oder Dateien zu verweigern, deren Name mit "." Beginnt. Daher musste ich eine Ausnahme für einen bestimmten öffentlichen Ordner festlegen, für den ein so ungerader Name erforderlich ist.

Für die Aufzeichnung lautet meine spezielle Rewrite-Regel:

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

Diese Regel [F] verhindert alles, was mit "." Beginnt. aber .trusteddank der Magie von Regex "?!" Negation.

Da dieser Thread das erste ist, das bei der Suche nach dem genannten Fehler angezeigt wird, möchte ich eine weitere mögliche Ursache für diesen Fehler hinzufügen: Möglicherweise haben Sie mod_evasive aktiv und der Client, der diesen Fehler sieht, hat einfach die in Ihrem konfigurierten Grenzen überschrittenmod_evasive.conf

Dies ist insbesondere eine Ursache, die es wert ist, untersucht zu werden, wenn Sie plötzlich diesen Fehler für einen Client erhalten, der zuvor keine Probleme hatte und an dem sich nichts geändert hat.

(Wenn dies mod_evasivedie Ursache ist, wird der Fehler von selbst behoben, wenn der Client vorübergehend nicht mehr versucht, auf die Site zuzugreifen. Dies kann jedoch ein Zeichen dafür sein, dass Sie zu enge Grenzwerte konfiguriert haben.)