Hosting, Performans

WordPress 504 Gateway Timeout Hatası: Nedenleri, Tanısı ve Adım Adım Çözüm Rehberi

21 Nisan 2026 No comments yet
WordPress 504 Gateway Timeout Hatası kapak görseli

WordPress sitenizi açmaya çalışırken ekranda “504 Gateway Timeout” hatasıyla karşılaşmak, hem ziyaretçiler hem de site sahipleri için can sıkıcı bir deneyimdir. Bu hata, sitenizin tamamen çöktüğünü değil, istek zincirindeki bir sunucunun diğerinden zamanında yanıt alamadığını gösterir. Bu rehberde 504 hatasının neden oluştuğunu, hangi katmanlarda teşhis yapmanız gerektiğini ve kalıcı çözümü için atabileceğiniz adımları, uygulamalı komutlarla birlikte anlatıyorum.

Kısa Özet

504 Gateway Timeout hatası; Nginx, Apache, Cloudflare veya LiteSpeed gibi ön uç sunucuların, PHP-FPM / upstream WordPress sunucusundan belirli bir süre içinde yanıt alamaması durumunda döndürdüğü HTTP durum kodudur. Çözüm çoğunlukla üç eksende toplanır: PHP/worker zaman aşımı ayarlarının artırılması, ağır sorgu veya eklentinin tespit edilip optimize edilmesi ve reverse proxy / CDN zincirindeki timeout değerlerinin hizalanması. Bu yazıda her üç eksen için adım adım ilerleyen, komut satırı ve wp-config.php seviyesinde doğrulanabilir bir yol haritası bulacaksınız.

Neden Önemli?

504 hatası ziyaretçiniz için sitenizi erişilemez yapar; arama motorları ise tekrarlanan 504 yanıtlarını “sunucu güvenilmez” olarak yorumlayarak tarama sıklığını ve sıralamanızı aşağı çeker. Hata kısa süreli olsa bile Core Web Vitals ölçümlerini bozar; uzun sürerse Google Search Console “Sunucu hatası (5xx)” uyarısı olarak indeksleme hatalarına dönüşür. Dahası, 504 çoğu zaman ardında daha derin bir performans problemi (yavaş SQL sorgusu, kilitlenmiş cron, kötü optimize edilmiş eklenti) gizler; o yüzden hatayı sadece “görünür kılmamak” için bastırmak yerine kök nedenini bulmak gerekir.

504 Hatasının Teknik Arka Planı

WordPress istekleri, tipik bir üretim yığınında şu katmanlardan geçer:

  1. İstemci (tarayıcı) → CDN veya Cloudflare.
  2. CDN → Kaynak sunucudaki reverse proxy (Nginx, Apache, LiteSpeed).
  3. Reverse proxy → PHP-FPM (veya mod_php).
  4. PHP-FPM → MySQL / MariaDB ve harici API’lar.

504 hatasını döndüren katman, altındaki katmandan zamanında yanıt alamayan ilk katmandır. Nginx ise upstream timed out hatası günlüğe düşer; Cloudflare ise 524 veya 504 döndürebilir. Bu yüzden “504 gördüm” derken önce hangi bileşenin bu yanıtı ürettiğini tespit etmek gerekir. Hatayı üreten katmanı doğru bulmadan yapılan çözüm denemeleri çoğu zaman sadece bir sonraki timeout’u birkaç saniye ileri atar.

504 Gateway Timeout Hatasının Başlıca Nedenleri

1. PHP Execution Time Çok Düşük

WordPress’te ağır sayfalar (arşiv sayfaları, WooCommerce raporları, büyük eklenti kurulumları) varsayılan 30 saniyelik max_execution_time içinde tamamlanamayabilir. PHP isteği bitiremediğinde PHP-FPM, Nginx’e yanıt gönderemez; Nginx de yukarıya 504 döner.

2. PHP-FPM Worker Tükenmesi

pm.max_children değeri düşükse ve aynı anda gelen yavaş istekler worker’ları kilitliyorsa, yeni istekler kuyrukta beklerken request_terminate_timeout süresini aşar. Sonuç: sayfa açılmaz, 504 döner.

