Nginx Başlamıyor: Konfigürasyon Hatalarını Bulma ve Çözme

Tarafındankomut
0 Comments

Nginx’i yeniden başlatmaya çalışıyorsun, servis bir türlü ayağa kalkmıyor. Terminalde kırmızı yazılar, systemd hata mesajları, belki production ortamında panikle geçen dakikalar… Bu senaryoyu yaşadıysan yalnız değilsin. Nginx konfigürasyon hataları, en deneyimli sysadminlerin bile başını ağrıtabiliyor. Ama iyi haber şu: Nginx, hataları bulmak için son derece iyi araçlara sahip. Sistematik yaklaşırsan sorunu genellikle birkaç dakika içinde tespit edebilirsin.

İlk Adım: systemctl ile Durumu Anlamak

Nginx başlamadığında ilk içgüdün muhtemelen servisi tekrar başlatmaya çalışmak oluyor. Ama önce ne olduğunu anlamak çok daha verimli.

systemctl status nginx

Bu komut sana servisin mevcut durumunu, son birkaç log satırını ve en önemlisi exit code’u gösteriyor. Şuna benzer bir çıktı görürsün:

● nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2024-01-15 14:23:11 UTC; 2min ago
    Process: 12453 ExecStartPre=/usr/sbin/nginx -t (code=exited, status=1/FAILURE)
   Main PID: 12453 (code=exited, status=1/FAILURE)

Jan 15 14:23:11 webserver nginx[12453]: nginx: [emerg] unknown directive "server_nmae" in /etc/nginx/sites-enabled/myapp.conf:8
Jan 15 14:23:11 webserver nginx[12453]: nginx: configuration file /etc/nginx/nginx.conf test failed

Dikkat et, ExecStartPre satırında Nginx’in başlamadan önce nginx -t çalıştırdığını görüyorsun. Bu konfigürasyon test adımı başarısız olduğu için servis hiç başlamıyor. Ve alt satırlarda zaten hatanın ne olduğu yazıyor: server_nmae diye bir direktif yok, doğrusu server_name.

nginx -t: En Temel Silahın

Nginx konfigürasyon sorunlarını debug etmenin en hızlı yolu bu komut:

nginx -t

Ya da tam path ile:

/usr/sbin/nginx -t

Başarılı olduğunda şunu görürsün:

nginx: the configuration file /etc/nginx/nginx.conf syntax is OK
nginx: configuration file /etc/nginx/nginx.conf test is successful

Hata olduğunda ise:

nginx: [emerg] unknown directive "server_nmae" in /etc/nginx/sites-enabled/myapp.conf:8
nginx: configuration file /etc/nginx/nginx.conf test failed

Burada kritik bilgiler var. Dosya adı ve satır numarası doğrudan sana söyleniyor. /etc/nginx/sites-enabled/myapp.conf dosyasının 8. satırına git, orada sorun var.

nginx -t çıktısındaki hata seviyeleri şunlar olabilir:

  • [emerg]: Kritik hata, Nginx kesinlikle başlamaz
  • [warn]: Uyarı, Nginx başlar ama bir şeyler optimal değil
  • [notice]: Bilgi mesajı, sorun yok

journalctl ile Detaylı Log Analizi

systemctl status sana son birkaç satırı gösterir. Ama daha fazlasına ihtiyaç duyarsan journalctl kullan:

journalctl -u nginx --no-pager -n 50

Son 50 satırı görmek için. Ya da son başlatma denemesinden bu yana olan tüm logları için:

journalctl -u nginx --since "1 hour ago"

Çok daha kullanışlı bir versiyon, sadece son boot’taki Nginx loglarını getirir:

journalctl -u nginx -b

Bir de gerçek zamanlı takip etmek istersen, özellikle test yaparken çok işe yarıyor:

journalctl -u nginx -f

Bu komutu açık bırak, başka terminalde systemctl restart nginx çalıştır, hataları anında görürsün.

Yaygın Hata Tipleri ve Çözümleri

Syntax Hataları

Bunlar en kolay bulunanlardır çünkü Nginx sana tam olarak nerede olduklarını söyler.

Noktalı virgül unutmak:

server {
    listen 80
    server_name example.com;  # listen satırında ; yok!
    
    location / {
        root /var/www/html;
    }
}

Bu durumda Nginx şöyle bir hata verir:

nginx: [emerg] invalid parameter "server_name" in /etc/nginx/sites-enabled/myapp.conf:3

Dikkat et, Nginx hata mesajında 3. satırı gösteriyor ama asıl sorun 2. satırda. Çünkü Nginx parser’ı listen 80 bittikten sonra noktalı virgül bekliyor, onu bulamayınca bir sonraki token’ı (server_name) geçersiz parametre olarak algılıyor. Bu yüzden hata mesajındaki satırın bir öncesine de bak.

Kapanmayan süslü parantez:

server {
    listen 80;
    server_name example.com;
    
    location / {
        root /var/www/html;
        # Burada kapanış parantezi eksik
    
}

Hata mesajı genellikle şöyle olur:

nginx: [emerg] unexpected "}" in /etc/nginx/sites-enabled/myapp.conf:9

Ya da dosya sonunda:

nginx: [emerg] unexpected end of file, expecting "}" in /etc/nginx/sites-enabled/myapp.conf:9

Port Çakışmaları

Nginx başlamıyor ama syntax hatası da görmüyorsun? Belki başka bir process aynı portu tutuyor.

ss -tlnp | grep :80

Ya da:

lsof -i :80

Çıktı şuna benziyorsa sorun var:

COMMAND   PID     USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
apache2  1234     root    4u  IPv6  12345      0t0  TCP *:80 (LISTEN)

Apache de port 80’i dinliyor. İkisi birlikte çalışamaz. Ya Apache’yi durdurursun ya da Nginx’i farklı porta alırsın.

systemctl stop apache2
systemctl disable apache2

SSL Sertifika Sorunları

SSL konfigürasyonu yanlışsa Nginx başlamaz. Tipik senaryo şu:

nginx: [emerg] cannot load certificate "/etc/ssl/certs/mysite.crt": BIO_new_file() failed (SSL: error:02001002:system library:fopen:No such file or directory)

Sertifika dosyası yok ya da yanlış path verilmiş. Kontrol et:

ls -la /etc/ssl/certs/mysite.crt
ls -la /etc/ssl/private/mysite.key

Dosyalar varsa izin sorununa bak:

# Sertifika dosyası okunabilir olmalı
chmod 644 /etc/ssl/certs/mysite.crt
# Private key sadece root tarafından okunabilmeli
chmod 600 /etc/ssl/private/mysite.key

Include Dosyası Bulunamadı

nginx.conf içinde include direktifi kullanıyorsan ve o dosyalar yoksa:

nginx: [emerg] open() "/etc/nginx/sites-enabled/*.conf" failed (2: No such file or directory) in /etc/nginx/nginx.conf:62

Bu genellikle Ubuntu/Debian sistemlerinde sites-enabled dizininin boş olmasından kaynaklanır. Konfigürasyon dosyasını kontrol et:

grep -r "include" /etc/nginx/nginx.conf

Eğer include /etc/nginx/sites-enabled/*; varsa ve orada hiç dosya yoksa, Nginx bunu hata olarak görebilir. Çözüm olarak ya wildcard include’u kaldır ya da placeholder bir dosya oluştur.

Nginx Log Dosyalarını Okumak

Nginx iki temel log dosyası kullanır. Bunların nerede olduğunu bulmak için:

grep -E "error_log|access_log" /etc/nginx/nginx.conf

Tipik yerler:

  • /var/log/nginx/error.log
  • /var/log/nginx/access.log

Error log’u canlı takip etmek için:

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

Sadece belirli bir zaman dilimine ait hataları görmek için:

grep "2024/01/15" /var/log/nginx/error.log | grep "[emerg]"

Error log içindeki hata seviyelerini filtrelemek:

# Sadece kritik hatalar
grep "[emerg]" /var/log/nginx/error.log

# Uyarılar dahil
grep -E "[emerg]|[warn]" /var/log/nginx/error.log

# Son 100 hata satırı
grep "[error]" /var/log/nginx/error.log | tail -100

Gerçek Dünya Senaryosu: Upstream Bağlantı Hatası

Diyelim ki bir PHP-FPM uygulaması için Nginx reverse proxy kuruyorsun. Nginx başlıyor ama istekler yanıt vermiyor ve error log’da şunu görüyorsun:

2024/01/15 15:30:22 [error] 1234#1234: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.10, server: example.com, request: "GET / HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000"

PHP-FPM çalışmıyor ya da yanlış portta. Kontrol et:

systemctl status php8.1-fpm
ss -tlnp | grep :9000

PHP-FPM’in socket mi yoksa TCP port mu kullandığına bak:

cat /etc/php/8.1/fpm/pool.d/www.conf | grep "^listen"

Eğer socket kullanıyorsa Nginx konfigürasyonunda bunu yansıtman gerekir:

location ~ .php$ {
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    # Yanlış olan: fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    include fastcgi_params;
}

İzin ve Ownership Sorunları

Nginx worker process’leri genellikle www-data veya nginx kullanıcısı altında çalışır. Bu kullanıcının gerekli dosyalara erişimi yoksa başlayabilir ama çalışmaz.

Nginx’in hangi kullanıcı ile çalıştığını bul:

grep "^user" /etc/nginx/nginx.conf

Web root dizininin izinlerini kontrol et:

ls -la /var/www/html/

Nginx kullanıcısına uygun izinleri ver:

chown -R www-data:www-data /var/www/html/
find /var/www/html/ -type d -exec chmod 755 {} ;
find /var/www/html/ -type f -exec chmod 644 {} ;

SELinux veya AppArmor çalışan sistemlerde ise durum daha karmaşık. Ubuntu’da AppArmor profili sorun çıkarıyorsa:

aa-status | grep nginx

Konfigürasyonu Daha Detaylı Test Etmek

nginx -t temel test için yeterli. Ama bazen daha fazlasına ihtiyaç duyarsın. Nginx’i tam debug modunda çalıştırabilirsin:

nginx -T

Bu komut tüm konfigürasyon dosyalarını dahil edilmiş halleriyle birlikte ekrana döküyor. Hangi dosyanın nereye include edildiğini görmek için mükemmel. Çıktı uzun olacağından less ile kullan:

nginx -T | less

Belirli bir konfigürasyon dosyasını test etmek istiyorsan:

nginx -t -c /etc/nginx/sites-available/myapp.conf

Ama dikkat: bu şekilde test ettiğinde include direktifleri düzgün çalışmayabilir. En sağlıklısı ana nginx.conf üzerinden test etmek.

Sistemin Genel Sağlık Durumunu Kontrol Et

Bazen sorun Nginx’te değil, sistemin genel durumundadır.

Bellek kontrolü:

free -h

Disk dolu mu:

df -h /var/log/nginx/

Log dosyaları bazen inanılmaz boyutlara ulaşabiliyor ve disk dolarsa Nginx yeni log yazamaz, bu da sorun yaratabilir.

Açık dosya limiti:

ulimit -n
cat /proc/sys/fs/file-max

Yüksek trafikli sistemlerde Nginx’in açabileceği dosya sayısı sisteme bağlı limitlerle kısıtlanabilir. /etc/nginx/nginx.conf içinde worker_rlimit_nofile direktifine bak.

Nginx Konfigürasyonu Geri Almak

Konfigürasyon değişikliği yaptın, Nginx çöktü ve ne değiştirdiğini bilmiyorsun. Bu durumda git kullanıyorsan işin kolay:

cd /etc/nginx
git diff
git stash  # Değişiklikleri geri al
systemctl start nginx

Eğer git kullanmıyorsan, bu olaydan sonra muhtemelen kullanmaya başlarsın. Ama acil çözüm olarak son yedekten geri dön:

cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf
nginx -t && systemctl start nginx

Bu yüzden her büyük değişiklikten önce yedek al:

cp /etc/nginx/sites-enabled/myapp.conf /etc/nginx/sites-enabled/myapp.conf.bak.$(date +%Y%m%d_%H%M%S)

Upstream ve Proxy Konfigürasyon Sorunları

Nginx’i load balancer veya reverse proxy olarak kullanıyorsan upstream blokları sorun yaratabilir:

upstream backend {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    server 192.168.1.12:8080;
}

Eğer bu IP’lerden hiçbirine ulaşılamıyorsa ve max_fails ayarı yoksa Nginx başlar ama istekler hata verir. Bu durumda error log’da şunu görürsün:

upstream timed out (110: Connection timed out) while connecting to upstream

Debug için upstream sunuculara Nginx makinasından bağlantıyı test et:

curl -v http://192.168.1.10:8080/
telnet 192.168.1.10 8080

Pratik Debug Checklist

Bir sonraki Nginx acilinde hızlıca geçebileceğin adımlar şunlar:

  • systemctl status nginx ile genel durumu gör
  • nginx -t ile konfigürasyon syntax kontrolü yap
  • journalctl -u nginx -n 100 ile son logları incele
  • tail -f /var/log/nginx/error.log ile error log’a bak
  • ss -tlnp | grep ':80|:443' ile port çakışmasını kontrol et
  • ls -la ile sertifika ve web root dosyalarının varlığını doğrula
  • df -h ile disk durumunu kontrol et
  • nginx -T ile tüm konfigürasyonu dök ve incele

Sonuç

Nginx konfigürasyon sorunları başlangıçta korkutucu gözükse de aslında son derece sistematik bir şekilde çözülebilir. Nginx’in hata mesajları diğer birçok servise kıyasla çok daha bilgilendirici. Dosya adı ve satır numarasını doğrudan söylüyor.

En büyük tuzak ise paniğe kapılıp rastgele değişiklikler yapmak. Sistematik yaklaş: önce nginx -t, sonra journalctl, sonra error log. Bu üç adım sorunların büyük çoğunluğunu ortaya çıkarır.

Üretim ortamında her zaman konfigürasyon değişikliklerini version control altında tut ve değişiklik yapmadan önce yedek al. nginx -t başarılı olana kadar asla systemctl restart nginx çalıştırma. Bu iki alışkanlık seni bir sürü gece yarısı krizinden kurtarır.

Son olarak, sık yaşadığın sorunlar için kendi notlarını tut. Her ortam biraz farklı davranır ve zaman içinde kendi sisteminin özelliklerini çok daha iyi tanımaya başlarsın.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir