Ottengo questo errore quando provo ad accedere a localhost tramite un browser.

AH01630: client denied by server configuration

Ho controllato le autorizzazioni della cartella del mio sito usando:

sudo chmod 777 -R *

Ecco il mio file di configurazione:

<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 si utilizza Apache 2.4

Devi selezionare consenti e nega regole

Dai un'occhiata a http://httpd.apache.org/docs/2.4/upgrading.html#access

In 2.2, il controllo dell'accesso basato sul nome host del client, l'indirizzo IP e altre caratteristiche delle richieste del client è stato effettuato usando le direttive Order, Allow, Deny e Satisfy.

In 2.4, tale controllo degli accessi viene eseguito come altri controlli di autorizzazione, utilizzando il nuovo modulo mod_authz_host.

La nuova direttiva è Require :

2.2 configurazione:

Order allow,deny
Allow from all

2.4 configurazione:

Require all granted

Inoltre, non dimenticare di riavviare il server Apache dopo queste modifiche ( # service httpd restart)

Per tutte le directory scrivi Require all grantedinvece diAllow from all

Aggiornare

Se quanto sopra non funziona, rimuovi anche questa riga di seguito:

Ordine consentire, negare

Controlla che il percorso DocumentRoot sia corretto. Ciò può causare questo errore.

Ho apportato le stesse modifiche suggerite da Ravisorg a OSX 10.10 Yosemite che aggiorna Apache alla versione 2.4. Di seguito sono riportate le modifiche che sono state aggiunte a http.conf.

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

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

Questo mi ha fatto impazzire per un giorno e mezzo, ma ho trovato una soluzione se tutte le altre soluzioni sono state provate senza successo.

Questo è per macOS.

• Vai a Monitoraggio attività (ricerca spotlight per: attività)
• Nel monitor delle attività cerca httpd, che è il servizio Apache
• Seleziona quello che appartiene a root e fai clic su X in alto a sinistra per chiuderlo.

A quel punto ho immediatamente smesso di ricevere 403 errori e tutto ha iniziato a funzionare come previsto. La cosa strana è che non ho nemmeno dovuto riavviare apache ha funzionato, suppongo si sia riavviato da solo quando sono andato sul mio localhost, sinceramente non lo so, ma immagino che il problema sia Apache che non si riavvia effettivamente quando si utilizza il riavvio di apachectl, oppure fermarsi o iniziare. Spero che questo aiuti qualcuno.

Il problema è in VirtualHost ma probabilmente non lo è

Richiedi tutto concesso

Conferma che la tua configurazione è corretta, ecco il campione corretto

Se si modifica il registro degli errori e si ricarica la pagina, è necessario visualizzare ulteriori informazioni sull'esatto problema.

Prendi le variabili d'ambiente in modo che $ {APACHE_LOG_DIR} funzioni davvero ...

source /etc/apache2/envvars

Quindi coda e guarda ...

tail -f ${APACHE_LOG_DIR}/error.log

Mi sono risolto da solo dopo aver trascorso un paio d'ore.

Ho installato Apache / 2.4.7 (Ubuntu) tramite coookbook in vagrant vm.

Il file /etc/apache2/apache2.conf non ha <VirtualHost *:80>elementi per impostazione predefinita.

Ho fatto due modifiche per farlo

1. aggiunto <VirtualHost *:80>
2. 
   opzioni aggiunte Indici FollowSymLinks
   AllowOverride all
   Allow from all

poi finalmente ho appena avviato vm ..

Qualcuno ha pensato che il server Wamp predefinito non includa il httpd-vhosts.conffile. Il mio approccio è quello di rimuovere la nota qui sotto

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

nel httpd.conffile. Questo è tutto.

nel mio caso,

sto usando macOS Mojave (Apache / 2.4.34). Si è verificato un problema nelle impostazioni dell'host virtuale nel file /etc/apache2/extra/httpd-vhosts.conf. dopo aver aggiunto il tag di directory richiesto il mio problema era scomparso.

Richiedi tutto concesso

Spero che la struttura di configurazione dell'host virtuale completo ti salverà.

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

tutto quello che devi fare è sostituire MainProjectFolderName con il tuo esatto ProjectFolderName.

Questo mi stava facendo impazzire. Alla fine ho capito qual era il problema: stavo usando percorsi diretti per il registro degli errori e si sbagliavano.

Perché Apache dà un messaggio di errore vago (e sbagliato)? Utilizzare invece un messaggio di errore corretto e utile come: Percorso per la direttiva ErrorLog "/wrong/path/and/filename.log" non è valido.

Ad ogni modo, per risolvere il problema assicurati che le direttive del tuo registro errori siano simili a queste:

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

Se si utilizza Apache 2.4 in WampServer sul sistema operativo Windows.

Devi aprire il file https-vhosts.conf nel blocco note.

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

Se non riesci a trovare il file sopra. controlla lo screenshot qui sotto

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

Nel codice sopra Sostituisci

Require local

con

Require all granted

E salvalo. Riavvia il servizio Apache e riprova.

Per quanto mi riguarda, avevo effettivamente aggiornato le regole Consenti e Nega in base allo standard 2.4.

Require all granted

Tuttavia, ciò continuava a farmi ricevere lo stesso errore AH01630. Ho trovato un altro thread e mi ha suggerito di reinstallare Apache2. In qualche modo ha funzionato! Se qualcuno si preoccupasse di spiegare il perché, sarebbe utile.

Credito a: AH01630: client negato dalla configurazione del server ma richiede che sia impostato tutto concesso (Apache 2.4, CentOs)

Se si dispone di host https, non dimenticare di apportare Require all grantedmodifiche anche a ssl config.

Inoltre, a volte è utile controllare le autorizzazioni come utente 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

Per Wamp 3 (Apache 2.4), oltre a mettere il server online come descritto nelle altre risposte, nel file degli host virtuali conf/extra/httpd-vhosts.conf
potrebbe essere necessario sostituire

Require local

con

Require all granted

Questo è applicabile se httpd.confhai

Include conf/extra/httpd-vhosts.conf

Quando si utilizza Ubuntu verificare se il modulo CGI è abilitato. Altrimenti:

sudo a2enmod cgi

Assicurarsi che siano incluse eventuali configurazioni specifiche dell'utente!

Se nessuna delle altre risposte in questa pagina per te funziona, ecco cosa mi sono imbattuto dopo ore trascorse a frugare in giro.

Ho usato configurazioni specifiche dell'utente, con Sitesspecificato come mio UserDirin /private/etc/apache2/extra/httpd-userdir.conf. Tuttavia, mi è stato proibito l'accesso all'endpointhttp://localhost/~jwork/ .

Ho visto /var/log/apache2/error_logche l'accesso /Users/jwork/Sites/era bloccato. Tuttavia, mi è stato permesso di accedere a DocumentRoot, tramite http://localhost/. Ciò ha suggerito che non avevo i diritti per visualizzare l' ~jworkutente. Ma per quanto ne sapevo ps aux | egrep '(apache|httpd)'e lsof -i :80, Apache era in esecuzione per l' jworkutente, quindi qualcosa chiaramente non era scritto con la mia configurazione utente.

Dato un utente di nome jwork, ecco il mio file di configurazione:

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

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

Questa configurazione è perfettamente valida. Tuttavia, ho scoperto che la mia configurazione utente non veniva inclusa:

/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

Si noti che questo è il percorso predefinito per il file conf userdir, ma come vedrai di seguito, è configurabile in httpd.conf. Assicurarsi che le seguenti righe siano abilitate:

/private/etc/apache2/httpd.conf

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

# ...

LoadModule userdir_module libexec/apache2/mod_userdir.so

Per coloro che hanno bloccato questo errore come me e nulla ha aiutato dall'alto: controlla se la cartella del problema da error.log esiste effettivamente sul tuo server. Il mio è stato generato automaticamente da Django in un posto sbagliato (è stato incasinato con root statico, quindi manage.py collectstatic). Non ho idea del perché non si possano nominare correttamente gli errori.

Oltre alle direttive mancanti Ordere Allowmenzionate in altre risposte, tenere presente che anche un'espressione regolare non corrispondente di una DirectoryMatchdirettiva può causare questo errore.

Se il percorso richiesto è /home/user-foo1bar/www/myproject/il corrispondente corrispondente non corrisponderà

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

pertanto, anche una configurazione di accesso valida potrebbe causare questo errore.

Una causa oscura (appena trattata), ma possibile, è una regola interna mod_rewrite, nel file di configurazione principale (non .htaccess) che scrive in un percorso che esiste nella radice del file system del server. Supponi di avere una /mediadirectory nel tuo sito e riscrivi qualcosa del genere:

RewriteRule /some_image.png /media/some_other_location.png

Se si dispone di una /mediadirectory nella directory principale del server, verrà tentata la riscrittura (risultante in errore di accesso negato) anziché quella nella directory del sito, poiché la radice del file system viene controllata prima da mod_rewrite, per l'esistenza della prima directory nel percorso, prima della directory del sito.

Il problema potrebbe essere che la direttiva non è in <Directory>

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

È possibile fare riferimento alla direttiva all'interno di una sezione <Directory>, <File> o <Posizione>, nonché ai file .htaccess per controllare l'accesso a parti particolari del server. L'accesso può essere controllato in base al nome host o all'indirizzo IP del client.

Ne ho un altro che può essere utile a qualcuno. Stava ricevendo lo stesso messaggio di errore dopo l'aggiornamento da PHP 5.6 => 7.0. Avevamo modificato le impostazioni di caricamento di PHP e ci siamo dimenticati di cambiarlo una volta copiato. Anche se non stavo caricando immagini in quel momento, Silverstripe (il nostro CMS) si stava rifiutando di salvare e lanciare quell'errore. Aumentata la dimensione del caricamento dell'immagine e ha funzionato immediatamente.

Nel caso in cui questo aiuti chiunque googling come me, ho avuto questo messaggio di errore nel tentativo di accedere a un file SVG sul mio server, ad esempio https://example.com/images/file.svg . Altri tipi di file sembravano a posto, solo SVG non funzionava.

Ho /etc/httpdcercato i file conf e controllato ognirequire all denied tipo di configurazione, ma non riuscivo a trovare quale configurazione avesse questo effetto.

Ho trasformato LogLevel in debug nella configurazione di VirtualHost e ho potuto vedere la registrazione mod_authz_core specificando che era attivo un "Richiedi tutto negato":

[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

Attraverso i test ciechi ho spostato il file nella radice del Web root e ho scoperto che potevo accedervi su https://example.com/file.svg .. quindi non è riuscito nella cartella 'images'. Questo mi ha portato a un file .htaccess nella cartella delle immagini che non avevo idea che fosse lì.

Risulta che Zen Cart 1.5 viene fornito con un file images / .htaccess che ha:

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

Questo è stato molto fastidioso e spero che questo possa ricordare ad altri di controllare i file .htaccess ad ogni livello del file system che porta al file a cui si riscontrano problemi di accesso nel caso in cui ci sia questo tipo di follia tom.

In realtà ho risolto questo aggiungendo l'accesso alla directory alla voce: 80.

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

Prima che tutti ottengano tutta la "sicurezza" su di me, nelle mie circostanze specifiche questo non è un problema di sicurezza.

Se stai usando una risorsa remota, ti consiglio invece di assicurarti che la tua richiesta CURL passi tramite HTTPS / TLS, quindi questa voce della directory va sulla porta 443.

Questo "bug" è in realtà il nuovo comportamento normale di Apache 2.4. Nel mio caso, avevo una regola molto specifica per negare l'accesso a qualsiasi cartella o file con nome che inizia con ".", Quindi ho dovuto impostare un'eccezione per una particolare cartella pubblica che richiede un nome così strano.

Per la cronaca la mia particolare regola di riscrittura è:

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

Questa regola [F] obbedisce a tutto a partire da "." ma .trustedgrazie alla magia di regex "?!" negazione.

Perché questa discussione è la prima cosa che compare quando si cerca l'errore menzionato, vorrei aggiungere un'altra possibile causa per questo errore: potresti averlo mod_evasiveattivo e il client che vede questo errore ha semplicemente superato i limiti configurati nel tuomod_evasive.conf

Questa è soprattutto una causa che vale la pena indagare se improvvisamente si verifica questo errore per un client che non ha avuto problemi in precedenza e nient'altro è cambiato.

(se mod_evasiveè la causa, l'errore scompare da solo se il client smette temporaneamente di provare ad accedere al sito; tuttavia potrebbe essere un segno che hai configurato limiti troppo rigidi)

Per me, tutte le soluzioni proposte non funzioneranno. Questo può aiutare, se usi cgi, fastcig o fpm come proxy devi aggiungere una posizione nel tuo vhost per evitare questo problema. Ciò consente a 404 di essere proxy passthrough.

<Location />
require all granted
</Location>