Nginx 403 Forbidden Hatası Nasıl Çözülür? Nedenleri ve Çözümleri

Nginx 403 Forbidden hatası, sunucunun isteği aldığını ancak ilgili kaynağa erişime izin vermediğini gösterir. En sık nedenler yanlış dosya ve klasör izinleri, Nginx kullanıcısının dosyalara erişememesi, hatalı root veya alias yapılandırması, dizinde index dosyasının bulunmaması ve erişimi engelleyen Nginx kurallarıdır.

Sorunu çözmek için izinleri rastgele 777 yapmak yerine önce 403 hatasının neden oluştuğunu belirlemek gerekir.

İlk olarak Nginx error logunu kontrol edin

403 hatasının gerçek nedeni çoğu zaman Nginx error logunda görülebilir.

Yaygın log konumu:

/var/log/nginx/error.log

Son kayıtları görmek için:

sudo tail -n 100 /var/log/nginx/error.log

Canlı takip için:

sudo tail -f /var/log/nginx/error.log

kullanabilirsiniz.

403 veren sayfayı tekrar açtığınızda logda oluşan yeni kaydı inceleyin.

Nginx yapılandırmasını test edin

Yapılandırmanın geçerli olup olmadığını kontrol etmek için:

sudo nginx -t

kullanın.

Yapılandırma doğruysa değişiklik sonrasında:

sudo systemctl reload nginx

kullanılabilir.

Üretim sunucusunda yapılandırmayı test etmeden Nginx'i restart etmekten kaçınmak daha güvenlidir.

Dosya gerçekten mevcut mu?

Örneğin Nginx:

root /var/www/site;

kullanıyorsa ilgili dosyaların gerçekten bu dizinde bulunup bulunmadığını kontrol edin:

ls -lah /var/www/site

Dosya mevcut olsa bile Nginx kullanıcısının dosyaya ulaşabilmesi için üst dizinlerin izinlerinin de uygun olması gerekir.

Dosya izinleri nasıl kontrol edilir?

Örneğin:

ls -l /var/www/site

kullanabilirsiniz.

Bir dosya için:

stat /var/www/site/index.html

komutu daha ayrıntılı bilgi gösterebilir.

Genel olarak web sunucusunun statik dosyaları okuyabilmesi gerekir.

Ancak hangi kullanıcı ve grup yapısının kullanılacağı sunucunun yapılandırmasına göre değişebilir.

Klasör izinleri neden önemlidir?

Nginx yalnızca hedef dosyayı okumakla kalmaz, dosyaya ulaşabilmek için yol üzerindeki dizinlerden geçebilmelidir.

Örneğin:

/var/www/site/public/index.html

dosyasının kendisi okunabilir olsa bile üst dizinlerden birine erişim yoksa 403 oluşabilir.

Yol üzerindeki izinleri incelemek için uygun sistemlerde:

namei -l /var/www/site/public/index.html

oldukça kullanışlıdır.

Bu komut yol üzerindeki her dizinin izinlerini ayrı ayrı görmenize yardımcı olur.

chmod 777 çözüm mü?

Genellikle hayır.

İzin problemi görüldüğünde internette sıkça:

chmod -R 777

önerisiyle karşılaşılır.

Bu yaklaşım özellikle production sunucularında ciddi güvenlik sorunları oluşturabilir.

Sorun yalnızca okuma veya dizine erişim izni ise gerekli minimum izinler verilmelidir.

Her şeyi 777 yapmak yerine doğru kullanıcı, grup ve izin yapısını belirleyin.

Nginx hangi kullanıcıyla çalışıyor?

Nginx worker process'lerinin hangi kullanıcı altında çalıştığını kontrol etmek için:

ps aux | grep nginx

kullanabilirsiniz.

Ubuntu ve Debian sistemlerinde sıklıkla www-data görülebilir ancak bunu varsaymak yerine kendi sunucunuzda doğrulayın.

Nginx yapılandırmasındaki kullanıcı bilgisi de incelenebilir.

Dosya sahipliği nasıl kontrol edilir?

Örneğin:

ls -lah /var/www/site

çıktısında dosya ve klasörlerin owner ve group bilgileri görülür.

Yanlış sahiplik bazı durumlarda erişim sorunlarına neden olabilir.

Ancak tüm siteyi düşünmeden:

chown -R

ile başka bir kullanıcıya geçirmek doğru değildir.

Özellikle uygulamanın yazması gereken upload, cache veya runtime dizinleri varsa izin modeli ayrıca değerlendirilmelidir.

