502 Bad Gateway ve 504 Gateway Timeout: Reverse Proxy Debug Rehberi

502 Bad Gateway ve 504 Gateway Timeout: Reverse Proxy Debug Rehberi

Bir sabah uyandınız, sitenize giren ziyaretçi tek bir satır görüyor: "502 Bad Gateway" ya da "504 Gateway Timeout". Ne PHP hata mesajı, ne stack trace, ne bir ipucu — sadece çıplak bir kod. İncident response başlangıcı için elinizdeki en sade veri budur.

Bu yazı 5xx ailesi içinde upstream tabanlı hataları — yani web sunucusunun arkasındaki uygulama sunucusu ile yaşadığı iletişim problemlerini — sysadmin gözüyle ele alıyor. 500 Internal Server Error gibi PHP/uygulama hatalarına değil, proxy/gateway katmanına odaklanıyoruz: PHP-FPM, Nginx, LiteSpeed, Apache reverse proxy, Cloudflare ve aralarındaki tüm zincire.

5xx Hata Ailesi: Hangisi Ne Anlama Geliyor?

Tarayıcıda gördüğünüz 5xx kodu, sorunun kabaca hangi katmandan geldiğini söyler. RFC 7231 ve sonraki RFC 9110 kodlar listesi şöyle:

Kod	Adı	Anlamı
500	Internal Server Error	Uygulama içinde yakalanmamış istisna (PHP fatal, Node uncaught, Python traceback)
501	Not Implemented	Sunucu HTTP metodunu tanımıyor (PUT/PATCH desteksiz)
502	Bad Gateway	Reverse proxy upstream'den geçersiz yanıt aldı
503	Service Unavailable	Sunucu geçici olarak yanıt veremiyor (bakım, aşırı yük, rate-limit)
504	Gateway Timeout	Reverse proxy upstream'i beklerken zaman aşımı yaşadı
505	HTTP Version Not Supported	Sunucu HTTP sürümünü desteklemiyor
506	Variant Also Negotiates	İçerik negotiation döngüsü
507	Insufficient Storage	WebDAV depolama yetersiz
508	Loop Detected	WebDAV / CloudLinux LVE limit aşıldı
509	Bandwidth Limit Exceeded	Bant genişliği kotası dolu (cPanel/WHM özel)
510	Not Extended	RFC 2774 protokol genişletme
511	Network Authentication Required	Captive portal kimlik doğrulama

Buna ek olarak Cloudflare'ın kendi proxy katmanı için ayrı bir aralık tanımlanmıştır: 520-527 kodları yalnızca Cloudflare üzerinden geçen istekler için döner ve klasik RFC tablosunda yer almaz. (Bu yazının sonunda detaylı ele alacağız.)

İncident response sırasında ilk yapılacak iş tarayıcıdaki kod ve hangi katmandan döndüğüni anlamaktır. Hata sayfasında cloudflare ibaresi varsa CDN proxy katmanı; nginx veya LiteSpeed görünüyorsa origin web sunucusu konuşuyordur. Bu ayrım, log inceleme sırasını belirler.

HTTP Request Akışı ve Reverse Proxy Mantığı

502 ve 504'ün ortaya çıkış noktasını anlamak için modern bir web isteğinin geçtiği zinciri yatay bir akış olarak çizmek gerekir:

[1] Client (browser)
  ↓ HTTPS
[2] CDN / Cloudflare (opsiyonel)
  ↓ HTTPS / HTTP
[3] Reverse Proxy / Web Server
    (Nginx, LiteSpeed, Apache mod_proxy)
  ↓ fastcgi_pass / proxy_pass
[4] Application Server
    (PHP-FPM, Node.js, Python WSGI/ASGI, Java Tomcat)
  ↓ TCP / Unix socket
[5] Database / Cache
    (MySQL, PostgreSQL, Redis, Memcached)

Her halka bir öncekine yanıt verir. Reverse proxy (3. katman) açısından üstündeki katman (4. katman = uygulama sunucusu) upstream kabul edilir. 502 ve 504 kodları her zaman bu upstream halkasıyla ilgilidir:

• 502 Bad Gateway: Reverse proxy upstream'e ulaştı; ancak upstream geçersiz / boş / okunamayan bir yanıt döndürdü. (Çoğunlukla upstream süreç çökmüş, socket kapanmış, ya da response header bozulmuştur.)
• 504 Gateway Timeout: Reverse proxy upstream'e bağlandı; ancak upstream yanıt vermek için tanımlı timeout süresini aştı. (Yavaş SQL sorgusu, takılı cron, sonsuz döngü, dış API beklemesi.)

İki kodun ayırımını net oturtmak: 502 "upstream cevap verdi ama saçma cevap verdi"; 504 "upstream hiç cevap vermedi, ben de bekledim, bekledim, bıraktım". Çözüm yolları bu ayrımdan başlar.

502 Bad Gateway: Yaygın Nedenler

1. PHP-FPM Pool Çökmesi veya Pool Down

En sık karşılaşılan senaryo. Nginx fastcgi_pass veya LiteSpeed lsapi yolu üzerinden PHP-FPM pool'una istek atar; pool ayakta değilse 502 döner.

# PHP-FPM durumunu kontrol et
systemctl status php-fpm
systemctl status php8.2-fpm   # Debian/Ubuntu

# Pool çalışıyor mu?
ps aux | grep -i fpm
ss -anp | grep php-fpm        # socket dinleniyor mu

# Hızlı toparlama
systemctl restart php8.2-fpm

Restart geçici çözüm; gerçek sebebi log'lar gösterir.

2. OOM Killer (Out of Memory) Devre Dışı Bırakmış

Linux çekirdeği RAM tükendiğinde OOM Killer mekanizması en çok bellek tüketen süreci öldürür. Çoğunlukla bu kurban PHP-FPM worker ya da Node process olur — sessiz sedasız ölür ve siz 502 görürsünüz.

# OOM olaylarını kontrol et
dmesg | grep -i -E 'killed|out of memory'
journalctl -k | grep -i 'killed process'

# Son 24 saatte PHP-FPM restart'ları
journalctl -u php8.2-fpm --since "24 hours ago" | grep -i 'started\|stopped\|killed'

dmesg çıktısında Out of memory: Killed process 12345 (php-fpm) satırı görüyorsanız OOM kurbanı belli demektir. Çözüm: RAM yükseltme, swap ekleme veya pm.max_children değerini düşürerek bellek tavanı kontrol altına alma.

3. pm.max_children Sınırına Ulaşma

PHP-FPM her HTTP isteğine bir worker atar. pm.max_children tanımlı tavanı aşan eşzamanlı istek geldiğinde yeni istekler kuyrukta beklediğinden — listen.backlog dolarsa — 502 üretir.

; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

Boyutlandırma: pm.max_children = (toplam_kullanilabilir_RAM / ortalama_php_worker_boyutu). Ortalama PHP-FPM worker ~30-80 MB tüketir; 4 GB RAM'in 2 GB'ını PHP'ye ayırırsanız ~50 child mantıklıdır.

4. Node.js Uygulamasının Crash Etmesi

Node app'i PM2 veya systemd ile yönetiyorsanız çökme sonrası otomatik restart vardır; ancak restart aralığında gelen istekler 502 alır.

# PM2 durum kontrol
pm2 status
pm2 logs --lines 100 --err

# Process restart sayısı (çok yüksekse uygulama instabil)
pm2 list

# systemd unit ile çalışıyorsa
journalctl -u myapp.service -n 200 --no-pager

Yakalanmamış uncaughtException ya da unhandledRejection Node'u öldürür. Yapısal çözüm: process.on('uncaughtException', ...) ile log alıp graceful shutdown; uzun vadede try/catch + Sentry/Bugsnag entegrasyonu.

5. Upstream Socket / Permission Hatası

Nginx unix socket üzerinden PHP-FPM'ye konuşurken socket dosyasının izinleri yanlışsa 502 döner.

# Socket dosyası ve izinleri
ls -la /var/run/php/php8.2-fpm.sock
# srw-rw---- 1 www-data www-data 0 May 10 14:00

# Nginx'in çalıştığı kullanıcı
ps aux | grep -i nginx | grep -v grep

