Linux’ta Nginx Nasıl Yönetilir: Başlatma, Durdurma, Yeniden Başlatma ve Yeniden Yükleme

Nginx, dünya genelinde milyonlarca üretim ortamuna hizmet veren yüksek performanslı, olay güdümlü bir web sunucusu ve ters proxy’dir. Yaşam döngüsünün yönetimi — başlatma, durdurma, yeniden başlatma ve yeniden yükleme — Linux init sisteminiz aracılığıyla kontrol edilir; bu sistem ya systemd (Ubuntu 16.04+, CentOS 7+, Debian 8+) ya da eski SysVinit çerçevesidir. restart ile reload arasındaki kritik fark kozmetik değildir: yeniden başlatma tüm aktif bağlantıları sonlandırırken, yeniden yükleme eski worker process’leri nazikçe boşaltmadan önce yeni worker process’leri çatallayarak sıfır kesinti süreli yapılandırma değişimi gerçekleştirir.

Bu kılavuz, ihtiyaç duyduğunuz her operasyonel komutu, her birinin temel mekaniklerini, uçuş öncesi yapılandırma doğrulamasını, log tabanlı tanılamayı ve üretimde sessiz hatalara yol açan uç durumları kapsamaktadır.

Ön Koşullar

Herhangi bir Nginx yönetim komutu vermeden önce aşağıdakileri doğrulayın:

• Root erişimine veya sudo ayrıcalıklarına sahip bir kullanıcı hesabına sahipsiniz.
• Nginx kurulu (nginx -v bir sürüm dizesi döndürmelidir).
• Dağıtımınızın hangi init sistemini kullandığını biliyorsunuz (systemctl --version systemd’yi doğrular; yokluğu SysVinit veya başka bir yönetici kullandığını gösterir).

Yeni bir sunucu hazırlıyorsanız, Ubuntu 22.04 LTS veya Debian 12 çalıştıran bir VPS Hosting ortamı varsayılan olarak systemd kullanacaktır; bu, tüm yeni dağıtımlar için önerilen yoldur.

Nginx Process Modelini Anlamak

Nginx, bir master process ve bir veya daha fazla worker process olarak çalışır. Master process yapılandırmayı okur, ayrıcalıklı portlara (80, 443) bağlanır ve worker yaşam döngüsünü yönetir. Worker’lar gerçek istemci bağlantılarını işler. Bu mimari, reload‘ın üretim için neden güvenli olduğunu açıklar: master, mevcut worker’lar uçuştaki istekleri sunmayı bitirip temiz bir şekilde çıkana kadar güncellenmiş yapılandırmayla yeni worker’lar oluşturur.

Sert bir restart verdiğinizde, master process’in kendisi sonlanır ve yeniden başlar; tüm açık bağlantılar düşürülür. Bunu yalnızca master process’in kendisinin kötü bir durumda olduğu veya ikili yükseltmelerden sonraki durumlar için saklayın.

systemd ile Nginx Yönetimi (Modern Linux Dağıtımları)

systemd, tüm çağdaş Linux dağıtımlarında standart servis yöneticisidir. Nginx, genellikle /lib/systemd/system/nginx.service konumunda bulunan bir birim dosyası aracılığıyla systemd ile entegre olur.

Nginx’i Başlatma

sudo systemctl start nginx

Bu, Nginx servis birimini etkinleştirir. Master process bir porta bağlanamaz veya bir yapılandırma hatasıyla karşılaşırsa, systemd hemen bir hata bildirir. Çıkış kodunu echo $? ile kontrol edin — sıfır olmayan bir değer başlatmanın başarısız olduğu anlamına gelir.

Nginx’i Durdurma

sudo systemctl stop nginx

Bu, Nginx master process’ine SIGTERM gönderir; master process daha sonra worker’lara kapanmadan önce aktif istekleri bitirmeleri için sinyal verir. Worker’lar yapılandırılmış zaman aşımı içinde çıkmazsa, systemd SIGKILL gönderir. Yoğun bir sunucuda bu, bağlantıların düşmesine neden olabilir — mümkün olduğunda bunun yerine reload kullanın.

Nginx’i Yeniden Başlatma

sudo systemctl restart nginx

Yeniden başlatma, sıralı bir durdurma ve ardından başlatma işlemidir. Tüm aktif bağlantılar sonlandırılır. Bunu yalnızca şu durumlarda kullanın:

