WordPress 502 Bad Gateway Hatası: Nedenleri ve Çözüm Rehberi
WordPress 502 Bad Gateway hatası, sitenizi ziyaret eden kullanıcıların beyaz veya gri bir ekranla karşılaştığı, Google ve Yandex gibi arama motorlarının da tarama sırasında başarısız bir yanıt aldığı sinir bozucu bir sunucu tarafı hatasıdır. Bu hata doğrudan WordPress çekirdek kodundan değil, WordPress’in üzerinde çalıştığı web sunucusu (Nginx veya Apache), PHP-FPM, ters vekil sunucu (reverse proxy) ya da CDN (Cloudflare gibi) katmanlarından kaynaklanır. Bu rehberde 502 Bad Gateway hatasının ne anlama geldiğini, en sık görülen nedenlerini, hatayı adım adım nasıl teşhis edeceğinizi ve WordPress sitenizde kalıcı olarak nasıl çözeceğinizi uygulamalı örneklerle anlatacağız.
502 Bad Gateway Hatası Nedir?
502 Bad Gateway, HTTP standardında “geçit (gateway) olarak görev yapan bir sunucu, yukarı akıştaki (upstream) sunucudan geçersiz bir yanıt aldı” anlamına gelen bir durum kodudur. WordPress sitenizde 502 hatası görüyorsanız, ziyaretçinin tarayıcısı ile PHP’yi gerçekten çalıştıran süreç arasında en az iki sunucu vardır ve bu sunuculardan biri diğerinden beklenen yanıtı alamamıştır. Tipik bir WordPress yığınında zincir şöyledir: Tarayıcı → CDN/Cloudflare → Nginx/Apache → PHP-FPM → MySQL. Bu zincirin herhangi bir halkasında kopukluk yaşanırsa kullanıcıya 502 hatası döner.
502 hatası, 500 Internal Server Error ile sıkça karıştırılır. Ancak aralarında önemli bir fark vardır: 500 hatası doğrudan uygulamanın (PHP/WordPress) içinden fırlar ve genellikle error log’a ayrıntılı bir mesaj düşer. 502 ise iki sunucu arasındaki iletişim hatasıdır; bu yüzden teşhis için sadece WordPress debug log’una değil, web sunucusu ve PHP-FPM log’larına da bakmanız gerekir. 503 Service Unavailable hatası ise sunucunun o an aşırı yüklü veya bakımda olduğunu, 504 Gateway Timeout ise upstream’in yanıt vermesinin çok uzun sürdüğünü gösterir. Dolayısıyla 502 ve 504 birçok durumda aynı kök nedenden (yavaş PHP, yetersiz worker) kaynaklanır ve çözümleri büyük ölçüde örtüşür.
502 Bad Gateway’in Tarayıcıda Görünümü
Kullanılan web sunucusuna ve CDN’e göre hata mesajının yazımı değişebilir. Aynı altta yatan sorunu anlatan yaygın varyasyonlar şunlardır: 502 Bad Gateway, 502 Bad Gateway nginx, HTTP Error 502, Error 502, Bad Gateway Error, Temporary Error (502), Cloudflare ekranında Web server is returning an unknown error (Error 502). Kullanıcıya gösterilen sayfa boş beyaz, sade bir Nginx hata sayfası ya da tamamen özelleştirilmiş bir CDN hata ekranı olabilir.
Bu Hata Neden Önemli? İşletmeniz İçin Riskleri
502 Bad Gateway hatası sadece bir “teknik sorun” değildir; doğrudan gelirinizi, marka itibarınızı ve SEO performansınızı etkiler. Bir e-ticaret sitesinde 502 gören müşteri büyük olasılıkla sepetini tamamlayamadan çıkacak ve çoğu zaman rakibe geçecektir. Kurumsal bir blogda sürekli 502 alan ziyaretçi, o markaya olan güvenini hızla yitirir. Google Search Console’un Tarama İstatistikleri (Crawl Stats) bölümünde tekrar eden 502 yanıtları görürseniz bu, arama motorlarının sitenizi daha az sıklıkla taramaya başlayacağı anlamına gelir; uzun vadede indekslenme hızı ve organik trafik düşer.
Ayrıca 502 hataları çoğu zaman kısa sürelidir (aralıklı olarak görünüp kaybolur), bu da teşhisi zorlaştırır. Kullanıcı hata gördüğünde sayfayı yeniler ve 2–3 deneme sonunda site açılır. Bu durumda siz “her şey yolunda” sanarsınız, ancak arkaplanda yüzlerce başarısız istek birikmiş olabilir. Bu yüzden uptime izleme araçları (UptimeRobot, Better Uptime, Pingdom gibi) ile 5xx yanıtlarını proaktif olarak takip etmek, 502 hatalarını kullanıcıdan önce yakalamanın en güvenilir yoludur.
WordPress’te 502 Bad Gateway Hatasının Başlıca Nedenleri
502 hatasının kök nedenlerini üç ana başlıkta toplayabiliriz: sunucu kaynakları, yapılandırma sorunları ve dış faktörler. Her birini ayrıntısıyla inceleyelim.
1. PHP-FPM Worker Sayısının Yetersiz Olması
En sık görülen neden budur. PHP-FPM, gelen her PHP isteğini bir “worker” süreciyle işler. Trafik artışlarında mevcut worker’lar dolarsa, Nginx upstream olarak PHP-FPM’e ulaşamaz ve ziyaretçiye 502 döner. Özellikle kampanya dönemlerinde WooCommerce mağazalarında, viral olan blog yazılarında ve kötü optimize edilmiş sorgularda bu problem hızla tetiklenir. Belirti: Saatlerce sorunsuz çalışan site, ani trafik sıçramalarında 502 vermeye başlar ve trafik normale döndüğünde kendiliğinden düzelir.
2. PHP Bellek Limiti (memory_limit) Aşımı
Bir PHP süreci, memory_limit değerinin üzerinde bellek tüketmeye çalıştığında fatal error alır ve çoğu zaman bu hata upstream tarafında 502 olarak görünür. Ağır Elementor sayfaları, büyük medya kütüphanesi, toplu ürün içe aktarımları, cache ön ısıtma (cache warming) işlemleri veya kötü yazılmış eklentiler bellek tüketimini kolayca 256 MB’ın üzerine çıkarabilir. Çoğu modern hosting sağlayıcısı varsayılan olarak 256 MB veya 512 MB limit sunar, ancak WooCommerce ve Elementor kullanan sitelerde bu değerin 512 MB’a çıkarılması önerilir.
3. Nginx veya Apache Timeout Ayarları
Nginx’te fastcgi_read_timeout, Apache’de ProxyTimeout süresi kısa ayarlanmışsa ve bir PHP betiği bu süreden uzun çalışırsa web sunucusu upstream ile bağlantıyı kopartır ve 502 döner. Yedek alma, büyük sitemap üretme, bulk ürün güncelleme gibi uzun soluklu işlemler bu hatayı kolayca tetikler. Timeout değerini doğrudan yükseltmek bazen geçici çözüm olsa da kök neden genellikle kötü optimize edilmiş bir sorgu ya da eklentidir; sadece timeout’u artırmak problemi saklar, çözmez.
4. PHP-FPM Süreç Çökmesi
PHP-FPM servisi tamamen durmuşsa (örneğin bir segfault, OOM killer tarafından öldürülme ya da yanlış konfigürasyon nedeniyle) Nginx upstream’e hiç ulaşamaz ve her istek 502 döner. systemctl status php8.2-fpm komutuyla servisin çalışıp çalışmadığını, journalctl -u php8.2-fpm --since "1 hour ago" ile de son hataları görebilirsiniz. Bu senaryoda çözüm genellikle servisi yeniden başlatmak ve sistem log’larından nedeni bulmaktır.
5. Cloudflare ve CDN Sorunları
Cloudflare, Sucuri veya diğer CDN ve WAF katmanları, kendi sunucuları ile origin sunucusu arasındaki iletişim koptuğunda 502 Bad Gateway döndürür. Origin sunucunun IP’sinin değişmesi, origin firewall’unun Cloudflare IP’lerini engellemesi, Cloudflare SSL modunun yanlış ayarlanması (Full yerine Flexible seçilmesi gibi) veya origin sunucusunun tamamen çökmüş olması en yaygın nedenlerdir. Cloudflare ekranında görünen 502 hatasında mutlaka hata mesajı içindeki Ray ID’yi not alın; destek talebinde kritik öneme sahiptir.
6. Eklenti veya Tema Kaynaklı Sonsuz Döngüler
Kötü yazılmış bir eklenti (özellikle cache, backup, yedekleme ya da cron yönetimi ile ilgili olanlar) sonsuz döngüye girebilir veya aşırı işlem başlatabilir. Bu da hem bellek hem worker kaynaklarını tüketir. Belirti: Belirli bir eklenti güncellendikten veya bir tema bileşeni değiştirildikten hemen sonra 502 hatalarının başlaması. Bu durumda adım adım eklenti deaktifleştirme yöntemi kritik öneme sahiptir.
7. DNS Yapılandırma Sorunları
Site sunucu taşıması sonrasında veya Cloudflare DNS’ine geçiş yapıldıktan sonra A kayıtları yanlış yönlendirilmişse, CDN upstream olarak geçersiz bir origin’e istek yollayacaktır. Bu da sistematik olarak 502 döner. DNS propagasyon süresi (tipik olarak 0–24 saat) boyunca farklı ziyaretçiler farklı deneyimler yaşayabilir; bir kısmı için site açılır, bir kısmı için 502 hatası görünür.
8. Veritabanı Bağlantı Gecikmeleri
PHP, MySQL’e bağlanamıyorsa veya bağlantı çok uzun sürüyorsa (ör. yavaş sorgu, aç kalmış connection pool), PHP süreci bekletilir ve sonunda timeout’a girer. Web sunucusu ise bu yanıtsızlığı 502 olarak kullanıcıya iletir. wp-content içindeki object-cache.php ve transients’in düzgün çalışması bu problemi büyük ölçüde azaltır.
Adım Adım 502 Bad Gateway Hatası Çözümü
Teşhisi hızlı ve sistematik yapmak önemlidir. Aşağıdaki adımları sırayla uygulayın; çoğu sitede 2–5 arası adım sorunu çözer.
Adım 1: Hata Gerçekten 502 mi? Farklı Cihaz ve Ağlarda Doğrulayın
Önce hatanın gerçekten sunucu tarafında olduğundan emin olun. Bazen tarayıcı cache veya ISP (internet servis sağlayıcı) DNS sorunu 502’ye benzer sonuçlar doğurabilir. Mobil veri ile (3G/4G/5G) ve farklı bir tarayıcıyla siteyi açın. Ek olarak curl ile doğrudan HTTP başlıklarına bakın:
curl -I https://siteniz.com/
# Yanıt başlıkları arasında gerçekten "HTTP/2 502" görünüyor mu?
# Server başlığı nginx mi, Apache mi, Cloudflare mi?Adım 2: Sunucu Error Log’larını İnceleyin
Hiçbir çözüm “log okumak”tan önce gelmez. Web sunucusu ve PHP-FPM log’larında 502 hatasının kök nedeni büyük olasılıkla yazılıdır. En sık bakılan dosyalar:
# Nginx error log
sudo tail -n 200 /var/log/nginx/error.log
# PHP-FPM error log (sürüm 8.2 örneği)
sudo tail -n 200 /var/log/php8.2-fpm.log
# Belirli bir siteye özel error log (cPanel / Plesk / DirectAdmin)
sudo tail -n 200 /var/www/siteniz.com/logs/error.logupstream prematurely closed connection, connect() failed (111: Connection refused) while connecting to upstream, recv() failed (104: Connection reset by peer) gibi mesajlar 502’nin PHP-FPM tarafından geldiğini; PHP Fatal error: Allowed memory size of X bytes exhausted mesajı ise bellek limiti sorununu işaret eder.
Adım 3: Tarayıcı ve CDN Cache’ini Temizleyin
Bazen 502 hatası CDN veya tarayıcı cache’inde kalır. Sunucu tarafında sorun çözülmüş olsa bile cache, hatayı ziyaretçilere göstermeye devam eder. Cloudflare panelinden Caching → Configuration → Purge Everything seçeneği ile tüm cache’i temizleyin. Tarayıcı tarafında da Ctrl+Shift+R (Windows/Linux) veya Cmd+Shift+R (Mac) ile hard reload yapın.
Adım 4: Cloudflare’i Geçici Olarak Devre Dışı Bırakıp Test Edin
Cloudflare kullanıyorsanız, sorunun CDN katmanında mı yoksa origin’de mi olduğunu anlamak için Cloudflare’i “Development Mode”a alın veya DNS kaydını geçici olarak gri bulut (proxy kapalı) moduna çekin. DNS propagasyonunu beklemek istemiyorsanız, hosts dosyanıza doğrudan origin IP’yi ekleyerek origin’e doğrudan erişim sağlayabilirsiniz. Eğer site origin üzerinden açılıyorsa sorun Cloudflare tarafındadır; yine de 502 alıyorsanız sorun origin’dedir.
Adım 5: PHP Worker ve Bellek Limitlerini Artırın
Bellek limiti ve worker sayısı 502 hatasının birinci derecede ilgilendiği iki ayardır. wp-config.php dosyanızda ABSPATH tanımından önce aşağıdaki satırları ekleyerek WordPress’in bellek limitini yükseltin:
// wp-config.php — bellek limiti
define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '768M' );Sunucu tarafında ise php.ini veya .user.ini dosyasında:
; php.ini
memory_limit = 512M
max_execution_time = 300
max_input_time = 300
upload_max_filesize = 128M
post_max_size = 128MPHP-FPM worker sayısı için pool dosyanızı düzenleyin (ör. /etc/php/8.2/fpm/pool.d/www.conf):
; PHP-FPM pool yapılandırması (örnek, 4 GB RAM'li sunucu için)
pm = dynamic
pm.max_children = 30
pm.start_servers = 6
pm.min_spare_servers = 4
pm.max_spare_servers = 10
pm.max_requests = 500
request_terminate_timeout = 300Değişikliklerden sonra servisi yeniden başlatın: sudo systemctl reload php8.2-fpm. Paylaşımlı hostingte bu ayarlara doğrudan erişemezsiniz; hosting firmanıza biletle başvurmanız gerekir.
Adım 6: Nginx Timeout ve Buffer Ayarlarını Yükseltin
Nginx site konfigürasyonunda (ör. /etc/nginx/sites-available/siteniz.com.conf) şu ayarları kontrol edin:
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
fastcgi_read_timeout 300s;
fastcgi_send_timeout 300s;
fastcgi_connect_timeout 60s;
fastcgi_buffer_size 128k;
fastcgi_buffers 4 256k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
}Sonrasında sudo nginx -t ile yapılandırmayı doğrulayın ve sudo systemctl reload nginx ile uygulayın.
Adım 7: WordPress Debug Modunu Açarak Uygulama Tarafını Test Edin
wp-config.php dosyanızda debug modunu log dosyasına yazacak şekilde aktif edin. Bu, ekranda hata göstermeden yöneticinin sessizce teşhis yapmasını sağlar:
// wp-config.php
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );Log dosyası wp-content/debug.log altında oluşur. Sorunun olduğu zaman dilimine bakıp hangi fonksiyon veya eklentinin fatal error ürettiğini görebilirsiniz. İşlem bittiğinde debug’ı kapatmayı unutmayın.
Adım 8: Eklentileri Güvenli Modda Devre Dışı Bırakın
Sorunun bir eklentiden kaynaklandığından şüpheleniyorsanız, WordPress admin paneline giremiyor olsanız bile WP-CLI ile tüm eklentileri tek seferde devre dışı bırakabilirsiniz:
# WP-CLI — tüm eklentileri devre dışı bırak
wp plugin deactivate --all --skip-plugins --skip-themes
# Sorun çözülürse eklentileri tek tek aktif ederek hatalıyı bulun
wp plugin activate woocommerce
wp plugin activate elementor
# ... sorun hangi eklenti aktif edildiğinde tekrarlıyorsa o eklentidirWP-CLI kurulu değilse, FTP veya SSH ile wp-content/plugins klasörünü geçici olarak plugins-eski olarak yeniden adlandırın; tüm eklentiler otomatik olarak devre dışı kalır. Site açılırsa klasör adını geri alıp eklentileri tek tek etkinleştirerek sorumluyu bulabilirsiniz.
Adım 9: Varsayılan Temaya Geçin
Eklentiler sorun değilse tema şüphelidir. WP-CLI ile varsayılan temaya geçin:
wp theme activate twentytwentyfour --skip-pluginsSite varsayılan temayla düzgün açılıyorsa, aktif temanızın bir fonksiyonu (özellikle functions.php içindeki dış API çağrıları, ağır hook’lar) 502’ye yol açıyor olabilir. Child theme kullanıyorsanız önce child’ın functions.php dosyasını inceleyin.
Adım 10: WordPress Çekirdek Dosyalarını Yeniden Yükleyin
Yukarıdaki adımlar sonuç vermiyorsa WordPress çekirdek dosyaları bozulmuş olabilir. WP-CLI ile ayarlarınızı ve içeriğinizi koruyarak core’u yeniden indirin:
# Mevcut WP sürümüyle core'u yeniden indir
wp core download --force --skip-content
# Veritabanı güncellemelerini de çalıştır
wp core update-dbBu işlem wp-config.php, wp-content klasörü ve mevcut veritabanını korur; yalnızca çekirdek dosyaları yeniler. İşlem öncesi mutlaka tam yedek alın.
Adım 11: Hosting Sağlayıcınızla İletişime Geçin
Paylaşımlı hostingte bazı adımlara erişiminiz olmayabilir. Sağlayıcınıza bilet açarken şu bilgileri eksiksiz iletmek çözüm süresini önemli ölçüde kısaltır: hatanın başladığı tarih/saat, örnek bir ziyaretçi URL’si, Cloudflare Ray ID (varsa), yaptığınız son değişiklik (eklenti güncellemesi, tema değişimi, medya yüklemesi vb.), mobil veri ile de hatanın tekrarlanıp tekrarlanmadığı.
Örnek Sunucu Yapılandırmaları
Apache .htaccess: Bellek ve Timeout
Apache + LiteSpeed kombinasyonu kullanan paylaşımlı hostinglerde .htaccess ile hızlı çözümler:
# .htaccess — WordPress kök dizini
<IfModule mod_php.c>
php_value memory_limit 512M
php_value max_execution_time 300
php_value max_input_time 300
php_value upload_max_filesize 128M
php_value post_max_size 128M
</IfModule>
# Apache timeout
Timeout 300
# ProxyPass timeout (reverse proxy kullanılıyorsa)
<IfModule mod_proxy.c>
ProxyTimeout 300
</IfModule>WP-CLI ile Hızlı Teşhis SQL Sorgusu
Yavaş veritabanı sorguları 502’ye yol açabilir. Autoload edilen şişmiş option kayıtlarını bulmak için:
# En büyük autoload kayıtlarını listele
wp db query "SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 20;"Eğer bir eklentiye ait “transient” kayıtları birkaç MB boyutundaysa bu, her sayfa yüklemesinde gereksiz bellek harcıyor demektir. İlgili eklentiyi güncelleyin veya değiştirin.
Sorun Giderme Kontrol Listesi
Bir 502 Bad Gateway incidenti sırasında aşağıdaki checklist’i sırayla geçin. Her madde, önceki bir adımın sonucuna bağlıdır:
- Mobil veri + farklı tarayıcı ile hatayı doğruladım.
curl -Içıktısında HTTP 502 ve Server başlığını not ettim.- Nginx/Apache ve PHP-FPM error log’larını 200 satır geriden okudum.
- Cloudflare Ray ID’yi (varsa) kaydettim.
- Tarayıcı ve CDN cache’ini temizledim.
- Cloudflare’i geçici olarak bypass ederek origin’i doğrudan test ettim.
WP_MEMORY_LIMITdeğerini 512M’a çıkardım.- PHP-FPM
pm.max_childrendeğerini trafik desenine göre artırdım. - Nginx
fastcgi_read_timeoutdeğerini 300s’ye çıkardım. - Debug log’unda fatal error aradım.
- WP-CLI ile tüm eklentileri deaktif ettim ve tek tek aktif ederek sorumluyu buldum.
- Varsayılan temaya geçip temayı elimine ettim.
- Core dosyalarını
wp core download --force --skip-contentile yeniledim. - Uptime izleme aracı kurdum, 5xx alarmı tanımladım.
- Hosting sağlayıcıma ayrıntılı bilet açtım (gerektiyse).
502 Bad Gateway Hatasını Önleme ve Proaktif İzleme
Hatayı çözmekten daha iyisi, baştan yaşamamaktır. 502 hatalarını minimum düzeyde tutmak için uygulayabileceğiniz önleyici adımlar şunlardır:
Uygun Boyutlandırılmış Hosting Seçin
WooCommerce ve yoğun Elementor kullanan sitelerde ucuz paylaşımlı hosting neredeyse kesinlikle 502 üretecektir. Ortalama aylık 50.000 sayfa görüntülemesi ve üzeri trafiği olan siteler için en az managed WordPress hosting veya küçük bir VPS önerilir. 2 CPU / 4 GB RAM bir VPS, doğru PHP-FPM ayarıyla çoğu orta ölçekli siteye rahatlıkla hizmet verir.
Cache Katmanı Ekleyin
LiteSpeed Cache, WP Rocket, W3 Total Cache veya FastCGI cache kullanarak PHP-FPM’e ulaşan istek sayısını %80–95 oranında azaltabilirsiniz. Bu, aynı donanımla 5–10 kat daha fazla trafik taşıyabileceğiniz anlamına gelir. Redis veya Memcached gibi bir object cache katmanı ise veritabanı yükünü ciddi oranda düşürür.
Uptime ve 5xx İzlemesi Kurun
UptimeRobot (ücretsiz), Better Uptime, Pingdom veya StatusCake gibi servislerle sitenizi en az 5 dakikada bir kontrol ettirin. Hem anasayfa hem de /wp-login.php gibi kritik sayfalar için ayrı izleme kurun. Ek olarak sunucu tarafında mtail veya Prometheus exporter ile Nginx 5xx yanıtlarını metriklere dönüştürüp alarmlayabilirsiniz.
Düzenli Yedekleme Stratejisi
502 hatasını çözme sürecinde (özellikle core ve eklenti müdahalelerinde) bir şeyler bozulabilir. Günlük tam yedek, haftalık off-site yedek ve değişiklik öncesi manuel yedek stratejisi, kurtarma süresini 8 saatten 15 dakikaya indirir. UpdraftPlus, BackWPup veya sunucu seviyesinde rsync + cron kurulumları pratik seçeneklerdir.
Sıkça Sorulan Sorular (SSS)
502 Bad Gateway hatası ziyaretçiden mi sunucudan mı kaynaklanır?
Neredeyse her zaman sunucu tarafı bir sorundur. İsim “Bad Gateway” olsa da hata, istemciden değil, sunucular arasındaki iletişimden kaynaklanır. Ziyaretçinin yapabileceği tek şey sayfayı yenilemektir; kalıcı çözüm sunucu yöneticisindedir.
502 hatası SEO’yu nasıl etkiler?
Google’ın tarayıcısı (Googlebot) tekrar tekrar 502 yanıtı aldığında ilgili sayfaları sitemapten geçici olarak kaldırmaya başlar ve tarama hızını düşürür. Kısa süreli (1–2 saatlik) 502 olayları genellikle sıralamaları etkilemez, ancak saatler sürerek tekrar eden 502’ler organik trafikte belirgin düşüşe yol açar. Düzelttiğinizde Google Search Console’dan manuel olarak yeniden tarama talep edin.
Cloudflare kullanıyorum, yine de 502 görüyorum; nedeni ne olabilir?
Cloudflare sadece CDN ve WAF katmanıdır; origin sunucusu yanıt vermiyorsa Cloudflare de 502 döner. Sık görülen nedenler: origin IP değişikliği, origin firewall’unun Cloudflare IP aralıklarını engellemesi, origin tarafında PHP-FPM çökmesi ve yanlış SSL modu (Full/Flexible uyumsuzluğu). Cloudflare destek ekibiyle iletişime geçerken mutlaka Ray ID paylaşın.
502 ile 504 arasındaki fark nedir?
502, “upstream’den geçersiz yanıt aldım” anlamına gelir; upstream ya hiç yanıt vermedi ya da bağlantı koptu. 504 ise “upstream yanıt verdi ama çok yavaş, timeout’a girdim” demektir. Teşhis ve çözüm yöntemleri büyük ölçüde örtüşür: her ikisinde de PHP-FPM worker yetersizliği, yavaş sorgu ve timeout ayarları birinci şüphelidir.
Paylaşımlı hostingde 502 hatasını tek başıma çözebilir miyim?
Sınırlı ölçüde. WordPress tarafındaki değişiklikleri (eklenti deaktive, tema değişimi, debug, cache temizliği, .htaccess düzenlemeleri) siz yapabilirsiniz. Ancak PHP-FPM pool, Nginx timeout, sunucu seviyesi bellek gibi ayarlar hosting sağlayıcısının yetkisindedir. Destek ekibine ayrıntılı log ve zaman damgası ileterek çözüm sürecini hızlandırabilirsiniz.
502 hatası yaşarken siteme giremiyorum, nasıl yedek alabilirim?
cPanel, Plesk veya DirectAdmin gibi hosting panellerinde dosya yöneticisi ve phpMyAdmin hâlâ çalışıyor olabilir; bu araçlarla wp-content klasörünün ZIP’ini ve veritabanının SQL dump’ını alabilirsiniz. SSH erişiminiz varsa tar -czf backup.tar.gz /var/www/siteniz.com ve mysqldump komutları en güvenilir yoldur.
Kaynak Önerileri ve Sonraki Adımlar
502 Bad Gateway hatasını çözerken ve önlerken başvurabileceğiniz ek kaynaklar: Nginx resmi dokümantasyonu (fastcgi_* direktifleri), PHP-FPM resmi dokümantasyonu (pool ayarları), WordPress Codex WP_DEBUG bölümü, Cloudflare Community’deki 502/504 troubleshooting konuları ve WPNeta blogundaki WordPress 500 Internal Server Error ve Core Web Vitals rehberleri. Performans sorunlarının 502 hatasını tetiklediği durumlar çok sıktır; bu yüzden Core Web Vitals optimizasyonunu ihmal etmeyin.
Sonuç olarak WordPress’te 502 Bad Gateway hatası panik yapılacak bir durum değil, sistematik teşhisle kısa sürede çözülebilen bir sunucu iletişim sorunudur. Yukarıdaki checklist’i sırayla uygulayın, log’ları mutlaka okuyun, değişiklikleri staging ortamında deneyin ve üretim sunucusunda yaptığınız her adımdan önce mutlaka yedek alın. Doğru izleme altyapısı ve yeterince kaynaklı bir hosting ile 502 hataları, sitenizin hayatında sadece birkaç dakikalık kısa anomaliler olarak kalacaktır.