3. Nginx `fastcgi_read_timeout` Değeri

Nginx, PHP-FPM’den yanıtı okurken fastcgi_read_timeout (varsayılan 60 sn) içinde yeni bir baytlık veri gelmezse bağlantıyı düşürür ve istemciye 504 döndürür. Arka planda uzun WP-Cron işleri veya büyük CSV içe aktarma işlemleri bu eşiği rahatlıkla aşar.

4. Yavaş veya Kilitli MySQL Sorguları

WordPress’te wp_options tablosunun autoload = yes alanlarının şişmesi, eksik indeksler, veya iyi optimize edilmemiş meta sorgular bir isteği dakikalarca sürdürebilir. PHP bu sorguyu beklerken yukarı katmanların timeout’u devreye girer.

5. Kilitlenmiş WP-Cron veya Uzun Zamanlanmış Görevler

WP-Cron HTTP üzerinden wp-cron.php tetiklendiği için, zamanlanmış bir görev uzun sürüyorsa arka planda worker’ı meşgul eder. Bazı sayfa yüklemeleri bu cron’u tetiklediğinde ziyaretçi 504 görür.

6. Cloudflare veya CDN Zincirinde Timeout

Cloudflare free planında kaynak sunucu 100 saniyede yanıt vermezse 524 üretir; bazı ara katmanlarda bu 504’e dönüşür. Aynı şekilde AWS CloudFront veya BunnyCDN varsayılan okuma timeout’ları WordPress yönetim paneli için yeterli olmayabilir.

7. Harici API İstekleri

Ödeme sağlayıcıları, kargo entegrasyonları, WooCommerce webhook’ları veya uzak RSS/feed çekme işlemleri yanıt vermediğinde, WordPress varsayılan olarak wp_remote_get üzerinden 5-10 saniye bekler. Birden fazla bloke edici dış çağrı üst üste gelince toplam süre 504 eşiğini aşar.

8. Yetersiz Sunucu Kaynağı (CPU / RAM / Disk I/O)

Paylaşımlı hosting veya küçük VPS’lerde CPU trafiği yoğunlaştığında process’ler yavaşlar. Özellikle yüksek trafikli WooCommerce siteleri için kaynak ölçeklemesi kaçınılmazdır.

9. DNS Çözümleme Sorunları

PHP, harici API’lara giderken DNS çözümleyemiyorsa her istek zaman aşımına kadar bekler. Yanlış yapılandırılmış /etc/resolv.conf veya bloke edilmiş DNS sunucuları bu gizli nedendir.

10. Güvenlik Duvarı (WAF) veya Bot Koruması

Aşırı agresif WAF kuralları yönetici AJAX isteklerini kilitleyip yanıtı geciktirebilir. Özellikle Wordfence’in bazı Firewall Learning Mode senaryolarında görülür.

Adım Adım Çözüm Rehberi

Aşağıdaki adımları sırayla uygulayın; her adımdan sonra siteyi gizli sekmede yenileyip hatanın çözülüp çözülmediğini kontrol edin.

Adım 1: Hatayı Doğrulayın ve Kapsamını Belirleyin

Öncelikle 504’ün hangi URL’lerde çıktığını not edin: yalnızca wp-admin mi? Belirli bir kategori sayfası mı? WooCommerce ödeme adımı mı? Kapsam, hangi tarafta çözüm yapmanız gerektiğine yön verir.

# Farklı ağlardan test ederek hatanın sunucu veya CDN kaynaklı olduğunu doğrulayın
curl -I https://ornek-site.com/
curl -I https://ornek-site.com/wp-admin/admin-ajax.php
curl -w "%{http_code} %{time_total}\n" -o /dev/null -s https://ornek-site.com/shop/

Yanıt 504 ise Server: başlığına bakın; cloudflare ise kaynak yanıt bile gelmemiş olabilir. nginx ise sorun PHP-FPM ile Nginx arasındadır.

Adım 2: WordPress Hata Günlüğünü Açın

wp-config.php dosyanıza ABSPATH satırının üstüne ekleyin:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
define( 'SCRIPT_DEBUG', false );

Sonra wp-content/debug.log dosyasını inceleyin. Fatal hatalar veya PHP Warning: Maximum execution time … exceeded mesajları 504’ün kaynağını işaret eder.

Adım 3: Sunucu Taraflı Logları İnceleyin

Sunucunuzda (VPS / cloud) şu logları kontrol edin:

# Nginx upstream zaman aşımı mesajlarını yakalayın
sudo tail -n 200 /var/log/nginx/error.log | grep -i 'upstream timed out'

# PHP-FPM yavaş istek logu
sudo tail -n 200 /var/log/php/php-fpm-slow.log

# Apache kullanıyorsanız
sudo tail -n 200 /var/log/apache2/error.log

upstream timed out (110: Connection timed out) while reading response header from upstream satırı açıkça PHP-FPM’in zamanında yanıt veremediğini gösterir.

Adım 4: PHP Ayarlarını Yükseltin

Kontrol panelinizde (cPanel, Plesk, DirectAdmin) veya sunucuda php.ini dosyasında aşağıdaki değerleri yükseltin:

max_execution_time = 300
max_input_time = 300
memory_limit = 512M
post_max_size = 128M
upload_max_filesize = 128M

wp-config.php üzerinden de ek güvence sağlayabilirsiniz:

@ini_set( 'memory_limit', '512M' );
@set_time_limit( 300 );
define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '768M' );

Adım 5: Nginx ve PHP-FPM Timeout Değerlerini Hizalayın

Root erişiminiz varsa Nginx server bloğunda:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_read_timeout 300s;
    fastcgi_send_timeout 300s;
    proxy_connect_timeout 300s;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
}

PHP-FPM havuz dosyasında (/etc/php/8.2/fpm/pool.d/www.conf):

request_terminate_timeout = 300
pm = dynamic
pm.max_children = 25
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 10

Değişiklik sonrası servisleri yeniden başlatın:

sudo nginx -t && sudo systemctl reload nginx
sudo systemctl restart php8.2-fpm

Adım 6: Yavaş Eklenti veya Temayı Tespit Edin

wp-content/mu-plugins/ dizinine bir dosya (örn. slow-request-logger.php) koyarak uzun süren istekleri loglayabilirsiniz:

<?php
// wp-content/mu-plugins/slow-request-logger.php
add_action( 'shutdown', function () {
    $duration = microtime( true ) - $_SERVER['REQUEST_TIME_FLOAT'];
    if ( $duration > 3.0 ) { // 3 saniyeyi aşan istekleri kaydet
        error_log( sprintf(
            '[slow-request] %.2fs %s %s',
            $duration,
            $_SERVER['REQUEST_METHOD'] ?? 'GET',
            $_SERVER['REQUEST_URI'] ?? '/'
        ) );
    }
} );

Ardından WP-CLI ile eklentileri tek tek devre dışı bırakıp tekrar açarak sorumluyu bulabilirsiniz:

wp plugin list --status=active --field=name
wp plugin deactivate PROBLEMLI-EKLENTI --dry-run
wp plugin deactivate PROBLEMLI-EKLENTI

Hata yönetici paneline de giremiyorsanız FTP ile wp-content/plugins/ klasörünü plugins-backup olarak yeniden adlandırın; WordPress tüm eklentileri devre dışı bırakır, ardından tek tek geri alırsınız.

Adım 7: Veritabanı Temizliği ve Optimizasyon

Şişen wp_options autoload alanı 504’ün gizli nedenlerindendir. En ağır autoload kayıtlarını görmek için:

SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 20;

Kullanılmayan geçici (transient) kayıtları temizleyin:

DELETE FROM wp_options WHERE option_name LIKE '\_transient\_%';
DELETE FROM wp_options WHERE option_name LIKE '\_site\_transient\_%';

WP-CLI ile daha güvenli bir yol:

wp transient delete --all
wp cache flush
wp db optimize

Adım 8: Nesne Önbelleği (Object Cache) ve Sayfa Önbelleği Ekleyin

Redis veya Memcached tabanlı nesne önbelleği, tekrarlanan veritabanı sorgularını bellekten okuyarak 504’ü tetikleyen yavaş sorguları azaltır. Yönetilen WordPress hostinglerinin çoğu tek tıkla Redis sunar. Alternatif olarak:

# Debian / Ubuntu örneği
sudo apt install redis-server php8.2-redis
sudo systemctl enable --now redis-server

Sonra Redis Object Cache eklentisini kurup etkinleştirin. Sayfa seviyesinde ise WP Rocket, W3 Total Cache veya LiteSpeed Cache (LiteSpeed sunucularda) ile tam sayfa önbelleği açın.

Adım 9: Harici API Çağrılarını İzole Edin

WordPress, “Site Health” sayfasında uzun süren HTTP isteklerini raporlar. Tools → Site Health → Info → Filesystem Permissions bölümünü kontrol ederken, eklentilerinizin dış servislere yaptığı isteklere timeout parametresi eklediğinden emin olun. Kendi tema/eklenti kodunuzda:

$response = wp_remote_get( 'https://ornek-api.com/veri', [
    'timeout'     => 6,
    'redirection' => 3,
    'blocking'    => true,
] );

if ( is_wp_error( $response ) ) {
    error_log( 'Harici API hatası: ' . $response->get_error_message() );
    return false;
}

Önemli: ön yüzde (front-end) asla blocking = true ve uzun timeout’lu uzak istekler yapmayın; bu 504’ün en yaygın nedenlerinden biridir.

Adım 10: WP-Cron Davranışını Düzeltin

wp-config.php dosyasına ekleyin:

define( 'DISABLE_WP_CRON', true );

Ardından sunucu crontab’ına dakikada bir gerçek cron ekleyin:

crontab -e
# Aşağıdaki satırı dosya sonuna ekleyin
* * * * * wget -q -O - https://ornek-site.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Böylece cron tetikleme yükü ziyaretçi sayfa yüklemelerine binmez ve 504 tetikleyicilerinden biri ortadan kalkar.

Adım 11: Cloudflare veya CDN Kurallarını Gözden Geçirin