Nginx www-data olarak çalışıyor ve socket php-fpm:php-fpm aitse ve grup okunma yoksa 502 alırsınız. Pool config'inde:

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

6. fastcgi_pass / proxy_pass Yanlış Yolu Gösteriyor

# Yanlış: PHP-FPM socket buradaki path'te değil
fastcgi_pass unix:/var/run/php5-fpm.sock;

# Doğru: aktif sürüm yolunu kullanın
fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;

Sürüm yükseltme sonrası unutulan path en yaygın 502 sebeplerinden biridir.

7. Cascade: MySQL Bağlantı Timeout

PHP-FPM worker MySQL'e bağlanamayınca uzun süre asılı kalır, sonunda Nginx fastcgi_read_timeout aşılır ve 502/504 cascade oluşur. Origin neden upstream PHP değil, upstream'in upstream'i olan MySQL'dir.

# MySQL ayakta mı?
systemctl status mysql
systemctl status mariadb

# Bağlantı sayısı tavana ulaşmış mı
mysql -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -e "SHOW VARIABLES LIKE 'max_connections';"

504 Gateway Timeout: Yaygın Nedenler

1. Yavaş PHP Script

max_execution_time veya web sunucusu fastcgi_read_timeout aşıldığında 504 üretilir. WordPress + WooCommerce, ağır rapor sayfaları, dış API'ye senkron istek atan kodlar tipik suçlulardır.

# PHP-FPM slow log etkinleştir
# pool config
request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/slow.log

# 5 saniyenin üzerinde çalışan istekleri yakalar
tail -f /var/log/php-fpm/slow.log

Slow log'da görünen stack trace, hangi PHP dosyasının hangi satırda takıldığını söyler.

2. MySQL Slow Query

Index'siz WHERE, çok büyük JOIN, FILESORT üreten ORDER BY'lar saniyeler süren sorgular çıkarır. Web sunucusu beklerken 504 üretir.

-- Slow query log etkinleştir
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

-- Yavaş sorguyu çalıştır, EXPLAIN al
EXPLAIN SELECT * FROM orders WHERE user_id = 123 ORDER BY created_at DESC;

Sonuçta type: ALL (full table scan) görüyorsanız index gerekli:

CREATE INDEX idx_orders_user_created ON orders (user_id, created_at);

3. Dış API / cURL Beklemesi

PHP kodu file_get_contents('https://external-api.com/...') veya curl üzerinden dış servise gidiyorsa ve dış servis cevap vermiyorsa, lokal sunucu beklerken 504 oluşur.

// Yanlış: timeout tanımsız
$response = file_get_contents($url);

// Doğru: timeout + try/catch
$ctx = stream_context_create(['http' => ['timeout' => 5]]);
$response = @file_get_contents($url, false, $ctx);
if ($response === false) {
    error_log('External API timeout: ' . $url);
    // fallback yanıt
}

cURL için CURLOPT_TIMEOUT ve CURLOPT_CONNECTTIMEOUT mutlaka tanımlı olmalıdır.

4. Nginx proxy_read_timeout Düşük

Varsayılan proxy_read_timeout = 60s bazı senaryolar (büyük dosya yükleme, rapor üretimi) için yetersizdir.

location ~ \.php$ {
    fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    fastcgi_read_timeout 300;
    fastcgi_send_timeout 300;
    fastcgi_connect_timeout 60;
    fastcgi_buffer_size 16k;
    fastcgi_buffers 16 16k;
}

# Reverse proxy senaryosunda
location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_read_timeout 300;
    proxy_connect_timeout 60;
    proxy_send_timeout 300;
}

5. LiteSpeed lsphp_max_idle_time

LiteSpeed web sunucusu kullanan paketlerde PHP timeout'u lsphp_max_idle_time ve Max Connections parametreleriyle belirlenir. cPanel altında WHM → LiteSpeed Web Server → Configuration üzerinden ayarlanır.

6. Uzun AJAX Endpoint'leri

WordPress admin-ajax.php üzerinden yapılan dashboard yenilemeleri, eklenti güncellemeleri ve mass action'lar dakikalarca sürebilir. Çözüm:

• AJAX endpoint'ini WP-Cron'a taşıma (asenkron iş)
• Action Scheduler kullanımı
• Progress bar + chunked işleme (her batch 100 satır)

503 + 508 + 509 — Kısa Çözüm

503 Service Unavailable

Üç ana senaryosu vardır:

1. Planlı bakım modu: WordPress .maintenance dosyası, Laravel php artisan down, Magento bakım flag. Çıkış kolay: dosyayı silmek.
2. Imunify360 / mod_security rate-limit: Kötü niyetli istekleri durduran katman meşru kullanıcıyı da yakaladıysa 503 döner. WHM → ImunifyAV/360 logları kontrol; IP whitelist.
3. Backend kuyruk overflow: Nginx listen 80 backlog=N değerinin tükenmesi.

508 Loop Detected (CloudLinux LVE)

cPanel + CloudLinux kullanan paylaşımlı hosting paketlerinde her hesap LVE (Lightweight Virtualized Environment) içinde çalışır. Kullanıcının CPU, RAM veya I/O limiti aştığı an istek 508 ile reddedilir.

# LVE durumu (root)
lveinfo --period=24h --user=KULLANICI

# Anlık limit aşımı
lvetop

Çözüm: kodu optimize etmek (eklenti azaltma, cache); ya da paket yükseltme — daha yüksek LVE limit'i için.

509 Bandwidth Limit Exceeded

cPanel paketinde tanımlı aylık bant genişliği kotanız tükendiğinde döner. WHM → Modify Account → bandwidth artırma; ya da kullanıcı paneli üzerinden paket yükseltme.

Tanı — Buradan Başla

Bir 502/504 alarmı geldiğinde sırasıyla şu adımlar:

Adım 1 — Hata Sayfasında Hangi Katman İmza Atıyor?

Tarayıcı kaynak görüntülemesi veya curl -I https://siteniz.com ile döndürülen Server: header'ını okuyun:

• Server: cloudflare → Cloudflare katmanı; CF dashboard log gerekli
• Server: nginx → Origin Nginx; /var/log/nginx/error.log
• Server: LiteSpeed → cPanel altında LiteSpeed; /usr/local/lsws/logs/error.log
• Server: Apache → /var/log/apache2/error.log veya /var/log/httpd/error_log

Adım 2 — Nginx Error Log

# Son 200 satır, 502/504 olayları
tail -n 500 /var/log/nginx/error.log | grep -E '(upstream|timeout|502|504)'

# Real-time izleme
tail -f /var/log/nginx/error.log

Tipik 502 satırı:

2026/05/10 14:32:11 [error] 1234#0: *567 connect() to unix:/var/run/php/php8.2-fpm.sock failed (2: No such file or directory) while connecting to upstream

Tipik 504 satırı:

2026/05/10 14:35:02 [error] 1234#0: *568 upstream timed out (110: Connection timed out) while reading response header from upstream

Adım 3 — PHP-FPM Slow Log + Error Log

tail -n 200 /var/log/php-fpm/error.log
tail -n 200 /var/log/php-fpm/slow.log

# Son 1 saatte slow log satırı sayısı (sıklık göstergesi)
awk -v d="$(date -d '1 hour ago' '+%Y-%m-%d %H:%M:%S')" '$1" "$2 > d' /var/log/php-fpm/slow.log | wc -l

Adım 4 — OS Seviyesi

# RAM + swap kullanımı
free -m

# CPU + I/O + process snapshot
top -bn1 | head -25
htop  # interaktif

# OOM Killer izleri
dmesg -T | grep -i kill | tail -20

# Disk I/O bottleneck
iostat -x 1 5

# Sistem servislerinin son durumu
systemctl --failed

Adım 5 — Network / Upstream Test

# Yerel PHP-FPM upstream test
curl -I http://127.0.0.1:9000/

# Unix socket var mı, izin doğru mu
ls -la /var/run/php/

# Aktif TCP/UDS bağlantıları
ss -anp | grep -E 'php-fpm|node|nginx'

# MySQL erişim
mysql -uroot -e "SELECT 1;"

