502 Bad Gateway hatası; nedeni ve hızlı çözümü

Site açılmıyor ve tarayıcı sadece bir sayı gösteriyor: 502 Bad Gateway. Eğer Nginx isteğin önünde duruyorsa, bu mesaj Nginx'in isteği backend'e gönderdiği ve ondan yanıt alamadığı anlamına gelir. Yani sorun neredeyse her zaman backend tarafındadır, ne Nginx'te ne de kullanıcının tarayıcısında. İlk yapmanız gereken, hangi katmanın yanıt vermediğini anlamaktır.

502 hatası nereden gelir

Tarayıcıdan PHP'ye kadar bir HTTP isteğinin birkaç durağı vardır. Her durak 502 üretebilir ve her birinin kendi logu vardır:

• Tarayıcı → Cloudflare (veya herhangi bir CDN): kenar origin'e bağlanamazsa 502 verir.
• Cloudflare → Nginx: origin'in 80/443 portu kapalıysa yine 502.
• Nginx → PHP-FPM: FPM soketi veya portu yanıt vermezse, Nginx 502 hatası döndürür.
• PHP-FPM → MySQL veya Redis: burada genellikle 500 alırsınız, ancak FPM worker'ı ölürse sonuç 502 olur.

Sorun giderme sırası dışarıdan içeriye doğrudur. Önce hatanın Cloudflare'den mi yoksa sunucunun kendisinden mi geldiğine bakın.

Hızlı teşhis: hata CDN'den mi yoksa sunucudan mı

Sunucu IP'sine doğrudan bir istek gönderin ve başlıklara bakın:

curl -sSI -H "Host: example.com" http://185.x.x.x/ | head -n 5

Doğrudan yanıt 200 ise ama alan adı Cloudflare arkasından 502 veriyorsa, sorun kenarda veya origin ayarlarındadır. İkisi de 502 verdiyse, Nginx loguna gidin:

tail -f /var/log/nginx/error.log

Aradığınız satır şuna benzer bir şeydir:

connect() to unix:/run/php/php8.2-fpm.sock failed (11: Resource temporarily unavailable)

Veya:

upstream prematurely closed connection while reading response header from upstream

Birincisi, FPM worker kuyruğunun dolduğu anlamına gelir. İkincisi, PHP'nin çalışma ortasında öldüğü anlamına gelir. Bu ikisinin tedavisi tamamen farklıdır.

PHP-FPM zaman aşımı ve dolu worker kuyruğu

PHP-FPM'in sınırlı sayıda worker'ı vardır. Tüm worker'lar meşgul olduğunda, yeni istek kuyrukta bekler ve Nginx FPM'den önce pes ederse 502 verir. İki sayıyı yan yana görmeniz gerekir: FPM'deki request_terminate_timeout ve Nginx'teki fastcgi_read_timeout.

Eğer fastcgi_read_timeout 60 saniyede ve bir betik 90 saniye sürüyorsa, Nginx 60. saniyede bağlantıyı kapatır ve kullanıcı 502 görür, oysa PHP hâlâ çalışıyor ve worker'ı meşgul tutuyordur. Burada hata yaparlar: hatanın gitmesi için fastcgi_read_timeout değerini sonsuz yaparlar. Hata gider, ama kuyruk dolu kalır ve on dakika sonra tüm site 502 olur. Belirtisi de şudur: site birkaç dakika sağlıklıdır ve sonra aniden tüm istekler çöker.

Doğru yol, önce hangi betiğin uzun sürdüğünü anlamaktır. FPM yavaşlık logunu açın:

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

Birkaç dakika sonra, slow.log dosyası tam olarak hangi fonksiyonun ve kodun hangi satırının zaman aldığını söyler. On vakadan dokuzunda, indekssiz bir sorgu veya harici bir API'ye yapılan bir HTTP isteğidir.

Doğru pm.max_children ayarı

Worker sayısını tahminle değil, bellekle hesaplayın. Her PHP süreci yaklaşık 80 megabayt RSS alıyorsa ve sunucunun 4 gigabayt RAM'i varsa, mantıklı üst sınır 100 değil, yaklaşık 30 ila 35 worker'dır. Basit formül:

pm = dynamic
pm.max_children = 32
pm.start_servers = 8
pm.min_spare_servers = 8
pm.max_spare_servers = 16
pm.max_requests = 500

pm.max_requests değerini hafife almayın. WordPress eklentilerinde bellek sızıntısı gerçektir ve worker'ların periyodik yeniden başlatılması birçok kademeli 502'yi önler.

502 hatasında Cloudflare'in rolü

Cloudflare, origin'e bağlanamadığında veya origin geçerli yanıt vermediğinde 502 verir. Üç yaygın neden:

1. Origin IP'si DNS kaydında değişmiş ve eski A kaydı kalmış. DNS ve ağ kontrol aracı ile A ve AAAA kayıtlarının doğru IP'yi gösterdiğini kontrol edin.
2. Sunucu güvenlik duvarı, Cloudflare IP'lerini engellemiş. iptables veya CSF'niz varsa, Cloudflare aralıklarına izin verilmelidir.
3. SSL modu Full (strict) üzerinde ama origin'deki sertifika süresi dolmuş. Burada tarayıcı 502 görür ve origin logunda hiçbir şey yoktur.