Cloudflare kullanıyorsanız:

  • Network → Connection bölümünde Enable Always Use HTTPS aktif olsun.
  • Rules → Page Rules üzerinde wp-admin/* ve wp-login.php için Cache Level: Bypass kuralı girin.
  • Pro ve üstü planlarda Cloudflare → Rules → Transform Rules → Request Headers ile CF-Connecting-IP başlığının kaynak sunucuya ulaştığından emin olun. Gerçek IP gitmiyorsa sunucu taraflı logda tüm istekler Cloudflare IP’sinden görünür ve rate-limit tetiklemesi sık olur.

Cloudflare free planında 100 sn’den uzun süren istekler için 524 alırsınız; bu değer yükseltilemez. Çözüm: ilgili yönetim aracını /wp-admin/admin-ajax.php üzerinden kuyruk tabanlı çalışmaya (Action Scheduler veya wp-background-processing) taşımaktır.

Adım 12: Sunucu Kaynaklarını İzleyin ve Ölçekleyin

Hata tekrarladıkça top, htop, iotop ile gerçek zamanlı yük izlemesi yapın:

htop
iotop -ao
vmstat 2 5
sar -r 1 10   # sysstat paketi gerekir

CPU %90’ı aşıyorsa veya disk I/O wait değerleri %30’un üzerindeyse kaynak ölçeklemesi (daha büyük VPS, yönetilen WordPress hosting) gündeme gelir. Ölçekleme yapamıyorsanız eklenti sayısını azaltın, yüksek trafikli sayfalar için statik HTML önbellek üretin.

Sorun Giderme Checklist’i

Hata hâlâ çözülmediyse aşağıdaki hızlı kontrol listesini işletin. Her maddeyi kontrol edip sonucunu not edin:

  • wp-content/debug.log dosyasında son 15 dakikadaki fatal veya warning kayıtları incelendi mi?
  • nginx/error.log içinde upstream timed out satırı var mı?
  • php-fpm-slow.log açık ve uzun süren fonksiyon çağrıları kaydediliyor mu?
  • Aktif tüm eklentiler tek tek devre dışı bırakılarak test edildi mi?
  • Varsayılan bir temaya (Twenty Twenty-Four) geçip hata yeniden üretildi mi?
  • wp cache flush, wp transient delete --all, wp rewrite flush komutları çalıştırıldı mı?
  • WP-Cron gerçek sistem cron’una taşındı mı?
  • Object Cache (Redis / Memcached) açık mı?
  • Cloudflare üzerinden geliyorsa kaynak sunucu IP’sini doğrudan /etc/hosts ile test ederek kontrol edildi mi?
  • Son yedekten veya staging ortamından karşılaştırma yapılabildi mi?

Hızlı Komut Özeti

Aşağıdaki komutlar WP-CLI ve Linux üzerinde çalışan bir kurulumda, 504 sorunlarını hızlıca teşhis etmek için kullanılabilir:

# WordPress sürüm ve çekirdek doğrulaması
wp core verify-checksums

# Yavaş veya çakılan eklentileri tespit etmek için sıralı devre dışı bırakma
wp plugin deactivate --all --skip-plugins
wp plugin activate TEMEL-EKLENTI

# Veritabanı boyutu ve sorun çıkaran tabloları görmek
wp db size --tables --format=table

# Çöp kayıtları temizleme
wp post delete $(wp post list --post_status=trash --format=ids) --force
wp comment delete $(wp comment list --status=spam --format=ids) --force

# Cron kuyruğunu manuel tetikleme
wp cron event run --due-now

Kalıcı Koruma için Önlemler

504 hatasını tek seferlik çözmek yerine tekrar etmesini engelleyecek önlemler almak, hem SEO’nuzu hem de ziyaretçi deneyimini uzun vadede korur. Aşağıdaki pratikleri rutin bakım planınıza ekleyin:

  • Her ay WordPress çekirdek, tema ve eklentileri güncel tutun; eski eklentilerin uyumsuzluğu yavaş sorgulara yol açar.
  • Günlük veya haftalık otomatik yedekleme (UpdraftPlus, BlogVault, sunucu snapshot) alın; 504 sonrası hızlı geri dönüş için yedek kritiktir.
  • Staging ortamınızda büyük güncellemeleri önce test edin; üretimde doğrudan denemeyin.
  • Uygulama performans izleme (New Relic, Blackfire, Query Monitor eklentisi) kullanarak yavaş sorguları proaktif olarak bulun.
  • Sunucu sağlık metriklerini (CPU, RAM, disk, bağlantı havuzu) Grafana/Prometheus, Netdata veya yönetilen hosting panelinden izleyin.
  • Aşırı ziyaretçi ataklarını engellemek için Cloudflare veya Wordfence gibi katmanlarla rate-limit kurun.

Sık Sorulan Sorular (SSS)

504 hatası sitemin hacklendiğini mi gösterir?

Doğrudan hayır. 504 her zaman bir zaman aşımı sinyalidir; ancak bazı kötü amaçlı botnet taramaları sunucuyu yorarak 504 üretebilir. Günlükte yüksek trafikli şüpheli IP aralıkları varsa WAF kuralları ile rate-limit uygulayın. Güvenlik endişeniz varsa yasal tarama araçları (Wordfence scan, Sucuri SiteCheck) ile dosya bütünlüğünü kontrol edin.

Cloudflare kapatınca 504 gitti, suçlu Cloudflare mi?

Cloudflare çoğu zaman sorunun kendisi değil, sorunun görünür katmanıdır. Kaynak sunucu zamanında yanıt verseydi Cloudflare 504 döndürmezdi. “Development Mode” açıkken CDN önbelleği devre dışı kaldığı için bazı yavaş istekler hızlanır gibi görünür. Asıl çözüm yine kaynak sunucu optimizasyonudur.

WooCommerce ödeme sayfasında sık sık 504 alıyorum, ne yapmalıyım?

Ödeme işlemlerinde harici ödeme sağlayıcısına yapılan API çağrıları darboğaz olur. Async işlem (Action Scheduler), daha uzun fastcgi_read_timeout, Redis object cache ve ödeme sağlayıcısından webhook yerine “Thank You” sayfasında polling kullanmak çözüm sağlar. Ayrıca ödeme gateway eklentisinin güncel sürümde olduğundan emin olun.

Maintenance mode açıkken 504 görüyorum, ilişkili mi?

Büyük güncellemelerde .maintenance dosyası geçici 503 döndürür, 504 değil. Ancak güncelleme sırasında arka planda veri tabanı geçişi yavaşsa ön uçta 504 görülebilir. Güncellemeyi WP-CLI ile komut satırından yapmak arayüz tabanlı güncellemelere göre daha az 504 üretir.

504 hatası yalnızca yönetici panelinde çıkıyor, ön yüzde yok. Neden?

Yönetici paneli genellikle yüksek sayıda AJAX isteği ve admin-ajax.php tetiklemesi yapar. Heartbeat API veya eklenti tabanlı dashboard widget’ları uzun sürüyor olabilir. Heartbeat Control eklentisi ile aralığı 60 saniyeye çıkarın ve gereksiz widget’ları kapatın.

Paylaşımlı hostingte root erişimim yok, Nginx ayarlarını nasıl değiştiririm?

Çoğu kaliteli Türk hosting sağlayıcısı, kontrol panelinden PHP Max Execution Time, Memory Limit ve Timeout ayarlarını yönetmenize izin verir. Değilse destek birimine konuyu belirterek iletin. Yine de çözüm gelmezse yönetilen WordPress hosting veya küçük bir VPS’e geçiş düşünülmelidir.

504 gördüğümde siteme ziyaretçi girebiliyor mu, tamamen kapalı mı?

504 anlık bir zaman aşımı yanıtıdır; bir sonraki istek başarıyla sunulabilir. Yani site “tamamen kapalı” değildir, ancak ziyaretçiniz sayfayı açamadığı için pratikte kapalı algılanır. Kalıcı değil, aralıklı bir kesinti türüdür.

Kaynak Önerileri

Bu rehberdeki yöntemleri daha derinlemesine uygulamak için aşağıdaki kaynakları da inceleyebilirsiniz:

  • WordPress resmi belgelendirmesinde wp-config.php yapılandırması bölümü.
  • Nginx belgelerinde fastcgi_read_timeout ve proxy_read_timeout yönergeleri.
  • PHP-FPM pm.max_children hesaplaması için topluluk rehberleri ve status_path kullanımı.
  • Query Monitor ve New Relic gibi APM araçlarının ücretsiz sürümleri.
  • WP-CLI handbook sayfasındaki performans ve bakım komutları.

Sonuç

WordPress 504 Gateway Timeout hatası, görünürde basit bir mesaj olsa da ardında çoklu katmandan gelen performans problemlerini barındırır. Doğru yaklaşım; önce hangi katmanın zaman aşımı ürettiğini tespit etmek, ardından PHP ayarlarından Nginx yapılandırmasına, WordPress eklenti/tema denetiminden Cloudflare kurallarına kadar uzanan bütünleşik bir çözüm planı uygulamaktır. Bu rehberdeki adımları düzenli biçimde uyguladığınızda yalnızca mevcut 504 hatasını çözmekle kalmaz, sitenizin genel performansını, güvenilirliğini ve SEO değerini de kalıcı olarak artırırsınız. Uzun vadede sağlıklı bir WordPress kurulumu, iyi izlenen bir sunucu ve disiplinli bir bakım rutini ile mümkündür; 504 sadece bu disiplinin eksik kaldığı noktaları size gösteren bir alarm olarak kabul edilmelidir.

Related posts