504 Gateway Timeout: ne anlama gelir ve nasıl çözülür

Hata ne anlama gelir

504, öndeki web sunucusunun (nginx, Apache, bir yük dengeleyici, bir CDN) arkasındaki uygulamadan vazgeçmesidir. İstek iletildi, arka uç çalışmaya başladı ve bir yanıt gelmeden öndeki zamanlayıcı doldu. Bir 502 Bad Gateway hatasından farkı, arka uca ulaşılabilmesidir; yalnızca çok yavaştır. Tipik zamanlayıcılar nginx'te 60 saniye (fastcgi_read_timeout, proxy_read_timeout), Apache'de 60 saniye (ProxyTimeout) ve Cloudflare'de 100 saniyedir; ücretsiz planda bunu değiştiremezsiniz.

Zaman aşımını artırmak nadiren çözümdür. Bir şey çok uzun sürüyor ve bulmanız gereken o şeydir.

Yaygın nedenler

1. Yavaş bir veritabanı sorgusu. Her sayfa yüklemesinde devasa bir tablodaki satırları sayan bir WordPress eklentisi, eksik bir dizin, süresi dolmuş geçici verilerle dolu bir wp_options tablosu. Her istek bekler ve yük altında beklemeler birikir.
2. Takılı kalan harici bir çağrı. Uygulama bir ödeme sağlayıcısına, bir e-posta hizmetine, bir hava durumu API'sine veya bir lisans sunucusuna ulaşır ve o hizmet yavaş ya da kapalıdır. O çağrıda zaman aşımı yoksa sayfanız onu bekler.
3. Çok az işçi. Tüm PHP-FPM işçileri yavaş isteklerle meşgul; yenileri ön taraf vazgeçene kadar kuyrukta bekler. Dışarıdan bu, her bir istek hızlı olsa bile bir zaman aşımı gibi görünür.
4. Ön planda çalışan cron veya yedekleme. Bir yedekleme eklentisi, bir içe aktarma, 50.000 URL'lik bir site haritası: bir web isteği içinde üretildiklerinde her zaman aşımını aşarlar.
5. Disk G/Ç'si veya swap. Sunucunun belleği tükenir ve swap kullanır; her şey on kat yavaşlar. Düşük CPU kullanımıyla yüksek yük olarak görünür.
6. Ön ve arka arasındaki ağ. Bir veri merkezindeki bir yük dengeleyici, başka birindeki arka uç, paketleri sessizce düşüren bir güvenlik duvarı. Nadirdir, ama boşta bir arka uçla her istekte 504 buraya işaret eder.

Ziyaretçiyseniz

Bir dakika sonra yeniden yükleyin. Site kapalı olmaktan çok yavaşsa farklı bir sayfa deneyin; zaman aşımı tek bir ağır sayfaya bağlı olabilir.

Kendi siteniz ise: önce kontrol edin

Web sitesi çökme kontrolünü çalıştırın: durum kodunu ve yanıt süresini dışarıdan bildirir. Bugün 30 saniyede yanıt veren bir site, yarın yük altında 504 gösterecek bir sitedir.

Kendi sunucunuzda zamanın nereye gittiğini bulun:

# işçiler birikiyor mu?
sudo tail -n 30 /var/log/nginx/error.log | grep -E 'timed out|timeout'

# PHP şu anda ne yapıyor? (havuzda pm.status_path gerekir)
curl -s 'http://127.0.0.1/fpm-status?full' | grep -E 'state|request URI|duration' | head -40

# MySQL/MariaDB: hangi sorgular çalışıyor ve ne kadar süredir?
sudo mysql -e 'SHOW FULL PROCESSLIST;'

# bellek ve swap
free -m
vmstat 1 5

Aynı sorguyla dolu bir işlem listesi veya vmstat içindeki sıfır olmayan si/so sütunları nedeni gösterir.

Kendi sunucunuzda çözümler

1. Yavaş sorgu logunu açın ve sorguyu düzeltin

SET GLOBAL slow_query_log = 1;
SET GLOBAL long_query_time = 2;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Birkaç dakika sonra sudo mysqldumpslow -s t /var/log/mysql/slow.log | head en kötü sorguları listeler. Eksik dizini ekleyin veya sorguyu çalıştıran eklentiyi bulup değiştirin. WordPress'te şişmiş bir options tablosu klasik bir örnektir:

wp transient delete --all
wp db query "SELECT option_name, LENGTH(option_value) AS size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;"

Her istekte otomatik yüklenen yüzlerce kilobaytlık her şey kaldırılmak için bir adaydır.

2. Harici çağrılara zaman aşımı koyun

Uygulamanızın yaptığı her HTTP çağrısının, web sunucusununkinden kısa kendi zaman aşımına ihtiyacı vardır. cURL'lü PHP'de: CURLOPT_CONNECTTIMEOUT 5 ve CURLOPT_TIMEOUT 10. WordPress'te wp_remote_get() bir timeout argümanı alır; birçok eklenti bunu varsayılanda bırakır ve sonsuza dek bekler. Üçüncü taraf bir hizmet kapalıysa sayfa ölmemeli, işlevi azaltmalıdır (canlı kargo ücreti olmadan formu göstermek gibi).

3. Uzun işleri istekten çıkarın

Yedeklemeler, içe aktarmalar, dışa aktarmalar, büyük site haritaları ve e-posta gönderimi bir sayfa görüntülemesinde değil, bir cron işinde veya kuyrukta yer almalıdır. WordPress için sözde cron'u kapatın ve gerçeğini çalıştırın:

// wp-config.php
define('DISABLE_WP_CRON', true);

# crontab -e
*/5 * * * * cd /var/www/example.com && wp cron event run --due-now >/dev/null 2>&1

4. Zaman aşımlarını dikkatle ayarlayın

Tek bir sayfanın meşru olarak daha uzun süreye ihtiyacı varsa (bir yönetici dışa aktarımı, bir rapor), zaman aşımını genel olarak değil, yalnızca o konum için yükseltin:

location = /wp-admin/export.php {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
}

PHP-FPM'li Apache: bir <Location> bloğunun içinde ProxyTimeout 300. PHP'nin kendisinde max_execution_time vardır; aynı değere ayarlayın, yoksa PHP önce durur ve 500 alırsınız. Sonra sudo nginx -t && sudo systemctl reload nginx.

5. Swap kullanımını durdurun

ps aux --sort=-%mem | head

PHP-FPM işçilerinin her biri 150 MB kullanıyorsa ve 4 GB'lık bir sunucuda bunlardan 30 tane çalıştırıyorsanız hesap tutmaz. pm.max_children değerini düşürün, belleği artırın veya belleği kullanan eklentiyi düzeltin. Swap kullanmayan bir sunucu, 504'lerinin çoğu ortadan kalkan bir sunucudur.

6. Önbellek

Tam sayfa önbelleği (nginx FastCGI önbelleği, bir WordPress önbellek eklentisi, Varnish), tekrar eden ziyaretçilere PHP'ye veya veritabanına dokunmadan hizmet verir. Yük altındaki 504'lerin çoğu, ana sayfa ve en çok açılan sayfalar önbellekten geldiğinde ortadan kalkar.

Sorun hosting firmanızdaysa

Paylaşımlı hostingde yavaş sorguları ve eklentileri düzeltebilirsiniz, ama sunucunun zaman aşımlarını veya komşuların yükünü düzeltemezsiniz. Hosting firmanıza şunu gönderin:

Merhaba, example.com web sitem yaklaşık 16:00 UTC'den beri "504 Gateway Timeout" döndürüyor. Daha önce iki saniyenin altında yüklenen sayfalar şimdi zaman aşımına uğruyor. Hiçbir şeyi değiştirmedim. Lütfen hesabımın veritabanı sunucusunun veya PHP havuzunun aşırı yüklü olup olmadığını ya da sunucudaki başka bir hesabın yüksek yüke neden olup olmadığını kontrol edip ne bulduğunuzu bana söyleyebilir misiniz?

Bir sonrakini önlemek

Bir 504, daha da yavaşlamış yavaş bir sitedir ve yanıt süresi zaman aşımından çok önce ölçülebilir. Web sitesi kontrolleri her kontrolün yanıt süresini kaydeder; buna bir uyarı koyarsanız, ziyaretçiler bir hata görmeden haftalar önce eğilimi görürsünüz. Sunucu ajanı içeriden yük, bellek ve swap ekler. Kendi sunucunuzda bir Deep Fix yavaş sorguyu veya takılı kalan çağrıyı bulur ve düzeltir; 15 dakikalık bloklar hâlinde faturalanır, fiyat sipariş vermeden önce.