Birçok kişiyi yanıltan bir nokta: Cloudflare origin hatasını önbelleğe almaz, ancak kendi hata sayfasını 502 koduyla döndürür. Tarayıcının Network sekmesinde cf-ray görüyorsanız, hata kenardan gelmiştir ve origin logunu ayrıca incelemelisiniz.

Worker'lar tükendiğinde ama sunucu sağlıklı olduğunda

CPU ve RAM'in tamamen boş olduğu ama sitenin 502 verdiği bir durum vardır. Bu neredeyse her zaman, FPM worker'larının harici bir kaynağı beklerken takıldığı anlamına gelir: kilitlenmiş bir MySQL bağlantısı, yanıt vermeyen bir Redis veya harici bir servise timeout'suz bir curl isteği.

Kuyruğun anlık durumunu görmek için:

systemctl status php8.2-fpm
ss -x -p | grep php

Soket bağlantı sayısı anormal derecede yüksekse ve azalmıyorsa, bir betik tüm worker'ları uyutuyordur. Bu durumda pm.max_children değerini artırmak sadece acıyı erteler. Betiği bulmanız gerekir.

WordPress'te, wp-cron.php yüksek trafikli sitelerde her zaman şüphelilerden biridir. Her ziyaret ayrı bir cron isteği oluşturur ve yüksek trafikte worker kuyruğunu doldurur. Standart çözüm, dahili cron'u devre dışı bırakıp sistem crontab'ı ile çalıştırmaktır:

define('DISABLE_WP_CRON', true);

*/5 * * * * wget -q -O - https://example.com/wp-cron.php?doing_wp_cron >/dev/null 2>&1

Sorun ne zaman sunucu kaynaklarındandır

FPM'i doğru ayarladıktan ve yavaş betiği bulduktan sonra hâlâ yoğun saatlerde 502 alıyorsanız, artık sorun ayarlar değildir; sunucu sınıra ulaşmıştır. Burada iki yolunuz var ve aralarındaki seçim yük desenine bağlıdır.

Kodu ve ayarları kendiniz kontrol ediyorsanız ve FPM ile önbellek parametrelerini serbestçe ayarlamak istiyorsanız, tam SSH erişimli Linux hosting kalıp her hafta 502 ile savaşmaktan daha doğru bir seçimdir. Sitenizin yükü sürekli ve ağırsa ve veritabanını web sunucusundan izole etmeniz gerekiyorsa, dedicated sunucu daha mantıklıdır.

Beş dakikalık kontrol listesi

1. /var/log/nginx/error.log dosyasına bakın ve tam upstream mesajını alın.
2. systemctl status php8.2-fpm ile servisin sağlığını kontrol edin.
3. pm.max_children değerini sunucunun gerçek belleğiyle karşılaştırın.
4. FPM yavaşlık logunu açın ve suçlu betiği bulun.
5. Cloudflare arkasındaysanız, DNS kaydını ve SSL modunu kontrol edin.

Bu beş adımdan sonra hâlâ hata alıyorsanız, artık ayarlara değil mimariye bakma zamanıdır. Yavaş site sorun giderme kılavuzu iyi bir başlangıç noktasıdır, çünkü 502 ve yavaşlık genellikle aynı kökene sahiptir. Web sunucusu düzeyindeki ayarlarla ilgili durumlar için, ServerNet'in dokümantasyon ve bilgi tabanı hazır örneklere sahiptir.

Sıkça sorulan sorular

502 ve 504 hatası arasındaki fark nedir?

502, backend'in geçersiz yanıt verdiği veya bağlantının kesildiği anlamına gelir; 504 ise backend'in belirlenen aralıkta hiç yanıt vermediği anlamına gelir. Pratikte 504 genellikle timeout artırılarak çözülür, ancak 502 arıza veya worker doygunluğunun işaretidir. İkisini de görüyorsanız, önce PHP-FPM worker kuyruğunu kontrol edin.

PHP-FPM'i yeniden başlatmak 502 hatasını çözer mi?

Geçici olarak evet, ama nedeni ortadan kaldırmaz. systemctl restart php8.2-fpm sonrası site birkaç saat sağlıklıysa ve sonra tekrar 502 veriyorsa, bir betik veya bellek sızıntısı worker'ları tüketiyordur. Suçluyu görmek için FPM yavaşlık logunu açın.

Neden sadece bazı kullanıcılar 502 hatası alıyor?

Çünkü hata belirli bir worker'a bağlıdır. Birkaç backend sunucusundan biri bozuksa veya load balancer'daki bir düğüm devre dışıysa, isteklerin sadece bir kısmı oraya ulaşır. Ayrıca kenar önbelleği sayfaların bir kısmını sunuyorsa, diğer kullanıcılar origin'e hiç ulaşmaz ve hatayı görmez.

502 hatasının SEO üzerinde etkisi var mı?

Evet, ve etkisi hızlıdır. Google tarayıcısı birkaç ardışık ziyarette 502 görürse, sitenin tarama hızı düşer ve sayfalar daha geç indekslenir. Hata birkaç saatten fazla sürerse, sayfaların sonuçlardan geçici olarak kaldırılma olasılığı vardır. Önceliği siteyi geri getirmeye verin, sonra optimizasyona geçin.