Adım 6 — cPanel Tarafı (root erişim yok)

Paylaşımlı pakette /var/log/ okuyamazsınız; cPanel araçları:

• Errors → son PHP hataları
• Resource Usage → CPU/Memory/EP grafikleri (CloudLinux destekli sunucularda)
• Visitors → erişim log'unda 502/504 status kod sayımı

Çözüm Matrisi

PHP-FPM Tuning

; /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 50              ; (RAM_GB * 1024) / avg_worker_size_MB
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500             ; her worker N istek sonrası restart (memory leak savunması)

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

; OPcache (php.ini)
opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=10000
opcache.validate_timestamps=0     ; production: file mtime kontrol yok, deploy sonrası reload

opcache.validate_timestamps=0 deploy script'inizden php -r 'opcache_reset();' veya systemctl reload php-fpm çağrısı yapılmasını gerektirir.

Nginx Timeout + Buffer

http {
    # FastCGI (PHP-FPM)
    fastcgi_connect_timeout 60s;
    fastcgi_send_timeout    300s;
    fastcgi_read_timeout    300s;
    fastcgi_buffer_size     32k;
    fastcgi_buffers         16 32k;
    fastcgi_busy_buffers_size 64k;

    # Reverse proxy (Node/Python upstream)
    proxy_connect_timeout 60s;
    proxy_send_timeout    300s;
    proxy_read_timeout    300s;
    proxy_buffer_size     16k;
    proxy_buffers         16 16k;
    proxy_busy_buffers_size 32k;

    # Klient bağlantısı
    keepalive_timeout 65s;
    send_timeout 60s;

    # Backlog (yüksek trafik)
    # listen 80 backlog=2048;
}

proxy_buffer_size / fastcgi_buffer_size özellikle büyük HTTP header döndüren backend'lerde önemlidir. Set-Cookie header'ları zincirleme JWT taşıyan API'lerde 4 KB default buffer dolar; upstream yanıtın tamamı buffera sığmadığı için Nginx 502 üretir.

MySQL Slow Query Optimizasyonu

-- Index olmadan: type=ALL = full table scan
EXPLAIN SELECT * FROM posts WHERE author_id = 5 AND status = 'published';

-- Composite index oluştur
CREATE INDEX idx_posts_author_status ON posts (author_id, status);

-- max_connections + wait_timeout (my.cnf)
[mysqld]
max_connections = 200
wait_timeout = 600
interactive_timeout = 600
innodb_buffer_pool_size = 1G

WordPress Özel: Query Monitor + LSCache + Redis

# wp-cli ile Query Monitor kurulumu
wp plugin install query-monitor --activate

# Object cache (LSCache veya Redis)
wp plugin install redis-cache --activate
wp redis enable

wp-config.php içine:

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_CACHE_KEY_SALT', 'site1');

LiteSpeed paketinde ise LSCache plugin'i + LiteSpeed Cache Object Cache (Memcached/Redis) tek tıkla devreye alınır.

Cloudflare Üzerinde 524 ve Argo

Cloudflare proxy'si origin'i 100 saniye bekler; üzerine çıkarsa 524 timeout üretir. 100 saniyenin Enterprise plan dışında değiştirilemediğini unutmayın. Pratik çıkış yolları:

• Uzun süren işlemleri asenkron kuyruğa atın (job queue: Redis + worker)
• API endpoint yerine Webhook callback modeline geçin
• Cloudflare Workers ile origin'e dokunmadan edge-side cevap döndürün
• Argo Smart Routing daha hızlı yol seçimi sağlar (latency düşürür); ancak hard 100s sınırını değiştirmez

Önleyici İzleme

Bir kez 502/504 yaşanmadan önce alarm vermek için:

• Sentry / Bugsnag — uygulama içi hata yakalama; PHP-FPM 500 + Node uncaughtException
• Uptime Kuma — açık kaynak monitoring; her 30 saniyede HTTP status kontrol; status değişiminde Telegram/Slack alarm
• Zabbix / Prometheus + Grafana — sunucu metrikleri (CPU, RAM, disk I/O, network)
• PHP-FPM Status Page — /status endpoint ile aktif worker sayısı, kuyruk uzunluğu
• MySQL Performance Schema — yavaş sorgu istatistikleri

