J'obtiens cette erreur lorsque j'essaie d'accéder à localhost via un navigateur.

AH01630: client denied by server configuration

J'ai vérifié les autorisations de mon dossier de site en utilisant:

sudo chmod 777 -R *

Voici mon fichier de configuration:

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

Si vous utilisez Apache 2.4

Vous devez vérifier les règles d'autorisation et de refus

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

Dans la version 2.2, le contrôle d'accès basé sur le nom d'hôte du client, l'adresse IP et d'autres caractéristiques des demandes des clients a été effectué à l'aide des directives Order, Allow, Deny et Satisfy.

En 2.4, ce contrôle d'accès se fait de la même manière que les autres contrôles d'autorisation, en utilisant le nouveau module mod_authz_host.

La nouvelle directive est obligatoire :

2.2 configuration:

Order allow,deny
Allow from all

2.4 configuration:

Require all granted

N'oubliez pas non plus de redémarrer le serveur apache après ces modifications ( # service httpd restart)

Pour tous les répertoires, écrivez Require all grantedau lieu deAllow from all

Mise à jour

Si ce qui précède ne fonctionne pas, supprimez également la ligne mentionnée ci-dessous:

Ordonnance autoriser, refuser

Vérifiez que le chemin d'accès DocumentRoot est correct. Cela peut provoquer cette erreur.

J'ai apporté les mêmes modifications que ravisorg a suggéré à OSX 10.10 Yosemite qui met à niveau Apache vers la version 2.4. Voici les modifications qui ont été ajoutées à http.conf.

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

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

Cela m'a rendu complètement fou pendant un jour et demi, mais j'ai trouvé une solution si toutes les autres solutions ont été essayées sans succès.

C'est pour macOS.

• Accédez au moniteur d'activité (recherche Spotlight pour: activité)
• Dans le moniteur d'activité, recherchez httpd qui est le service Apache
• Sélectionnez celui qui appartient à root et cliquez sur X en haut à gauche pour le fermer.

À ce stade, j'ai immédiatement cessé de recevoir des erreurs 403 et tout a commencé à fonctionner comme prévu. Ce qui est étrange, c'est que je n'ai même pas eu à redémarrer Apache, cela a juste fonctionné, je suppose qu'il s'est redémarré quand je suis allé chez mon hôte local, honnêtement, je ne sais pas, mais je suppose que le problème est qu'Apache ne redémarre pas réellement lors de l'utilisation d'Apachectl restart, ou arrêter ou démarrer. J'espère que cela aide quelqu'un.

Le problème est dans VirtualHost mais n'est probablement pas

Exiger tout accordé

Confirmez que votre configuration est correcte, voici un échantillon correct

Si vous réduisez le journal des erreurs et rechargez la page, vous devriez voir plus d'informations sur le problème exact.

Saisissez les variables d'environnement pour que $ {APACHE_LOG_DIR} fonctionne réellement ...

source /etc/apache2/envvars

Puis queue et regarder ...

tail -f ${APACHE_LOG_DIR}/error.log

Je me suis résolu après avoir passé quelques heures.

J'ai installé Apache / 2.4.7 (Ubuntu) via coookbook dans vagrant vm.

Le fichier /etc/apache2/apache2.conf n'a pas <VirtualHost *:80> élément par défaut.

J'ai fait deux changements pour y arriver

1. ajoutée <VirtualHost *:80>
2. 
   Options ajoutées Index FollowSymLinks
   AllowOverride all
   Allow from all

puis finalement je viens de démarrer vm ..

Quelqu'un at-il pensé que le serveur Wamp par défaut n'inclut pas le httpd-vhosts.conffichier. Mon approche est de supprimer la note ci-dessous

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

dans le httpd.conffichier. C'est tout.

dans mon cas,

j'utilise macOS Mojave (Apache / 2.4.34). Il y avait un problème dans les paramètres de l'hôte virtuel dans le fichier /etc/apache2/extra/httpd-vhosts.conf. après avoir ajouté la balise de répertoire requise, mon problème a disparu.

Exiger tout accordé

J'espère que la structure de configuration complète de l'hôte virtuel vous sauvera.

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

il ne vous reste plus qu'à remplacer MainProjectFolderName par votre ProjectFolderName exact.

Cela me rendait fou. Enfin compris quel était le problème: j'utilisais des chemins directs pour le journal des erreurs et ils se trompaient.

Pourquoi Apache donne-t-il un message d'erreur vague (et erroné)? Utilisez à la place un message d'erreur correct et utile comme: Le chemin d'accès à la directive ErrorLog "/wrong/path/and/filename.log" n'est pas valide.

