Bir tarayıcı aracılığıyla localhost'a erişmeye çalışırken bu hatayı alıyorum.

AH01630: client denied by server configuration

Site klasörü izinlerimi aşağıdakileri kullanarak kontrol ettim:

sudo chmod 777 -R *

İşte yapılandırma dosyam:

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

Apache 2.4 kullanıyorsanız

İzin verme ve reddetme kurallarını kontrol etmelisiniz

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

2.2'de, istemci ana makine adı, IP adresi ve istemci isteklerinin diğer özelliklerine dayalı erişim kontrolü Order, Allow, İzin Ver ve Satisfy yönergeleri kullanılarak yapılmıştır.

2.4'te, bu erişim kontrolü, diğer mod_authz_host modülü kullanılarak diğer yetkilendirme kontrolleriyle aynı şekilde yapılır.

Yeni yönerge Gerektir :

2.2 yapılandırma:

Order allow,deny
Allow from all

2.4 yapılandırma:

Require all granted

Ayrıca bu değişikliklerden sonra apache sunucusunu yeniden başlatmayı da unutmayın ( # service httpd restart)

Tüm dizinler için yazmak Require all grantedyerineAllow from all

Güncelleme

Yukarıdakiler işe yaramazsa, aşağıda belirtilen satırı da kaldırın:

Sipariş ver, reddet

DocumentRoot yolunun doğru olup olmadığını iki kez kontrol edin. Bu, bu hataya neden olabilir.

Rapvisorg'ın Apache'yi 2.4 sürümüne yükselten OSX 10.10 Yosemite için önerdiği aynı değişiklikleri yaptım. Http.conf dosyasına eklenen değişiklikler aşağıdadır.

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

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

Bu beni bir buçuk gündür kesinlikle deli ediyordu, ancak diğer tüm çözümler başarısız bir şekilde denenirse bir çözüm buldum.

Bu macOS içindir.

• Etkinlik İzleyicisi'ne gidin (spotlight search for: activity)
• Etkinlik izleyicide Apache hizmeti olan httpd'yi arayın
• Köke ait olanı seçin ve kapatmak için sol üstteki X işaretine tıklayın.

Bu noktada hemen 403 hatası almayı bıraktım ve her şey beklendiği gibi çalışmaya başladı. Garip bir şey bile, sadece çalıştı apache yeniden başlatmak zorunda değildi, sanırım benim yerel ana bilgisayar gittiğimde kendini yeniden başlattı, dürüst bilmiyorum ama sorun Apache aslında apachectl yeniden başlatma kullanırken yeniden başlamıyor, ya da dur ya da başla. Umarım bu birine yardımcı olur.

Sorun VirtualHost'ta ama muhtemelen değil

Tümünün verilmesini iste

Onay sizin yapılandırma doğru olduğunu, burada doğru örneğidir

Hata günlüğünü kapatır ve sayfayı yeniden yüklerseniz, sorunla ilgili daha fazla bilgi görmeniz gerekir.

$ {APACHE_LOG_DIR} aslında çalışacak şekilde ortam değişkenlerini alın ...

source /etc/apache2/envvars

Sonra kuyruk ve izle ...

tail -f ${APACHE_LOG_DIR}/error.log

Birkaç saat geçirdikten sonra kendimi çözdüm.

Apache / 2.4.7'yi (Ubuntu) vagrant vm'deki coookbook aracılığıyla yükledim.

/etc/apache2/apache2.conf dosyasında yok <VirtualHost *:80> varsayılan olarak öğe .

Bunu yapmak için iki değişiklik yaptım

1. katma <VirtualHost *:80>
2. katma
   Seçenek Dizinler FollowSymLinks
   AllowOverride hepsinden
   izin ver Hepsinden izin ver

sonra nihayet vm önyükleme ..

Herkes bu wamp sunucusu varsayılan httpd-vhosts.confdosyayı dahil düşünmüştü . Benim yaklaşımım aşağıdaki notu kaldırmak

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

içinde httpd.confdosyaya. Hepsi bu.

benim durumumda,

macOS Mojave (Apache / 2.4.34) kullanıyorum. /Etc/apache2/extra/httpd-vhosts.conf dosyasında sanal ana bilgisayar ayarlarında bir sorun oluştu. Gerekli dizin etiketini ekledikten sonra sorunum ortadan kalktı.

Tümünün verilmesini iste

Umarım tam sanal ana bilgisayar kurulum yapısı sizi kurtaracaktır.

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

tüm yapmanız gereken MainProjectFolderName yerine tam ProjectFolderName.

Bu beni delirtiyordu. Sonunda sorunun ne olduğunu anladım: Hata günlüğü için doğrudan yollar kullanıyordum ve yanıldılar.

Apache neden belirsiz (ve yanlış) bir hata mesajı veriyor? Bunun yerine aşağıdaki gibi doğru ve kullanışlı bir hata iletisi kullanın: Path for ErrorLog yönergesi "/wrong/path/and/filename.log" geçersiz.

Her neyse, düzeltmek için hata günlüğü yönergelerinizin şöyle görünmesini sağlayın:

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

Windows işletim sisteminde WampServer'da Apache 2.4 kullanıyorsanız.

Https-vhosts.conf dosyasını not defterinde açmanız gerekir .

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

Yukarıdaki dosyayı bulamıyorsanız. aşağıdaki ekran görüntüsünü kontrol et

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

Yukarıdaki kodda Değiştir

Require local

ile

Require all granted

Ve sakla. Apache hizmetini yeniden başlatın ve tekrar deneyin.

Benim için, 2.4 standardına dayalı olarak İzin Ver ve Reddet kurallarını güncelledim.

Require all granted

Ancak bu yine de aynı AH01630 hatasını almama neden oluyordu. Başka bir iş parçacığı buldum ve apache2'yi yeniden yüklemeyi önerdi. Her nasılsa bu işe yaradı! Biri nedenini açıklamak isterse, bu yardımcı olacaktır.

Kredi: AH01630: istemci sunucu yapılandırması tarafından reddedildi, ancak tüm izinler ayarlandı (Apache 2.4, CentOs)

Https ana makineniz varsa Require all granted, ssl config için de değişiklik yapmayı unutmayın .

Ayrıca, bazen apache kullanıcısı olarak izinleri kontrol etmek yararlı olabilir:

# 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

Wamp 3 (Apache 2.4) için, sunucuyu diğer yanıtlarda açıklandığı gibi çevrimiçi duruma getirmenin yanı sıra, Sanal Ana Bilgisayarlar dosyasında conf/extra/httpd-vhosts.conf
değiştirmeniz gerekebilir

Require local

ile

Require all granted

Bu, eğer httpd.confvarsa

Include conf/extra/httpd-vhosts.conf

Ubuntu kullanırken CGI modülünün etkin olup olmadığını kontrol edin. Değilse:

sudo a2enmod cgi

Kullanıcıya özgü yapılandırmaların dahil edildiğinden emin olun!

Bu sayfadaki diğer cevapların hiçbiri işe yaramazsa, saatlerce süren akınlardan sonra karşılaştığım şey.

I, kullanıcıya özgü yapılandırmaları kullanılan Sitesbenim olarak belirtilen UserDirin /private/etc/apache2/extra/httpd-userdir.conf. Ancak, son noktaya erişimim yasaklandıhttp://localhost/~jwork/ .

Ben de görebiliyordum /var/log/apache2/error_logo erişime /Users/jwork/Sites/engellenmiş ediliyordu. Ancak, yoluyla DocumentRoot erişmesine izin verildi http://localhost/. Bu, ~jworkkullanıcıyı görüntüleme haklarım olmadığını gösterdi . Ama bildiğim kadarıyla anlayabiliyordu olarak ps aux | egrep '(apache|httpd)'ve lsof -i :80Apache için koşuyordu, jworkbir şey açıkça benim kullanıcı yapılandırma ile yazmayın bu yüzden, kullanıcı.

Adlı bir kullanıcı verildiğinde jwork, yapılandırma dosyam şuydu:

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

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

Bu yapılandırma tamamen geçerlidir. Ancak, kullanıcı yapılandırmamın dahil olmadığını buldum:

/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

Bunun userdir conf dosyasının varsayılan yolu olduğunu, ancak aşağıda göreceğiniz gibi yapılandırılabileceğini unutmayın httpd.conf. Aşağıdaki satırların etkinleştirildiğinden emin olun:

/private/etc/apache2/httpd.conf

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

# ...

LoadModule userdir_module libexec/apache2/mod_userdir.so

Benim gibi bu hata sıkışmış olanlar ve hiçbir şey yukarıdan yardımcı oldu: error.log sorun klasörü gerçekten sunucunuzda olup olmadığını kontrol edin. Benimki Django tarafından yanlış yerde otomatik olarak üretildi (statik kökle karıştırıldı, sonra manage.py collectstatic). Neden hataları doğru şekilde adlandıramazsınız hakkında hiçbir fikrim yok.

Eksik Orderve Allowdiğer cevaplarda belirtilen direktiflerin yanında , bir DirectoryMatchdirektifin eşleşmeyen düzenli ifadesinin de bu hataya neden olabileceğini unutmayın.

İstenen yol aşağıdaki /home/user-foo1bar/www/myproject/folloing eşleştiriciyse

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

bu nedenle, geçerli bir erişim yapılandırması bile bu hataya neden olabilir.

Bunun bir nedeni (bununla daha önce ilgilenmiş olmakla birlikte), bunun olası nedeni, ana yapılandırma dosyasında (.htaccess değil), sunucu dosya sisteminin kökünde var olan bir yola yazan dahili bir mod_rewrite kuralıdır. /mediaSitenizde bir dizininiz olduğunu ve bunun gibi bir şeyi yeniden yazdığınızı varsayalım:

RewriteRule /some_image.png /media/some_other_location.png

/mediaSunucunuzun kök dizininde bir dizininiz varsa , dosya sistemi kökü ilk olarak mod_rewrite tarafından denetlendiğinden, site dizininizdeki dizinden ziyade yeniden yazma işlemi denenir (erişim reddedildi hatasıyla sonuçlanır). Yol dizini, site dizininizden önceki ilk dizinin

Sorun direktifin <Directory> altında olmaması olabilir

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

Yönergeye, <Directory>, <Files> veya <Location> bölümünde ve ayrıca sunucunun belirli bölümlerine erişimi denetlemek için .htaccess dosyaları içinde başvurulabilir. Erişim, istemci ana bilgisayar adı veya IP adresine göre kontrol edilebilir.

Birisi için yararlı olabilecek başka bir tane daha var. PHP 5.6 => 7.0'dan yükselttikten sonra aynı hata mesajını alıyordum. PHP yükleme ayarlarını değiştirdik ve kopyalandıktan sonra değiştirmeyi unuttuk. O sırada resim yüklemiyor olmama rağmen, Silverstripe (CMS) kaydetmeyi ve bu hatayı atmayı reddediyordu. Resim yükleme boyutunu artırdı ve hemen çalıştı.

Bu, benim gibi dolaşan herkese yardımcı olursa, sunucumda bir SVG dosyasına erişmeye çalışırken bu hata mesajını aldım, örneğin https://example.com/images/file.svg . Diğer dosya türleri iyi görünüyordu, sadece SVG başarısız oluyordu.

Etrafa avlanan /etc/httpdconf dosya ve her kontrolrequire all denied tür yapılandırmayı ve hangi yapılandırmanın bu etkiye sahip olduğunu bulamadım.

LogLevel'i VirtualHost yapılandırmasında hata ayıklamak için çevirdim ve mod_authz_core günlüğünü, 'Tümü reddedildi' etkin olarak belirten görebiliyordum:

[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

Kör test yoluyla dosyayı web kökünün köküne taşıdım ve sonra https://example.com/file.svg .. adresinden erişebildiğimi gördüm, bu yüzden sadece 'images' klasöründe başarısız oldu. Bu beni orada hiçbir fikrim yoktu görüntüleri klasöründe bir .htaccess dosyaya götürdü.

Zen Cart 1.5'in şu özelliklere sahip bir resim / .htaccess dosyası ile birlikte geldiği ortaya çıktı:

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

Bu çok can sıkıcı ve umarım bu diğerlerine dosya sisteminin her düzeyinde .htaccess dosyalarını kontrol etmeyi hatırlatabilir.

Aslında: 80 giriş dizin erişimi ekleyerek bunu çözdü.

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

Herkes tüm 'güvenliği' üzerime almadan önce, belirli koşullar altında bu bir güvenlik sorunu değildir.

Uzak bir kaynak kullanıyorsanız, bunun yerine CURL isteğinizin HTTPS / TLS üzerinden gittiğinden emin olun, sonra bu dizin girişi 443 bağlantı noktasına gider.

Bu "hata" aslında Apache 2.4'ün yeni normal davranışıdır. Benim durumumda, "." İle başlayan herhangi bir klasöre veya dosyaya erişimi reddetmek için çok özel bir kural vardı, bu yüzden böyle garip bir ad gerektiren belirli bir ortak klasör için bir istisna ayarlamak zorunda kaldım.

Kayıt için benim özel yeniden yazma kuralı:

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

Bu kural [F], "." İle başlayan her şeye uyar. ama .trustednormal ifade büyüsü sayesinde "?!" olumsuzluk.

Bu iş parçacığı, söz konusu hatayı ararken ortaya çıkan ilk şey olduğundan, bu hata için başka bir olası neden eklemek istiyorum: mod_evasiveetkin olabilir ve bu hatayı gören istemci,mod_evasive.conf

Bu, özellikle daha önce hiç problemi olmayan bir müşteri için aniden bu hatayı alıyorsanız ve başka bir şey değişmemişse araştırmaya değer bir nedendir.

(nedense mod_evasive, istemci siteye erişmeye çalışmayı geçici olarak durdurursa hata kendiliğinden kaybolur; ancak çok sıkı sınırlar yapılandırdığınızın bir işareti olabilir)