Nginx 404 Not Found Hatası Nasıl Çözülür? Nedenleri ve Çözümleri

Nginx 404 Not Found hatası, istenen URL için Nginx'in veya arkasındaki uygulamanın uygun bir dosya ya da route bulamadığını gösterir. Sorun yanlış root ayarı, hatalı location bloğu, eksik dosya, yanlış server_name, SPA yönlendirmesi veya backend uygulamasındaki route nedeniyle oluşabilir.

İlk olarak şu ayrımı yapmak önemlidir:

404 cevabını gerçekten Nginx mi veriyor, yoksa Node.js, PHP veya başka bir backend uygulaması mı?

Çünkü çözüm buna göre değişir.

Önce Nginx yapılandırmasını test edin

Yapılandırmada syntax hatası olup olmadığını kontrol etmek için:

sudo nginx -t

kullanın.

Yapılandırma doğruysa buna benzer bir sonuç alınır:

syntax is ok

test is successful

Değişiklik yaptıktan sonra yapılandırmayı yeniden yüklemek için:

sudo systemctl reload nginx

kullanılabilir.

nginx -t başarılı olmadan Nginx'i reload veya restart etmekten kaçınmak daha güvenlidir.

Dosya gerçekten mevcut mu?

Örneğin kullanıcı:

https://site.com/about.html

adresine giriyor ancak Nginx'in kullandığı web dizininde about.html bulunmuyorsa 404 hatası alınabilir.

Dosyanın varlığını:

ls -lah /var/www/site

ile kontrol edebilirsiniz.

Gerçek web dizininizin yolu farklı olabilir.

Nginx root ayarını kontrol edin

Nginx yapılandırmasında:

root /var/www/site;

gibi bir satır bulunabilir.

Eğer dosyalar gerçekte:

/var/www/metin2up/public

altındaysa ancak Nginx:

/var/www/html

klasörünü kullanıyorsa istenen dosya bulunamayabilir.

Aktif yapılandırmayı görmek için:

sudo nginx -T

kullanılabilir.

Bu komut Nginx tarafından yüklenen yapılandırmayı görmenize yardımcı olur.

server_name doğru mu?

Virtual host yapılandırmasında:

server_name example.com www.example.com;

gibi bir tanım bulunabilir.

Alan adı yanlış server bloğuna düşüyorsa beklemediğiniz bir web kökü veya varsayılan site çalışabilir.

Özellikle aynı sunucuda birden fazla site bulunuyorsa server_name ayarlarını dikkatlice kontrol edin.

Yanlış Nginx config dosyasını düzenliyor olabilirsiniz

Ubuntu ve Debian tabanlı sistemlerde yaygın olarak:

/etc/nginx/sites-available/

ve:

/etc/nginx/sites-enabled/

dizinleri kullanılır.

Bir dosyayı sites-available içerisinde değiştirmiş olmanız onun mutlaka aktif olduğu anlamına gelmez.

Aktif yapılandırmayı doğrulamak için:

sudo nginx -T

oldukça faydalıdır.

Böylece Nginx'in gerçekte hangi yapılandırmayı yüklediğini görebilirsiniz.

location bloğu 404 oluşturabilir

Örneğin:

location /api/ { ... }

ve:

location / { ... }

blokları farklı şekilde davranabilir.

Ana sayfa açılırken:

/api/users

veya:

/konu/ornek-konu

404 veriyorsa ilgili location eşleşmelerini kontrol etmek gerekir.

Nginx'in location eşleştirme kuralları nedeniyle beklediğinizden farklı bir blok isteği işliyor olabilir.

Node.js uygulamasında 404 hatası

Nginx reverse proxy olarak kullanılıyorsa 404 cevabı backend uygulamasından geliyor olabilir.

Örneğin Nginx:

proxy_pass http://127.0.0.1:3000;

ile Node.js uygulamasına istek gönderiyorsa backend'in route'u tanımaması 404 üretebilir.

Backend'i doğrudan test etmek için:

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

kullanılabilir.

Burada da 404 alıyorsanız problem büyük ihtimalle Nginx'ten değil backend route'undan kaynaklanıyordur.

Nginx ve backend'i ayrı ayrı test edin

Örneğin:

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

ile dışarıdan görülen cevabı kontrol edin.

Ardından backend:

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

ile test edilebilir.

Bu ayrım problemi çok daha hızlı bulmanızı sağlar.

proxy_pass kullanırken URL davranışına dikkat edin