# PHP-FPM status endpoint
location ~ ^/(fpm-status|fpm-ping)$ {
    allow 127.0.0.1;
    deny all;
    fastcgi_pass unix:/var/run/php/php8.2-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $fastcgi_script_name;
    include fastcgi_params;
}

curl http://127.0.0.1/fpm-status?json ile JSON çıktı alabilir, Grafana panelinde takip edebilirsiniz.

Canary deploy: Üretime değişiklik atılırken canary adlı bir sunucuya önce gönderip metrikleri 5-10 dakika izleyin. 5xx oranı yükseliyorsa rollback otomatik tetiklensin.

Buyukweb Perspektifi: Hosting ve VDS Farkı

Buyukweb hizmetleri açısından 502/504 senaryoları iki katmana ayrılır:

cPanel Paylaşımlı Paketler

LiteSpeed Web Server + cPanel altyapısında çalışan paylaşımlı hosting paketleri, çoğu 502/504 senaryosunu destek ekibi seviyesinde çözer. Kullanıcı root erişimine sahip olmadığı için:

• PHP version değişimi cPanel MultiPHP Manager üzerinden tek tıkla
• PHP memory_limit, max_execution_time cPanel PHP Options üzerinden
• LiteSpeed Cache ayarları LSCache plugin üzerinden
• Daha ağır senaryolarda Buyukweb destek hattı: 0850 302 60 70

LiteSpeed mimarisi geleneksel Nginx + PHP-FPM kombinasyonuna göre daha az 502 üretir çünkü PHP süreç yönetimini kendi içinde tutar (lsapi).

VDS — Tam Root Erişim

Buyukweb VDS paketlerinde sysadmin/devops kontrolü tamamen sizdedir:

• PHP-FPM pm.max_children, OPcache, slow log tuning
• Nginx fastcgi_read_timeout, buffer sizing
• MySQL max_connections, slow query log, EXPLAIN-tabanlı index optimizasyonu
• Redis Object Cache deployment
• Sentry/Uptime Kuma kurulumu

Bursa Tier 3 veri merkezinde barındırılan KVM tabanlı VDS'lerimiz tüm bu manuel tuning için uygundur. Detaylı paket karşılaştırması için paket karşılaştırma sayfasını inceleyebilirsiniz.

Cloudflare Özel Hata Kodları (520-527)

Cloudflare proxy katmanı origin'e ulaşamadığında veya origin'den anormal davranış gördüğünde RFC dışı özel kodlar üretir:

Kod	Anlam	Tipik Sebep
520	Web server returned unknown error	Origin beklenmedik response döndürdü (boş header, malformed)
521	Web server is down	Origin TCP port 80/443 cevap vermiyor; firewall veya servis down
522	Connection timed out	Origin TCP handshake'i tamamlamıyor; yoğun yük veya firewall drop
523	Origin is unreachable	DNS / routing problemi; A record yanlış IP
524	A timeout occurred	Origin TCP'ye cevap verdi ama 100s içinde HTTP yanıtı vermedi
525	SSL handshake failed	Origin SSL/TLS sertifikası geçersiz
526	Invalid SSL certificate	Origin SSL doğrulanamadı (Full Strict modunda)
527	Railgun error	Cloudflare Railgun bağlantı sorunu (eski; deprecated)

Cloudflare gösterdiği zaman önce origin status'unu doğrudan kontrol edin: curl -I --resolve siteniz.com:443:ORIGIN_IP https://siteniz.com ile Cloudflare'ı atlayarak test. Origin sağlamsa Cloudflare tarafı; origin de hatalıysa origin sysadmin tarafı.

521/522 görüyorsanız ilk bakacağınız:

# Origin firewall Cloudflare IP'lerine açık mı
ufw status | grep -i 443

# Origin web sunucusu ayakta mı
systemctl status nginx
ss -tulnp | grep -E ':(80|443)'

Sık Sorulan Sorular

502 Bad Gateway hatasını kullanıcı görür ama log'da hiç giriş yok — neden?

