Eu recebo esse erro ao tentar acessar o host local por meio de um navegador.

AH01630: client denied by server configuration

Eu verifiquei as permissões da pasta do meu site usando:

sudo chmod 777 -R *

Aqui está o meu arquivo de configuração:

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

Se você estiver usando o Apache 2.4

Você deve verificar as regras de permissão e negação

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

Na 2.2, o controle de acesso com base no nome do host do cliente, endereço IP e outras características das solicitações do cliente foi realizado usando as diretivas Ordem, Permitir, Negar e Satisfazer.

Na 2.4, esse controle de acesso é feito da mesma maneira que outras verificações de autorização, usando o novo módulo mod_authz_host.

A nova diretiva é Exigir :

2.2 configuração:

Order allow,deny
Allow from all

2.4 configuração:

Require all granted

Também não se esqueça de reiniciar o servidor apache após essas alterações ( # service httpd restart)

Para todos os diretórios, escreva em Require all grantedvez deAllow from all

Atualizar

Se o acima não funcionar, remova-o abaixo da linha mencionada:

Ordem permitir, negar

Verifique novamente se o caminho DocumentRoot está correto. Isso pode causar esse erro.

Fiz as mesmas alterações que o ravisorg sugeriu para o OSX 10.10 Yosemite que atualiza o Apache para a versão 2.4. Abaixo estão as alterações que foram adicionadas ao http.conf.

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

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

Isso me deixou absolutamente doida por um dia e meio, mas eu encontrei uma solução se todas as outras soluções foram tentadas sem êxito.

Isso é para o macOS.

• Vá para o Monitor de atividades (pesquisa em destaque: atividade)
• No monitor de atividades, procure httpd, que é o serviço Apache
• Selecione o que pertence à raiz e clique em X no canto superior esquerdo para fechá-lo.

Nesse ponto, eu imediatamente parei de receber 403 erros e tudo começou a funcionar como esperado. O estranho é que eu nem precisei reiniciar o apache, apenas funcionou, acho que ele se reiniciou quando fui ao meu host local, sinceramente não sei, mas acho que o problema é que o Apache não está realmente reiniciando ao usar o apachectl restart, ou pare ou comece. Espero que isso ajude alguém.

O problema está no VirtualHost, mas provavelmente não é

Exigir todos os concedidos

Confirme se sua configuração está correta, aqui está uma amostra correta

Se você seguir o log de erros e recarregar a página, verá mais algumas informações sobre o problema exato.

Pegue as variáveis ​​de ambiente para que $ {APACHE_LOG_DIR} funcione ...

source /etc/apache2/envvars

Então siga e assista ...

tail -f ${APACHE_LOG_DIR}/error.log

Eu me resolvi depois de passar algumas horas.

Eu instalei o Apache / 2.4.7 (Ubuntu) através do coookbook no vagrant vm.

O arquivo /etc/apache2/apache2.conf não possui <VirtualHost *:80>elemento por padrão.

Eu fiz duas alterações para fazê-lo

1. adicionado <VirtualHost *:80>
2. adicionado
   Opções Índices FollowSymLinks
   AllowOverride all
   Allow from all

então finalmente acabei de inicializar vm ..

Alguém já pensou sobre esse padrão de servidor wamp não incluir o httpd-vhosts.confarquivo. Minha abordagem é remover a nota abaixo

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

no httpd.confarquivo. Isso é tudo.

No meu caso,

Estou usando o macOS Mojave (Apache / 2.4.34). Ocorreu um problema nas configurações do host virtual no arquivo /etc/apache2/extra/httpd-vhosts.conf. depois de adicionar a tag de diretório necessária, meu problema desapareceu.

Exigir todos os concedidos

Espero que a estrutura completa de configuração do host virtual o 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>

tudo o que você deve fazer substitui o MainProjectFolderName pelo seu ProjectFolderName exato.

Isso estava me deixando louco. Finalmente descobri qual era o problema: eu estava usando caminhos diretos para o log de erros e eles estavam errados.

Por que o Apache transmite uma mensagem de erro vaga (e errada)? Em vez disso, use uma mensagem de erro correta e útil como: Caminho para a diretiva ErrorLog "/wrong/path/and/filename.log" é inválido.

De qualquer forma, para corrigir, verifique se as diretivas do log de erros são parecidas com esta:

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

Se você estiver usando o Apache 2.4 no WampServer no sistema operacional Windows.

Você precisa abrir o arquivo https-vhosts.conf no bloco de notas.

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

Se você não conseguir encontrar o arquivo acima. verifique a captura de tela abaixo

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

No código acima, substitua

Require local

com

Require all granted

E salve. Reinicie o serviço Apache e tente novamente.

Para mim, eu atualizei as regras de permissão e negação com base no padrão 2.4.

Require all granted

No entanto, isso ainda estava me fazendo receber o mesmo erro AH01630. Encontrei outro tópico e sugeri a reinstalação do apache2. De alguma forma isso funcionou! Se alguém quiser explicar o porquê, isso seria útil.

Crédito para: AH01630: cliente negado pela configuração do servidor, mas exige que todos os concedidos estejam configurados (Apache 2.4, CentOs)

Se você possui o host https, não se esqueça de fazer Require all grantedalterações na configuração do SSL também.

Além disso, às vezes é útil verificar permissões como o usuário 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 o Wamp 3 (Apache 2.4), além de colocar o servidor on-line como descrito nas outras respostas, no arquivo Hosts Virtuais, conf/extra/httpd-vhosts.conf
você pode precisar substituir

Require local

com

Require all granted

Isso é aplicável se httpd.confvocê tiver

Include conf/extra/httpd-vhosts.conf

Ao usar o Ubuntu, verifique se o módulo CGI está ativado. Se não:

sudo a2enmod cgi

Verifique se todas as configurações específicas do usuário estão incluídas!

Se nenhuma das outras respostas desta página para você funcionar, eis o que encontrei após horas de discussões.

Eu costumava configurações específicas do usuário, com Sitesespecificado como o meu UserDirno /private/etc/apache2/extra/httpd-userdir.conf. No entanto, fui proibido o acesso ao terminal http://localhost/~jwork/.

Pude ver /var/log/apache2/error_logque o acesso ao /Users/jwork/Sites/estava sendo bloqueado. No entanto, eu tinha permissão para acessar o DocumentRoot, via http://localhost/. Isso sugeriu que eu não tinha direitos para visualizar o ~jworkusuário. Mas, tanto quanto eu poderia dizer por ps aux | egrep '(apache|httpd)'e lsof -i :80, Apache estava correndo para o jworkusuário, assim que algo não foi claramente escrever com a configuração do usuário.

Dado um usuário chamado jwork, aqui estava o meu arquivo de configuração:

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

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

Esta configuração é perfeitamente válida. No entanto, descobri que minha configuração de usuário não estava sendo incluída:

/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

Observe que este é o caminho padrão para o arquivo conf userdir, mas como você verá abaixo, é configurável em httpd.conf. Verifique se as seguintes linhas estão ativadas:

/private/etc/apache2/httpd.conf

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

# ...

LoadModule userdir_module libexec/apache2/mod_userdir.so

Para quem ficou com esse erro como eu e nada ajudou de cima: verifique se a pasta do problema de error.log realmente existe no seu servidor. O meu foi gerado automaticamente pelo Django no lugar errado (foi danificado com raiz estática, então manage.py collectstatic). Não tenho idéia por que não se pode nomear erros corretamente.

Além das diretivas ausentes Ordere ausentes Allowmencionadas em outras respostas, saiba que uma expressão regular não correspondente de uma DirectoryMatchdiretiva também pode causar esse erro.

Se o caminho solicitado for /home/user-foo1bar/www/myproject/o seguinte, o correspondente não corresponderá

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

portanto, mesmo uma configuração de acesso válida pode causar esse erro.

Uma causa obscura (tendo acabado de lidar com isso), ainda que possível, é uma regra interna mod_rewrite, no arquivo de configuração principal (não .htaccess), que grava em um caminho existente na raiz do sistema de arquivos do servidor. Digamos que você tenha um /mediadiretório em seu site e reescreva algo como isto:

RewriteRule /some_image.png /media/some_other_location.png

Se você tiver um /mediadiretório na raiz do servidor, a reescrita será tentada para isso (resultando no erro de acesso negado) em vez daquele no diretório do site, pois a raiz do sistema de arquivos é verificada primeiro por mod_rewrite, quanto à existência do primeiro diretório no caminho, antes do diretório do site.

O problema pode ser que a diretiva não esteja em <Diretório>

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

A diretiva pode ser referenciada nas seções <Diretório>, <Arquivos> ou <Localização>, bem como nos arquivos .htaccess para controlar o acesso a partes específicas do servidor. O acesso pode ser controlado com base no nome do host ou no endereço IP do cliente.

Eu tenho outro que pode ser útil para alguém. Estava recebendo a mesma mensagem de erro após a atualização do PHP 5.6 => 7.0. Alteramos as configurações de upload do PHP e esquecemos de mudar uma vez copiadas. Embora eu não estivesse carregando imagens na época, o Silverstripe (nosso CMS) estava se recusando a salvar e lançar esse erro. Aumentou o tamanho do upload da imagem e funcionou imediatamente.

Caso isso ajude alguém a pesquisar no Google como eu, recebi esta mensagem de erro ao tentar acessar um arquivo SVG no meu servidor, por exemplo, https://example.com/images/file.svg . Outros tipos de arquivos pareciam bons, apenas o SVG estava falhando.

Eu procurei /etc/httpdarquivos conf e verifiquei todos osrequire all denied tipos de configuração, e simplesmente não consegui encontrar qual configuração estava causando esse efeito.

Virei o LogLevel para depurar na configuração do VirtualHost e pude ver o log mod_authz_core especificando que havia um 'Exigir tudo negado' em efeito:

[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

Por meio do teste cego, movi o arquivo para a raiz da raiz da web e descobri que podia acessá-lo em https://example.com/file.svg .. para que ele falhasse apenas na pasta 'images'. Isso me levou a um arquivo .htaccess na pasta de imagens que eu não fazia ideia de que estava lá.

Acontece que o Zen Cart 1.5 vem com um arquivo images / .htaccess que possui:

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

Isso foi muito chato e espero que isso possa lembrar outras pessoas para verificar arquivos .htaccess em todos os níveis do sistema de arquivos que levam ao arquivo que você está tendo problemas para acessar, caso ocorra esse tipo de brincadeira.

Na verdade, eu resolvi esse problema adicionando o acesso ao diretório na entrada: 80.

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

Antes que todos tenham toda a 'segurança' em mim, sob minhas circunstâncias específicas, isso não é um problema de segurança.

Se você estiver usando um recurso remoto, recomendo que a sua solicitação CURL seja via HTTPS / TLS, então essa entrada de diretório vai para a porta 443.

Esse "bug" é realmente o novo comportamento normal do Apache 2.4. No meu caso, eu tinha uma regra muito específica para negar acesso a qualquer pasta ou arquivo com o nome começando com ".", Então tive que definir uma exceção para uma pasta pública específica que requer um nome estranho.

Para o registro, minha regra de reescrita específica é:

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

Esta regra [F] obedece a tudo começando com "." mas .trusted, graças à magia do regex "?!" negação.

Como esse encadeamento é a primeira coisa que aparece ao procurar o erro mencionado, gostaria de adicionar outra causa possível para esse erro: você pode estar mod_evasiveativo e o cliente que vê esse erro simplesmente ultrapassou os limites configurados no seumod_evasive.conf

Isso é especialmente uma causa que vale a pena investigar se você estiver recebendo esse erro repentinamente para um cliente que não apresentava problemas antes e nada mais mudou.

(se mod_evasivefor a causa, o erro desaparecerá se o cliente parar temporariamente de tentar acessar o site; no entanto, pode ser um sinal de que você configurou limites muito rígidos)

Para mim, todas as soluções propostas não funcionarão. Isso pode ajudar, se você usar cgi, fastcig ou fpm como proxy, precisará adicionar um local no seu vhost para evitar esse problema. Isso permite que 404 seja proxy de passagem.

<Location />
require all granted
</Location>