Nginx yapılandırmasındaki proxy_pass satırında kullanılan URI ve sondaki / işareti, backend'e gönderilen yolun nasıl oluşturulacağını etkileyebilir.

Örneğin /api/ altında çalışan bir location için yanlış proxy_pass yapılandırması backend'e beklenmeyen bir URL gönderebilir.

Sonuç olarak backend route'u bulamaz ve 404 döndürebilir.

Bu nedenle reverse proxy sorunlarında backend'in gerçekte hangi URL'yi aldığını kontrol etmek önemlidir.

SPA sitelerinde yenileyince 404 sorunu

React, Vue veya benzeri client-side routing kullanan uygulamalarda sık görülen bir durumdur.

Örneğin:

/profil

adresine uygulama içerisinden geçiş yaptığınızda sayfa açılır.

Ancak tarayıcıyı yenilediğinizde Nginx fiziksel olarak /profil isimli bir dosya veya klasör arayabilir ve 404 verebilir.

SPA yapısına uygun durumlarda örneğin:

try_files $uri $uri/ /index.html;

benzeri bir fallback kullanılabilir.

Ancak bu ayar her site için doğru değildir.

Özellikle gerçek 404 sayfalarının ve SEO açısından bulunmayan URL'lerin gerçekten 404 döndürmesi gereken projelerde bütün istekleri kontrolsüz biçimde index.html dosyasına yönlendirmek yanlış sonuçlara yol açabilir.

try_files nedir?

try_files, Nginx'in istenen kaynakları belirli bir sırayla kontrol etmesini sağlar.

Örneğin:

try_files $uri $uri/ =404;

önce istenen dosyayı, ardından dizini kontrol eder; hiçbiri yoksa 404 döndürür.

SPA uygulamalarında davranış farklı yapılandırılabilir.

Kullanacağınız yöntem sitenin mimarisine göre belirlenmelidir.

Clean URL kullanırken 404 oluşabilir

Bir forum veya içerik sitesinde:

/konu/ornek-baslik

gibi temiz URL'ler kullanılıyorsa bu adreslerin uygulama tarafından karşılanması gerekir.

Nginx bu URL'yi fiziksel klasör olarak arıyorsa 404 oluşabilir.

Bu durumda isteğin backend uygulamasına aktarılması veya kullanılan mimariye uygun route yapılandırmasının yapılması gerekir.

Ana sayfa açılıyor ama alt sayfalar 404 veriyor

Bu durum özellikle şu nedenlerle oluşabilir:

- SPA fallback eksik

- Backend route eksik

- Yanlış location

- Hatalı try_files

- Rewrite kuralı problemi

- Yanlış proxy yönlendirmesi

- Uygulama deploy edilirken bazı dosyaların eksik kalması

Ana sayfanın açılması Nginx yapılandırmasının tamamının doğru olduğunu garanti etmez.

Dosya adı büyük küçük harf farkına dikkat edin

Linux dosya sistemlerinde:

Logo.png

ile:

logo.png

aynı dosya değildir.

HTML içerisinde:

/images/logo.png

istenirken gerçek dosya:

/images/Logo.png

ise 404 alınabilir.

Windows ortamında çalışan bir projenin Linux sunucuya taşınmasından sonra bu tür sorunlar daha belirgin hale gelebilir.

Statik dosyalar 404 veriyorsa

CSS, JavaScript veya görseller 404 veriyorsa:

- Dosyanın gerçekten mevcut olduğunu

- URL yolunun doğru olduğunu

- root veya alias ayarını

- Build çıktısının doğru dizine gönderildiğini

- Büyük küçük harf kullanımını

kontrol edin.

Tarayıcı geliştirici araçlarındaki Network bölümü hangi dosyanın 404 aldığını bulmaya yardımcı olabilir.

root ve alias aynı şey değildir

Nginx'te root ve alias benzer amaçlarla kullanılabilse de istek yolunu dosya sistemine eşlerken farklı davranırlar.

Yanlış alias yapılandırması özellikle belirli klasörlerdeki statik dosyaların 404 vermesine neden olabilir.

Bu nedenle internetten rastgele bir location örneğini kopyalamak yerine URL ile gerçek dosya yolu arasındaki eşleşmeyi kontrol edin.

Dosya mevcut ama yine de 404 veriyorsa

Şunları kontrol edin:

1. Nginx gerçekten doğru server bloğunu mu kullanıyor?

2. root doğru mu?

3. location isteği başka şekilde yakalıyor mu?

4. try_files nasıl davranıyor?

5. alias kullanılıyor mu?

6. Dosya adında büyük küçük harf farkı var mı?

