Recibo este error cuando intento acceder a localhost a través de un navegador.

AH01630: client denied by server configuration

Verifiqué los permisos de la carpeta de mi sitio usando:

sudo chmod 777 -R *

Aquí está mi archivo de configuración:

<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 está usando Apache 2.4

Tienes que marcar permitir y denegar reglas

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

En 2.2, el control de acceso basado en el nombre de host del cliente, la dirección IP y otras características de las solicitudes del cliente se realizó utilizando las directivas Order, Allow, Deny y Satisfy.

En 2.4, dicho control de acceso se realiza de la misma manera que otras comprobaciones de autorización, utilizando el nuevo módulo mod_authz_host.

La nueva directiva es Requerir :

2.2 configuración:

Order allow,deny
Allow from all

2.4 configuración:

Require all granted

Además, no olvide reiniciar el servidor apache después de estos cambios ( # service httpd restart)

Para todos los directorios, escriba en Require all grantedlugar deAllow from all

Actualizar

Si lo anterior no funciona, también elimine esta línea mencionada a continuación:

Orden permitir, negar

Verifique que la ruta de DocumentRoot sea correcta. Eso puede causar este error.

Hice los mismos cambios que ravisorg sugirió a OSX 10.10 Yosemite que actualiza Apache a la versión 2.4. A continuación se muestran los cambios que se agregaron a http.conf.

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

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

Esto me volvió completamente loco por un día y medio, pero encontré una solución si todas las demás soluciones se han probado sin éxito.

Esto es para macOS.

• Vaya a Monitor de actividad (búsqueda destacada de: actividad)
• En el monitor de actividad, busque httpd, que es el servicio Apache
• Seleccione el que pertenece a la raíz y haga clic en X en la esquina superior izquierda para cerrarlo.

En ese momento, dejé de recibir inmediatamente 403 errores y todo comenzó a funcionar como se esperaba. Lo extraño es que ni siquiera tuve que reiniciar Apache, simplemente funcionó, supongo que se reinició solo cuando fui a mi servidor local, honestamente no lo sé, pero supongo que el problema es que Apache no se reinicia realmente cuando se usa Apachectl restart, o detenerse o comenzar. Espero que esto ayude a alguien.

El problema está en VirtualHost pero probablemente no

Requerir todo otorgado

Confirme que su configuración es correcta, aquí está la muestra correcta

Si sigue el registro de errores y vuelve a cargar la página, debería ver más información sobre el problema exacto.

Tome las variables de entorno para que $ {APACHE_LOG_DIR} realmente funcione ...

source /etc/apache2/envvars

Luego cola y mira ...

tail -f ${APACHE_LOG_DIR}/error.log

Me resolví después de pasar un par de horas.

Instalé Apache / 2.4.7 (Ubuntu) a través de coookbook en vagrant vm.

El archivo /etc/apache2/apache2.conf no tiene <VirtualHost *:80>elemento por defecto.

Hice dos cambios para hacerlo

1. adicional <VirtualHost *:80>
2. 
   Opciones añadidas Índices FollowSymLinks
   AllowOverride all
   Allow from all

entonces finalmente acabo de arrancar vm ..

¿Alguien ha pensado en que el servidor predeterminado de wamp no incluya el httpd-vhosts.confarchivo? Mi enfoque es eliminar la nota a continuación

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

en el httpd.confarchivo Eso es todo.

en mi caso,

Estoy usando macOS Mojave (Apache / 2.4.34). Hubo un problema en la configuración del host virtual en el archivo /etc/apache2/extra/httpd-vhosts.conf. después de agregar la etiqueta de directorio requerida, mi problema desapareció.

Requerir todo otorgado

Espero que la estructura completa de configuración del host virtual lo salve.

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

todo lo que tiene que hacer reemplaza MainProjectFolderName con su ProjectFolderName exacto.

Esto me estaba volviendo loco. Finalmente descubrí cuál era el problema: estaba usando rutas directas para el registro de errores y estaban equivocados.

¿Por qué Apache muestra un mensaje de error vago (e incorrecto)? En su lugar, use un mensaje de error correcto y útil como: La ruta para la directiva ErrorLog "/wrong/path/and/filename.log" no es válida.

De todos modos, para solucionarlo, asegúrese de que sus directivas de registro de errores se vean así:

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

Si está utilizando Apache 2.4 en WampServer en el sistema operativo Windows.

Es necesario abrir https-vhosts.conf archivo en el bloc de notas.

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

Si no puede encontrar el archivo anterior. ver captura de pantalla a continuación

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

En el código anterior Reemplazar

Require local

con

Require all granted

Y guárdalo. Reinicie el servicio Apache e intente nuevamente.

Para mí, en realidad había actualizado las reglas Permitir y Denegar basadas en el estándar 2.4.

Require all granted

Sin embargo, esto todavía me causaba recibir el mismo error AH01630. Encontré otro hilo y sugirió reinstalar apache2. De alguna manera esto funcionó! Si a alguien le importa explicar por qué, eso sería útil.

Crédito a: AH01630: el cliente denegado por la configuración del servidor pero requiere que todo lo que se haya otorgado esté configurado (Apache 2.4, CentOs)

Si tiene un host https, no olvide hacer Require all grantedcambios para la configuración SSL también.

Además, a veces es útil verificar los permisos como usuario de 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

Para Wamp 3 (Apache 2.4), además de poner el servidor en línea como se describe en las otras respuestas, en el archivo Hosts virtuales conf/extra/httpd-vhosts.conf
es posible que deba reemplazar

Require local

con

Require all granted

Esto es aplicable si en httpd.confusted tiene

Include conf/extra/httpd-vhosts.conf

Cuando use Ubuntu verifique si el módulo CGI está habilitado. Si no:

sudo a2enmod cgi

¡Asegúrese de que se incluyan las configuraciones específicas del usuario!

Si ninguna de las otras respuestas en esta página para usted funciona, esto es lo que me encontré después de horas de vacilar.

Solía configuraciones específicas del usuario, con Sitesespecificada como mi UserDiren /private/etc/apache2/extra/httpd-userdir.conf. Sin embargo, se me prohibió el acceso al punto final.http://localhost/~jwork/ .

Pude ver /var/log/apache2/error_logque ese acceso a /Users/jwork/Sites/estaba siendo bloqueado. Sin embargo, se me permitió acceder a DocumentRoot a través de http://localhost/. Esto sugirió que no tenía derechos para ver al ~jworkusuario. Pero por lo que me di cuenta por ps aux | egrep '(apache|httpd)'y lsof -i :80, Apache se ejecuta para el jworkusuario, por lo que algo estaba claramente no escribir con la configuración de usuario.

Dado un usuario llamado jwork, aquí estaba mi archivo de configuración:

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

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

Esta configuración es perfectamente válida. Sin embargo, descubrí que mi configuración de usuario no estaba incluida:

/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

Tenga en cuenta que esta es la ruta predeterminada al archivo conf de userdir, pero como verá a continuación, es configurable en httpd.conf. Asegúrese de que las siguientes líneas estén habilitadas:

/private/etc/apache2/httpd.conf

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

# ...

LoadModule userdir_module libexec/apache2/mod_userdir.so

Para aquellos que se quedaron con este error como yo y nada ayudó desde arriba: verifique si la carpeta del problema de error.log realmente existe en su servidor. La mía fue generada automáticamente por Django en el lugar equivocado (estaba desordenado con la raíz estática, entonces manage.py collectstatic). No tengo idea de por qué uno no puede nombrar los errores correctamente.

Además de las directivas faltantes Ordery Allowmencionadas en otras respuestas, tenga en cuenta que una expresión regular no coincidente de una DirectoryMatchdirectiva también puede causar este error.

Si la ruta solicitada es /home/user-foo1bar/www/myproject/la coincidencia siguiente no coincidirá

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

por lo tanto, incluso una configuración de acceso válida puede causar este error.

Una causa oscura (que acaba de resolver), pero posible, es una regla interna mod_rewrite, en el archivo de configuración principal (no .htaccess) que escribe en una ruta que existe en la raíz del sistema de archivos del servidor. Digamos que tiene un /mediadirectorio en su sitio y reescribe algo como esto:

RewriteRule /some_image.png /media/some_other_location.png

Si tiene un /mediadirectorio en la raíz de su servidor, se intentará reescribirlo (lo que dará como resultado el error de acceso denegado) en lugar del que está en el directorio de su sitio, ya que mod_rewrite comprueba primero la raíz del sistema de archivos. del primer directorio en la ruta, antes del directorio de su sitio.

El problema puede ser que la directiva no está en <Directorio>

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

Se puede hacer referencia a la directiva en una sección <Directorio>, <Archivos> o <Ubicación>, así como en archivos .htaccess para controlar el acceso a partes particulares del servidor. El acceso se puede controlar en función del nombre de host del cliente o la dirección IP.

Tengo otro que puede ser útil para alguien. Recibía el mismo mensaje de error después de actualizar desde PHP 5.6 => 7.0. Habíamos cambiado la configuración de carga de PHP, y olvidamos cambiar una vez copiada. Aunque no estaba subiendo imágenes en ese momento, Silverstripe (nuestro CMS) se negaba a guardar y arrojó ese error. Aumentó el tamaño de carga de la imagen y funcionó de inmediato.

En caso de que esto ayude a alguien a buscar en Google como yo, recibí este mensaje de error al intentar acceder a un archivo SVG en mi servidor, por ejemplo, https://example.com/images/file.svg . Otros tipos de archivos parecían estar bien, solo SVG fallaba.

Busqué alrededor de /etc/httpdarchivos conf y comprueba cada require all deniedtipo de configuración, y no podía encontrar lo config estaba teniendo este efecto.

Convertí LogLevel para depurar en la configuración de VirtualHost y pude ver el registro mod_authz_core especificando que había un 'Requerir todo denegado' en efecto:

[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

A través de pruebas ciegas, moví el archivo a la raíz de la raíz web, y descubrí que podía acceder a él en https://example.com/file.svg ... por lo que solo falló en la carpeta 'imágenes'. Esto me llevó a un archivo .htaccess en la carpeta de imágenes que no tenía idea de que estaba allí.

Resulta que Zen Cart 1.5 viene con un archivo de imágenes / .htaccess que tiene:

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

Esto fue muy molesto y espero que esto les recuerde a los demás que comprueben los archivos .htaccess en todos los niveles del sistema de archivos que conducen al archivo al que tienen problemas para acceder en caso de que ocurra este tipo de tonterías.

De hecho, resolví esto agregando el acceso al directorio a la entrada: 80.

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

Antes de que todos tengan toda la "seguridad" sobre mí, bajo mis circunstancias específicas, esto no es un problema de seguridad.

Si está utilizando un recurso remoto, le recomiendo que se asegure de que su solicitud CURL se envíe a través de HTTPS / TLS, luego esta entrada del directorio va al puerto 443.

Este "error" es en realidad el nuevo comportamiento normal de Apache 2.4. En mi caso, tenía una regla muy específica para denegar el acceso a cualquier carpeta o archivo cuyo nombre comenzara con ".", Así que tuve que establecer una excepción para una carpeta pública en particular que requiere un nombre tan extraño.

Para el registro, mi regla particular de reescritura es:

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

Esta regla [F] obedece todo a partir de ". pero.trusted , gracias a la magia de la expresión regular "?!" negación.

Debido a que este hilo es lo primero que aparece al buscar el error mencionado, me gustaría agregar otra posible causa de este error: es posible que esté mod_evasiveactivo y que el cliente que lo ve simplemente haya cruzado los límites configurados en sumod_evasive.conf

Esto es especialmente una causa que vale la pena investigar si de repente recibe este error para un cliente que no tuvo problemas antes y nada más ha cambiado.

(si mod_evasivees la causa, el error desaparecerá por sí solo si el cliente deja de intentar acceder temporalmente al sitio; sin embargo, puede ser una señal de que ha configurado límites demasiado estrictos)

Para mí, todas las soluciones propuestas no funcionarán. Esto puede ayudar, si usa cgi, fastcig o fpm como proxy, debe agregar una ubicación en su vhost para evitar este problema. Esto permite que 404 sea proxy de paso a través.

<Location />
require all granted
</Location>