cPanel 403 Forbidden hatası nasıl çözülür?
403 Forbidden, sunucunun isteği anladığını ancak istenen sayfaya erişime izin vermediğini belirtir. Bu mesaj tek başına nedenini söylemez. Eksik bir ana sayfa dosyası, yanlış dosya izni veya erişimi engelleyen bir kural aynı ekranı oluşturabilir.
Bu rehber, cPanel hosting hesabınızdaki web sitesinde görülen 403 hatası içindir. Önce DCHost müşteri portalından cPanel'e giriş yapın. Aşağıda hatalı adresi bulacak, ilgili günlük kaydını okuyacak ve yalnız soruna yol açan dosya ya da kuralı düzelteceksiniz.
1. Hatanın nerede çıktığını belirleyin
Önce tam sayfa adresini, hata saatini ve son yaptığınız işlemi not edin. Site taşıma, ZIP açma, dosya izni değiştirme veya güvenlik kuralı ekleme sonrasında mı başladı?
- Sorunlu sayfayı açın. Chrome veya Edge'de F12 → Network yolunu izleyin.
- Sayfayı bir kez yenileyin ve listede ilgili isteği seçin.
- Status Code değerinin
403olduğunu kontrol edin. Sayfanın üzerinde “Forbidden” yazması tek başına yanıt kodunu doğrulamaz. - Ana sayfa ile sorunlu alt sayfayı ayırın. Ana sayfanın açılması, örneğin yönetim panelinin veya yüklenen bir görselin de açıldığını göstermez.
Bu ekranda sunucu, istenen kaynağa erişime izin verilmediğini bildiriyor.
1. adım: Hata metnini not edin
- Hata metnini not edin
Forbidden başlığı ve permission uyarısı erişimin reddedildiğini gösteriyor. Hangi dosyanın ya da kuralın buna neden olduğunu öğrenmek için aynı isteğin saatini ve ilgili hata kaydını kontrol edin.
Alttaki ErrorDocument mesajı tek başına ikinci bir kök neden göstermez. HTTP durum kodunu tarayıcının Network ekranında ayrıca doğrulayın.
| Yanıt | Anlamı | Kontrole nereden başlayın? |
|---|---|---|
| 401 Unauthorized | İstek için geçerli kimlik doğrulama bilgisi eksik veya kabul edilmemiş. | Giriş ve varsa klasörün parola koruması |
| 403 Forbidden | İstek anlaşıldı, erişim reddedildi. | Doğru klasör, ana sayfa dosyası, izinler ve erişim kuralları |
| 404 Not Found | İstenen kaynak bulunamadı veya varlığı açıklanmıyor. | Adres, dosya adı ve uygulamanın yönlendirmeleri |
| 500 Internal Server Error | Sunucu beklenmeyen bir durum nedeniyle isteği tamamlayamadı. | 500 hata rehberindeki günlük ve PHP kontrolleri |
Her 403 düzeltilmesi gereken bir hata değildir. Özel bir yedek klasörüne veya yetkiniz olmayan bir yönetim alanına erişim bilerek engellenmiş olabilir. Hedefiniz, ziyaretçiye açık olması gereken sayfayı yeniden çalıştırmaktır.
2. Doğru site klasörünü bulun ve değişikliği yedekleyin
- cPanel'de Domains → Domains bölümünü açın.
- Sorun yaşadığınız alan adının Document Root bilgisini bulun. Bu, o sitenin yayın klasörüdür.
- Files → File Manager ile bu klasöre gidin. Üstteki yol bilgisini karşılaştırın; her alan adının
public_htmlkökünü kullandığını varsaymayın. - Düzenleyeceğiniz dosyayı Download ile indirin veya Copy ile web kökü dışındaki özel bir klasöre kopyalayın. İzin değiştirecekseniz eski değeri de not edin.
Örnekte ana alan adının Document Root değeri /public_html. Bu rehberin hata örnekleri, çalışan ana site dosyalarından ayrı olarak bu konumun altındaki forbidden-guide deneme klasöründe hazırlandı. Kendi hesabınızda önce sorunlu alan adının gerçek yayın klasörünü bulun.
cPanel içindeki Domains ekranında ilgili alan adının satırını kontrol edin.
1. adım: Document Root yolunu esas alın
- Document Root yolunu esas alın
Örnek alan adının Document Root değeri /public_html. File Manager içinde bu klasöre, sorunlu adres bir alt klasördeyse onun altına gidin. Başka bir alan adının klasöründeki dosyayı değiştirmeyin.
Bu ekranda mevcut klasör yolu kontrol edildi; alan adı, yönlendirme veya HTTPS ayarı değiştirilmedi. Farklı alan adlarında klasör yolu farklı olabilir.
Siteyi ZIP'ten çıkardıysanız dosyalar fazladan bir üst klasörün içinde kalmış olabilir. Örneğin beklenen ana sayfa public_html/index.php yerine public_html/proje/index.php altında bulunabilir. Önce uygulamanın doğru yayın klasörünü belirleyin; bütün dosyaları taşımayın veya document root değerini tahminle değiştirmeyin.
Yedek dosyalarını, veritabanı dökümlerini ve parola içeren ayarların .bak kopyalarını web kökünde tutmayın. Bir değişiklik sonuç vermezse aldığınız kopyaya ve önceki izne geri dönün. Dosya Yöneticisi rehberi kopyalama, yükleme ve izin ekranlarını ayrıntılı anlatır.
3. Aynı isteğin hata kaydını okuyun
Metrics → Errors ekranını açın. Bu bölüm web sunucusunun en yeni 300'e kadar hata kaydını, yeniler üstte olacak şekilde gösterir. Hatanın çıktığı saatle dosya yolunu birlikte eşleştirin; sunucunun saat dilimi bilgisayarınızdan farklı olabilir.
| Günlükteki ifade | Ne anlatır? | Sonraki adım |
|---|---|---|
No matching DirectoryIndex ve directory index forbidden | Sunucu uygun ana sayfa dosyasını bulamadı; klasör içeriğini listelemek de kapalı. | Index dosyasını kontrol edin. |
Permission denied / file permissions deny server access | Dosyaya erişim, izin veya sahiplik nedeniyle engelleniyor olabilir. | Dosya ve klasör izinlerini kontrol edin. |
search permissions are missing / unable to check htaccess file | Dosyanın okunabilirliği veya üst klasöre geçiş izni denetimi engelliyor olabilir. | Üst klasörleri ve sahipliği kontrol ettirin. |
client denied by server configuration | Sunucu yapılandırmasındaki bir erişim kuralı isteği engelliyor. | .htaccess ve erişim kurallarına bakın. |
ModSecurity ile birlikte erişim reddi veya kural kimliği | Bir web güvenlik kuralı ilgili isteğe müdahale etmiş olabilir. | Aynı saate ait güvenlik kaydını inceletin. |
Bu ifadeler hata türünü tanımanıza yardımcı olur; tek bir kelimeye bakarak karar vermeyin. Errors ekranının boş olması, engel bulunmadığını göstermez. Uygulama kendi 403 yanıtını üretmiş ve Apache hata günlüğüne kayıt düşmemiş olabilir. CDN veya sunucunun önündeki bir güvenlik katmanı ise isteği Apache'ye ulaşmadan engelleyebilir. Eski bir hata satırının listede kalması da yeni isteğin başarısız olduğu anlamına gelmez.
4. Eksik index dosyasını kontrol edin
Bir klasör adresi açıldığında sunucu, yapılandırmasına göre index.php veya index.html gibi bir başlangıç dosyası arar. Uygun dosya bulunamaz ve klasör listeleme kapalıysa 403 yanıtı oluşabilir.
- Doğru yayın klasörünü File Manager ile açın.
- Uygulamanızın başlangıç dosyasının orada bulunup bulunmadığına bakın. Dosya adı ve harflerin büyüklüğü doğru olmalıdır; Linux'ta
Index.htmlileindex.htmlfarklı dosyalardır. - Dosya yanlış klasöre yüklenmişse uygulamanın dağıtım yapısına göre doğru konuma alın. Silinmiş veya yanlışlıkla yeniden adlandırılmışsa bildiğiniz çalışan sürümü geri getirin.
.htaccessiçinde DirectoryIndex satırı varsa hangi dosya adını aradığını kontrol edin. Uygulamanın giriş dosyasını bilmeden rastgele bir dosyayıindex.phpolarak yeniden adlandırmayın.- Aynı klasör adresini yeniden açın; yalnız dosyanın doğrudan adresini denemekle yetinmeyin.
Örnek: yanlışlıkla yeniden adlandırılan ana sayfayı geri getirme
Deneme klasörünün çalışan index.html dosyası welcome.html olarak yeniden adlandırıldığında aynı klasör adresi HTTP 403 döndü. Metrics → Errors, o istek için şu kaydı gösterdi:
AH01276: Cannot serve directory /home/[account]/public_html/forbidden-guide/missing-index/: No matching DirectoryIndex (index.html,index.php) found, and server-generated directory index forbidden by Options directive
Kayıt, sunucunun index.html veya index.php aradığını ve dosya bulunmayınca klasör listelemeye de izin verilmediğini söylüyor.
Errors ekranındaki kaydı sorunlu isteğin saati ve klasörüyle eşleştirin.
1. adım: No matching DirectoryIndex bölümünü bulun
- No matching DirectoryIndex bölümünü bulun
No matching DirectoryIndex (index.html,index.php) bölümü, bu klasörde sunucunun beklediği açılış dosyalarının bulunamadığını gösteriyor. Kendi kaydınızda listelenen dosya adlarını esas alın.
- Dizin listelemesinin kapalı kaldığını görün
Kayıt, server-generated directory index forbidden by Options directive ifadesiyle devam ediyor. Bu örnekte doğru çözüm açılış dosyasını geri getirmektir; klasördeki dosyaları herkese listelemek için Options +Indexes eklemeyin.
Hesap adı ve istemci IP adresleri gizlenmiştir. Günlük kaydı, tek başına tarayıcının güncel HTTP yanıtını göstermez.
Bu örnekte welcome.html, adı değişmiş bilinen çalışan ana sayfa dosyasıydı. File Manager'da dosya seçilip Rename açıldı, adı yeniden index.html yapıldı ve Rename File ile kaydedildi. Başka dosyalar taşınmadı.
Doğru dosyayı seçip Rename penceresini açın.
1. adım: New file name alanına beklenen adı yazın
- New file name alanına beklenen adı yazın
Bu örneğin statik HTML açılış sayfası için index.html yazılıyor. Kendi sitenizde önce dosyanın gerçekten açılış sayfası olduğunu ve hedefte aynı adlı dosya bulunmadığını doğrulayın.
- Rename File ile adı değiştirin
Rename File düğmesine basın. Ardından dosya listesinde yeni adı kontrol edip aynı sorunlu adresi yeniden açın. Görsel, yeniden adlandırma onayından önceki ekranı gösterir.
Bu işlem yalnızca yanlış adlandırılmış doğru açılış dosyası içindir. WordPress veya başka bir uygulamanın eksik index.php dosyasını uygulamanın güvenilir yedeğinden geri yükleyin.
Aynı klasör adresi yeniden açıldığında HTTP 200 döndü ve “Örnek sayfa açılıyor” metni görüntülendi. Klasör listeleme kapalı kaldı; geri getirilen başlangıç dosyası sayfanın açılmasını sağladı.
Açılış dosyası düzeltildikten sonra örnek sayfanın içeriği görünüyor.
1. adım: Sayfanın doğru içeriği gösterdiğini doğrulayın
- Sayfanın doğru içeriği gösterdiğini doğrulayın
Daha önce Forbidden görünen adreste şimdi Örnek sayfa açılıyor başlığı ve açıklama metni var. Kendi sitenizde doğru sayfanın, bağlantıların ve ilgili işlemlerin çalıştığını kontrol edin.
Bu görsel sayfa içeriğini gösterir; sayısal HTTP durum kodu görünmez. Yanıt kodunu tarayıcının Network ekranında ayrıca kontrol edin.
Klasör listelemeyi açmak çözüm mü?
Advanced → Indexes → No Indexing, ana sayfa dosyası olmayan klasörün içeriğini listelemeyi kapatır. .htaccess içindeki Options -Indexes de klasör listelemesini kapatabilir. Klasör listelemeyi açmanız gerekmez; mevcut korumayı koruyun.
Dosya listesinin ziyaretçiye gösterilmesi, sitenizin yeniden çalıştığı anlamına gelmez. Ayrıca No Indexing, adresi bilinen dosyalara doğrudan erişimi engellemez; özel dosyalar web kökü dışında saklanmalıdır.
5. Dosya ve klasör izinlerini kontrol edin
Dosya mevcut olduğu hâlde sunucu okuyamıyorsa önce günlüğün gösterdiği tek dosyayı veya klasörü inceleyin. File Manager → ilgili öğeyi seçin → Permissions yolunu açın.
| Alan | Anlamı |
|---|---|
| User | Dosyanın sahibi |
| Group | Dosyayla ilişkili kullanıcı grubu |
| World | Diğer kullanıcılar |
| Read / Write / Execute | Okuma / yazma / çalıştırma; klasörlerde Execute, o klasörden geçerek içindeki dosyalara ulaşmayı sağlar. |
- Mevcut izin değerini not edin.
- Yalnız yanlışlıkla değişen öğeyi, hizmetiniz için bilinen doğru izne geri alın.
- Change Permissions ile kaydedin. Dosya listesindeki Permissions sütununu kontrol edin.
- Aynı web adresini yeniden açın ve yeni hata kaydına bakın.
Örnek: okunamayan dosyanın önceki iznini geri verme
Ayrı deneme klasöründeki index.html dosyasının izni 0000 yapıldığında dosyanın web adresi HTTP 403 verdi. Dosya yerindeydi; fakat User, Group ve World için okuma izni kapalıydı. Metrics → Errors ekranındaki kayıt bunu dosya yoluyla birlikte gösterdi:
AH00132: file permissions deny server access: /home/[account]/public_html/forbidden-guide/file-permissions/index.html
Aynı isteğin saatinde oluşan AH00132 kaydını inceleyin.
1. adım: file permissions deny server access mesajını bulun
- file permissions deny server access mesajını bulun
AH00132: file permissions deny server access ifadesi, sunucunun dosyaya izinler nedeniyle erişemediğini bildiriyor. Bu kaydı eksik açılış dosyası hatasıyla karıştırmayın.
- Kaydın hangi dosyayı gösterdiğini kontrol edin
Örnekte kayıt file-permissions/index.html ile bitiyor. File Manager içinde bu dosyayı bulun; başka dosyaların izinlerini topluca değiştirmeyin.
Hesap adı ve IP adresleri gizlenmiştir. Dosya sahibinin yanlış olması veya üst klasör izinleri farklı hata kayıtları üretebilir; mesajı tam okuyun.
File Manager'da yalnız bu dosya seçildi ve Permissions açıldı. Dosyanın önceki çalışan izni 0644 idi. Şu kutular seçildi:
- User: Read ve Write.
- Group: yalnız Read.
- World: yalnız Read.
- Execute: üç sütunda da kapalı.
Alttaki değerler 6 / 4 / 4 olduğunda Change Permissions ile kaydedildi. Dosya listesindeki izin yeniden 0644 göründü.
File Manager içinde doğru dosyayı seçip Permissions penceresini açın.
1. adım: 6 / 4 / 4 değerlerini kontrol edin
- 6 / 4 / 4 değerlerini kontrol edin
Bu statik HTML örneğinde User için Read ve Write, Group ile World için yalnız Read seçilidir. Execute kutuları boş kalır; alttaki değerler 6 / 4 / 4 olur.
- Change Permissions ile uygulayın
Change Permissions düğmesine basın. Ardından aynı adrese yeniden giderek içeriği ve HTTP yanıtını kontrol edin. Görsel, izinler seçildikten sonra ve onaydan önceki ekranı gösterir.
0644 bu örnekteki statik dosya içindir; her dosyaya aynı izni uygulamayın. Özel yapılandırma dosyalarının gereksinimleri farklı olabilir. 0777 vermeyin.
Dosyanın web adresi yeniden açıldığında HTTP 200 döndü. Önceki çalışan izin geri verildiğinde sayfa erişime açıldı.
Örnek: klasörün içindeki dosyaya ulaşılamaması
İkinci izin örneğinde dosya değiştirilmedi; onu barındıran folder-permissions klasörünün izni 0644 yapıldı. Bu değer klasörde geçiş için gereken Execute iznini kaldırdı; içindeki sayfa açılmak istendiğinde HTTP 403 alındı. Günlükte şu mesaj görüldü:
AH00529: /home/[account]/public_html/forbidden-guide/folder-permissions/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/home/[account]/public_html/forbidden-guide/folder-permissions/' is executable
AH00529 kaydında .htaccess denetimi ve klasör erişimi birlikte anlatılıyor.
1. adım: unable to check htaccess file bölümünü bulun
- unable to check htaccess file bölümünü bulun
Kayıt, sunucunun .htaccess dosyasını kontrol edemediğini bildiriyor. Önce hata satırının işaret ettiği yolu bulun; .htaccess içeriğini rastgele değiştirerek başlamayın.
- is executable ifadesinin klasörle ilgili olduğunu görün
Buradaki is executable ifadesi klasörün geçiş iznini kontrol etmenizi söylüyor. Bir klasörde Execute, içindeki yola erişebilmek için gerekir; HTML dosyasını çalıştırılabilir yapmak anlamına gelmez.
Hesap adı ve IP adresleri gizlidir. Bu örnekte sorun üst klasör iznindedir; aynı hata başka ortamlarda dosya okuma izni veya sahiplikle de ilişkili olabilir.
Günlükte .htaccess geçmesi, sorunun mutlaka o dosyanın içeriğinde olduğunu göstermez. Bu örnekte sunucu klasöre geçemediği için denetimi tamamlayamıyordu.
- File Manager'da engellenen klasöre girmeye çalışmak yerine bir üst klasör,
/public_html/forbidden-guide, açıldı. - folder-permissions klasörü seçildi ve Permissions açıldı.
- Önceki çalışan izin 0755 olduğu için User, Group ve World sütunlarının üçünde de Execute işaretlendi. Diğer kutular değiştirilmedi; değerler 7 / 5 / 5 oldu.
- Change Permissions ile kaydedildi. Klasör listesinde 0755 görüldü ve aynı web adresi yeniden HTTP 200 döndü.
Permissions penceresinde dosya yerine doğru klasörün seçili olduğunu kontrol edin.
1. adım: 7 / 5 / 5 değerlerini kontrol edin
- 7 / 5 / 5 değerlerini kontrol edin
Bu örnekte User için Read, Write ve Execute; Group ile World için Read ve Execute seçilidir. Alt satır 7 / 5 / 5 gösterir. Group ve World için Write seçilmez.
- Change Permissions ile değişikliği uygulayın
Change Permissions düğmesine basın; ardından aynı sorunlu adresi yeniden açın. Bu ekranda seçimler hazırdır, henüz onay verilmemiştir.
0755 bu örneğin herkese açık site klasörü için doğrulandı. Özel klasörlerin izinlerini veya tüm hesabın izinlerini topluca değiştirmeyin.
Klasördeki Execute, içindeki her dosyayı program gibi çalıştırmak anlamına gelmez; dosyaya ulaşmak için klasörden geçiş yetkisidir. Bu yüzden normal bir dosyanın 644 izniyle klasörün ihtiyaç duyduğu izin aynı değildir.
Normal, herkese açık web dosyalarında 644, klasörlerde 755 sık görülür; bazı yapılandırmalarda 750 veya daha kısıtlı değerler doğru olabilir. Bunlar tüm hesaba uygulanacak hazır bir reçete değildir. Özel ayar dosyalarının gereksinimi de farklıdır.
Dosya izni ile sahiplik aynı şey değildir. 644 görünen bir dosya, yanlış sahibin/grubun altında veya geçiş izni olmayan bir üst klasördeyse hâlâ açılamayabilir. File Manager'dan değiştiremiyorsanız ya da beklenen izinlerde sorun sürüyorsa dosya yolunu destek ekibine iletin. Hosting hesabında bütün dosyaları veya üst klasörleri topluca değiştirmeyin.
777 kullanmayın. Herkese yazma izni vermek; eksik index dosyasını, yanlış sahipliği veya bir güvenlik kuralını düzeltmez. Özel dosyaların korunmasını da zayıflatabilir.
6. .htaccess içindeki erişim kuralını inceleyin
Hata bir kural ekledikten sonra başladıysa ilgili klasörün .htaccess dosyasına bakın. Dosya görünmüyorsa File Manager → Settings → Show Hidden Files (dotfiles) → Save yolunu kullanın.
Apache 2.4'te şu satır, geçerli olduğu kapsamda bütün isteklere erişimi reddeder:
Require all denied
Bu satır geçerli bir erişim kuralıdır; kendiliğinden yazım hatası sayılmaz. Özel bir klasörü korumak için gerekli olabilir. Herkese açık site klasörüne yanlışlıkla eklendiyse istenmeyen 403 sonucunu oluşturabilir.
- Günlükte belirtilen yol ile açık
.htaccessdosyasının yerini karşılaştırın. Üst klasörlerdeki kurallar da alt klasörlere uygulanabilir. - Dosyanın düzenleme öncesi kopyasını alın.
- Edit ile açın; son değişikliği çalışan sürümle karşılaştırın.
- Yalnız yanlış yere eklenmiş veya hatalı olduğu doğrulanmış kuralı geri alın. Save Changes ile kaydedin.
- Aynı sayfanın yanıtını ve yeni günlük kayıtlarını kontrol edin.
Örnek: herkese açık klasöre eklenen engeli geri alma
Bu örnekte yalnız forbidden-guide/access-rule deneme klasörünün .htaccess dosyasına Require all denied eklendi. Sonraki istek HTTP 403 döndü; Metrics → Errors ekranında şu kayıt görüldü:
AH01630: client denied by server configuration: /home/[account]/public_html/forbidden-guide/access-rule/
AH01630 kaydını isteğin saati ve ilgili klasörle birlikte değerlendirin.
1. adım: client denied by server configuration mesajını bulun
- client denied by server configuration mesajını bulun
Bu mesaj, erişimin sunucu yapılandırmasındaki bir kural nedeniyle reddedildiğini gösterir. Hangi kuralın etkili olduğunu tek başına söylemez; ilgili .htaccess dosyasını ve son değişiklikleri inceleyin.
Hesap adı ve IP adresleri gizlenmiştir. Koruma amacıyla tanımlanmış bir engeli, amacını doğrulamadan kaldırmayın.
Düzenleme öncesi kopya için File Manager → Copy kullanıldı. Hedef olarak, hesap ana dizininde ve public_html dışında bulunan /forbidden-guide-private/htaccess-before.txt seçildi. Kopyanın düzenleme öncesindeki içeriği sakladığı kontrol edildi; eklenen engel satırı da bu kopyada bulunuyor. Kendi hesabınızda da yedek için webden erişilmeyen uygun bir hedef kullanın; bu örnek klasörün hesabınızda hazır bulunduğunu varsaymayın.
File Manager içinde doğru .htaccess dosyasını seçip Copy penceresini açın.
1. adım: Yedeği web kökü dışında tutun
- Yedeği web kökü dışında tutun
Örnekte hedef, public_html dışında önceden oluşturulmuş özel bir klasördür. Copy alanındaki yol hesap ana dizinine göre kullanılır; yedeği sitenizden indirilebilecek bir yere koymayın.
- Copy Files ile kopyayı oluşturun
Copy Files düğmesine basın; ardından hedef klasörde kopyanın oluştuğunu kontrol edin. Görsel, kopyalama onayından önceki ekranı gösterir.
Bu kopya mevcut dosyanın yedeğidir; son çalışan sürümle aynı olmayabilir. Son çalışan yedeğiniz varsa onu da ayrı koruyun.
Edit ekranında yorum satırı, Options -Indexes ve son eklenen Require all denied satırı birlikte görüldü. Yalnız yanlışlıkla eklenen engel satırı kaldırıldı; klasör listelemesini kapatan kural korundu.
Bu kontrollü örnekte üçüncü satır herkese açık sayfaya erişimi engelliyor.
1. adım: Require all denied satırını kontrol edin
- Require all denied satırını kontrol edin
Require all denied geçerli bir erişim kuralıdır ve bu kapsamda herkesi reddeder. Örneğin amacı herkese açık bir sayfa sunmak olduğundan bu kural kaldırılacaktır; özel bir klasörü koruyorsa aynı işlemi yapmayın.
Bu bir sözdizimi hatası değildir. Düzenlemeyi yalnızca yedek aldıktan ve sayfanın gerçekten herkese açık olması gerektiğini doğruladıktan sonra yapın.
Save Changes sonrasında Success! onayı geldi. Az önce engellenen sayfa yeniden açıldığında HTTP 200 döndü.
Örnekte Require all denied kaldırıldı; dizin listelemesini kapatan kural korunuyor.
1. adım: Gerekli korumaların yerinde kaldığını kontrol edin
- Gerekli korumaların yerinde kaldığını kontrol edin
Options -Indexes satırı korunuyor. Kendi dosyanızdaki yönlendirme, uygulama ve güvenlik kurallarını topluca silmeyin; sadece soruna neden olduğu doğrulanan kuralı düzeltin.
- Save Changes ile kaydedin
Save Changes düğmesine basıp aynı adresi yeniden açın. Beklenen sayfanın geldiğini, yanıt kodunu ve son denemeden sonra yeni hata kaydı oluşup oluşmadığını kontrol edin.
Bu görsel düzeltilmiş editör içeriğini gösterir; kaydın tamamlandığına dair bildirim veya HTTP yanıt kodu görünmez.
Dosyanın tamamını silmek veya her yere Require all granted eklemek; parola korumasını, özel dosya kısıtlarını ve uygulama kurallarını bozabilir. Order, Allow veya Deny gibi eski kurallar varsa yanlarına tahminle yeni Require satırları eklemeyin. Kuralın hangi isteği kapsadığından emin değilseniz destek isteyin.
7. Yalnız sizde açılmıyorsa IP engelini kontrol edin
Aynı sayfa başka bir bağlantıda açılırken sizin bağlantınızda 403 veriyorsa IP veya isteğe bağlı bir kuralı araştırın. Bu fark tek başına IP engelinin kanıtı değildir; oturum ve gönderilen istek de değişmiş olabilir.
- cPanel'de Security → IP Blocker ekranını açın.
- Currently-Blocked IP Addresses listesindeki tek IP adreslerini ve aralıkları inceleyin. Bir aralık, o anda kullandığınız dış IP adresini de kapsayabilir.
- Yalnız sizin eklediğiniz ve yanlış olduğu doğrulanan kaydı kaldırın: ilgili satırda Delete → Remove IP.
- Aynı bağlantı ve aynı web adresi üzerinden yeniden kontrol edin.
Bu demo hesabında liste “No IPs are being blocked” gösteriyordu. Ekran yalnız kontrol edildi; IP adresi ekleme veya engel kaldırma işlemi yapılmadı.
Security bölümündeki IP Blocker ekranında Currently-Blocked IP Addresses listesine bakın.
1. adım: No IPs are being blocked sonucunu doğru yorumlayın
- No IPs are being blocked sonucunu doğru yorumlayın
Bu demo hesabın listesinde No IPs are being blocked yazıyor; bu araçta bir IP engeli tanımlı değil. Kendi hesabınızda kayıt varsa sorun yaşayan bağlantının IP adresi ve ilgili aralıkla karşılaştırın.
Liste yalnızca cPanel IP Blocker kayıtlarını gösterir. Boş olması CDN, WAF, uygulama veya sunucu güvenlik duvarında hiçbir engel bulunmadığını kanıtlamaz. Bu incelemede engel eklenmedi veya kaldırılmadı.
IP Blocker, web sitesine erişimi yönetir. Webmail, sunucu güvenlik duvarı, CDN ve uygulamanın kendi engel listeleri ayrı kontrollerdir. Listenin boş olması, başka bir katmanda engel bulunmadığını göstermez. Birden fazla IP'yi kapsayan kaydı ne işe yaradığını anlamadan kaldırmayın.
8. Form veya yönetim işlemi 403 veriyorsa güvenlik kaydını inceletin
Ana sayfa açılıyor ancak içerik kaydetme, dosya yükleme veya yönetim panelindeki belirli bir işlem engelleniyorsa ModSecurity, başka bir WAF veya uygulamanın kendi yetki kontrolü devrede olabilir. Yalnız hata ekranına bakarak hangisi olduğunu ayıramazsınız.
- Hesabınızda varsa Security → ModSecurity ekranında ilgili alan adının durumuna bakın. On görünmesi, o isteğin ModSecurity tarafından engellendiğini kanıtlamaz.
- Hatanın çıktığı tam adresi, saati ve yapılan işlemi not edin. Varsa Rule ID veya CDN'nin istek kimliğini ekleyin.
- Destek talebinde aynı isteğin güvenlik kayıtlarıyla eşleştirilmesini isteyin. Yanlış engelleme doğrulanırsa ilgili kuralın uygun kapsamda düzeltilmesi gerekir.
ModSecurity menüsü görünmüyorsa özellik hesabınıza açılmamış olabilir. Bu durum, sitede hiçbir güvenlik denetimi bulunmadığını veya 403 hatasının ModSecurity kaynaklı olduğunu göstermez. İlgili isteğin kaydını destek ekibi kontrol edebilir.
ModSecurity'yi bütün alan adlarında kapatmak veya güvenlik duvarını kaldırmak çözüm değildir. CDN kaynaklı bir engel, cPanel'deki izin değişikliğiyle düzelmeyebilir. WordPress'te yalnız wp-admin veya bir eklenti işlemi etkileniyorsa son güvenlik/eklenti değişikliğini ve kullanıcı yetkisini de inceleyin; bütün eklentileri aynı anda silmeyin.
9. Düzeltmenin gerçekten işe yaradığını kontrol edin
Save Changes veya Change Permissions onayı, web isteğinin düzeldiğini tek başına göstermez.
- Başta hata veren aynı adresi yeniden açın. Sorun belirli bir oturumda veya bağlantıda çıktıysa aynı koşulları koruyun.
- Network → Status Code ile yeni yanıtı kontrol edin. Ziyaretçiye açık normal bir sayfada beklenen içerik ve
200yanıtı birlikte görünmelidir. - Önbellekten eski sonuç gelmediğinden emin olun. Gerekirse geliştirici araçları açıkken Disable cache seçeneğini kullanın; CDN önbelleği varsa ilgili adresi ayrıca kontrol edin.
- Yeni saatte aynı hata kaydı oluşup oluşmadığına bakın. Eski kayıtları silmeniz gerekmez.
- Sorun sürerse önceki dosya/izin değerine dönün; başka değişikliği ancak yeni bulguya göre yapın.
Yönlendirmeli veya oturum gerektiren uygulamalarda başarılı akış her adımda 200 vermeyebilir; beklenen son sayfanın ve işlemin çalıştığını kontrol edin. Ödeme veya sipariş gönderimini deneme amacıyla tekrar tekrar yapmayın. Açılmaması gereken özel klasörlerin korumasının da sürdüğünden emin olun.
Destek talebine hangi bilgileri ekleyin?
DCHost müşteri portalından destek talebi açarken şu bilgileri iletin:
- Etkilenen hizmet, tam sayfa adresi ve hata saati/saat dilimi.
- Sorunun herkeste mi, yalnız bir bağlantıda mı veya belirli işlemde mi görüldüğü.
- Son değişiklik ve denediğiniz düzeltme.
- Aynı isteğe ait hata satırı; varsa Rule ID veya istek kimliği.
- IP engeli araştırılıyorsa o anda kullandığınız dış IP adresi; bunu yalnız özel destek talebinde paylaşın.
Parola, oturum çerezi, API anahtarı ve tüm hesap yedeğini mesajın içine koymayın. Destek ekibi, dosya sahipliğini ve müşteri hesabında görünmeyen güvenlik kurallarını kontrol edebilir.
Sık sorulan sorular
403 Forbidden ile 500 hatası aynı mı?
Hayır. 403, isteğe erişimin reddedildiğini; 500, sunucunun isteği beklenmeyen bir sorun nedeniyle tamamlayamadığını belirtir. .htaccess içindeki geçerli bir erişim engeli 403 verebilirken tanınmayan komut 500 oluşturabilir. Yanıt kodu ve aynı saatin günlüğüyle ilerleyin.
Dosyaları yükledim, ana sayfa neden 403 veriyor?
Önce Document Root, yüklediğiniz klasör ve uygulamanın başlangıç dosyasını karşılaştırın. Eksik index dosyasıyla kapalı klasör listeleme bir araya geldiğinde 403 oluşabilir. Klasör listelemeyi açmak yerine dosyaların doğru yapıda yayımlandığını kontrol edin.
İzinler 644 ve 755 ama sorun devam ediyor. Ne yapmalıyım?
Bu değerler tek başına yeterli değildir. Sahiplik, üst klasöre geçiş izni, .htaccess kuralları ve güvenlik katmanları ayrıca etkili olabilir. Aynı dosya yoluna ait günlüğü inceleyin; izinleri rastgele artırmayın.
cPanel açılıyor ama sitem 403 veriyor. Hosting çalışmıyor mu?
cPanel girişiyle web sitenizin isteği farklı işlemlerdir. Panelin açılması site dosyalarının, uygulamanın ve web erişim kurallarının doğru olduğunu göstermez. Sorunlu site adresini ve o isteğin kaydını kontrol edin.
WordPress yönetim paneli 403 veriyorsa nereden başlamalıyım?
Yalnız giriş sayfası mı, yoksa oturum açtıktan sonraki belirli işlem mi engelleniyor, ayırın. Kullanıcı yetkisi, güvenlik eklentisi, .htaccess ve WAF kayıtlarını son değişiklikle birlikte inceleyin. ModSecurity'yi topluca kapatmadan ilgili isteğin neden reddedildiğini bulun.
Resmi kaynaklar
Kaynaklar 15 Ekim 2026 tarihinde kontrol edildi. Menülerin görünümü sürüme ve hosting hesabınızın yetkilerine göre değişebilir.