İki tipik sebep vardır: (1) Log dosyası rotate edilmiş ve sıkıştırılmıştır; zgrep '502' /var/log/nginx/*.log.gz ile sıkıştırılmış arşivde arayın. (2) Hata Cloudflare/CDN katmanından dönüyordur; origin'e ulaşmamıştır, doğal olarak origin log boş. Tarayıcı response Server: header'ını okuyup hata sayfasının hangi katmandan döndüğünü doğrulayın.

504 hatası alıyorum ama PHP max_execution_time'ı 300'e çıkardım, yine 504 — neden?

PHP max_execution_time tek başına yetmez. Web sunucusu seviyesinde fastcgi_read_timeout (Nginx) veya lsphp_max_idle_time (LiteSpeed), ardından Cloudflare seviyesinde 100s upstream timeout zincirleme şekilde geçilmesi gerekir. En küçük timeout, gerçek limit'tir. Üç katmanı da yükseltmediyseniz 504 devam eder.

PHP-FPM pm.max_children değerini ne kadar artırmalıyım?

Formül basit: (toplam_RAM_MB - sistem_diğer_kullanım) / ortalama_worker_size_MB. Ortalama PHP-FPM worker 30-80 MB tüketir (WP + plugin ağı varsa daha çok). 4 GB RAM'in 1 GB'ı sistem + MySQL + Redis kullanımına ayrılırsa, kalan 3 GB ile ortalama 50 MB worker varsayımıyla pm.max_children = 60 makul. Aşırı yüksek değer (örn. 200) RAM'i tüketip OOM Killer'ı tetikler ve 502 cascade yaratır.

Cloudflare 524 timeout çözmek için Enterprise plana mı geçmek gerekiyor?

100 saniye limitini değiştirmek için Enterprise plan gerekir. Ancak çoğu senaryo Enterprise gerekmeden çözülebilir: uzun işlemleri arka plan kuyruğuna alın (Redis + worker), kullanıcıya hemen 202 Accepted dönüp ardından webhook/SSE ile sonuç bildirin. Cloudflare Workers da edge-side hesaplamayı origin'e dokunmadan bitirmenizi sağlar.

502 alarken site bazen açılıyor, bazen açılmıyor — bu nasıl debug edilir?

İntermittent (kesintili) 502, çoğunlukla kapasite tabanlıdır: trafik tepelerinde pm.max_children veya max_connections (MySQL) limitine ulaşılır, isteklerin bir kısmı zaman aşımına uğrar. Çözüm akışı: (1) PHP-FPM status sayfası enable + Grafana ile dakikalık aktif worker grafiği; (2) 502 anındaki worker doluluk oranına bakın; (3) limit'e çarpıyorsa pm.max_children artırın veya request başına süreyi düşürün (cache, query optimizasyonu).

Sonuç

502 Bad Gateway ve 504 Gateway Timeout — bu iki kod size sunucu mimarinizdeki bir kırılganlığı gösteriyor. Reverse proxy katmanı ile upstream uygulama sunucusu arasındaki sözleşme bozulmuş demektir: ya konuşan taraf cevap veremez halde (502), ya da çok yavaş (504).

İncident response sırasında yol haritası açık: hata kodu → log katmanı → süreç durumu → OS seviyesi → upstream test → tuning. Bu zinciri kasli takip ettiğinizde dakikalar içinde gerçek nedeni izole edersiniz.

Buyukweb cPanel paketleri çoğu 502/504 senaryosunu otomatik atlatır; VDS sahipleri ise tüm tuning'i kendi ellerinde yapar. Hangi katmanda olursanız olun destek için 0850 302 60 70 numaramız size yardımcı olur.

---

İlgili Büyükweb Hizmetleri

Sunucu yönetimi ve performans tuning için Buyukweb hizmetleri:

• VDS Sunucu
• Paket Karşılaştırma
• cPanel Web Hosting
• Fiziksel Dedicated Sunucu
• Sunucu Barındırma (Colocation)

Sorularınız için 0850 302 60 70 numaralı destek hattımıza veya iletişim sayfamıza yazabilirsiniz.