Dizinde index dosyası yoksa 403 oluşabilir

Örneğin kullanıcı:

https://site.com/

adresine giriyor ve Nginx'in web kökünde:

index.html

veya yapılandırmada tanımlanan başka bir index dosyası bulunmuyorsa dizin listeleme kapalı olduğu için 403 görülebilir.

Nginx yapılandırmasında örneğin:

index index.html index.htm;

gibi bir ayar bulunabilir.

Gerçek dosyanın mevcut olup olmadığını kontrol edin.

Directory index of ... is forbidden hatası

Nginx error logunda:

directory index of ... is forbidden

benzeri bir mesaj görüyorsanız genellikle istenen dizinde uygun bir index dosyası bulunmuyordur ve directory listing kapalıdır.

Çözüm ihtiyaca göre:

- Doğru index dosyasını oluşturmak

- index ayarını düzeltmek

- Doğru web kökünü kullanmak

olabilir.

Directory listing'i yalnızca 403'ü ortadan kaldırmak amacıyla açmak her zaman doğru değildir.

autoindex nedir?

Nginx'te:

autoindex on;

kullanıldığında uygun yapılandırmada dizin içerisindeki dosyalar ziyaretçiye listelenebilir.

Bu özellik bazı dosya sunucularında bilinçli olarak kullanılabilir.

Ancak normal web sitelerinde yanlışlıkla etkinleştirilmesi:

- Yedek dosyalarının

- Özel dosyaların

- Kullanıcı yüklemelerinin

- İç klasörlerin

görünmesine neden olabilir.

Bu yüzden yalnızca 403 sorununu çözmek amacıyla autoindex on eklemek önerilmez.

root ayarı yanlış olabilir

Örneğin gerçek site dosyaları:

/var/www/site/public

altındayken yapılandırmada:

root /var/www/site;

kullanılıyorsa istekler yanlış dizine gidebilir.

Aktif Nginx yapılandırmasını görmek için:

sudo nginx -T

kullanabilirsiniz.

Bu sayede hangi server ve location bloklarının gerçekten yüklendiğini görebilirsiniz.

Yanlış server bloğu çalışıyor olabilir

Aynı sunucuda birden fazla domain bulunuyorsa server_name ayarları önemlidir.

Örneğin:

server_name example.com www.example.com;

yanlış veya eksikse istek başka bir server bloğuna düşebilir.

Bunun sonucunda beklenmeyen bir web kökü veya erişim kuralı uygulanabilir.

location bloğunda erişim engellenmiş olabilir

Nginx yapılandırmasında belirli yollar için erişim bilinçli olarak kapatılmış olabilir.

Örneğin yapılandırmaya bağlı olarak:

deny all;

kullanılması erişimi engeller.

Bu tür kurallar:

- Admin alanları

- Gizli dosyalar

- İç servisler

- Belirli dizinler

için bilinçli olarak eklenmiş olabilir.

403'ü çözmek için güvenlik kuralını doğrudan kaldırmadan önce neden bulunduğunu öğrenin.

IP kısıtlamalarını kontrol edin

Nginx belirli IP adreslerine izin verip diğerlerini engelleyecek şekilde yapılandırılabilir.

Örneğin allow ve deny kuralları kullanılıyorsa sizin IP adresiniz izin verilen listede bulunmayabilir.

Bu durumda site herkeste değil yalnızca belirli kullanıcılarda 403 verebilir.

Gizli dosyalara erişim bilinçli olarak engellenebilir

.env, .git veya hassas yapılandırma dosyalarının web üzerinden erişilebilir olmaması gerekir.

Örneğin:

https://site.com/.env

403 veya 404 döndürüyorsa bunu otomatik olarak düzeltilmesi gereken bir problem olarak değerlendirmeyin.

Bazı 403 cevapları güvenlik amacıyla bilinçli olarak oluşturulur.

alias kullanıyorsanız yapılandırmayı kontrol edin

Belirli URL'leri başka bir klasöre bağlamak için alias kullanılabilir.

Yanlış:

- Dosya yolu

- Slash kullanımı

- Location eşleşmesi

- Dosya izinleri

403 veya 404 gibi sonuçlara neden olabilir.

root ve alias aynı davranışa sahip değildir. Bu nedenle yapılandırmayı sitenin gerçek dosya yapısına göre kontrol edin.

Reverse proxy kullanılan sitede 403 nereden geliyor?

Nginx Node.js, Python veya başka bir backend'e reverse proxy yapıyorsa 403 cevabı backend uygulamasından da geliyor olabilir.