• Nginx ikili dosyasının kendisi güncellendiğinde.
• Master process yanıt vermediğinde.
• Dinleme soketlerini serbest bırakıp yeniden bağlamanız gerektiğinde (örn. port değişikliğinden sonra).

Yeniden başlatmadan önce her zaman bir yapılandırma testi çalıştırın (aşağıdaki Doğrulama bölümünde ele alınmıştır).

Nginx’i Yeniden Yükleme (Sıfır Kesinti Süreli Yapılandırma Uygulama)

sudo systemctl reload nginx

Bu, üretimde yapılandırma değişikliklerini uygulamak için doğru komuttur. Dahili olarak, systemd Nginx master process’ine SIGHUP gönderir. Master, nginx.conf‘ı yeniden okur, doğrular ve yeni worker process’leri çatalar. Eski worker’lar mevcut bağlantıları sunmaya devam eder, boşta kalana kadar bekler, ardından çıkar. Tüm geçiş son kullanıcılar için sorunsuz gerçekleşir.

Kritik uç durum: Yeni yapılandırma bir hata içeriyorsa, reload bazı dağıtımlarda sessizce başarısız olabilir — eski yapılandırma aktif kalır, ancak terminale hiçbir hata yansıtılmaz. Bu nedenle her yeniden yüklemeden önce nginx -t ile ön doğrulama zorunludur.

Nginx Durumunu Kontrol Etme

sudo systemctl status nginx

Bu komut, servis durumunu (active (running), inactive (dead), failed), master process’in PID’ini, bellek ve CPU kullanımını ve journal log’unun son birkaç satırını gösterir. Herhangi bir Nginx sorunu için en hızlı ilk adım tanılamasıdır.

Sağlıklı bir örnek için örnek çıktı:

● nginx.service - A high performance web server and a reverse/proxy server
     Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-01-13 10:22:04 UTC; 2h 15min ago
       Docs: man:nginx(8)
    Process: 1234 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on;
   Main PID: 1235 (nginx)
      Tasks: 3 (limit: 4915)
     Memory: 6.4M
        CPU: 312ms
     CGroup: /system.slice/nginx.service
             ├─1235 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─1236 "nginx: worker process"
             └─1237 "nginx: worker process"

Nginx’i Önyüklemede Başlatılacak Şekilde Etkinleştirme

sudo systemctl enable nginx

Bu olmadan, Nginx sunucu yeniden başlatıldıktan sonra otomatik olarak başlamaz. Tek bir çağrıyla start komutuyla eşleştirin:

sudo systemctl enable --now nginx

Nginx Otomatik Başlatmayı Devre Dışı Bırakma

sudo systemctl disable nginx

SysVinit ile Nginx Yönetimi (Eski Sistemler)

SysVinit, CentOS 6 ve Ubuntu 14.04 gibi kullanım ömrü sona ermiş dağıtımlarda bulunur. service sarmalayıcısı, /etc/init.d/ konumundaki init betiklerine tutarlı bir arayüz sağlar.

Üretimde hâlâ SysVinit tabanlı sistemler çalıştırıyorsanız, desteklenen bir dağıtıma geçiş yapmanız şiddetle tavsiye edilir. Bu sistemler artık güvenlik yamaları almamaktadır; bu durum, internete açık herhangi bir sunucu için önemli bir risk oluşturmaktadır.

systemd ile SysVinit: Komut Karşılaştırması

Herhangi Bir Servis Değişikliğinden Önce Yapılandırma Doğrulaması

Bu, Nginx yönetiminde en önemli operasyonel alışkanlıktır. Bozuk bir yapılandırma dosyası restart‘ın başarısız olmasına ve sunucunuzun çevrimdışı kalmasına neden olur.

sudo nginx -t

Başarılı bir test şunu döndürür:

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

Çözümlenen yapılandırmayı da yazdıran ayrıntılı çıktı için (include direktiflerini hata ayıklarken kullanışlıdır):

sudo nginx -T

nginx -T, tüm birleştirilmiş yapılandırmayı stdout’a döker; bu, /etc/nginx/conf.d/ veya /etc/nginx/sites-enabled/ genelinde yayılmış birden fazla sunucu bloğu içeren karmaşık kurulumları denetlemek için paha biçilmezdir.

Güvenli yapılandırma değişiklikleri için iş akışı:

# 1. Edit your configuration
sudo nano /etc/nginx/nginx.conf

# 2. Validate — stop here if errors are reported
sudo nginx -t

