504 Gateway Timeout Hatası Nedir, Nasıl Düzeltilir?

Bir ürün içe aktarma işlemi başlattınız, yedek alıyordunuz ya da WooCommerce sipariş raporu çekiyordunuz; sayfa uzun süre yüklendi ve sonunda 504 Gateway Timeout ekranı geldi. Bu hata, "sunucu bozuldu" demez. Tam olarak şunu der: aradaki sunucu, arkadaki sunucudan cevap bekledi ve sabrı tükendi. Yani bir şey ölmedi — bir şey çok uzun sürdü. Bu ayrım, 504'ün neden diğer 5xx hatalarından farklı bir teşhis yöntemi gerektirdiğini açıklar.

Türkçe kaynakların neredeyse tamamı burada tek bir tavsiye veriyor: "timeout süresini artırın." Bu tavsiye sorunu çözmez, gizler. Daha kötüsü, çoğu zaman 504'ü 502'ye çevirir — çünkü süre uzadıkça takılan istek daha fazla bellek ve süreç tüketir, havuz dolar ve sunucu bu kez bağlantıyı tamamen reddeder. Bu yazıda tersini yapacağız: önce zaman aşımı zincirindeki hangi halkanın önce dolduğunu tespit edeceğiz, sonra o halkayı büyütmek yerine altta yatan yavaşlığı — yavaş MySQL sorgusunu, takılan PHP işlemini, cevap vermeyen bir dış servisi — bulup düzelteceğiz. Süreyi artırmak listenin son maddesi, ilk maddesi değil.

504 Gateway Timeout Hatası Ne Anlama Geliyor#

504, bir ara sunucunun (gateway veya proxy) verdiği hatadır. Yani bu hatayı üreten makine, isteği asıl işleyen makine değildir; onu bekleyen makinedir.

Tipik bir modern kurulumda istek şu zincirden geçer:

Tarayıcı → Cloudflare → Nginx → PHP-FPM → MySQL

Bu zincirdeki her halkanın kendi sabır sınırı vardır. Biri sınırını aştığında, kendisinden önceki halkaya 504 döndürür. Bu yüzden 504 gördüğünüzde sorulacak ilk soru "neden yavaş" değil, "bu 504'ü kim üretti" olmalıdır. Cevabı, hata sayfasının kendisi ele verir:

Cloudflare kullanıyorsanız ve hata sayfasında Ray ID varsa, sorun neredeyse kesinlikle origin sunucunuzdadır; Cloudflare sadece haberciyi oynuyordur.

Bir de sık karıştırılan bir durum var: 504 ile tarayıcının ERR_CONNECTION_TIMED_OUT hatası aynı şey değildir. 504'te bir sunucu size cevap vermiştir — cevabın içeriği "bekleyemedim"dir. ERR_CONNECTION_TIMED_OUT'ta hiç cevap gelmez; bu ağ katmanı sorunudur ve err connection timed out hatası yazısında ayrı ele alınıyor.

Zaman Aşımı Zinciri: Hangi Değer Önce Dolar#

Bu bölüm, Türkçe içerikte neredeyse hiç anlatılmayan ve 504 teşhisinin merkezinde duran konudur. Bir isteğin üzerinde aynı anda birden fazla süre sınırı vardır ve gördüğünüz hata, hangisinin önce dolduğuna göre değişir.

Şimdi kritik nokta: PHP'nin max_execution_time'ı Nginx'in fastcgi_read_timeout'undan küçükse, 504 hiç görmezsiniz. PHP kendini 30. saniyede durdurur, ölümcül hata üretir ve Nginx'e düzgün bir 500 döner. Sayfada göreceğiniz şey "Maximum execution time of 30 seconds exceeded" olur — bu senaryonun ayrıntısı maximum execution time exceeded hatası yazısında.

504 görüyorsanız bu, PHP'nin kendi sınırının dolmadığı anlamına gelir. Bunun iki tipik sebebi vardır:

1. max_execution_time zaten yüksek (örneğin 300 saniyeye çıkarılmış) ve Nginx'in 60 saniyesi ondan önce doluyor.
2. PHP'nin sayacı işlemiyor. Bu en çok yanıltan durumdur: max_execution_time yalnızca PHP'nin kendi kodunu çalıştırdığı süreyi sayar. Bir MySQL sorgusu, bir curl isteği veya bir dosya kilidi beklerken geçen süre bu sayaca yazılmaz. Yani 20 dakika süren bir veritabanı sorgusu boyunca PHP'nin sayacı hiç ilerlemez; sonunda 504'ü Nginx üretir.

İkinci madde, "PHP limitini artırdım ama hâlâ 504 alıyorum" şikâyetinin gerçek açıklamasıdır. Beklemenin PHP dışında geçtiği her senaryoda PHP limitiyle oynamak hiçbir işe yaramaz.

Sizde hangi değerlerin geçerli olduğunu görmek için:

php -i | grep -E "max_execution_time|max_input_time|memory_limit"
grep -rE "fastcgi_read_timeout|proxy_read_timeout" /etc/nginx/
grep -rE "request_terminate_timeout" /etc/php/*/fpm/pool.d/

Paylaşımlı hostingde bunları göremiyorsanız, kök dizine geçici bir bilgi.php koyup phpinfo() çıktısına bakmak yeterli olur — işiniz bitince dosyayı mutlaka silin.

Asıl Sebebi Bulmak: Yavaş MySQL Sorgusu#

504'lerin en büyük tek kaynağı yavaş veritabanı sorgularıdır. Ve bunu bulmanın "tahmin etmek" dışında somut bir yolu var: slow query log.

MySQL/MariaDB'de yavaş sorgu günlüğünü açın:

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

Kalıcı olması için my.cnf dosyasına yazın:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
log_queries_not_using_indexes = 1

Birkaç saat çalıştıktan sonra günlüğe bakın. Tipik bir kayıt şuna benzer:

# Time: 2026-08-11T13:41:02.114Z
# Query_time: 41.882  Lock_time: 0.000  Rows_sent: 18  Rows_examined: 2841190
SELECT p.ID FROM wp_posts p
INNER JOIN wp_postmeta pm ON p.ID = pm.post_id
WHERE pm.meta_key = '_stock_status' AND pm.meta_value = 'instock'
ORDER BY p.post_date DESC;

Buradaki en önemli satır Query_time değil, Rows_examined'dır. 18 satır döndürmek için 2,8 milyon satır taranmışsa, bu sorguda indeks kullanılmıyor demektir. Bu, tek başına 40 saniye eder ve doğrudan 504 üretir.

Sorunun kaynağını doğrulamak için sorguyu EXPLAIN ile inceleyin:

EXPLAIN SELECT p.ID FROM wp_posts p
INNER JOIN wp_postmeta pm ON p.ID = pm.post_id
WHERE pm.meta_key = '_stock_status';

Çıktıda type sütunu ALL ise tam tablo taraması yapılıyordur; key sütunu NULL ise hiçbir indeks kullanılmıyordur. WordPress/WooCommerce sitelerinde bu neredeyse her zaman wp_postmeta tablosunda olur ve şişmiş _transient_ kayıtları başlıca suçludur.

Anlık durumu görmek de çok işe yarar. Site 504 verirken şu komutu çalıştırın:

SHOW FULL PROCESSLIST;

Time sütununda 30-40 saniyedir çalışan bir sorgu görüyorsanız, suçluyu yakaladınız demektir. State sütunu Sending data, Copying to tmp table veya Locked diyorsa, sorunun cinsini de öğrenmiş olursunuz. Locked özellikle önemlidir: sorgu yavaş değildir, başka bir sorgunun tabloyu bırakmasını bekliyordur — bu durumda hızlandırmanız gereken sorgu, gördüğünüz sorgu değildir.

Veritabanı tarafında yapılacak yapılandırma iyileştirmeleri için mysql mariadb performans optimizasyonu yazısı ayrıntılı bir başvuru kaynağıdır.

Takılan PHP İşlemini Bulmak#

Yavaşlık veritabanında değilse, PHP tarafında takılan bir süreç vardır. Bunu görmenin en doğrudan yolu PHP-FPM'in slow log özelliğidir — ve bu özellik, PHP'nin o anda hangi satırda beklediğini yığın izi (stack trace) olarak yazar.

Havuz yapılandırmanıza ekleyin (/etc/php/8.3/fpm/pool.d/www.conf):

slowlog = /var/log/php-fpm-slow.log
request_slowlog_timeout = 10s

PHP-FPM'i yeniden başlatın ve günlüğü izleyin:

systemctl reload php8.3-fpm
tail -f /var/log/php-fpm-slow.log

10 saniyeden uzun süren her istek için şuna benzer bir kayıt düşer:

[11-Aug-2026 13:52:44]  [pool www] pid 21883
script_filename = /home/kullanici/public_html/index.php
[0x00007f0e] curl_exec() /home/kullanici/public_html/wp-content/plugins/kargo-entegrasyon/api.php:118
[0x00007f0e] fiyat_sorgula() /home/kullanici/public_html/wp-content/plugins/kargo-entegrasyon/hooks.php:42

Bu çıktı her şeyi söyler: istek curl_exec() içinde takılmış, yani bir dış API cevap vermiyor. Bu vakada MySQL'i optimize etmek, PHP limitini artırmak veya Nginx timeout'unu büyütmek hiçbir şeyi düzeltmez. Doğru çözüm, o curl çağrısına makul bir zaman aşımı koymaktır:

curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, 5);
curl_setopt($ch, CURLOPT_TIMEOUT, 10);

Yıllardır gördüğüm 504'lerin şaşırtıcı bir kısmı tam olarak budur: sitenin kendisi hızlıdır, bir kargo/ödeme/stok entegrasyonunun uzak sunucusu cevap vermiyordur ve zaman aşımı tanımlanmadığı için PHP sonsuza kadar bekler.

Slow log yoksa, canlı süreçlere bakarak da fikir edinebilirsiniz:

ps aux | grep php-fpm | sort -k10 -r | head

TIME sütunu yüksek olan süreçler uzun süredir CPU yakıyordur; htop ile aynı listeyi canlı olarak da izleyebilirsiniz.

Timeout Değerini Artırmak: Ne Zaman Doğru, Ne Zaman Yanlış#

Süreyi artırmak her zaman yanlış değildir — yanlış olan, teşhisten önce yapmaktır.

Artırmak doğrudur eğer işlem doğası gereği uzun sürüyorsa ve bunu biliyorsanız: tam site yedeği alma, 50.000 satırlık ürün içe aktarma, büyük bir veritabanı taşıma, yıllık rapor üretme. Bu işlemler zaten dakikalar sürer ve 60 saniyelik bir sınıra sığmaları beklenemez.

Artırmak yanlıştır eğer normalde 1 saniyede açılan bir sayfa artık 60 saniyede açılmıyorsa. Burada süreyi uzatmak, hastalığı tedavi etmez; sadece ateşin ölçüldüğü termometreyi kırar. Üstelik gerçek bir zarar da verir: her takılan istek bir PHP-FPM süreci işgal eder. Zaman aşımını 60'tan 300 saniyeye çıkardığınızda, her takılan istek beş kat daha uzun süre havuzda kalır. Havuz dolduğunda artık 504 değil, 502 Bad Gateway almaya başlarsınız — hata daha kötü bir hâle dönüşmüştür. Bu geçişin mekaniği 502 bad gateway hatası çözümü yazısında ayrıntılı anlatılıyor.

Gerçekten artırmanız gerekiyorsa, sadece o işlemin çalıştığı konum için artırın; tüm siteye uygulamayın.

Nginx tarafında, yönetim paneline özel bir kural:

location = /wp-admin/admin-ajax.php {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    include fastcgi_params;
}

Apache + mod_proxy_fcgi tarafında:

<IfModule mod_proxy_fcgi.c>
    ProxyTimeout 300
</IfModule>

PHP tarafında, sadece o betiğin içinde:

set_time_limit(300);
ini_set('memory_limit', '512M');

Değişiklikten sonra Nginx yapılandırmasını mutlaka doğrulayın:

nginx -t && systemctl reload nginx

Apache ve Nginx bu senaryolarda farklı davranır: Apache'de ProxyTimeout tüm proxy bağlantılarını kapsarken, Nginx FastCGI ve HTTP proxy için ayrı ayarlar kullanır — hangisini düzenlediğinizi karıştırmamak için önce site bloğunun fastcgi_pass mı yoksa proxy_pass mı kullandığına bakın.

Adım Adım 504 Teşhis Akışı#

Aşağıdaki sırayı bozmadan uygulayın; her adım bir ihtimali eler.

1. 504'ü kimin ürettiğini belirleyin. Hata sayfasında Cloudflare Ray ID var mı, "nginx" yazısı mı var? Cloudflare kullanıyorsanız DNS'te turuncu bulutu geçici olarak kapatıp origin'i doğrudan test edin — hata devam ediyorsa sorun sunucunuzdadır.
2. Hangi URL'lerin etkilendiğini daraltın. Tüm site mi, sadece /wp-admin mi, yalnızca tek bir form gönderimi mi? Tek bir işlem etkileniyorsa suçlu o işlemin kodudur; tüm site etkileniyorsa altyapıdadır.
3. Süreyi ölçün. Hatanın kaç saniyede geldiğini not edin:

curl -o /dev/null -sS -w "toplam: %{time_total}s | ilk bayt: %{time_starttransfer}s\n" https://ornek-siteniz.com/agir-sayfa

Süre tam 60 saniyeyse Nginx varsayılanı, tam 100 saniyeye yakınsa Cloudflare sınırı devrededir. Bu tek sayı, zincirdeki hangi halkanın konuştuğunu neredeyse kesinleştirir.

4. Hata anında SHOW FULL PROCESSLIST çalıştırın. Uzun süren sorgu varsa veritabanı tarafındasınız.
5. PHP-FPM slow log'unu açın ve hatayı tekrarlatın. Yığın izinde curl_exec, file_get_contents, mysqli_query veya sleep görüyorsanız suçlu satır elinizdedir.
6. Son değişikliği geri alın. Hata belirli bir eklenti/tema güncellemesinden veya deploy'dan sonra başladıysa, önce geri alın; teşhis sonra gelir.
7. Kaynak doygunluğunu kontrol edin. htop ile CPU'ya, free -h ile belleğe bakın. Sunucu takas alanına düşmüşse her şey yavaşlar ve 504 bir semptomdan ibarettir.
8. En son, gerekliyse, süreyi artırın — ve yalnızca ilgili konum için.

504 Hatasını Kalıcı Olarak Önlemek#

Uzun işlemleri istek döngüsünden çıkarın. Bu, en kalıcı çözümdür. Bir kullanıcının tarayıcısı, 3 dakikalık bir toplu içe aktarmayı beklemek için yanlış yerdir. İşi bir kuyruğa alın, arka planda çalıştırın, kullanıcıya "işlem başlatıldı" deyin. WordPress'te bu genelde WP-CLI ile ya da gerçek bir cron görevi tanımlayarak yapılır:

wp import urunler.xml --authors=create --allow-root

Dış çağrılara zaman aşımı koyun — istisnasız. Kodunuzdaki her curl, her file_get_contents, her API çağrısı bir zaman aşımı taşımalıdır. Bunu yapmayan tek bir entegrasyon, tüm sitenizi bir başkasının sunucusunun sağlığına bağımlı hâle getirir.

Veritabanı bakımını rutine bağlayın. Şişmiş wp_options autoload verisi, temizlenmemiş transient kayıtları ve indekssiz meta sorguları zamanla birikir. Düzenli optimizasyon, 504'ün en yaygın kaynağını kurumadan tutar.

Önbellekleme katmanı ekleyin. Sayfa önbelleği, PHP'nin ve MySQL'in hiç devreye girmediği anlamına gelir; önbellekten dönen bir sayfada zaman aşımı olamaz. Nesne önbelleği ise tekrarlanan sorguları belleğe alarak veritabanı baskısını düşürür.

İzleme kurun ve eşiği düşük tutun. Sitenizin yanıt süresini izleyin; ortalama 300 ms'den 3 saniyeye çıktığında haberiniz olsun. 504 gördüğünüzde iş işten geçmiştir; asıl kazanç, 504'e giden yokuşu erken fark etmektir.

Sıkça Sorulan Sorular#

504 hatası benim internetimden mi kaynaklanıyor#

Hayır, 504 sunucu tarafı bir hatadır ve bağlantınızla ilgisi yoktur. Bu kodu üreten şey, isteğinizi ileten bir ara sunucunun arkadaki sunucudan zamanında cevap alamamasıdır; sizin bağlantınız isteği ve cevabı başarıyla taşımıştır. İnternet bağlantınız kaynaklı bir sorun olsaydı tarayıcı size 504 yerine ERR_CONNECTION_TIMED_OUT gibi bir ağ hatası gösterirdi. Yine de doğrulamak isterseniz aynı sayfayı mobil veriyle veya farklı bir ağdan açmayı deneyin; sonuç değişmiyorsa sorun kesinlikle sunucudadır.

504 ile 502 arasındaki fark nedir#

504 "arkadaki sunucu zamanında cevap vermedi", 502 ise "arkadaki sunucudan geçersiz veya bozuk bir cevap geldi" demektir. Pratikte 504'te bir bekleme vardır; sayfa uzun süre yüklenir ve sonra hata gelir. 502'de ise hata genellikle anında gelir, çünkü bağlantı kurulamamış veya süreç ölmüştür. İkisi birbirine dönüşebilir: zaman aşımı süresini artırdığınızda takılan istekler süreç havuzunu doldurur ve aldığınız hata 504'ten 502'ye kayar. Bu yüzden 502 görmeye başladıysanız, bir önceki adımda timeout değerini artırıp artırmadığınızı hatırlamak teşhisi hızlandırır.

Timeout süresini artırmak 504 hatasını çözer mi#

Sadece işlem doğası gereği uzunsa çözer, aksi halde sorunu erteler. Yedekleme, toplu içe aktarma veya büyük rapor üretimi gibi zaten dakikalar süren işlemler için süreyi artırmak doğru ve gereklidir. Ancak normalde saniyeler içinde açılan bir sayfa artık dakikalarca sürüyorsa, süreyi uzatmak yalnızca hatanın görünme anını geciktirir ve bu arada her takılan istek bir sunucu süreci işgal etmeye devam eder. Süre artırımı, teşhisin sonucunda verilen bilinçli bir karar olmalı; teşhisin yerine geçen bir refleks değil.

Yavaş sorguyu nasıl bulurum#

MySQL'in slow query log özelliğini açıp long_query_time değerini 2 saniyeye çekmek en güvenilir yöntemdir. Birkaç saat sonra günlükte biriken kayıtlarda Query_time yüksek olanlara değil, Rows_examined sayısı Rows_sent sayısından orantısız büyük olanlara odaklanın; bu, indeks kullanılmadığının işaretidir. Anlık teşhis için hata tam yaşanırken SHOW FULL PROCESSLIST komutunu çalıştırıp Time sütunu yüksek satırlara bakabilirsiniz. Bulduğunuz sorguyu EXPLAIN ile inceleyerek hangi tabloda tam tarama yapıldığını netleştirin.

Paylaşımlı hostingde 504 hatasını kendim çözebilir miyim#

Kısmen çözebilirsiniz; sunucu seviyesindeki timeout değerlerine erişiminiz olmasa da asıl sebebe müdahale edebilirsiniz. Ağır eklentileri devre dışı bırakmak, sayfa önbelleği kurmak, veritabanındaki gereksiz transient kayıtlarını temizlemek, dış API entegrasyonlarına zaman aşımı eklemek ve toplu işlemleri küçük parçalara bölmek panelden yapılabilir işlerdir. Bunlar yetmiyorsa hosting sağlayıcınıza slow query log veya PHP slow log çıktısını ileterek destek kaydı açın; somut bir log satırı, "sitem yavaş" demekten çok daha hızlı sonuç verir.

Cloudflare kullanırken 504 alıyorum, sorun Cloudflare'de mi#

Neredeyse her zaman hayır; Cloudflare yalnızca origin sunucunuzun geç kaldığını size bildiriyordur. Cloudflare origin'inizden belirli bir süre içinde yanıt bekler ve bu süre dolduğunda kendi hata sayfasını gösterir, ama gecikmenin kaynağı sizin sunucunuzdur. Doğrulamak için alan adının DNS kaydındaki proxy'yi geçici olarak kapatıp siteyi doğrudan test edin; hata sürüyorsa sorun kesin olarak origin tarafındadır. Uzun süren işlemleri Cloudflare'in beklediği süreye sığdıramıyorsanız, o işlemleri arka plana taşımak kalıcı çözümdür.

504 hatası SEO'ma zarar verir mi#

Kısa süreli 504 kalıcı zarar vermez ama tekrar ederse verir. Googlebot 504 aldığında sayfayı hemen dizinden çıkarmaz; geçici bir sorun kabul edip daha sonra tekrar dener. Ancak tarama sırasında sürekli zaman aşımı yaşayan bir sitenin tarama bütçesi düşürülür, yeni içerikler daha geç dizine alınır ve uzun süren vakalarda sayfalar dizinden düşer. Ayrıca 504 alan gerçek kullanıcılar siteyi terk ettiği için hemen çıkma oranı bozulur; bu da dolaylı olarak sıralamayı etkiler.

Kapanış#

504 Gateway Timeout, bir arıza bildirimi değil bir sabır bildirimidir: zincirdeki bir halka beklemekten vazgeçmiştir. Doğru teşhis, "hangi halka konuştu" sorusuyla başlar — hatanın tam 60 saniyede mi yoksa 100 saniyeye yakın mı geldiğini ölçmek çoğu zaman tek başına cevabı verir. Ardından SHOW FULL PROCESSLIST, slow query log ve PHP-FPM slow log üçlüsü, suçluyu dosya ve satır numarasına kadar daraltır. Yıllardır gördüğüm vakaların büyük kısmında suçlu, indekssiz bir meta sorgusu ya da zaman aşımı tanımlanmamış bir dış API çağrısıydı; hiçbirinde çözüm "timeout'u artırmak" değildi. Süreyi artırmak, ancak işlemin gerçekten uzun sürdüğünü kanıtladıktan sonra ve yalnızca o konum için yapılması gereken son adımdır.

Bu teşhisin gerektirdiği araçların çoğu — slow query log, PHP-FPM havuz ayarları, Nginx timeout blokları — sunucu seviyesinde erişim ister. Paylaşımlı pakette bu ayarlara ulaşamıyor ve 504'ler tekrarlıyorsa VDS sunucu tarafına geçmek, zaman aşımı zincirinin her halkasını kendi elinize almak demektir. Yavaşlığın kaynağı yoğun trafik ve ağır veritabanı işlemleriyse yüksek performanslı sunucu paketleri CPU ve disk tarafındaki darboğazı doğrudan hedefler. WooCommerce gibi sipariş yoğun bir yapıda çalışıyorsanız e-ticaret hosting paketleri bu tür işlemler için ayarlanmış kaynak profilleriyle gelir. Log okumak, sorgu optimize etmek ve havuz ayarlarını yönetmek istemiyorsanız sunucu yönetimi hizmeti bu işi devralır.