Türkiye (Türkçe)
Almanya (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
504 Gateway Timeout, NGINX’in backend’e ulaştığı fakat belirlenen süre içinde yanıt başlığı veya veri alamadığı anlamına gelir. Bu rehber timeout ayarlarını körlemesine artırmadan PHP-FPM, veritabanı, harici API, import ve uygulama darboğazını bulmayı açıklar.
2026/07/17 03:22:51 [error] 2190#2190: *1147 upstream timed out (110: Connection timed out) while reading response header from upstream
upstream: "fastcgi://unix:/run/php/php8.3-fpm.sock"504, NGINX’in upstream hedefini bulduğunu ancak zamanında kullanılabilir cevap alamadığını gösterir. Kök neden yavaş PHP kodu, kilitlenen veritabanı, dış API, dolu worker havuzu veya uygulama içi sonsuz bekleme olabilir.
Logdaki 'while connecting to upstream' ifadesi bağlantı kurulma aşamasındaki; 'while reading response header from upstream' ise bağlantı kurulduktan sonra backend’in ilk yanıtını geciktirdiği sorunu gösterir.
proxy_read_timeout ve fastcgi_read_timeout toplam işlem süresini değil, iki ardışık okuma arasındaki beklemeyi sınırlar. Değeri büyütmek bazı uzun işlemleri tamamlatabilir fakat yavaş sorgu veya bloklanan worker sorununu ortadan kaldırmaz.
WordPress importu, WooCommerce raporu, büyük yedek, video işleme veya harici API çağrısı gibi uzun görevler HTTP isteği içinde çalıştırılıyorsa queue, cron veya arka plan worker mimarisine taşınması daha sağlıklıdır.
504 yalnız yoğun saatlerde oluşuyorsa PHP-FPM max_children, uygulama worker sayısı, MySQL slow query, CPU load ve disk gecikmesi birlikte incelenmelidir.
Timeout değerini artırmadan önce aynı isteğin backend’e doğrudan gönderildiğinde ne kadar sürdüğünü ölçün; süre değil bekleme nedeni optimize edilmelidir.
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ı: Backend bağlantıyı kabul etti ancak ilk yanıt başlığını süresinde üretmedi.
Muhtemel neden: Yavaş uygulama, DB kilidi, dolu worker veya dış API.
Anlamı: Backend’e TCP/socket bağlantısı belirlenen sürede kurulamadı.
Muhtemel neden: Ağ, backlog, servis yoğunluğu veya ulaşılmaz hedef.
Anlamı: Yanıt başladı fakat veri akışı bekleme sınırını aştı.
Muhtemel neden: Yavaş stream, büyük çıktı veya backend’in duraklaması.
Anlamı: PHP-FPM havuzunda boş worker kalmamış.
Muhtemel neden: Yetersiz max_children veya uzun süren PHP istekleri.
Anlamı: PHP kendi çalışma süresi limitine ulaştı.
Muhtemel neden: Yavaş kod, büyük import veya dış servis beklemesi.
Anlamı: Uzun işlem sırasında veritabanı bağlantısı kopmuş.
Muhtemel neden: Timeout, paket boyutu, restart veya ağ sorunu.
Anlamı: Tarayıcı genel timeout sayfasını gösteriyor.
Muhtemel neden: Proxy, FastCGI veya upstream cevap gecikmesi.
Anlamı: İstemci isteği tamamlamadan süre dolmuş.
Muhtemel neden: Yavaş upload veya istemci bağlantısı; upstream 504 ile karıştırılmamalı.
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.
curl -sk -o /dev/null -w 'origin connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n' https://example.com/
curl -s -o /dev/null -w 'backend start=%{time_starttransfer} total=%{time_total}\n' http://127.0.0.1:3000/Gecikmenin NGINX önünde mi backend içinde mi olduğunu gösterir.
grep -R "upstream timed out" /var/log/nginx 2>/dev/null | tail -n 100Hangi URL ve upstream hedefinde zaman aşımı oluştuğunu toplar.
nginx -T | grep -nE 'proxy_(connect|read|send)_timeout|fastcgi_(connect|read|send)_timeout'Include dosyaları dâhil gerçek etkin süreleri gösterir.
uptime
vmstat 1 5
iostat -xz 1 3 2>/dev/null
free -hCPU, RAM, run queue ve disk gecikmesini kontrol eder.
ps -eo pid,etimes,%cpu,%mem,cmd --sort=-etimes | head -n 30
mysqladmin processlist 2>/dev/null | head -n 50Uzun çalışan process ve sorguları görünür kılar.
nginx -t && systemctl reload nginx
curl -skI --max-time 30 https://example.com/Değişiklik sonrası güvenli reload ve sonuç testidir.
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 504 Gateway Timeout için systemd, paket yolu ve journald kontrolleri.
grep -R 'upstream timed out' /var/log/nginx | tail -n 50
systemctl status nginx php8.3-fpm --no-pager
journalctl -u php8.3-fpm -n 100 --no-pagerNGINX 504 Gateway Timeout için SELinux, PHP-FPM pool ve RHEL tabanlı servis kontrolleri.
grep -R 'upstream timed out' /var/log/nginx | tail -n 50
systemctl status nginx php-fpm --no-pager
journalctl -u php-fpm -n 100 --no-pagerPlesk tarafından üretilen NGINX sanal host dosyalarında nginx 504 gateway timeout kontrolü.
grep -R 'upstream timed out' /var/www/vhosts/system/example.com/logs /var/log/nginx 2>/dev/null | tail -n 50
plesk repair web example.com -nÖnce gecikmenin bağlantı, ilk yanıt, veri akışı veya uygulama içi işlem aşamasında olduğunu belirleyin.
Tek endpoint mi, tüm site mi ve kaç saniyede 504 oluşuyor kaydedin.
curl -sk -o /dev/null -w '%{http_code} %{time_starttransfer} %{time_total}\n' https://example.com/islemConnecting, reading response header veya reading upstream ifadelerini sınıflandırın.
grep 'upstream timed out' /var/log/nginx/error.log | tail -n 50Aynı isteği doğrudan uygulama portuna gönderin.
curl -s -o /dev/null -w '%{http_code} %{time_total}\n' http://127.0.0.1:3000/islemSlowlog, uzun sorgu, API çağrısı ve dolu worker havuzunu inceleyin.
ps -eo pid,etimes,%cpu,%mem,cmd --sort=-etimes | head -n 30İşin beklenen süresine göre en dar location bloğunda süre belirleyin.
nginx -T | grep -nE 'proxy_read_timeout|fastcgi_read_timeout'Tek istek yanında eşzamanlı birkaç istekte worker ve süre davranışını gözlemleyin.
for i in {1..5}; do curl -sk -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/islem & done; waitImport işlemi PHP süresi, memory, DB ve harici medya indirmesine takılabilir.
tail -f wp-content/debug.log /var/log/nginx/error.logBüyük tablolar ve indeks eksikliği yavaş sorgu üretebilir.
mysqladmin processlistUpload timeout ile request body limiti ayrı kontrol edilmelidir.
nginx -T | grep -nE 'client_max_body_size|client_body_timeout'Uygulamanın dış servise verdiği timeout NGINX’ten daha uzun olabilir.
curl -v --max-time 15 https://api.example.net/healthWorker havuzu, DB bağlantı limiti ve CPU doygunluğunu inceleyin.
uptime; free -h; ss -sBackend restart olmadan cevap veremiyor veya readiness yanlış olabilir.
docker stats --no-stream; docker psNGINX backend’e ulaşır ancak belirlenen süre içinde yanıt alamaz. Yavaş PHP, veritabanı, harici API, dolu worker havuzu veya ağ gecikmesi sık nedenlerdir.
Hayır. İşlem gerçekten uzun sürmesi bekleniyorsa yardımcı olabilir; fakat yavaş sorgu, kilit veya çöken worker sorununu yalnız gizleyebilir.
FastCGI sunucusundan iki ardışık okuma arasındaki bekleme süresini ölçer; tüm isteğin toplam süresini doğrudan sınırlamaz.
502 çoğunlukla backend’e bağlanamama veya geçersiz yanıt; 504 ise bağlantı kurulmasına rağmen zamanında cevap alamama durumudur.
NGINX error_log, PHP-FPM slowlog, WordPress debug.log ve MySQL processlist aynı zaman aralığında karşılaştırılmalıdır.
Mümkünse WP-CLI, cron, queue veya arka plan worker ile HTTP isteğinden bağımsız çalıştırılmalıdır.
PHP-FPM max_children, uygulama worker sayısı, DB bağlantı limiti, CPU load, RAM ve disk gecikmesi birlikte incelenmelidir.
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.