Ik krijg deze foutmelding wanneer ik via een browser toegang probeer te krijgen tot localhost.
AH01630: client denied by server configuration
Ik heb de machtigingen van mijn sitemap gecontroleerd met:
sudo chmod 777 -R *
Hier is mijn configuratiebestand:
<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>
Antwoord 1, autoriteit 100%
Als u Apache 2.4 gebruikt
U moet de regels voor toestaan en weigeren controleren
Bekijk http://httpd.apache.org/docs/2.4/upgrading.html#access
In 2.2, toegangscontrole op basis van client-hostnaam, IP-adres en andere
kenmerken van klantverzoeken werd gedaan met behulp van de richtlijnen
Bestellen, toestaan, weigeren en voldoen.In 2.4 wordt dergelijke toegangscontrole op dezelfde manier gedaan als andere
autorisatiecontroles, met behulp van de nieuwe module mod_authz_host.
De nieuwe richtlijn is Vereisen:
2.2 configuratie:
Order allow,deny
Allow from all
2.4 configuratie:
Require all granted
Vergeet ook niet om de apache-server opnieuw op te starten na deze wijzigingen (# service httpd restart)
Antwoord 2, autoriteit 38%
Voor alle mappen schrijft u Require all grantedin plaats van Allow from all
Bijwerken
Als het bovenstaande niet werkt, verwijder dan ook de onderstaande regel:
Bestelling toestaan, weigeren
Antwoord 3, autoriteit 5%
Controleer nogmaals of het DocumentRoot-pad correct is. Dat kan deze fout veroorzaken.
Antwoord 4, autoriteit 3%
Ik heb dezelfde wijzigingen aangebracht die ravisorg voorstelde in OSX 10.10 Yosemite die Apache opwaardeert naar versie 2.4. Hieronder staan de wijzigingen die zijn toegevoegd aan http.conf.
<Directory />
AllowOverride none
Require all denied
</Directory>
<Directory /Volumes/Data/Data/USER/Sites/>
AllowOverride none
Require all granted
</Directory>
Antwoord 5, autoriteit 2%
Hier werd ik anderhalve dag helemaal gek van, maar ik vond een oplossing als alle andere oplossingen tevergeefs waren geprobeerd.
Dit is voor macOS.
- Ga naar activiteitenmonitor (spotlight-zoekopdracht voor: activiteit)
- Zoek in activiteitenmonitor naar httpd, de Apache-service
- Selecteer degene die bij root hoort en klik op X linksboven om het te sluiten.
Op dat moment kreeg ik onmiddellijk geen 403-fouten meer en begon alles te werken zoals verwacht. Het rare is dat ik apache niet eens opnieuw hoefde te starten, het werkte gewoon, ik denk dat het zichzelf opnieuw opstartte toen ik naar mijn localhost ging, ik weet het eerlijk gezegd niet, maar ik denk dat het probleem is dat Apache niet echt opnieuw opstart bij het gebruik van apachectl restart, of stoppen of beginnen. Hoop dat dit iemand helpt.
Antwoord 6
Het probleem zit in VirtualHost, maar waarschijnlijk niet
Alles toekennen vereisen
Bevestigdat uw configuratiecorrect is, hier is het juiste voorbeeld
Antwoord 7
Ik heb mezelf opgelost na een paar uur te hebben doorgebracht.
Ik heb Apache/2.4.7 (Ubuntu) geïnstalleerd via coookbook in vagrant vm.
/etc/apache2/apache2.conf bestand heeft standaard geen <VirtualHost *:80>element.
Ik heb twee wijzigingen aangebracht om het voor elkaar te krijgen
<VirtualHost *:80>- toegevoegd
Opties Indexen FollowSymLinks
ToestaanAlles overschrijven
Toestaan van alle
toen heb ik eindelijk vm opgestart..
Antwoord 8
Heeft iemand erover nagedacht dat de standaard wamp-server het bestand httpd-vhosts.confniet bevat.
Mijn aanpak is om de onderstaande opmerking te verwijderen
conf
# Virtual hosts
Include conf/extra/httpd-vhosts.conf
in httpd.conf-bestand.
Dat is alles.
Antwoord 9
in mijn geval,
ik gebruik macOS Mojave (Apache/2.4.34). Er was een probleem in de instellingen van de virtuele host in het bestand /etc/apache2/extra/httpd-vhosts.conf. na het toevoegen van de vereiste directory-tag was mijn probleem verdwenen.
Alles toekennen vereisen
Ik hoop dat de volledige configuratie van de virtuele host je zal redden.
<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 wat u hoeft te doen, vervang de MainProjectFolderName door uw exacte ProjectFolderName.
Antwoord 10
Voor mij werken niet alle voorgestelde oplossingen. Dit kan helpen, als je cgi, fastcig of fpm als proxy gebruikt, moet je een locatie in je vhost toevoegen om dit probleem te voorkomen. Hierdoor kan 404 een passthrough-proxy zijn.
<Location />
require all granted
</Location>
Antwoord 11
Als je het foutenlogboek volgt en de pagina opnieuw laadt, zou je wat meer informatie over het exacte probleem moeten zien.
Pak de omgevingsvariabelen zodat ${APACHE_LOG_DIR} echt zal werken…
source /etc/apache2/envvars
Dan staart en kijk…
tail -f ${APACHE_LOG_DIR}/error.log
Antwoord 12
Als u Apache 2.4 gebruikt in WampServer op Windows OS.
U moet het bestand https-vhosts.confopenen in Kladblok.
C:\wamp64\bin\apache\apache2.4.37\conf\extra\https-vhosts.conf
Als u het bovenstaande bestand niet kunt vinden. check screenshot hieronder
<VirtualHost *:80>
ServerName localhost
DocumentRoot c:/wamp64/www
<Directory "c:/wamp64/www/">
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Require local
</Directory>
</VirtualHost>
In bovenstaande code Vervangen
Require local
met
Require all granted
En sla het op. Start de Apache-service opnieuw en probeer het opnieuw.
Antwoord 13
Voor mij had ik de regels voor toestaan en weigeren geüpdatet op basis van de 2.4-standaard.
Require all granted
Dit zorgde er echter nog steeds voor dat ik dezelfde AH01630-fout kreeg. Ik vond een andere thread en die stelde voor om apache2 opnieuw te installeren. Op de een of andere manier werkte dit! Als iemand wil uitleggen waarom, zou dat nuttig zijn.
Met dank aan: AH01630: client geweigerd door serverconfiguratie maar vereist dat alles is toegekend is ingesteld (Apache 2.4, CentOs)
Antwoord 14
Dit maakte me gek. Ben er eindelijk achter wat het probleem was:
Ik gebruikte directe paden voor het foutenlogboek en ze waren verkeerd.
Waarom geeft Apache een vage (en verkeerde) foutmelding? Gebruik in plaats daarvan een correct en nuttig foutbericht zoals: Pad voor ErrorLog-richtlijn “/wrong/path/and/filename.log” is ongeldig.
Hoe dan ook, zorg ervoor dat uw foutenlogboekrichtlijnen er ongeveer zo uitzien:
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
Antwoord 15
Voor degenen die net als ik bij deze fout bleven en niets hielp van bovenaf: controleer of de probleemmap van error.log daadwerkelijk op uw server bestaat. De mijne werd automatisch gegenereerd door Django op de verkeerde plaats (was geknoeid met statische root en vervolgens manage.py collectstatic). Heb geen idee waarom men fouten niet correct kan benoemen.
Antwoord 16
Als je een https-host hebt, vergeet dan niet om Require all grantedwijzigingen ook voor ssl-configuratie aan te brengen.
Soms is het ook handig om de rechten te controleren als de apache-gebruiker:
# 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
Antwoord 17
Voor Wamp 3 (Apache 2.4), naast het online zetten van de server zoals beschreven in de andere antwoorden, in het Virtual Hosts-bestand conf/extra/httpd-vhosts.conf
misschien moet je
. vervangen
Require local
met
Require all granted
Dit is van toepassing als u in httpd.conf
Include conf/extra/httpd-vhosts.conf
Antwoord 18
Controleer bij gebruik van Ubuntu of de CGI-module is ingeschakeld. Zo niet:
sudo a2enmod cgi
Antwoord 19
Zorg ervoor dat gebruikersspecifieke configuraties zijn opgenomen!
Als geen van de andere antwoorden op deze pagina voor u werkt, is dit wat ik tegenkwam na urenlang rondscharrelen.
Ik heb gebruikersspecifieke configuraties gebruikt, met Sitesgespecificeerd als mijn UserDirin /private/etc/apache2/extra/httpd-userdir.conf. Ik kreeg echter geen toegang tot het eindpunt http://localhost/~jwork/.
Ik kon in /var/log/apache2/error_logzien dat de toegang tot /Users/jwork/Sites/werd geblokkeerd. Ik kreeg echter toegang tot de DocumentRoot, via http://localhost/. Dit suggereerde dat ik geen rechten had om de gebruiker ~jworkte bekijken. Maar voor zover ik kon zien aan de hand van ps aux | egrep '(apache|httpd)'en lsof -i :80, Apache draaide voor de jwork-gebruiker, dus er was duidelijk iets niet geschreven met mijn gebruiker configuratie.
Gegeven een gebruiker met de naam jwork, hier was mijn configuratiebestand:
/private/etc/apache2/users/jwork.conf
<Directory "/Users/jwork/Sites/">
Require all granted
</Directory>
Deze configuratie is perfect geldig. Ik ontdekte echter dat mijn gebruikersconfiguratie niet werd opgenomen:
/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
Merk op dat dit het standaardpad naar het userdir conf-bestand is, maar zoals je hieronder zult zien, kan het worden geconfigureerd in httpd.conf. Zorg ervoor dat de volgende regels zijn ingeschakeld:
/private/etc/apache2/httpd.conf
Include /private/etc/apache2/extra/httpd-userdir.conf
# ...
LoadModule userdir_module libexec/apache2/mod_userdir.so
Antwoord 20
Ik heb dit eigenlijk opgelost door de directory-toegang toe te voegen aan het :80-item.
<Directory "c:/whatever-directory-you-use/">
AllowOverride All
Require all granted
</Directory>
Voordat iedereen alle ‘beveiliging’ op mij krijgt, is dit onder mijn specifieke omstandigheden geen beveiligingsprobleem.
Als je een externe bron gebruikt, raad ik je aan om ervoor te zorgen dat je CURL-verzoek via HTTPS / TLS gaat, en dan gaat dit directory-item op de 443-poort.
Antwoord 21
Omdat deze thread het eerste is dat opduikt bij het zoeken naar de genoemde fout, zou ik een andere mogelijke oorzaak voor deze fout willen toevoegen: je hebt misschien mod_evasiveactief en de klant ziet deze fout gewoon heeft de limieten overschreden die zijn geconfigureerd in uw mod_evasive.conf
Dit is vooral een oorzaak die het onderzoeken waard is als u deze foutmelding plotseling krijgt voor een klant die voorheen geen problemen had en er verder niets is veranderd.
(als mod_evasivede oorzaak is, dan verdwijnt de fout vanzelf als de client tijdelijk stopt met proberen toegang te krijgen tot de site; het kan echter een teken zijn dat u te strakke limieten heeft ingesteld)
Antwoord 22
Naast de ontbrekende instructies Orderen Allowdie in andere antwoorden worden genoemd, moet u zich ervan bewust zijn dat een niet-overeenkomende reguliere expressie van een DirectoryMatch-richtlijn ook kan leiden tot deze fout.
Als het gevraagde pad /home/user-foo1bar/www/myproject/is, komt de volgende matcher niet overeen
<DirectoryMatch "/home/user-[a-z]+/www/myproject/">
...
</DirectoryMatch>
dus zelfs een geldige toegangsconfiguratie kan deze fout veroorzaken.
Antwoord 23
Een obscure (nadat ik het zojuist heb behandeld), maar mogelijk, oorzaak hiervan is een interne mod_rewrite-regel, in het hoofdconfiguratiebestand (niet .htaccess) die schrijft naar een pad dat zich in de root van het serverbestandssysteem bevindt . Stel dat je een /mediadirectory op je site hebt, en je herschrijft zoiets als dit:
RewriteRule /some_image.png /media/some_other_location.png
Als je een /mediadirectory in de root van je server hebt, zal het herschrijven ernaar worden geprobeerd (resulterend in de fout toegang geweigerd) in plaats van die in je sitedirectory, aangezien de De root van het bestandssysteem wordt eerst gecontroleerd door mod_rewrite, op het bestaan van de eerste map in het pad, vóór uw sitemap.
Antwoord 24
Het probleem kan zijn dat de richtlijn niet onder < Directory>
https://httpd.apache.org/docs/2.4 /mod/mod_authz_host.html#requiredirectives
Er kan naar de richtlijn worden verwezen in een < Directory>, < Bestanden>, of < Locatie> sectie en .htaccess-bestanden om de toegang tot bepaalde delen van de server te regelen. Toegang kan worden gecontroleerd op basis van de hostnaam van de client of het IP-adres.
Antwoord 25
Ik heb er nog een die nuttig kan zijn voor iemand.
Kreeg dezelfde foutmelding na het upgraden van PHP 5.6 => 7.0. We hadden de PHP-uploadinstellingen gewijzigd en waren vergeten deze te wijzigen nadat ze waren gekopieerd.
Hoewel ik op dat moment geen afbeeldingen aan het uploaden was, weigerde Silverstripe (onze CMS) op te slaan en die fout te genereren. De uploadgrootte van afbeeldingen vergroot en het werkte meteen.
Antwoord 26
In het geval dat dit iemand helpt die rond Googlet zoals ik was, kreeg ik deze foutmelding toen ik probeerde toegang te krijgen tot een SVG-bestand op mijn server, b.v. https://example.com/images/file.svg. Andere bestandstypen leken prima, alleen SVG werkte niet.
Ik zocht rond in /etc/httpdconf-bestanden en controleerde elke configuratie van het type require all denied, en kon gewoon niet vinden welke configuratie dit effect had.
p>
Ik heb LogLevel ingeschakeld om fouten op te sporen in de VirtualHost-configuratie en kon de mod_authz_core-logboekregistratie zien die aangeeft dat er een ‘Alles weigeren’ van kracht was:
[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
Door blind testen heb ik het bestand naar de root van de webroot verplaatst en ontdekte dat ik het vervolgens kon openen op https://example.com/file.svg.. dus het mislukte alleen in de map ‘images’. Dit leidde me naar een .htaccess-bestand in de map afbeeldingen waarvan ik niet wist dat het daar was.
Blijkbaar wordt Zen Cart 1.5 geleverd met een afbeeldingen/.htaccess-bestand met:
# 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>
Dit was erg vervelenden ik hoop dat dit anderen eraan kan herinneren om .htaccess-bestanden op elk niveau van het bestandssysteem te controleren, die leiden naar het bestand waartoe je problemen hebt om toegang te krijgen in het geval van dit soort tom dwaasheid gaande.
Antwoord 27
Deze “bug” is eigenlijk het nieuwe normale gedrag van Apache 2.4. In mijn geval had ik een zeer specifieke regel om toegang te weigeren tot elke map of elk bestand waarvan de naam begint met “.”, dus ik moest een uitzondering instellen voor een bepaalde openbare map die zo’n vreemde naam vereist.
Voor de goede orde, mijn specifieke herschrijfregel is:
RewriteRule "(?!\.trusted)(^|/)\." - [F]
Deze regel [F] beëindigt alles dat begint met “.” maar .trusted, dankzij de magie van regex “?!” ontkenning.
Antwoord 28
Verkrijg een oplossing voor het probleem, moet het bestand apache2.conf wijzigen, daarna werkt het,
oude code in /etc/apache2/apache2.conf
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
veranderd in
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
Daarna, om Apache de herschrijfregels te laten begrijpen, moeten we eerst mod_rewrite activeren. Het is al geïnstalleerd, maar is uitgeschakeld bij een standaard Apache-installatie. Gebruik de opdracht a2enmod om de module in te schakelen:
$ sudo a2enmod rewrite
Hierdoor wordt de module geactiveerd of wordt u gewaarschuwd dat de module al is ingeschakeld. Om deze wijzigingen door te voeren, start u Apache opnieuw.
$ sudo systemctl restart apache2
het werkt eindelijk voor mij.
Antwoord 29
Het kostte me wat gehannes om dit werkend te krijgen op mijn eigen FreeBSD-server.
- FreeBSD 13
- Apache 2.4
- Python 3.8
- LetsEncrypt
.. maar uiteindelijk kwam ik met een werkende VirtualHost:
<VirtualHost *:443>
ServerName mysite.mydomain.com
DocumentRoot "/usr/local/www/apache24/data/mysite
WSGIDaemonProcess mysite python-path=/usr/local/www/apache24/data/mysite/venv/lib/python3.8/site-packages/
WSGIProcessGroup mysite
WSGIScriptAlias / /usr/local/www/apache24/data/mysite/core/wsgi.py
SSLEngine on
SSLCertificateFile "/usr/local/etc/letsencrypt/live/mysite.mydomain.com/cert.pem"
SSLCertificateKeyFile "/usr/local/etc/letsencrypt/live/mysite.mydomain.com/privkey.pem"
SSLCertificateChainFile "/usr/local/etc/letsencrypt/live/mysite.mydomain.com/fullchain.pem"
<FilesMatch "\.(cgi|shtml|phtml|php|py)$">
SSLOptions +StdEnvVars
</FilesMatch>
BrowserMatch "MSIE [2-5]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
CustomLog "/usr/local/www/apache24/data/mysite/log/py-ssl.log" \
"%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
CustomLog "/usr/local/www/apache24/data/mysite/log/py-access.log" combined
ErrorLog "/usr/local/www/apache24/data/mysite/log/py-error.log"
<Directory "/usr/local/www/apache24/data/mysite">
AllowOverride All
Options +ExecCGI
Require all granted
Allow from all
</Directory
</VirtualHost>