Turkey (Türkçe)
Germany (German)
Worldwide (English)
İstek akışıİstemci, NGINX ve backend arasındaki kopma noktası
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
NGINX yüksek trafikte yeni bağlantı kabul edemiyor, worker_connections are not enough veya too many open files yazıyorsa yalnız tek bir sayı artırılmamalıdır. Worker sayısı, file descriptor üst sınırı, proxy bağlantıları, keepalive, WebSocket ve bot trafiği birlikte ölçülmelidir.
2026/07/17 04:27:03 [alert] 2511#2511: 1024 worker_connections are not enough
2026/07/17 04:27:04 [crit] 2511#2511: accept4() failed (24: Too many open files)Her NGINX worker’ın eşzamanlı bağlantı üst sınırı worker_connections ile belirlenir. Reverse proxy bağlantıları, upstream socketleri ve bazı açık dosyalar da descriptor tüketir; teorik kapasite işletim sistemi limitini aşamaz.
worker_processes auto çoğu sistemde CPU sayısına göre worker oluşturur; toplam istemci kapasitesi basitçe worker_processes × worker_connections gibi görünse de proxy kullanımında her istemci için ek upstream bağlantısı gerekebilir.
worker_rlimit_nofile NGINX worker’larının açık dosya limitini yükseltebilir fakat systemd LimitNOFILE ve process soft/hard limitleriyle uyumlu olmalıdır.
Uzun keepalive, WebSocket veya SSE bağlantıları düşük istek trafiğinde bile çok sayıda bağlantıyı açık tutabilir. stub_status, ss ve /proc process limitleri birlikte izlenmelidir.
Limit uyarısı ani başladıysa bot/DDoS, slow client, upstream bağlantı sızıntısı veya yanlış keepalive yapılandırması araştırılmadan yalnız limit yükseltilmemelidir.
Kapasite hesabında proxy kullanan bir istemcinin hem client hem upstream bağlantısı tüketebileceğini hesaba katın; gerçek değer stub_status ve process fd sayısıyla ölçülmelidir.
E-postada, tarayıcıda veya SSH günlüğünde gördüğünüz ifadeyi aratın. Her kartta anlam, muhtemel neden ve güvenli ilk işlem bulunur.
Anlamı: Bir worker yeni bağlantı için tanımlı limite ulaştı.
Muhtemel neden: Düşük limit, uzun bağlantılar veya trafik patlaması.
Anlamı: Process yeni socket/file descriptor açamıyor.
Muhtemel neden: NOFILE soft/hard veya systemd limiti düşük.
Anlamı: Upstream ya da istemci socketi oluşturulamadı.
Muhtemel neden: Descriptor limiti veya sızıntı.
Anlamı: Reload/çıkış sırasında açık socket kaldı.
Muhtemel neden: Uzun bağlantı veya modül davranışı.
Anlamı: Yerel ephemeral port veya ağ kaynağı tükenmiş olabilir.
Muhtemel neden: Çok fazla upstream bağlantısı veya TIME_WAIT.
Anlamı: Bağlantı limiti doğrudan dolmasa da worker/backend kuyruğu büyüyor.
Muhtemel neden: Upstream kapasitesi NGINX’ten düşük.
Anlamı: Yaygın varsayılan/örnek değer yoğun sistem için yetersiz olabilir.
Muhtemel neden: Config kapasite planı yapılmamış.
Anlamı: Uygulama veya NGINX process file descriptor sınırına ulaştı.
Muhtemel neden: Limit veya dosya/socket sızıntısı.
Bu ifadeyle eşleşen kayıt bulunamadı.
Komutlar root erişimi içindir. Önce yalnızca durum ve log toplayın; nedeni görmeden kalıcı ayar değiştirmeyin.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile|keepalive_timeout|keepalive_requests'Etkin kapasite ve bağlantı yaşam ayarlarını gösterir.
MASTER=$(cat /run/nginx.pid); cat /proc/$MASTER/limits | grep -i 'open files'
for p in $(pgrep -f 'nginx: worker'); do echo PID=$p FD=$(ls /proc/$p/fd | wc -l); cat /proc/$p/limits | grep -i 'open files'; doneMaster ve worker gerçek NOFILE limitlerini/fd kullanımını gösterir.
ss -s
ss -ant state established | wc -l
ss -ant state time-wait | wc -lAktif, established ve TIME_WAIT bağlantılarını ölçer.
curl -s http://127.0.0.1/nginx_statusActive, accepts, handled, requests, reading/writing/waiting değerlerini gösterir.
systemctl show nginx -p LimitNOFILE
systemctl cat nginxService unit ve override dosyalarındaki açık dosya üst sınırını gösterir.
nginx -t && systemctl reload nginx
systemctl show nginx -p LimitNOFILEConfig değişikliğini uygulayıp servis limitini doğrular.
NGINX hatasının temel nedeni aynı olsa da paket yolları, servis adları, güvenlik katmanları ve sanal host yönetimi kullanılan Linux dağıtımına veya Plesk altyapısına göre değişir.
NGINX Worker Connections ve Open Files için systemd, paket yolu ve journald kontrolleri.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'
systemctl show nginx -p LimitNOFILE
ss -sNGINX Worker Connections ve Open Files için SELinux, PHP-FPM pool ve RHEL tabanlı servis kontrolleri.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'
systemctl show nginx -p LimitNOFILE
ss -sPlesk tarafından üretilen NGINX sanal host dosyalarında nginx worker connections ve open files kontrolü.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'
systemctl show nginx -p LimitNOFILE
plesk repair web -nÖnce gerçek bağlantı/fd kullanımını ve trafik türünü ölçün; ardından NGINX, systemd ve işletim sistemi limitlerini uyumlu ayarlayın.
Ani bot trafiği mi, normal büyüme mi, WebSocket/keepalive mı belirleyin.
date; uptime; ss -sWorker sayısı, bağlantı limiti ve rlimit değerlerini kaydedin.
nginx -T | grep -nE 'worker_processes|worker_connections|worker_rlimit_nofile'Config değeriyle /proc limits ve açık descriptor sayısını karşılaştırın.
for p in $(pgrep -f 'nginx: worker'); do echo -n "$p "; ls /proc/$p/fd | wc -l; doneEstablished, waiting, TIME_WAIT, WebSocket ve upstream bağlantılarını ayırın.
ss -ant | awk 'NR>1 {s[$1]++} END {for(k in s) print k,s[k]}'worker_connections, worker_rlimit_nofile ve systemd LimitNOFILE birlikte planlanmalıdır.
systemctl show nginx -p LimitNOFILEReload sonrası fd sayısı, stub_status ve error_log uyarılarını takip edin.
nginx -t && systemctl reload nginx
watch -n2 'ss -s; curl -s http://127.0.0.1/nginx_status'Limit artışı öncesi IP/URI dağılımı ve rate limiting planı gerekir.
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | headUzun süre açık kalan bağlantılar worker kapasitesini tüketir.
ss -antp | grep nginx | wc -lWaiting bağlantıları ve keepalive_timeout değeri incelenir.
curl -s http://127.0.0.1/nginx_status; nginx -T | grep keepalive_timeoutHer istemci için ek upstream socket gerekebileceği hesaba katılır.
ss -antp | grep nginx | headBir worker fd sayısı sürekli yükseliyorsa açık hedefler incelenir.
lsof -p $(pgrep -f 'nginx: worker' | head -1) | head -n 50Global nginx.conf, web server template ve domain trafiği birlikte değerlendirilir.
nginx -T | grep worker_connections; ss -sHer worker process’in aynı anda açabileceği bağlantıların üst sınırını belirler; proxy upstream bağlantıları da bu sayıya dâhil olabilir.
Kabaca worker_processes × worker_connections düşünülür fakat file descriptor limiti, proxy bağlantıları ve trafik türü gerçek kapasiteyi düşürür.
Process NOFILE, systemd LimitNOFILE, worker_rlimit_nofile ve gerçek fd kullanımını birlikte uyumlu hale getirmek gerekir.
Hayır. İşletim sistemi limiti düşükse etkisiz olur; bot trafiği veya fd sızıntısı varsa sorunu büyütebilir.
Aktif bağlantı, accepts, handled, requests ile reading/writing/waiting bağlantı sayılarını gösterir.
Evet. Uzun süre açık kalan her WebSocket istemci ve çoğunlukla upstream bağlantısı tüketir.
systemctl show nginx -p LimitNOFILE ve çalışan worker’ın /proc/PID/limits dosyası birlikte kontrol edilmelidir.
cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim ve güvenlik katmanlarını birlikte analiz ederek yalnızca servisi kaldırmak yerine arızanın temel nedenini gideriyoruz.