7. Reverse proxy kullanılıyorsa 404 backend'den mi geliyor?

Ayrıca Nginx error loglarını inceleyin.

Nginx error log nasıl kontrol edilir?

Yaygın konum:

/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

kullanılabilir.

Siteye özel log yolu yapılandırılmışsa dosyanın konumu farklı olabilir.

Access log da faydalıdır

İsteklerin Nginx'e gelip gelmediğini görmek için:

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

kullanabilirsiniz.

Burada:

- İstenen URL

- HTTP durum kodu

- İstek zamanı

- İstemci bilgileri

gibi kayıtlar bulunabilir.

404 veren gerçek URL'yi görmek özellikle önemlidir.

404 ile 403 arasındaki fark

404 Not Found: İstenen kaynak bulunamadı veya uygulama bu route'u tanımıyor.

403 Forbidden: Kaynak bulunabilir ancak erişim reddediliyor.

Dosya izinleri çoğunlukla 403 ile ilişkilendirilse de yapılandırmaya bağlı farklı davranışlar görülebilir.

Bu nedenle HTTP durum kodunu doğru teşhis etmek önemlidir.

404 ile 502 arasındaki fark

404: Kaynak veya route bulunamıyor.

502: Nginx backend'den geçerli bir yanıt alamıyor veya backend'e bağlanamıyor.

Node.js uygulaması tamamen kapalıysa genellikle 404 yerine 502 gibi bir gateway problemi beklenir.

Backend çalışıyor ancak ilgili route mevcut değilse 404 görülebilir.

Eski URL'ler 404 veriyorsa ne yapılmalı?

Bir sayfanın adresi kalıcı olarak değiştirildiyse ve yeni karşılığı varsa uygun bir 301 yönlendirme kullanılabilir.

Örneğin:

Eski:

/thread.html?id=123

Yeni:

/konu/ornek-konu

gibi bir URL yapısına geçilmişse eski adreslerin doğru yeni sayfaya yönlendirilmesi kullanıcı deneyimi ve SEO açısından önemlidir.

Ancak her 404 URL'yi ana sayfaya yönlendirmek doğru değildir.

Gerçekten bulunmayan sayfaların 404 olarak kalması gerekebilir.

Özel 404 sayfası kullanılabilir

404 oluşmasını tamamen engellemek yerine kullanıcıya faydalı bir hata sayfası göstermek daha doğru olabilir.

Özel 404 sayfasında:

- Ana sayfaya dönüş

- Arama alanı

- Popüler içerikler

- Kategoriler

gibi seçenekler sunulabilir.

Ancak sayfa görsel olarak özel olsa bile gerçekten bulunmayan URL'nin HTTP durum kodunun 404 olarak kalması önemlidir.

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

Şu sırayla ilerleyebilirsiniz:

1. 404 veren tam URL'yi belirleyin.

2. curl ile HTTP cevabını kontrol edin.

3. Dosya veya route gerçekten mevcut mu kontrol edin.

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

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

6. server_name ve root ayarlarını kontrol edin.

7. location, try_files ve varsa alias kurallarını inceleyin.

8. Reverse proxy kullanıyorsanız backend'i doğrudan test edin.

9. Nginx access ve error loglarını kontrol edin.

10. Değişiklik yaptıysanız önce nginx -t, ardından kontrollü şekilde reload yapın.

Sık yapılan hatalar

Nginx 404 problemi çözülürken şu hatalardan kaçının:

- Her 404 sorununu Nginx kaynaklı sanmak

- Dosyanın gerçekten mevcut olup olmadığını kontrol etmemek

- Yanlış config dosyasını düzenlemek

- server_name ayarını gözden kaçırmak

- root ile alias davranışını karıştırmak

- Backend route'unu test etmemek

- SPA için yanlış fallback kullanmak

- Bütün 404 sayfalarını ana sayfaya 301 yönlendirmek

- nginx -t çalıştırmadan yapılandırmayı reload etmek

- Nginx loglarını incelememek

Özetle, Nginx 404 Not Found hatasını çözmenin en önemli adımı 404 cevabının hangi katmanda üretildiğini belirlemektir. Statik dosya sunuluyorsa dosya yolu ve Nginx yapılandırması, reverse proxy kullanılıyorsa backend route'ları ayrıca kontrol edilmelidir.

Doğru teşhis için URL → aktif Nginx yapılandırması → dosya veya route → backend → loglar sırasıyla ilerlemek, rastgele ayar değiştirmekten çok daha güvenli ve hızlıdır.