Örneğin backend:

127.0.0.1:3000

üzerinde çalışıyorsa doğrudan:

curl -i http://127.0.0.1:3000/istenen-yol

ile test edilebilir.

Backend de 403 döndürüyorsa problem:

- Authentication

- Authorization

- CSRF

- Uygulama güvenlik kuralı

- IP kısıtlaması

gibi uygulama katmanında olabilir.

Bu durumda yalnızca Nginx izinlerini değiştirmek çözüm değildir.

Nginx mi backend mi 403 veriyor nasıl anlaşılır?

Önce dış URL'yi test edin:

curl -I https://site.com/istenen-yol

Ardından backend'i doğrudan test edin:

curl -i http://127.0.0.1:3000/istenen-yol

Ayrıca Nginx access ve error loglarını inceleyin.

Bu karşılaştırma 403'ün hangi katmanda üretildiğini anlamayı kolaylaştırır.

SELinux 403 sorununa neden olabilir mi?

SELinux kullanılan sistemlerde klasik Unix dosya izinleri doğru görünmesine rağmen güvenlik politikası Nginx'in belirli dosyalara erişmesini engelleyebilir.

Bu durum özellikle RHEL, CentOS, AlmaLinux, Rocky Linux gibi SELinux kullanılan ortamlarda araştırılması gereken ihtimallerden biridir.

SELinux'u yalnızca sorunu çözmek amacıyla tamamen kapatmak yerine logları ve gerekli context/policy yapılandırmasını incelemek daha güvenlidir.

403 ile 404 arasındaki fark nedir?

403 Forbidden: Sunucu isteği anlıyor ancak erişime izin vermiyor.

404 Not Found: İstenen kaynak bulunamıyor veya route tanımlı değil.

Ancak bazı sistemler güvenlik amacıyla var olan bir kaynağı gizlemek için 404 döndürebilir. Bu nedenle yalnızca durum koduna değil loglara ve yapılandırmaya da bakılmalıdır.

403 ile 401 arasındaki fark nedir?

Genel olarak:

401 Unauthorized: Kimlik doğrulama gerekli veya geçerli authentication bilgisi bulunmuyor.

403 Forbidden: İstek anlaşılmış olsa da erişim izni verilmiyor.

Uygulama tarafında bu kodların nasıl kullanıldığı projeye göre değişebilir.

Nginx 403 sorunu için hızlı kontrol sırası

403 hatasında şu sırayla ilerleyebilirsiniz:

1. Hatanın oluştuğu tam URL'yi belirleyin.

2. /var/log/nginx/error.log kayıtlarını kontrol edin.

3. sudo nginx -t çalıştırın.

4. sudo nginx -T ile aktif yapılandırmayı inceleyin.

5. root veya alias yolunun doğru olduğunu doğrulayın.

6. Dosyanın gerçekten mevcut olduğunu kontrol edin.

7. Dosya ve üst dizinlerin izinlerini inceleyin.

8. Nginx'in hangi kullanıcıyla çalıştığını kontrol edin.

9. Index dosyasının mevcut olup olmadığına bakın.

10. deny, allow ve diğer erişim kurallarını inceleyin.

11. Reverse proxy varsa backend'i doğrudan test edin.

12. SELinux kullanılan sistemlerde güvenlik politikasını da araştırın.

13. Değişiklik sonrasında nginx -t başarılıysa reload yapın.

Sık yapılan hatalar

Nginx 403 hatası çözülürken şu hatalardan kaçının:

- Doğrudan chmod -R 777 kullanmak

- Tüm dosyaların sahipliğini rastgele değiştirmek

- Error logunu kontrol etmemek

- Index dosyasının eksik olduğunu fark etmemek

- root ve alias farkını gözden kaçırmak

- Güvenlik için eklenmiş deny kurallarını bilinçsizce kaldırmak

- .env gibi hassas dosyaları erişilebilir hale getirmek

- Backend tarafından üretilen 403'ü Nginx hatası sanmak

- SELinux'u doğrudan devre dışı bırakmak

- nginx -t çalıştırmadan yapılandırmayı yeniden yüklemek

Özetle, Nginx 403 Forbidden hatasında ilk yapılması gereken işlem izinleri 777 yapmak değil, Nginx error logunu kontrol ederek erişimin neden reddedildiğini belirlemektir.

Sorunu güvenli şekilde çözmek için loglar → aktif Nginx yapılandırması → root veya alias → dosya ve dizin izinleri → erişim kuralları → backend sırasıyla kontrol edilmelidir.