# 3. Apply with zero downtime
sudo systemctl reload nginx

# 4. Confirm the service is still healthy
sudo systemctl status nginx

Nginx Master Process’ine Doğrudan Sinyal Gönderme

systemd’nin kullanılamadığı veya ayrıntılı kontrole ihtiyaç duyduğunuz senaryolar için, Nginx nginx -s aracılığıyla doğrudan POSIX sinyallerini kabul eder:

sudo nginx -s reload    # Equivalent to SIGHUP — graceful config reload
sudo nginx -s reopen    # Reopen log files (used after log rotation)
sudo nginx -s stop      # Fast shutdown (SIGTERM)
sudo nginx -s quit      # Graceful shutdown — waits for workers to finish

Master process PID’i varsayılan olarak /var/run/nginx.pid‘da saklanır. Sinyalleri manuel olarak da gönderebilirsiniz:

sudo kill -HUP $(cat /var/run/nginx.pid)

reopen sinyali, log rotasyon süreçlerinde özellikle önemlidir. logrotate, /var/log/nginx/access.log‘ı taşıdığında, Nginx reopen gönderene kadar eski dosya tanımlayıcısına yazmaya devam eder; bu noktada yeni dosya yolunu oluşturur ve ona yazar.

Hataları Tanılama: Log’lar ve Journal

Nginx başlatılamadığında veya yeniden yüklenemediğinde, iki kaynak tanılama verisi sağlar.

systemd Journal

sudo journalctl -u nginx --since "10 minutes ago"

Yeniden başlatma girişimi sırasında canlı çıktıyı takip etmek için:

sudo journalctl -u nginx -f

Nginx Hata Log’u

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

Gerçek zamanlı izleme için:

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

Yaygın hata kalıpları ve nedenleri:

• bind() to 0.0.0.0:80 failed (98: Address already in use) — Başka bir process (Apache, önceki bir Nginx örneği) port 80’i tutuyor. sudo ss -tlnp | grep :80 ile tespit edin.
• open() "/var/log/nginx/error.log" failed (13: Permission denied) — Nginx worker kullanıcısının log dizinine yazma erişimi yok.
• nginx: [emerg] unknown directive — nginx.conf‘da bir yazım hatası veya desteklenmeyen modül direktifi. nginx -t çıktısı tam dosya ve satır numarasını içerecektir.
• connect() failed (111: Connection refused) while connecting to upstream — Nginx çalışıyor, ancak upstream uygulama (PHP-FPM, Node.js) çalışmıyor. Bu, başlatma sırasında değil, hata log’unda görünür.

Kontrol Paneli Olan Sunucularda Nginx Yönetimi

Sunucunuz cPanel veya Plesk gibi bir kontrol paneli çalıştırıyorsa, Nginx Apache’nin önünde bir ters proxy katmanı olarak veya birincil web sunucusu olarak yönetilebilir. Bu ortamlarda, panelin servis orkestrasyon sistemini anlamadan Nginx’i yeniden başlatmak için ham systemctl komutlarını kullanmayın — bazı paneller systemd birim dosyasını geçersiz kılar ve Nginx’i kendi daemon denetçileri aracılığıyla yönetir.

cPanel tarafından yönetilen ortamlarda, doğru yeniden başlatma komutu genellikle şudur:

/scripts/restartsrv_nginx

cPanel ile VPS dağıtımı, servis yönetimini WHM’nin Servis Yöneticisi aracılığıyla gerçekleştirir; bu, yukarıdaki CLI betiklerinin yanı sıra bir GUI arayüzü sağlar.

Panel olmadan tam manuel kontrol istediğiniz ortamlar için, operasyonel modelinize uygun bir yönetim katmanı bulmak amacıyla mevcut VPS Kontrol Panelleri‘ni inceleyin.

Özel Donanımda Nginx

Nginx’i yük dengeleyici veya TLS sonlandırma noktası olarak çalıştıran yüksek trafikli dağıtımlar, özel kaynaklardan önemli ölçüde yararlanır. Bir Dedicated Server‘da, worker process sayılarını fiziksel CPU çekirdekleriyle tam olarak eşleşecek şekilde ayarlayabilir, diğer kiracılarla rekabet etmeden büyük worker_connections değerleri yapılandırabilir ve çekirdek düzeyinde optimizasyonları (SO_REUSEPORT, sendfile, tcp_nopush) tam potansiyeliyle kullanabilirsiniz. Servis yönetim komutları VPS ortamlarıyla aynıdır — fark, servisi nasıl kontrol ettiğinizde değil, neyi yapılandırabildiğinizde yatar.