Quoi qu'il en soit, pour corriger, assurez-vous que vos directives de journal d'erreurs ressemblent à ceci:

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

Si vous utilisez Apache 2.4 dans WampServer sur le système d'exploitation Windows.

Vous devez ouvrir le fichier https-vhosts.conf dans le bloc-notes.

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

Si vous ne trouvez pas le fichier ci-dessus. vérifier la capture d'écran ci-dessous

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

Dans le code ci-dessus Remplacer

Require local

avec

Require all granted

Et enregistrez-le. Redémarrez le service Apache et réessayez.

Pour moi, j'avais en fait mis à jour les règles Allow et Deny basées sur la norme 2.4.

Require all granted

Cependant, cela me faisait toujours recevoir la même erreur AH01630. J'ai trouvé un autre fil et il a suggéré de réinstaller apache2. D'une manière ou d'une autre, cela a fonctionné! Si quelqu'un veut expliquer pourquoi, ce serait utile.

Crédit à: AH01630: client refusé par la configuration du serveur mais nécessite que tout ce qui est accordé soit défini (Apache 2.4, CentOs)

Si vous avez un hôte https, n'oubliez pas de faire Require all granted modifications à la configuration SSL.

De plus, il est parfois utile de vérifier les autorisations en tant qu'utilisateur 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

Pour Wamp 3 (Apache 2.4), en plus de mettre le serveur en ligne comme décrit dans les autres réponses, dans le fichier Virtual Hosts, conf/extra/httpd-vhosts.conf
vous devrez peut-être remplacer

Require local

avec

Require all granted

Ceci est applicable si httpd.confvous avez

Include conf/extra/httpd-vhosts.conf

Lors de l'utilisation d'Ubuntu, vérifiez si le module CGI est activé. Si non:

sudo a2enmod cgi

Assurez-vous que toutes les configurations spécifiques à l'utilisateur sont incluses!

Si aucune des autres réponses sur cette page pour vous ne fonctionne, voici ce que j'ai rencontré après des heures de patauger.

J'ai utilisé des configurations spécifiques à l'utilisateur, avec Sitesspécifié comme mon UserDirdans /private/etc/apache2/extra/httpd-userdir.conf. Cependant, on m'a interdit l'accès au point de terminaisonhttp://localhost/~jwork/ .

Je pouvais voir /var/log/apache2/error_logque l'accès à /Users/jwork/Sites/était bloqué. Cependant, j'ai été autorisé à accéder au DocumentRoot via http://localhost/. Cela suggérait que je n'avais pas le droit de voir l' ~jworkutilisateur. Mais pour autant que je sache ps aux | egrep '(apache|httpd)'et lsof -i :80, Apache fonctionnait pour l' jworkutilisateur, donc quelque chose n'était clairement pas écrit avec ma configuration utilisateur.

Étant donné un utilisateur nommé jwork, voici mon fichier de configuration:

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

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

Cette config est parfaitement valide. Cependant, j'ai trouvé que ma configuration utilisateur n'était pas incluse:

/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

Notez qu'il s'agit du chemin par défaut du fichier conf userdir, mais comme vous le verrez ci-dessous, il est configurable dans httpd.conf. Assurez-vous que les lignes suivantes sont activées:

/private/etc/apache2/httpd.conf

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

# ...

LoadModule userdir_module libexec/apache2/mod_userdir.so

Pour ceux qui ont collé à cette erreur comme moi et rien n'a aidé d'en haut: vérifiez si le dossier de problème de error.log existe réellement sur votre serveur. Le mien a été généré automatiquement par Django au mauvais endroit (a été gâché avec la racine statique, alors manage.py collectstatic). N'ayez aucune idée pourquoi on ne peut pas nommer correctement les erreurs.

Outre les directives manquantes Orderet Allowmentionnées dans d'autres réponses, sachez qu'une expression régulière non correspondante d'une DirectoryMatchdirective peut également provoquer cette erreur.

Si le chemin demandé est /home/user-foo1bar/www/myproject/le matcher suivant ne correspondra pas

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

par conséquent, même une configuration d'accès valide peut provoquer cette erreur.

