502 Bad Gateway Hatası Nedir ve Nasıl Çözülür?

502 Bad Gateway hatası nedir?

502 Bad Gateway, ağ geçidi ya da ters proxy olarak çalışan bir sunucunun, arkasındaki upstream sunucudan geçersiz bir yanıt aldığını bildiren HTTP durum kodudur. Tarayıcınız siteye ulaşır, ancak ön kapıdaki sunucu uygulamadan düzgün cevap alamaz. Bu yüzden ziyaretçiye hata sayfası gösterir.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yazıdaki teknik anlatım MDN, RFC 9110, nginx, PHP ve Cloudflare dokümanlarına dayanır. Amacımız, sitenizde 502 gördüğünüzde hatanın nerede doğduğunu anlamanız ve doğru kişiye doğru bilgiyle gitmenizdir.

Günlük hayatta 502 bad gateway hatasını çoğu zaman şöyle görürsünüz: site bir anda "502 Bad Gateway", "Bad Gateway" ya da "HTTP Error 502" yazar. Bazen bir yenilemeyle düzelir, bazen saatlerce sürer. Bu rehberde nedenleri, teşhis sırasını ve her rol için ayrı adım listesini veriyoruz.

502 hatasını kim çözmeli: ziyaretçi, site sahibi, sunucu yöneticisi?

Sorumluluk çoğu zaman sunucu tarafındadır. MDN de bu hatanın sunucu sahiplerinin ve yöneticilerinin inceleyeceği bir sunucu hatası olduğunu belirtir. Ancak istisna vardır: site diğer ziyaretçilere açılıyorsa ve siz VPN ya da özel ağ ayarı kullanıyorsanız sorun sizin ağınızda olabilir.

Üç rolü şöyle ayırabilirsiniz:

• Ziyaretçi: Sayfayı yeniler, VPN'i kapatır, başka ağdan dener ve site sahibine haber verir.
• Site sahibi: Son değişikliği, eklentiyi, temayı ve CDN ayarını gözden geçirir, hosting sağlayıcısına doğru bilgiyle başvurur.
• Sunucu yöneticisi: Ters proxy ile uygulama arasındaki bağlantıyı, servislerin durumunu, günlükleri ve kaynak sınırlarını inceler.

Paylaşımlı hostingde yönetici rolü sağlayıcıdadır. Yani cPanel kullanıyorsanız ve sunucuya kök erişiminiz yoksa, aşağıdaki komutlar size değil sağlayıcınıza aittir.

Bir istek ters proxy ve upstream arasında nasıl ilerler?

Modern sitelerde istek tek bir sunucuda bitmez. Ziyaretçi önce CDN'e ya da doğrudan web sunucusuna gelir. Nginx veya Apache gibi ön kapı, isteği PHP-FPM, Node.js ya da başka bir uygulama sunucusuna aktarır. Bu arka katmana upstream denir.

502 tam olarak bu aktarma sırasında doğar. Ön kapı çalışıyordur, fakat upstream kapalıdır, bağlantıyı reddeder, yarıda keser ya da anlaşılmaz bir yanıt döner. Böylece ön kapı, kendi görevi gereği "geçersiz yanıt aldım" der.

Zinciri kabaca şöyle düşünün:

1. Ziyaretçi tarayıcıdan istek gönderir.
2. CDN ya da ters proxy isteği alır.
3. İstek uygulama katmanına (PHP-FPM, Node.js, Python vb.) gider.
4. Uygulama veritabanına ya da başka servise bağlanır.
5. Yanıt aynı yoldan geri döner.

Birden fazla upstream varsa tablo biraz değişir. Yük dengeleyici ya da nginx, isteği sağlıklı görünen sunuculara dağıtır. Nginx dokümanına göre proxy_next_upstream varsayılanı, hata ve zaman aşımı durumlarında isteği sıradaki sunucuya yollar. Tüm upstream sunucular yanıt vermezse ziyaretçi yine 502 ya da benzeri bir hata görür.

Hatanın hangi halkada çıktığını bulmak, çözümün yarısıdır.

502, 500, 503 ve 504 arasındaki fark nedir?

Dört kod da sunucu tarafı hatadır, fakat anlamları farklıdır. RFC 9110'a göre 502, ağ geçidi görevindeki sunucunun upstream'den geçersiz yanıt almasıdır. 504 ise zamanında yanıt alınamamasıdır. 503 geçici aşırı yük ya da bakım nedeniyle isteği karşılayamamaktır. 500 ise genel sunucu hatasıdır.

500 ve 503 ayrıntılarını ayrı yazılarımızda ele alıyoruz. Burada yalnızca ayrımı özetliyoruz.

MDN'e göre ağ geçidi hiç HTTP yanıtı alamazsa 504 gönderir. Pratikte ise bazı yığınlar bu ayrımı farklı uygular. Bu yüzden kodu değil, günlükteki cümleyi esas alın.

502 Bad Gateway hatasının en yaygın nedenleri nelerdir?

Nedenlerin çoğu upstream katmanında toplanır. Aşağıdaki liste, resmi dokümanlarda ve dağıtım belgelerinde en çok geçen sebepleri özetler; sıralama sitenize göre değişir.

• PHP-FPM, Node.js ya da uygulama servisi çökmüş veya hiç başlamamıştır.
• PHP-FPM işçi havuzu dolmuş ve yeni istekler sıraya takılmıştır.
• Ters proxy yanlış adrese ya da porta bağlanmaya çalışıyordur.
• Uygulama yanıtı yarıda kesiyor ya da geçersiz başlık gönderiyordur.
• Bellek bitmiş ve işletim sistemi uygulamayı sonlandırmıştır.
• Güvenlik duvarı ya da yanlış izinler, ters proxy ile upstream arasındaki bağlantıyı engelliyordur.
• CDN ile kaynak sunucu arasında bağlantı kurulamıyordur.

Yani tek bir sihirli çözüm yoktur. Teşhis sırasını izlemek, tahminden çok daha hızlı sonuç verir.

Ziyaretçi olarak 502 hatasını nasıl kontrol edersiniz?

Önce sorunun sizde mi sitede mi olduğunu ayırın. Sayfayı bir kez yenileyin, ardından gizli pencerede açın. Daha sonra mobil veriyle ya da başka bir ağdan deneyin. Site başka ağlardan da hata veriyorsa sorun sunucudadır.

Kısa kontrol listesi:

1. Sayfayı yenileyin ve birkaç dakika bekleyin.
2. VPN, proxy ve reklam engelleyici gibi araçları kapatın.
3. Başka bir cihaz ya da ağdan açmayı deneyin.
4. DNS sorgulama aracımızla alan adının doğru yere çözüldüğünü kontrol edin.
5. Sorun sürerse site sahibine ya da hosting sağlayıcısına hata saatini bildirin.

Önbelleği temizlemek bazen yardımcı olur, fakat 502 sunucu kaynaklı olduğu için çoğu zaman çözmez.

Site sahibi olarak ilk hangi adımları denersiniz?

Site sahibiyseniz ilk soru şudur: hata ne zaman başladı ve hemen öncesinde ne değişti? Bir eklenti güncellemesi, tema değişikliği, yeni bir cron işi ya da trafik artışı çoğu vakada tetikleyicidir.

Sırasıyla şunları deneyin:

1. Hosting panelinden kaynak kullanımına (CPU, RAM, işlem sayısı) bakın.
2. Son güncellenen eklentiyi ya da temayı devre dışı bırakın.
3. Bakım modu ve güvenlik eklentilerinin ayarlarını kontrol edin.
4. CDN kullanıyorsanız geçici olarak CDN'i atlayıp kaynak sunucuya doğrudan erişmeyi deneyin.
5. Hata saatini, adresi ve ekran görüntüsünü kaydedin.
6. Bu bilgilerle sağlayıcınıza destek talebi açın.

Hata aralıklıysa, yani bazen çıkıp bazen kayboluyorsa, bunu not edin. Aralıklı 502 çoğu zaman kaynak sınırına ya da yoğun saatlere işaret eder. Sürekli çıkan 502 ise genellikle kapalı bir servisi ya da bozuk bir yapılandırmayı gösterir. Bu ayrım, sağlayıcıya aktaracağınız bilginin en değerli kısmıdır.

Düzenli yedekleme stratejiniz varsa, geri dönüş her zaman elinizin altında olur. Üstelik yedek, eklenti kaynaklı sorunlarda en hızlı çıkış yoludur.

Sunucu yöneticisi 502 teşhisine nereden başlar?

Kendi VPS'inizi yönetiyorsanız teşhis sırası basittir: önce servis ayakta mı, sonra ters proxy upstream'e ulaşıyor mu, en son günlük ne diyor. Aşağıdaki komutlar Debian ve Ubuntu tabanlı sistemlerde sık görülen düzeni varsayar; servis adları ve günlük yolları dağıtıma göre değişir.

sudo systemctl status nginx
sudo systemctl status php-fpm
sudo nginx -t
sudo tail -n 50 /var/log/nginx/error.log
ss -ltnp

PHP-FPM servisinin adı bazı dağıtımlarda sürüm numarası taşır. Doğru adı bulmak için systemctl list-units --type=service çıktısına bakın. Aynı şekilde nginx günlük yolu, kurulum şekline göre farklı olabilir.

Günlükte iki tür cümle çok işinize yarar:

• Connection refused: Upstream o adreste dinlemiyor demektir.
• Prematurely closed connection: Upstream yanıtı bitirmeden bağlantıyı kapatmıştır.

İlk cümle genellikle servisin kapalı olduğunu, ikincisi uygulama çökmesini ya da işlem sonlandırmasını düşündürür.

PHP-FPM çöktüğünde ya da havuz dolduğunda ne olur?

WordPress, Laravel ve çoğu PHP sitesi nginx arkasında PHP-FPM ile çalışır. PHP-FPM kapalıysa ya da dinlediği soket ile nginx'in bağlanmaya çalıştığı soket farklıysa, nginx upstream'e ulaşamaz ve 502 üretir.

Daha sinsi durum havuzun dolmasıdır. PHP el kitabına göre pm.max_children, aynı anda karşılanabilecek istek sayısının sınırını belirler. Tüm işçiler meşgulse yeni istekler bekler. Bekleme uzarsa zaman aşımı, bazen de bağlantı hatası görürsünüz.

PHP-FPM günlüğünde "server reached pm.max_children setting" benzeri bir uyarı görürseniz havuzun tavana dayandığını anlarsınız. Bu uyarı, yalnızca değeri yükseltmeniz gerektiği anlamına gelmez. Önce yavaş çalışan betiğin ya da sorgunun neden işçiyi uzun süre tuttuğunu araştırın.

Başka bir sık neden de dinleme adresi uyumsuzluğudur. PHP-FPM tarafında listen ayarı bir Unix soketi ya da IP:port olabilir. Nginx tarafındaki fastcgi_pass aynı adresi göstermelidir. Biri güncellenip diğeri unutulursa 502 kaçınılmazdır.

pm.max_children değerini nasıl hesaplarsınız?

PHP el kitabı pm.max_children için sabit bir sayı önermez; değer sunucunuzun belleğine ve uygulamanızın işlem başına tükettiği belleğe bağlıdır. Mantık basittir: PHP'ye ayırabileceğiniz belleği, bir işlemin ortalama kullanımına bölersiniz.

Aşağıdaki sayılar yalnızca bir örnek hesaptır, gerçek sitenizin ölçümü değildir:

• Sunucuda PHP'ye ayırabildiğiniz bellek: 2 GB (örnek).
• Bir PHP-FPM işlemi ortalama 50 MB tutuyor (örnek).
• Sonuç: yaklaşık 40 işlem, yani pm.max_children = 40 civarı.

Gerçek ortalamayı canlı trafikte top ya da htop ile bir PHP-FPM çocuk işleminin bellek kullanımına bakarak ölçün. Ardından işletim sistemi, veritabanı ve önbellek için pay bırakın. Çok yüksek bir değer belleği bitirir ve bu kez işletim sistemi işlemleri öldürür; sonuç yine 502 olur.

pm = dynamic
pm.max_children = 40
pm.max_requests = 500

Buradaki 500 de örnektir. Doküman, pm.max_requests değerinin üçüncü taraf kütüphanelerdeki bellek sızıntılarını aşmak için işlem yenileme amacıyla kullanılabileceğini söyler.

Nginx proxy timeout ayarları 502 ve 504'te ne işe yarar?

Nginx dokümanına göre proxy_connect_timeout bağlantı kurma süresini, proxy_read_timeout iki ardışık okuma arasındaki bekleme süresini belirler. Üçü de (connect, read, send) varsayılan olarak 60 saniyedir. FastCGI için karşılıkları fastcgi_connect_timeout ve fastcgi_read_timeout adını taşır.

Süreleri körlemesine büyütmek çözüm değildir. Yavaş bir betiği 300 saniye bekletmek, ziyaretçiyi daha uzun süre boş sayfada tutar ve PHP işçilerini daha uzun meşgul eder. Önce yavaşlığın kaynağını bulun.

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 5s;
    proxy_read_timeout 60s;
}

Örnekteki sayılar birer örnektir. Raporlama gibi gerçekten uzun süren işler için isteği arka plana, yani kuyruğa almak daha sağlıklı bir yoldur.

Bir ayrıntıya dikkat edin: proxy_next_upstream varsayılanı error timeout değerleridir. Birden fazla upstream varsa nginx bu durumlarda isteği bir sonrakine yollar. Tek upstream varsa yedek yoktur ve hata doğrudan ziyaretçiye yansır.

Apache'de ters proxy 502 hatası nasıl oluşur?

Apache, mod_proxy ile ters proxy olarak çalıştığında aynı mantık geçerlidir. Upstream yanıt vermezse ya da geçersiz başlık gönderirse Apache 502 üretebilir. Resmi dokümana göre ProxyBadHeader varsayılanı olan IsError, geçersiz başlıkta 502 döndürür.

ProxyTimeout yönergesi, proxy isteklerinin ağ zaman aşımını belirler. Doküman, bunu "takılan yavaş uygulama sunucusu" durumunda sonsuza kadar beklemek yerine düzgün şekilde hata dönmek için önerir. Varsayılanı Timeout değerine eşittir.

cPanel gibi panellerde Apache ve nginx birlikte çalışabilir. Bu durumda hata iki katmandan birinde doğabilir. Günlükleri okumadan hangisinin 502 ürettiğini anlayamazsınız. Panelli hostingde bu günlüklere erişiminiz yoksa sağlayıcınızdan ilgili satırları isteyin.

Daha geniş bir karşılaştırma için OpenLiteSpeed ile nginx farkını anlattığımız yazıya bakabilirsiniz.

Node.js, PM2 ve Next.js uygulamalarında 502 neden çıkar?

Node.js uygulamaları çoğunlukla nginx arkasında kendi portunda çalışır. Uygulama çöktüyse, port farklıysa ya da süreç yöneticisi servisi yeniden başlatamadıysa nginx 502 verir. Bu, Node dünyasında 502'nin en yaygın sebebidir.

Sırayla şunları kontrol edin:

1. Uygulama süreci çalışıyor mu? PM2 kullanıyorsanız pm2 status bunu gösterir.
2. Uygulama, nginx'in proxy_pass ile işaret ettiği portta mı dinliyor?
3. Uygulama yalnızca IPv4 ya da yalnızca IPv6 üzerinde mi dinliyor? Bazı kurulumlarda localhost adı farklı bir adrese çözülür ve bağlantı kurulamaz.
4. Son dağıtımdan sonra derleme (build) başarıyla bitti mi?
5. Bellek yetersizliği nedeniyle süreç sonlandırıldı mı?

Kurulum ayrıntıları için Node.js kurulumu ve nginx ile systemd yayını, PM2 ile süreç yönetimi ve Next.js uygulamasını VPS'e yayınlama yazılarımızı okuyabilirsiniz. Orada anlattıklarımızı burada tekrarlamıyoruz.

Cloudflare ya da CDN arkasında 502 nasıl teşhis edilir?

Cloudflare dokümanına göre 502 ya da 504, Cloudflare'in kaynak web sunucunuzla iletişim kuramadığı anlamına gelir. Hatayı iki yerden görebilirsiniz: kaynak sunucudan gelen hata Cloudflare markalı sayfayla, Cloudflare'in kendi ürettiği hata ise markasız boş sayfayla görünür.

Bu ayrım size nereye bakacağınızı söyler:

• Markalı sayfa: Sorun kaynak sunucudadır. Hosting sağlayıcınızla çalışın.
• Markasız boş sayfa: Cloudflare kaynaklı olabilir. Dokümana göre bir örnek, kaynağın gzip ile sıkıştırılmış içeriği sunup content-length başlığını güncellememesidir.

Cloudflare Destek'e yazarken saat ve saat dilimini, etkilenen adresi ve alan adınızın /cdn-cgi/trace çıktısını eklemeniz istenir. CDN'i geçici olarak devre dışı bırakıp kaynağa doğrudan gitmek, hatanın hangi katmanda olduğunu hızla gösterir.

Kaynak sunucunuzun gerçek adresini ve IP bilgisini herkese açık yerlerde paylaşmayın. IP sorgulama aracı gibi araçlarla yalnızca kendi kayıtlarınızı doğrulayın.

Cloudflare 520-524 hataları 502'den nasıl ayrılır?

Cloudflare, 502 ve 504'ün yanında kendine özgü 52x kodları da kullanır. Resmi 5xx sayfası bu kodları tek cümleyle tanımlar ve hepsinde hosting sağlayıcıya hata kodu, saat ve etkilenen adresle başvurmayı önerir.

Kısacası 520-526 aralığını görüyorsanız Cloudflare kullanıyorsunuz demektir ve sorun çoğu zaman kaynak sunucudadır. 525 ve 526 için SSL sorgulama aracı ile sertifikanızı kontrol edin. Sertifika temellerini SSL sertifikası yazımızda anlattık.

502 hatası SEO'yu ve satışları nasıl etkiler?

Kısa süreli bir 502 sıralamanızı bozmaz, fakat uzayan hata bozar. Google Search Central, 5xx ve 429 hatalarının tarama hızını geçici olarak yavaşlattığını yazar. Hatalı URL sayısı arttıkça tarama oranı da orantılı olarak düşer.

Google'ın aynı sayfasına göre, indekste olan URL'ler önce korunur, fakat sürekli sunucu hatası dönen adresler zamanla indeksten düşer. Sunucu tekrar 2xx dönmeye başlayınca Google tarama hızını kademeli olarak artırır.

E-ticarette etki daha doğrudan olur. Ödeme sayfası 502 verirse sepet terk edilir. Reklam trafiği çekiyorsanız, hatalı sayfaya giden her tıkın bedelini yine ödersiniz. Bu nedenle e-ticarette sayfa hızı ve kullanılabilirlik konusunu birlikte düşünmek gerekir. Genel resim için site hızının SEO'ya etkisi yazımıza da bakın.

Kalıcı bir bakım ya da geçici kapanış varsa, kod olarak 503 ve Retry-After kullanmak 502'den daha doğrudur.

Hata günlüğündeki satırlar neyi anlatır?

Günlük, 502'nin gerçek nedenini söyleyen tek kaynaktır. Nginx hata günlüğü, upstream ile yaşanan sorunu genellikle "upstream" kelimesini içeren bir cümleyle kaydeder. Cümlenin son kısmı, hatanın hangi aşamada olduğunu gösterir.

• "Connection refused" ve "while connecting to upstream": Bağlantı kurulamadı; servis kapalı ya da adres yanlış.
• "Upstream timed out" ve "while reading response header": Upstream bağlantıyı kabul etti ama yanıt başlığını göndermedi; yavaş betik ya da kilitlenmiş süreç olabilir.
• "Upstream prematurely closed connection": Upstream yanıtı bitirmeden bağlantıyı kapattı; çökme ya da bellek yetersizliği akla gelir.
• "Permission denied": Soket dosyasına erişim izni yok; kullanıcı ve grup ayarlarına bakın.
• "No such file or directory": Soket dosyası bulunamıyor; PHP-FPM çalışmıyor ya da yol farklı.

Satırın yanındaki saat damgası, ziyaretçinin hata gördüğü saatle eşleşmelidir. Böylece alakasız eski kayıtlara takılmazsınız. Ayrıca günlük çok hızlı büyüyorsa, bunun kendisi de bir uyarıdır: sürekli tekrarlayan bir hata sunucuyu yoruyordur.

Bu kayıtları okumak için kök erişimi gerekir. Paylaşımlı hostingde sağlayıcınızdan ilgili zaman aralığındaki satırları isteyin.

WordPress sitelerinde 502 için hangi kontrolleri yaparsınız?

WordPress sahipleri 502'yi çoğunlukla bir eklenti ya da tema değişikliğinden sonra görür. Yönetim paneline giremiyorsanız dosya yöneticisi ya da FTP ile wp-content/plugins klasörünün adını geçici olarak değiştirebilirsiniz. Bu, tüm eklentileri devre dışı bırakır ve suçlunun eklenti olup olmadığını hızla gösterir.

Şu sırayı deneyin:

1. Hatadan hemen önce güncellenen eklentiyi bulun ve devre dışı bırakın.
2. Sorun sürerse tüm eklentileri durdurup tek tek geri açın.
3. Temayı varsayılan bir temaya geçirmeyi deneyin.
4. Hosting panelinde PHP sürümünü ve bellek sınırını kontrol edin.
5. Yoğun çalışan cron işlerini, yedekleme eklentilerini ve içe aktarma işlemlerini gözden geçirin.

Ağır bir eklenti, aynı anda birçok PHP işçisini uzun süre tutabilir. Bu da havuzun dolmasına ve 502'ye yol açar. Dolayısıyla eklenti sayısını makul tutmak, hem güvenlik hem kararlılık için iyi bir alışkanlıktır.

Hata sürerse ve sunucuya erişiminiz yoksa, bulduklarınızı sağlayıcınıza aktarın. WordPress'in kendisini onarmaya çalışırken yedeksiz değişiklik yapmayın.

502 hatasını bir daha yaşamamak için hangi önlemleri alırsınız?

Kalıcı çözüm, hatayı önceden görmeyi ve tek bir arızanın tüm siteyi düşürmesini engellemeyi gerektirir. Bunların çoğu sağlayıcınızla birlikte yapacağınız işlerdir.

• İzleme: Ana sayfayı ve kritik sayfaları dışarıdan düzenli aralıklarla kontrol eden bir uptime izleme kurun.
• Servis yeniden başlatma: systemd ya da PM2 ile çöken servisin otomatik ayağa kalkmasını sağlayın.
• Kaynak planı: RAM ve PHP işçi sayısını gerçek trafiğe göre ayarlayın.
• Önbellek: Sık istenen sayfaları önbelleğe alarak upstream yükünü azaltın. OPcache ve Redis ile Memcached yazılarımız bu konuyu işliyor.
• Güvenli dağıtım: Değişiklikleri canlıya almadan önce deneme ortamında test edin ve her zaman yedek alın.
• Sürüm uyumu: Eklenti, tema ve PHP sürümlerinin birbiriyle uyumunu güncellemeden önce kontrol edin.

Ayrıca saldırı trafiğini de unutmayın. Anormal sayıda istek PHP işçilerini tüketebilir. Fail2ban ve ModSecurity gibi katmanlar bu yükü azaltır.

Hangi durumlarda işi hosting sağlayıcınıza bırakmalısınız?

Dürüst cevabımız şudur: sunucu yönetimi sizin işiniz değilse, kendiniz kurcalamayın. Yanlış bir yapılandırma tek bir hatayı birkaç hataya çevirebilir. Aşağıdaki durumlarda doğrudan sağlayıcıya gidin.

• Paylaşımlı hosting ya da yönetilen VPS kullanıyorsanız ve kök erişiminiz yoksa.
• Hata sunucu geneline yayılmışsa ve birden fazla siteniz aynı anda düşüyorsa.
• Günlüklerde disk, bellek ya da ağ donanımına işaret eden satırlar görüyorsanız.
• Canlı bir e-ticaret sitesinde yapılandırma dosyasını ilk kez düzenleyecekseniz.
• Yanlış değişiklik yapıp yedeksiz kalma riskiniz varsa.

Ayrıca hosting seçerken destek kalitesini de ölçüt alın. Web sitesi için hosting nasıl seçilir yazımızda bu kriterleri sıraladık.

Hosting sağlayıcınıza yazarken destek talebine neler eklersiniz?

Eksik bilgi, destek süresini uzatır. Cloudflare de kendi dokümanında hata kodunu, saati ve adresi istediğini açıkça yazar. Aynı yaklaşım her sağlayıcı için işe yarar.

Talebinize şu bilgileri ekleyin:

1. Hatanın başladığı ve bittiği saat (saat dilimiyle).
2. Etkilenen tam adres ve hatanın tüm sayfalarda mı yoksa belirli sayfalarda mı çıktığı.
3. Hata sayfasının ekran görüntüsü.
4. Hatadan hemen önce yaptığınız değişiklik (eklenti, tema, dağıtım).
5. CDN kullanıyorsanız, kaynağa doğrudan erişimde sonucun ne olduğu.
6. Varsa hata günlüğünden ilgili birkaç satır.

Parola, anahtar ve özel bilgileri destek talebine koymayın. Günlük satırı paylaşacaksanız içindeki kişisel verileri temizleyin.

502 teşhisi için hızlı özet tablo nasıl okunur?

Aşağıdaki tablo, belirtiyi olası nedene ve sorumluya bağlar. Kesin hüküm değil, teşhis için başlangıç noktasıdır.

Tabloyu bir kontrol listesi gibi kullanın. Sonuç belirsizse günlükteki cümleyi esas alın.

Ekibimizden nasıl destek alırsınız?

Biz sunucu yönetimi sunan bir hosting firması değiliz. Fakat 502 gibi hatalar, sitenizin görünürlüğünü ve reklam bütçenizi doğrudan etkilediği için işin pazarlama tarafına dokunur. Hata saatlerini arama trafiği ve reklam verisiyle birlikte okumak, kaybı anlamanıza yardım eder.

Yeni bir site planlıyorsanız web tasarım hizmetimiz, mevcut sitenizin teknik görünürlüğü için SEO danışmanlığımız, online mağazanız için e-ticaret danışmanlığımız var. Teknik altyapı kararlarında sağlayıcınızla birlikte çalışır, ihtiyacınıza uygun gereksinimleri netleştirmenize yardım ederiz.

Performans ölçümü için Google Lighthouse ile site performans testi yazımız iyi bir başlangıçtır. Yavaşlık sorunlarının sunucu tarafını da web sitesi neden yavaş açılır yazımızda anlattık.

502 Bad Gateway hakkında özetle neyi aklınızda tutmalısınız?

502, arka planda bir şeyin ters gittiğini söyler; neyin ters gittiğini ise günlük söyler. Önce ziyaretçi tarafını eleyin, sonra servislerin durumuna, ters proxy ayarlarına ve kaynak sınırlarına bakın. CDN kullanıyorsanız markalı ve markasız hata sayfası ayrımı size yol gösterir.

Ayrıca hatayı kalıcı çözmek için izleme, otomatik yeniden başlatma ve gerçekçi kaynak planı gerekir. Sunucu yönetimi uzmanlık ister. Emin değilseniz, doğru bilgiyle sağlayıcınıza gitmek en güvenli yoldur.