Nginx örneğiniz HTTPS trafiğini sonlandırıyorsa, TLS sertifikalarınızın güncel olduğundan emin olun. Süresi dolmuş sertifikalar, systemctl status nginx‘ın yüzeyine çıkarmayacağı anlık bağlantı hatalarına neden olur — servis sağlıklı görünürken istemciler SSL el sıkışma hataları alır. SSL Sertifikaları‘nızı proaktif olarak yönetmek bu tür sessiz hataları önler.

Operasyonel Karar Matrisi

Belirli bir durum için doğru yönetim eylemini seçmek amacıyla bu matrisi kullanın:

Temel Teknik Çıkarımlar

• restart veya reload‘dan önce her zaman sudo nginx -t çalıştırın. Başarısız bir test, bozuk bir yapılandırmayla çalışan bir sunucuyu çevrimdışı almanızı engeller.
• Üretimde restart yerine reload tercih edin. Kesintisizdir ve yapılandırma değişikliği senaryolarının %99’unu karşılar.
• Manuel olarak kapatmanız gerektiğinde nginx -s stop yerine nginx -s quit daha güvenlidir — aktif bağlantıları boşaltmak için worker’ların bitmesini bekler.
• systemctl enable nginx, systemctl start nginx‘dan ayrıdır. enable‘ı unutmak, Nginx’in yeniden başlatmadan sonra hayatta kalmaması anlamına gelir.
• nginx -T (büyük harf) tam çözümlenmiş yapılandırmayı döker, tüm dahil edilen dosyalar dahil — büyük değişikliklerden önce etkin yapılandırmayı doğrulamak için kullanın.
• Kontrol paneli ortamlarının kendi yeniden başlatma betikleri vardır. cPanel veya Plesk’te ham systemd komutlarını kullanmak durum tutarsızlıklarına neden olabilir.
• Herhangi bir yapılandırma dağıtımı sırasında /var/log/nginx/error.log‘ı sürekli izleyin. Upstream hataları ve izin sorunları burada görünür, systemctl status‘da değil.

Sıkça Sorulan Sorular

nginx restart ile nginx reload arasındaki fark nedir?

restart, master process’i ve tüm worker’ları sonlandırır, aktif bağlantıları düşürür, ardından sıfırdan başlar. reload, master’a SIGHUP gönderir; master, eski worker’lar mevcut istekleri sunmayı bitirirken güncellenmiş yapılandırmayla yeni worker’lar çatalar — bu da sıfır kesinti süresiyle sonuçlanır.

nginx -t geçse bile sudo systemctl restart nginx neden başarısız olur?

Başarılı bir yapılandırma testi, başarılı bir başlatmayı garanti etmez. Yaygın nedenler arasında port çakışmaları (başka bir process zaten port 80 veya 443’e bağlı), yapılandırmada başvurulan eksik SSL sertifika dosyaları veya yetersiz dosya tanımlayıcı limitleri sayılabilir. Hatanın hemen ardından journalctl -u nginx‘ı kontrol edin.

Herhangi bir kesinti olmadan yapılandırma değişikliğini nasıl uygularım?

Doğrulamak için sudo nginx -t çalıştırın, ardından sudo systemctl reload nginx. Bu, yerinde nazik bir worker değişimi gerçekleştirir. Mevcut bağlantılar kesintiye uğramaz.

Nginx’i sunucu yeniden başlatıldıktan sonra otomatik olarak nasıl başlatırım?

sudo systemctl enable nginx çalıştırın. Bu, uygun systemd hedef dizininde bir sembolik bağlantı oluşturur. sudo systemctl start nginx ile birleştirin veya tek bir komutla etkinleştirmek ve başlatmak için sudo systemctl enable --now nginx kullanın.

Nginx log’ları nerede bulunur ve gerçek zamanlı olarak nasıl okuyabilirim?

Varsayılan olarak, hata log’u /var/log/nginx/error.log‘da ve erişim log’u /var/log/nginx/access.log‘da bulunur. sudo tail -f /var/log/nginx/error.log ile her birini gerçek zamanlı olarak takip edin. Zaman damgaları ve önem derecesi filtrelemesiyle yapılandırılmış log görüntüleme için sudo journalctl -u nginx -f kullanın.