Une cause obscure (qui vient de s'en occuper), mais possible, est une règle interne mod_rewrite, dans le fichier de configuration principal (pas .htaccess) qui écrit dans un chemin qui existe à la racine du système de fichiers du serveur. Supposons que vous ayez un /mediaannuaire dans votre site et que vous réécriviez quelque chose comme ceci:

RewriteRule /some_image.png /media/some_other_location.png

Si vous avez un /mediarépertoire à la racine de votre serveur, la réécriture y sera tentée (entraînant l'erreur d'accès refusé) plutôt que celle de votre répertoire de site, car la racine du système de fichiers est d'abord vérifiée par mod_rewrite, pour l'existence du premier répertoire du chemin, avant le répertoire de votre site.

Le problème peut être que la directive n'est pas sous <Répertoire>

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

La directive peut être référencée dans une section <Répertoire>, <Fichiers> ou <Emplacement> ainsi que des fichiers .htaccess pour contrôler l'accès à des parties particulières du serveur. L'accès peut être contrôlé en fonction du nom d'hôte ou de l'adresse IP du client.

J'en ai un autre qui peut être utile à quelqu'un. Reçoit le même message d'erreur après la mise à niveau de PHP 5.6 => 7.0. Nous avions changé les paramètres de téléchargement PHP et oublié de changer une fois copiés. Même si je ne téléchargeais pas d'images à l'époque, Silverstripe (notre CMS) refusait de sauvegarder et lançait cette erreur. Augmentation de la taille de téléchargement de l'image et cela a fonctionné immédiatement.

Au cas où cela aiderait quelqu'un à googler comme moi, j'ai eu ce message d'erreur en essayant d'accéder à un fichier SVG sur mon serveur, par exemple https://example.com/images/file.svg . D'autres types de fichiers semblaient corrects, seuls SVG échouaient.

J'ai /etc/httpdcherché des fichiers de conf et vérifié tous les require all deniedtypes de configuration, et je n'ai pas pu trouver quelle config avait cet effet.

J'ai tourné LogLevel pour déboguer dans la configuration VirtualHost et j'ai pu voir la journalisation mod_authz_core spécifiant qu'il y avait un 'Exiger tout refusé' en vigueur:

[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

Grâce à des tests en aveugle, j'ai déplacé le fichier à la racine de la racine Web, et j'ai découvert que je pouvais alors y accéder sur https://example.com/file.svg .. il n'a donc échoué que dans le dossier «images». Cela m'a conduit à un fichier .htaccess dans le dossier images dont je n'avais aucune idée qu'il était là.

Il s'avère que Zen Cart 1.5 est livré avec un fichier images / .htaccess qui a:

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

C'était très ennuyeux et j'espère que cela pourrait rappeler aux autres de vérifier les fichiers .htaccess à tous les niveaux du système de fichiers menant au fichier auquel vous avez du mal à accéder au cas où ce genre de folie de tom se produirait.

J'ai en fait résolu celui-ci en ajoutant l'accès au répertoire à l'entrée: 80.

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

Avant que tout le monde n'ait toute la «sécurité» sur moi, dans mes circonstances particulières, ce n'est pas un problème de sécurité.

Si vous utilisez une ressource distante, je recommanderais plutôt de vous assurer que votre demande CURL passe via HTTPS / TLS, puis cette entrée de répertoire va sur le port 443.

Ce "bug" est en fait le nouveau comportement normal d'Apache 2.4. Dans mon cas, j'avais une règle très spécifique pour refuser l'accès à tout dossier ou fichier dont le nom commence par ".", J'ai donc dû définir une exception pour un dossier public particulier qui nécessite un nom aussi étrange.

Pour mémoire, ma règle de réécriture particulière est:

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

Cette règle [F] interdit tout ce qui commence par "." mais .trusted, grâce à la magie des regex "?!" négation.

Parce que ce fil est la première chose qui apparaît lors de la recherche de l'erreur mentionnée, je voudrais ajouter une autre cause possible de cette erreur: vous pouvez être mod_evasiveactif et le client voyant cette erreur a simplement dépassé les limites configurées dans votremod_evasive.conf

C'est particulièrement une cause qui mérite d'être étudiée si vous obtenez soudainement cette erreur pour un client qui n'a eu aucun problème auparavant et que rien d'autre n'a changé.

(si mod_evasivec'est la cause, l'erreur disparaîtra d'elle-même si le client arrête temporairement d'essayer d'accéder au site; cependant, cela peut être un signe que vous avez configuré des limites trop strictes)

Pour moi, toutes les solutions proposées ne fonctionneront pas. Cela peut aider, si vous utilisez cgi, fastcig ou fpm comme proxy, vous devez ajouter un emplacement dans votre vhost pour éviter ce problème. Cela permet au 404 d'être un proxy passthrough.

<Location />
require all granted
</Location>