Bir web sitesi y\u00f6neticisi veya geli\u015ftiricisi olarak, kullan\u0131c\u0131lar\u0131n\u0131z\u0131n aniden “Hizmet Kullan\u0131lam\u0131yor” veya “A\u011f Ge\u00e7idi Zaman A\u015f\u0131m\u0131” gibi mesajlarla kar\u015f\u0131la\u015fmas\u0131 k\u00e2bus gibidir. Peki, bu tan\u0131d\u0131k ancak \u00e7o\u011fu zaman kafa kar\u0131\u015ft\u0131r\u0131c\u0131 503 ve 504 HTTP durum kodlar\u0131 tam olarak ne anlama geliyor ve Nginx, AWS Application Load Balancer (ALB) ve Cloudflare gibi yayg\u0131n altyap\u0131 bile\u015fenlerinde nas\u0131l tetikleniyorlar? Bu makalede, bu kritik hata kodlar\u0131n\u0131n derinliklerine inecek, temel farklar\u0131n\u0131 a\u00e7\u0131klayacak ve modern web mimarilerindeki tetiklenme mekanizmalar\u0131n\u0131 ger\u00e7ek d\u00fcnya senaryolar\u0131yla ad\u0131m ad\u0131m inceleyece\u011fiz. Amac\u0131m\u0131z, bu hatalar\u0131 sadece anlamakla kalmay\u0131p, ayn\u0131 zamanda onlar\u0131 etkili bir \u015fekilde giderebilmeniz ve hatta olu\u015fmadan \u00f6nleyebilmeniz i\u00e7in size kapsaml\u0131 bir yol haritas\u0131 sunmakt\u0131r.<\/p>\n
Web d\u00fcnyas\u0131nda gezinirken veya bir uygulama geli\u015ftirirken, kar\u015f\u0131m\u0131za \u00e7\u0131kan her HTTP durum kodu bir hikaye anlat\u0131r. 200 OK ba\u015far\u0131y\u0131, 404 Not Found ise arad\u0131\u011f\u0131m\u0131z kayna\u011f\u0131n bulunamad\u0131\u011f\u0131n\u0131 ifade eder. Ancak i\u015fler ters gitmeye ba\u015flad\u0131\u011f\u0131nda, genellikle 5xx serisi hatalarla kar\u015f\u0131la\u015f\u0131r\u0131z. Bu hatalar, sunucu taraf\u0131nda bir sorun oldu\u011funu, yani iste\u011fi i\u015fleyen sunucunun iste\u011fi yerine getiremedi\u011fini g\u00f6sterir. Kullan\u0131c\u0131 deneyimini do\u011frudan etkiledikleri ve potansiyel gelir kay\u0131plar\u0131na yol a\u00e7abildikleri i\u00e7in 5xx hatalar\u0131n\u0131 anlamak ve y\u00f6netmek hayati \u00f6neme sahiptir. \u00d6zellikle 503 Service Unavailable ve 504 Gateway Timeout, en s\u0131k kar\u015f\u0131la\u015f\u0131lan ve birbirine kar\u0131\u015ft\u0131r\u0131lan hatalardan ikisidir.<\/p>\n
503 Service Unavailable (Hizmet Kullan\u0131lam\u0131yor) hatas\u0131, sunucunun iste\u011fi \u015fu anda i\u015fleyemedi\u011fini belirtir. Bu durum genellikle sunucunun a\u015f\u0131r\u0131 y\u00fcklenmesi, bak\u0131mda olmas\u0131 veya ge\u00e7ici olarak kullan\u0131lamaz hale gelmesi gibi nedenlerden kaynaklan\u0131r. Bu hata, sunucunun iste\u011fi al\u0131p i\u015fleyebildi\u011fini, ancak belirli bir nedenle \u015fu anda hizmet veremedi\u011fini a\u00e7\u0131k\u00e7a ifade eder. \u00d6rne\u011fin, bir veritaban\u0131 ba\u011flant\u0131s\u0131 koptu\u011funda, bir uygulama sunucusu \u00e7\u00f6kt\u00fc\u011f\u00fcnde veya sistem kaynaklar\u0131 t\u00fckendi\u011finde (CPU, RAM vb.), uygulama bu durumu 503 olarak geri d\u00f6nd\u00fcrebilir. \u00d6nemli olan, bu hatan\u0131n genellikle ge\u00e7ici bir durum oldu\u011funu ve sunucunun daha sonra tekrar hizmet vermeye ba\u015flayaca\u011f\u0131n\u0131 ima etmesidir. Bu nedenle, baz\u0131 503 yan\u0131tlar\u0131, istemcilere ne kadar s\u00fcre sonra tekrar denemeleri gerekti\u011fini bildiren bir \u00d6te yandan, 504 Gateway Timeout (A\u011f Ge\u00e7idi Zaman A\u015f\u0131m\u0131) hatas\u0131, sunucunun (genellikle bir a\u011f ge\u00e7idi veya proxy) yukar\u0131 ak\u0131\u015f (upstream) sunucusundan zaman\u0131nda yan\u0131t alamad\u0131\u011f\u0131n\u0131 g\u00f6sterir. Yani, istemcinin iste\u011fini alan sunucu, bu iste\u011fi i\u015flemek i\u00e7in ba\u015fka bir sunucuya (\u00f6rne\u011fin bir uygulama sunucusu veya veritaban\u0131 sunucusu) y\u00f6nlendirmi\u015f, ancak bu ikinci sunucu belirli bir s\u00fcre i\u00e7inde yan\u0131t vermemi\u015ftir. Bu durum, arka u\u00e7 sunucusunun a\u015f\u0131r\u0131 yava\u015f \u00e7al\u0131\u015fmas\u0131, kilitlenmesi veya hi\u00e7 yan\u0131t vermemesi gibi durumlarda ortaya \u00e7\u0131kar. 504 hatas\u0131, genellikle a\u011f gecikmeleri, uzun s\u00fcren veritaban\u0131 sorgular\u0131, harici API \u00e7a\u011fr\u0131lar\u0131n\u0131n tak\u0131lmas\u0131 veya arka u\u00e7 uygulamas\u0131n\u0131n i\u015f y\u00fck\u00fcn\u00fc kald\u0131ramayacak kadar me\u015fgul olmas\u0131 gibi nedenlerle tetiklenir. Bu hata, proxy sunucusunun bekledi\u011fi s\u00fcrenin doldu\u011funu ve art\u0131k daha fazla bekleyemeyece\u011fini belirtir. Temel fark\u0131 \u00f6zetlemek gerekirse: 503, sunucunun “\u015fu an me\u015fgul\u00fcm\/hizmet veremiyorum” demesi gibiyken, 504, “arkada\u015f\u0131ma sordum ama bir t\u00fcrl\u00fc yan\u0131t alamad\u0131m” demesi gibidir. Bu iki hata aras\u0131ndaki ayr\u0131m\u0131 anlamak, sorunun kayna\u011f\u0131n\u0131 do\u011fru bir \u015fekilde te\u015fhis etmek ve gidermek i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n Nginx, modern web mimarilerinin vazge\u00e7ilmez bir par\u00e7as\u0131d\u0131r. Genellikle bir ters proxy (reverse proxy) ve y\u00fck dengeleyici (load balancer) olarak g\u00f6rev yapar, gelen istekleri arka u\u00e7 (upstream) sunucular\u0131na y\u00f6nlendirir. Bu kritik rol\u00fc nedeniyle, Nginx’in 503 ve 504 hatalar\u0131n\u0131 nas\u0131l tetikledi\u011fini anlamak, hata ay\u0131klama ve sistem performans\u0131n\u0131 optimize etme a\u00e7\u0131s\u0131ndan b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Nginx, bu hata kodlar\u0131n\u0131 \u00e7e\u015fitli yap\u0131land\u0131rma ayarlar\u0131 ve arka u\u00e7 sunucular\u0131n\u0131n davran\u0131\u015flar\u0131na ba\u011fl\u0131 olarak \u00fcretir.<\/p>\n 504 Gateway Timeout hatas\u0131, Nginx’in bir iste\u011fi arka u\u00e7 sunucusuna iletti\u011finde ve belirli bir s\u00fcre i\u00e7inde yan\u0131t alamad\u0131\u011f\u0131nda tetiklenir. Nginx’in bu davran\u0131\u015f\u0131 kontrol eden temel direktifler \u015funlard\u0131r: Yukar\u0131daki \u00f6rnekte, Nginx arka u\u00e7 sunucusundan 60 saniye i\u00e7inde yan\u0131t alamazsa 504 hatas\u0131 d\u00f6necektir. E\u011fer 503 Service Unavailable hatas\u0131 ise Nginx taraf\u0131ndan farkl\u0131 senaryolarda tetiklenir. En yayg\u0131n durum, Nginx’in bir veya daha fazla arka u\u00e7 sunucusunu “sa\u011fl\u0131ks\u0131z” (unhealthy) olarak i\u015faretlemesidir. Bu durum, Yukar\u0131daki \u00f6rnekte, e\u011fer Ger\u00e7ek d\u00fcnya senaryosunda, bir e-ticaret sitesinin \u00f6deme i\u015flemi s\u0131ras\u0131nda arka u\u00e7 mikroservislerinden birinin veritaban\u0131 ba\u011flant\u0131 havuzunun doldu\u011funu ve yeni ba\u011flant\u0131lar\u0131 reddetmeye ba\u015flad\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnelim. Bu durumda, mikroservis do\u011frudan 503 yan\u0131t\u0131 d\u00f6nd\u00fcrebilir veya o kadar yava\u015flar ki Nginx’in AWS Application Load Balancer (ALB), modern bulut tabanl\u0131 uygulamalar i\u00e7in esneklik ve \u00f6l\u00e7eklenebilirlik sa\u011flayan kritik bir bile\u015fendir. Gelen trafi\u011fi birden fazla hedef (target) aras\u0131nda da\u011f\u0131tarak uygulaman\u0131z\u0131n y\u00fcksek eri\u015filebilirli\u011fini ve performans\u0131n\u0131 garanti eder. Ancak ALB de, arka u\u00e7 hedeflerinin durumuna ve kendi yap\u0131land\u0131rmas\u0131na ba\u011fl\u0131 olarak 503 ve 504 hatalar\u0131 \u00fcretebilir. Bu hatalar\u0131n ALB ba\u011flam\u0131nda nas\u0131l tetiklendi\u011fini anlamak, AWS ortam\u0131ndaki uygulamalar\u0131n\u0131z\u0131n sorunlar\u0131n\u0131 gidermek i\u00e7in temel bir ad\u0131md\u0131r.<\/p>\n ALB’nin 503 Service Unavailable hatas\u0131 \u00fcretmesinin en yayg\u0131n nedeni, hedef grubundaki (target group) t\u00fcm hedeflerin sa\u011fl\u0131ks\u0131z (unhealthy) olarak i\u015faretlenmesi veya hedeflerin tamamen eksik olmas\u0131d\u0131r. ALB, hedef gruplar\u0131ndaki her bir hedef i\u00e7in d\u00fczenli sa\u011fl\u0131k kontrolleri (health checks) yapar. Bu sa\u011fl\u0131k kontrolleri, belirli bir HTTP yolu (path) \u00fczerinden hedeflere istek g\u00f6ndererek veya belirli bir TCP portunu kontrol ederek hedefin yan\u0131t verip vermedi\u011fini ve beklenen durumu (\u00f6rne\u011fin, HTTP 200 OK) d\u00f6nd\u00fcr\u00fcp d\u00f6nd\u00fcrmedi\u011fini denetler. E\u011fer bir hedef, yap\u0131land\u0131r\u0131lm\u0131\u015f sa\u011fl\u0131k kontrol\u00fc e\u015fiklerini (\u00f6rne\u011fin, 504 Gateway Timeout hatas\u0131 ise ALB taraf\u0131ndan, bir iste\u011fi arka u\u00e7 hedefine y\u00f6nlendirdi\u011finde ve hedeften yap\u0131land\u0131r\u0131lm\u0131\u015f s\u00fcre i\u00e7inde yan\u0131t alamad\u0131\u011f\u0131nda tetiklenir. ALB’nin bu davran\u0131\u015f\u0131 kontrol eden temel ayar, y\u00fck dengeleyicinin Bir vaka analizi olarak, pop\u00fcler bir sosyal medya platformunun resim y\u00fckleme hizmetini d\u00fc\u015f\u00fcnelim. Kullan\u0131c\u0131lar y\u00fcksek \u00e7\u00f6z\u00fcn\u00fcrl\u00fckl\u00fc resimler y\u00fckledi\u011finde, arka u\u00e7 servisi bu resimleri yeniden boyutland\u0131rmak ve farkl\u0131 formatlara d\u00f6n\u00fc\u015ft\u00fcrmek i\u00e7in zaman al\u0131c\u0131 i\u015flemler yapabilir. E\u011fer bu i\u015flemler, ALB’nin varsay\u0131lan 60 saniyelik Sonu\u00e7 olarak, ALB ortam\u0131nda 503 ve 504 hatalar\u0131n\u0131 gidermek i\u00e7in \u00f6ncelikle hedef grubunun sa\u011fl\u0131k kontrollerini ve hedeflerin durumunu kontrol etmek gerekir. 503 hatas\u0131 genellikle hedef sa\u011fl\u0131\u011f\u0131yla ilgiliyken, 504 hatas\u0131 daha \u00e7ok arka u\u00e7 uygulamas\u0131n\u0131n yan\u0131t s\u00fcresi ve ALB’nin Cloudflare, d\u00fcnya genelinde milyonlarca web sitesi i\u00e7in bir CDN (\u0130\u00e7erik Da\u011f\u0131t\u0131m A\u011f\u0131), g\u00fcvenlik katman\u0131 ve ters proxy hizmeti sunar. Bir web iste\u011fi Cloudflare \u00fczerinden ge\u00e7ti\u011finde, Cloudflare hem iste\u011fi \u00f6nbelle\u011fe alabilir hem de g\u00fcvenlik kontrolleri uygulayabilir, ard\u0131ndan iste\u011fi ger\u00e7ek origin (kaynak) sunucusuna y\u00f6nlendirir. Bu arac\u0131 rol\u00fc nedeniyle, Cloudflare’\u0131n 503 ve 504 gibi hata kodlar\u0131n\u0131 nas\u0131l i\u015fledi\u011fi ve kendi \u00f6zel 5xx hata kodlar\u0131n\u0131 ne zaman d\u00f6nd\u00fcrd\u00fc\u011f\u00fc, sorun giderme s\u00fcre\u00e7lerinde kritik bir \u00f6neme sahiptir.<\/p>\n Cloudflare, bir iste\u011fi origin sunucusuna iletti\u011finde ve origin sunucusundan belirli bir s\u00fcre i\u00e7inde yan\u0131t alamazsa 504 Gateway Timeout hatas\u0131 d\u00f6nd\u00fcrebilir. Ancak Cloudflare’\u0131n kendi \u00f6zel hata kodlar\u0131 da vard\u0131r ve bunlar genellikle temel 503\/504 senaryolar\u0131na kar\u015f\u0131l\u0131k gelir. \u00d6rne\u011fin, Cloudflare’\u0131n en yayg\u0131n zaman a\u015f\u0131m\u0131 hatas\u0131 524 A Timeout Occurred’dur. Bu hata, Cloudflare’\u0131n origin sunucusuna bir istek g\u00f6nderdi\u011finde ve origin sunucusunun 100 saniye i\u00e7inde (Cloudflare’\u0131n varsay\u0131lan zaman a\u015f\u0131m\u0131) bir yan\u0131t d\u00f6nd\u00fcrmemesi durumunda tetiklenir. Bu durum, arka u\u00e7 uygulamas\u0131n\u0131n \u00e7ok uzun s\u00fcren bir i\u015flem yapmas\u0131, veritaban\u0131 sorgular\u0131n\u0131n tak\u0131lmas\u0131 veya harici API \u00e7a\u011fr\u0131lar\u0131n\u0131n gecikmesi gibi nedenlerle ortaya \u00e7\u0131kar. Temel olarak, Cloudflare’\u0131n 524 hatas\u0131, Nginx veya ALB’nin d\u00f6nd\u00fcrece\u011fi 504 hatas\u0131n\u0131n Cloudflare taraf\u0131ndaki kar\u015f\u0131l\u0131\u011f\u0131d\u0131r. Bu hatay\u0131 g\u00f6rd\u00fc\u011f\u00fcn\u00fczde, sorunun Cloudflare ile origin sunucunuz aras\u0131ndaki ileti\u015fimde veya origin sunucunuzun kendisinde bir performans sorunu oldu\u011funu anlamal\u0131s\u0131n\u0131z.<\/p>\n 503 Service Unavailable hatas\u0131 i\u00e7in Cloudflare’\u0131n da kendi \u00f6zel e\u015fde\u011ferleri mevcuttur. Cloudflare’\u0131n 521 Web Server Is Down hatas\u0131, Cloudflare’\u0131n origin sunucunuza TCP ba\u011flant\u0131s\u0131 kuramad\u0131\u011f\u0131nda tetiklenir. Bu, origin sunucunuzun tamamen kapal\u0131 oldu\u011fu, g\u00fcvenlik duvar\u0131n\u0131n Cloudflare IP’lerini engelledi\u011fi veya web sunucusu uygulamas\u0131n\u0131n \u00e7al\u0131\u015fmad\u0131\u011f\u0131 durumlarda g\u00f6r\u00fcl\u00fcr. Benzer \u015fekilde, 522 Connection Timed Out hatas\u0131, Cloudflare’\u0131n origin sunucusuyla TCP ba\u011flant\u0131s\u0131 kurabildi\u011fi ancak origin sunucusunun bir HTTP yan\u0131t\u0131 d\u00f6nd\u00fcrmeden ba\u011flant\u0131y\u0131 kapatt\u0131\u011f\u0131 durumlarda ortaya \u00e7\u0131kar. Bu, origin sunucusunun a\u015f\u0131r\u0131 y\u00fcklenmesi, kaynaklar\u0131n\u0131n t\u00fckenmesi veya hatal\u0131 bir a\u011f yap\u0131land\u0131rmas\u0131 nedeniyle ger\u00e7ekle\u015febilir. Bu 521 ve 522 hatalar\u0131, temelde origin sunucunuzun hizmet veremedi\u011fini g\u00f6steren 503’\u00fcn farkl\u0131 varyasyonlar\u0131d\u0131r.<\/p>\n Cloudflare ayr\u0131ca, origin sunucunuzun do\u011frudan 503 veya 504 hatas\u0131 d\u00f6nd\u00fcrmesi durumunda bu hatalar\u0131 istemciye iletebilir. \u00d6rne\u011fin, e\u011fer origin sunucunuz bak\u0131m modundaysa ve 503 yan\u0131t\u0131 veriyorsa, Cloudflare bu 503 yan\u0131t\u0131n\u0131 oldu\u011fu gibi istemciye aktar\u0131r. Ancak, Cloudflare’\u0131n kendi g\u00fcvenlik duvar\u0131 (WAF) kurallar\u0131 veya DDoS koruma mekanizmalar\u0131 da belirli senaryolarda 503 hatas\u0131 d\u00f6nd\u00fcrebilir. \u00d6rne\u011fin, bir sald\u0131r\u0131 tespit edildi\u011finde veya bir IP adresi engellendi\u011finde, Cloudflare bazen 503 yan\u0131t\u0131yla iste\u011fi reddedebilir.<\/p>\n Bir vaka analizi olarak, bir haber portal\u0131n\u0131n yo\u011fun bir haber yay\u0131nland\u0131\u011f\u0131nda ani bir trafik art\u0131\u015f\u0131 ya\u015fad\u0131\u011f\u0131n\u0131 d\u00fc\u015f\u00fcnelim. Origin sunucular\u0131 bu y\u00fck\u00fc kald\u0131ramayarak a\u015f\u0131r\u0131 y\u00fcklenir ve yava\u015flamaya ba\u015flar. Cloudflare, bu yava\u015flayan origin sunucular\u0131na istek g\u00f6nderdi\u011finde, origin’den 100 saniye i\u00e7inde yan\u0131t gelmezse 524 hatalar\u0131 tetiklenecektir. E\u011fer origin sunucular\u0131 tamamen \u00e7\u00f6ker ve Cloudflare onlara hi\u00e7 ba\u011flanamazsa, 521 hatalar\u0131 ortaya \u00e7\u0131kar. Bu durumda, Cloudflare’\u0131n “Always Online” \u00f6zelli\u011fi, \u00f6nbelle\u011fe al\u0131nm\u0131\u015f i\u00e7eri\u011fi sunarak bir nebze olsun kullan\u0131c\u0131 deneyimini koruyabilir, ancak dinamik i\u00e7erik i\u00e7in hata kodlar\u0131 ka\u00e7\u0131n\u0131lmaz olacakt\u0131r. Sorun giderme a\u015famas\u0131nda, Cloudflare paneli \u00fczerindeki trafik analizi ve hata loglar\u0131n\u0131 kontrol etmek, origin sunucunuzun durumunu izlemek ve Cloudflare ile origin aras\u0131ndaki ba\u011flant\u0131 ayarlar\u0131n\u0131 g\u00f6zden ge\u00e7irmek hayati \u00f6neme sahiptir. \u00d6zellikle g\u00fcvenlik duvar\u0131 (firewall) ayarlar\u0131n\u0131n Cloudflare IP aral\u0131klar\u0131na izin verdi\u011finden emin olmak, 521 gibi ba\u011flant\u0131 hatalar\u0131n\u0131 \u00f6nlemek i\u00e7in ilk ad\u0131mlardan biridir.<\/p>\n Web uygulamalar\u0131ndaki 503 ve 504 hatalar\u0131, genellikle karma\u015f\u0131k altyap\u0131lar\u0131n birbiriyle etkile\u015fiminden kaynaklan\u0131r. Bu hatalar\u0131 gidermek, sistemin farkl\u0131 katmanlar\u0131n\u0131 anlamay\u0131 ve do\u011fru ara\u00e7lar\u0131 kullanmay\u0131 gerektirir. \u0130\u015fte bu hatalar\u0131n ger\u00e7ek d\u00fcnya senaryolar\u0131 ve etkili hata giderme stratejileri:<\/p>\n Bir Black Friday indirimi s\u0131ras\u0131nda e-ticaret sitenizin trafi\u011fi aniden f\u0131rlad\u0131. Kullan\u0131c\u0131lar sepete \u00fcr\u00fcn eklemekte veya \u00f6deme yaparken s\u00fcrekli 504 hatalar\u0131 al\u0131yor. Bu durumda ne yapmal\u0131s\u0131n\u0131z?<\/p>\n Bir sunucuya yama uygulad\u0131ktan veya bir uygulama da\u011f\u0131t\u0131m\u0131 yapt\u0131ktan sonra, web sitenize eri\u015fmeye \u00e7al\u0131\u015fan kullan\u0131c\u0131lar s\u00fcrekli 503 hatas\u0131 al\u0131yor.<\/p>\n Bu hata giderme stratejileri, 503 ve 504 hatalar\u0131n\u0131n karma\u015f\u0131k do\u011fas\u0131na \u0131\u015f\u0131k tutar. Her katman\u0131n kendi sorumluluklar\u0131 ve yap\u0131land\u0131rmalar\u0131 oldu\u011funu anlamak, sorunun kayna\u011f\u0131n\u0131 h\u0131zl\u0131ca bulman\u0131za ve \u00e7\u00f6zmenize yard\u0131mc\u0131 olacakt\u0131r.<\/p>\n Web uygulamalar\u0131ndaki 503 Service Unavailable ve 504 Gateway Timeout hatalar\u0131, kullan\u0131c\u0131 deneyimini do\u011frudan etkileyen ve i\u015f s\u00fcreklili\u011fi a\u00e7\u0131s\u0131ndan kritik \u00f6neme sahip durumlard\u0131r. Bu makalede, bu iki hata kodunun temel farklar\u0131n\u0131, Nginx, AWS Application Load Balancer (ALB) ve Cloudflare gibi modern web altyap\u0131lar\u0131nda nas\u0131l tetiklendiklerini ve bu hatalar\u0131 gidermek i\u00e7in kullan\u0131labilecek stratejileri detayl\u0131 bir \u015fekilde inceledik. G\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, 503 genellikle sunucunun ge\u00e7ici olarak hizmet veremedi\u011fini (a\u015f\u0131r\u0131 y\u00fck, bak\u0131m, \u00e7\u00f6kme) g\u00f6sterirken, 504 bir proxy veya a\u011f ge\u00e7idinin yukar\u0131 ak\u0131\u015f sunucusundan zaman\u0131nda yan\u0131t alamad\u0131\u011f\u0131n\u0131 (yava\u015flama, tak\u0131lma, zaman a\u015f\u0131m\u0131) belirtir. Her iki hata da farkl\u0131 k\u00f6k nedenlere i\u015faret etse de, her ikisi de uygulaman\u0131z\u0131n genel sa\u011fl\u0131\u011f\u0131 ve performans\u0131 hakk\u0131nda \u00f6nemli ipu\u00e7lar\u0131 sunar.<\/p>\n Nginx, yap\u0131land\u0131rma dosyalar\u0131ndaki 1. 503 ve 504 hatalar\u0131 aras\u0131ndaki temel fark nedir?<\/strong><\/p>\n 503 Service Unavailable, sunucunun iste\u011fi al\u0131p i\u015fleyebildi\u011fini ancak ge\u00e7ici olarak hizmet veremedi\u011fini (bak\u0131m, a\u015f\u0131r\u0131 y\u00fck) belirtir. 504 Gateway Timeout ise, bir proxy veya a\u011f ge\u00e7idi sunucusunun, iste\u011fi iletti\u011fi yukar\u0131 ak\u0131\u015f sunucusundan belirli bir s\u00fcre i\u00e7inde yan\u0131t alamad\u0131\u011f\u0131n\u0131 g\u00f6sterir.<\/p>\n 2. Nginx’te 504 hatas\u0131n\u0131 \u00f6nlemek i\u00e7in hangi ayarlar\u0131 kontrol etmeliyim?<\/strong><\/p>\n Nginx’te 3. AWS ALB’de 503 hatas\u0131 al\u0131yorsam ilk nereye bakmal\u0131y\u0131m?<\/strong><\/p>\n ALB’de 503 hatas\u0131 al\u0131yorsan\u0131z, \u00f6ncelikle hedef grubunuzdaki (target group) hedeflerin sa\u011fl\u0131k durumunu (health status) kontrol etmelisiniz. Genellikle bu, t\u00fcm hedeflerin sa\u011fl\u0131ks\u0131z olarak i\u015faretlendi\u011fi veya hedef grubunda hi\u00e7 hedef bulunmad\u0131\u011f\u0131 anlam\u0131na gelir.<\/p>\n 4. Cloudflare’\u0131n 524 hatas\u0131 ile 504 hatas\u0131 aras\u0131ndaki ili\u015fki nedir?<\/strong><\/p>\n Cloudflare’\u0131n 524 A Timeout Occurred hatas\u0131, Cloudflare’\u0131n origin sunucusundan belirli bir s\u00fcre (varsay\u0131lan 100 saniye) i\u00e7inde yan\u0131t alamad\u0131\u011f\u0131nda tetiklenir. Bu, Cloudflare’\u0131n kendi a\u011f ge\u00e7idi zaman a\u015f\u0131m\u0131d\u0131r ve i\u015flevsel olarak genel 504 Gateway Timeout hatas\u0131n\u0131n Cloudflare’a \u00f6zg\u00fc bir versiyonudur.<\/p>\n 5. Uygulama sunucum yava\u015flad\u0131\u011f\u0131nda hem 503 hem de 504 hatas\u0131 alabilir miyim?<\/strong><\/p>\n Evet, alabilirsiniz. E\u011fer uygulama sunucunuz o kadar yava\u015flarsa ki Nginx veya ALB’nin zaman a\u015f\u0131m\u0131 s\u00fcresi dolarsa 504 hatas\u0131 al\u0131rs\u0131n\u0131z. E\u011fer uygulama sunucunuz yava\u015flaman\u0131n \u00f6tesine ge\u00e7ip tamamen yan\u0131t vermeyi durdurur veya \u00e7\u00f6kerse, Nginx\/ALB onu sa\u011fl\u0131ks\u0131z olarak i\u015faretleyebilir ve di\u011fer isteklere 503 hatas\u0131 d\u00f6nd\u00fcrebilir.<\/p>\n #Teknoloji #WebGeli\u015ftirme #HTTPHatalar\u0131 #Nginx #ALB #Cloudflare #503 #504<\/p>\n","protected":false},"excerpt":{"rendered":"Bir web sitesi y\u00f6neticisi veya geli\u015ftiricisi olarak, kullan\u0131c\u0131lar\u0131n\u0131z\u0131n aniden “Hizmet Kullan\u0131lam\u0131yor” veya “A\u011f Ge\u00e7idi Zaman A\u015f\u0131m\u0131” gibi mesajlarla kar\u015f\u0131la\u015fmas\u0131 k\u00e2bus gibidir.","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1504],"tags":[],"class_list":{"0":"post-44788","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-nginx","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nRetry-After<\/code> ba\u015fl\u0131\u011f\u0131 i\u00e7erebilir. Bu hata, genellikle iste\u011fin bir proxy veya y\u00fck dengeleyici taraf\u0131ndan arka u\u00e7 sunucusuna ba\u015far\u0131yla iletildi\u011fini, ancak arka u\u00e7 sunucusunun kendisinin bir sorun ya\u015fad\u0131\u011f\u0131n\u0131 g\u00f6sterir.<\/p>\nNginx ile 503 ve 504 Hatalar\u0131n\u0131n Dans\u0131: Yap\u0131land\u0131rma ve Tetiklenme Mekanizmalar\u0131<\/h2>\n
proxy_connect_timeout<\/code>, proxy_send_timeout<\/code> ve proxy_read_timeout<\/code>. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n web sitenize eri\u015fmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 varsayal\u0131m. \u0130stek \u00f6nce Nginx’e ula\u015f\u0131r. Nginx bu iste\u011fi bir uygulama sunucusuna (\u00f6rne\u011fin, bir Node.js veya PHP-FPM sunucusu) iletir. E\u011fer uygulama sunucusu, Nginx’in proxy_read_timeout<\/code> direktifinde belirtilen s\u00fcre i\u00e7inde bir yan\u0131t g\u00f6ndermezse, Nginx istemciye 504 hatas\u0131 d\u00f6nd\u00fcrecektir. Bu durum, genellikle arka u\u00e7 uygulamas\u0131n\u0131n \u00e7ok uzun s\u00fcren bir veritaban\u0131 sorgusu \u00e7al\u0131\u015ft\u0131rmas\u0131, harici bir API’den yan\u0131t beklerken tak\u0131lmas\u0131 veya genel olarak yo\u011fun i\u015f y\u00fck\u00fc alt\u0131nda yava\u015flamas\u0131 gibi nedenlerden kaynaklan\u0131r. Bu zaman a\u015f\u0131m\u0131 de\u011ferlerini dikkatli bir \u015fekilde ayarlamak, uygulaman\u0131z\u0131n tipik yan\u0131t s\u00fcrelerine uygun olmal\u0131, ancak ayn\u0131 zamanda tak\u0131lan isteklerin sistem kaynaklar\u0131n\u0131 uzun s\u00fcre me\u015fgul etmesini de engellemelidir.<\/p>\n\nhttp {\n upstream backend_servers {\n server 192.168.1.100:8080;\n server 192.168.1.101:8080;\n }\n\n server {\n listen 80;\n server_name example.com;\n\n location \/ {\n proxy_pass http:\/\/backend_servers;\n proxy_connect_timeout 5s; # Arka uca ba\u011flanma s\u00fcresi\n proxy_send_timeout 10s; # Arka uca veri g\u00f6nderme s\u00fcresi\n proxy_read_timeout 60s; # Arka u\u00e7tan yan\u0131t bekleme s\u00fcresi (504'\u00fc tetikler)\n proxy_intercept_errors on; # Arka u\u00e7tan gelen 4xx\/5xx hatalar\u0131n\u0131 Nginx'in yakalamas\u0131\n error_page 504 \/custom_504.html; # \u00d6zel 504 hata sayfas\u0131\n }\n }\n}\n <\/code><\/pre>\n<\/p><\/div>\nproxy_intercept_errors<\/code> direktifi on<\/code> olarak ayarlanm\u0131\u015fsa, Nginx arka u\u00e7tan gelen 5xx hatalar\u0131n\u0131 da yakalayabilir ve kendi \u00f6zel hata sayfalar\u0131n\u0131 sunabilir. Bu, kullan\u0131c\u0131 deneyimini iyile\u015ftirmek i\u00e7in \u00f6nemlidir.<\/p>\nupstream<\/code> blo\u011fundaki max_fails<\/code> ve fail_timeout<\/code> direktifleri ile kontrol edilir. E\u011fer bir arka u\u00e7 sunucusu, fail_timeout<\/code> s\u00fcresi i\u00e7inde max_fails<\/code> say\u0131s\u0131ndan daha fazla hata (ba\u011flant\u0131 hatas\u0131, zaman a\u015f\u0131m\u0131 veya yap\u0131land\u0131r\u0131lm\u0131\u015f HTTP durum kodlar\u0131) verirse, Nginx o sunucuyu belirli bir s\u00fcre boyunca havuzdan \u00e7\u0131kar\u0131r. Bu s\u00fcre boyunca o sunucuya gelen t\u00fcm istekler, havuzda ba\u015fka sa\u011fl\u0131kl\u0131 sunucu yoksa 503 hatas\u0131yla kar\u015f\u0131la\u015f\u0131r.<\/p>\n\nhttp {\n upstream backend_servers {\n server 192.168.1.100:8080 max_fails=3 fail_timeout=30s; # 30 saniyede 3 hata sonras\u0131 30s boyunca devre d\u0131\u015f\u0131\n server 192.168.1.101:8080 max_fails=3 fail_timeout=30s;\n }\n\n server {\n listen 80;\n server_name example.com;\n\n location \/ {\n proxy_pass http:\/\/backend_servers;\n proxy_next_upstream error timeout http_500 http_502 http_503 http_504; # Hata durumunda di\u011fer upstream'e ge\u00e7\n error_page 503 \/custom_503.html;\n }\n }\n}\n <\/code><\/pre>\n<\/p><\/div>\n192.168.1.100:8080<\/code> sunucusu 30 saniye i\u00e7inde 3 kez hata verirse, Nginx onu 30 saniyeli\u011fine havuzdan \u00e7\u0131kar\u0131r. Bu s\u00fcre i\u00e7inde o sunucuya g\u00f6nderilecek istekler, e\u011fer proxy_next_upstream<\/code> direktifi ile ba\u015fka bir sa\u011fl\u0131kl\u0131 sunucuya y\u00f6nlendirilemezse, 503 hatas\u0131yla sonu\u00e7lanabilir. proxy_next_upstream<\/code> direktifi, bir arka u\u00e7 sunucusunda belirli hatalar (error<\/code>, timeout<\/code>, http_503<\/code> vb.) olu\u015ftu\u011funda Nginx’in iste\u011fi bir sonraki arka u\u00e7 sunucusuna y\u00f6nlendirmesini sa\u011flar. Bu, sistemin esnekli\u011fini art\u0131r\u0131r ancak t\u00fcm arka u\u00e7 sunucular\u0131 ayn\u0131 anda \u00e7\u00f6kerse veya hepsi sa\u011fl\u0131ks\u0131z olarak i\u015faretlenirse, Nginx en sonunda 503 hatas\u0131 d\u00f6nd\u00fcrecektir.<\/p>\nproxy_read_timeout<\/code> s\u00fcresi dolarak 504 hatas\u0131 tetiklenir. E\u011fer mikroservis s\u00fcrekli 503 d\u00f6n\u00fcyorsa ve max_fails<\/code> e\u015fi\u011fini a\u015farsa, Nginx o sunucuyu havuzdan \u00e7\u0131karacak ve bu da kullan\u0131c\u0131lar i\u00e7in 503 hatalar\u0131na yol a\u00e7acakt\u0131r. Dolay\u0131s\u0131yla, Nginx’in yap\u0131land\u0131rmas\u0131, arka u\u00e7 hizmetlerinin sa\u011fl\u0131\u011f\u0131 ve performans\u0131 ile do\u011frudan ili\u015fkilidir ve bu hata kodlar\u0131n\u0131n ne zaman ve nas\u0131l g\u00f6r\u00fcnece\u011fini belirler.<\/p>\nAWS Application Load Balancer (ALB) ile Hata Y\u00f6netimi: 503 ve 504 Neden Kar\u015f\u0131m\u0131za \u00c7\u0131kar?<\/h2>\n
unhealthy threshold<\/code>) a\u015fan bir \u015fekilde ba\u015far\u0131s\u0131z olursa, ALB o hedefi sa\u011fl\u0131ks\u0131z olarak i\u015faretler ve ona trafik g\u00f6ndermeyi durdurur. E\u011fer hedef grubundaki *t\u00fcm* hedefler sa\u011fl\u0131ks\u0131z hale gelirse veya hedef grubunda hi\u00e7 kay\u0131tl\u0131 hedef yoksa, ALB gelen t\u00fcm isteklere 503 Service Unavailable hatas\u0131 d\u00f6nd\u00fcr\u00fcr. Bu durum, genellikle arka u\u00e7 EC2 \u00f6rneklerinin \u00e7\u00f6kmesi, uygulama sunucular\u0131n\u0131n yan\u0131t vermemesi, veritaban\u0131 ba\u011flant\u0131 sorunlar\u0131 veya kaynak t\u00fckenmesi gibi nedenlerle ortaya \u00e7\u0131kar. \u00d6rne\u011fin, bir web uygulamas\u0131n\u0131n ani bir trafik art\u0131\u015f\u0131 ya\u015famas\u0131 ve t\u00fcm EC2 \u00f6rneklerinin CPU veya bellek limitlerine ula\u015farak donmas\u0131, ALB’nin t\u00fcm hedefleri sa\u011fl\u0131ks\u0131z olarak i\u015faretlemesine ve dolay\u0131s\u0131yla 503 hatas\u0131 vermesine neden olabilir.<\/p>\n\n# AWS CLI komutlar\u0131 ile \u00f6rnek sa\u011fl\u0131k kontrol\u00fc yap\u0131land\u0131rmas\u0131\n# Hedef Grubunu G\u00fcncelleme\naws elbv2 modify-target-group \\\n --target-group-arn arn:aws:elasticloadbalancing:REGION:ACCOUNT_ID:targetgroup\/my-target-group\/ID \\\n --health-check-protocol HTTP \\\n --health-check-port 80 \\\n --health-check-path \/health \\\n --health-check-interval-seconds 30 \\\n --health-check-timeout-seconds 5 \\\n --healthy-threshold-count 3 \\\n --unhealthy-threshold-count 3 \\\n --matcher HttpCode=200\n\n# E\u011fer \/health endpoint'i 30 saniye i\u00e7inde 3 kez 200 d\u00f6nmezse, hedef sa\u011fl\u0131ks\u0131z say\u0131l\u0131r.\n <\/code><\/pre>\n<\/p><\/div>\nIdle timeout<\/code> (Bo\u015fta kalma zaman a\u015f\u0131m\u0131) s\u00fcresidir. Varsay\u0131lan olarak 60 saniye olan bu s\u00fcre, ALB’nin bir ba\u011flant\u0131y\u0131 a\u00e7\u0131k tutma ve arka u\u00e7tan yan\u0131t bekleme s\u00fcresini belirler. E\u011fer arka u\u00e7 hedefi, bu Idle timeout<\/code> s\u00fcresi i\u00e7inde ALB’ye herhangi bir veri (bir yan\u0131t ba\u015fl\u0131\u011f\u0131 veya g\u00f6vdesi) g\u00f6ndermezse, ALB ba\u011flant\u0131y\u0131 kapat\u0131r ve istemciye 504 Gateway Timeout hatas\u0131 d\u00f6nd\u00fcr\u00fcr. Bu durum, genellikle arka u\u00e7 uygulamas\u0131n\u0131n \u00e7ok uzun s\u00fcren bir i\u015flem yapmas\u0131 (\u00f6rne\u011fin, karma\u015f\u0131k bir rapor olu\u015fturma, b\u00fcy\u00fck bir dosya i\u015fleme veya yava\u015f bir harici API’ye ba\u011f\u0131ml\u0131l\u0131k) nedeniyle ortaya \u00e7\u0131kar. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n b\u00fcy\u00fck bir Excel dosyas\u0131n\u0131 y\u00fckleyip i\u015flemesini bekleyen bir web uygulamas\u0131, bu i\u015flemin 60 saniyeyi a\u015fmas\u0131 durumunda ALB’den 504 hatas\u0131 alabilir. Bu zaman a\u015f\u0131m\u0131n\u0131, uygulaman\u0131z\u0131n en uzun s\u00fcren i\u015flemlerini g\u00f6z \u00f6n\u00fcnde bulundurarak ayarlaman\u0131z \u00f6nemlidir. Ancak, \u00e7ok uzun bir zaman a\u015f\u0131m\u0131 belirlemek de, tak\u0131lan isteklerin sunucu kaynaklar\u0131n\u0131 gereksiz yere me\u015fgul etmesine yol a\u00e7abilir.<\/p>\nIdle timeout<\/code> s\u00fcresini a\u015farsa, kullan\u0131c\u0131lar 504 hatas\u0131yla kar\u015f\u0131la\u015f\u0131r. Bu sorunu \u00e7\u00f6zmek i\u00e7in ALB’nin Idle timeout<\/code> s\u00fcresi, en uzun resim i\u015fleme s\u00fcresine uygun olarak art\u0131r\u0131labilir (\u00f6rne\u011fin, 300 saniyeye). Ancak daha iyi bir \u00e7\u00f6z\u00fcm, resim i\u015fleme g\u00f6revini bir mesaj kuyru\u011funa (\u00f6rne\u011fin, SQS) at\u0131p, arka planda asenkron olarak i\u015flemek ve kullan\u0131c\u0131ya hemen bir “resminiz i\u015fleniyor” mesaj\u0131 d\u00f6nmektir. Bu yakla\u015f\u0131m, hem zaman a\u015f\u0131m\u0131 sorunlar\u0131n\u0131 ortadan kald\u0131r\u0131r hem de kullan\u0131c\u0131 deneyimini iyile\u015ftirir.<\/p>\nIdle timeout<\/code> ayarlar\u0131yla ili\u015fkilidir. Bu bile\u015fenleri do\u011fru bir \u015fekilde izlemek ve yap\u0131land\u0131rmak, uygulaman\u0131z\u0131n kesintisiz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flaman\u0131n anahtar\u0131d\u0131r.<\/p>\nCloudflare ve Hata Kodlar\u0131: 503 ve 504’\u00fcn \u00d6tesinde Bir D\u00fcnya<\/h2>\n
\n# Cloudflare, bu t\u00fcr hatalar\u0131 genellikle kendi \u00f6zel hata sayfalar\u0131yla sunar.\n# Cloudflare paneli \u00fczerinden \u00f6zel hata sayfalar\u0131 yap\u0131land\u0131r\u0131labilir,\n# ancak hata tetiklenme mant\u0131\u011f\u0131 arka u\u00e7 yan\u0131t s\u00fcrelerine ba\u011fl\u0131d\u0131r.\n# \u00d6rne\u011fin, bir Cloudflare Worker'da uzun s\u00fcren bir Fetch i\u015flemi 524'e neden olabilir:\n\nasync function handleRequest(request) {\n \/\/ \u00c7ok uzun s\u00fcren bir i\u015flem veya harici API \u00e7a\u011fr\u0131s\u0131\n const response = await fetch('https:\/\/slow-api.example.com\/data', {\n signal: AbortSignal.timeout(90 * 1000) \/\/ 90 saniye zaman a\u015f\u0131m\u0131\n }); \n \/\/ E\u011fer slow-api 90 saniyeden uzun s\u00fcrerse, Worker bu hatay\u0131 yakalar.\n \/\/ Ancak Cloudflare'\u0131n kendi 100 saniyelik zaman a\u015f\u0131m\u0131 (524) devreye girebilir.\n\n return response;\n}\n\naddEventListener('fetch', event => {\n event.respondWith(handleRequest(event.request));\n});\n <\/code><\/pre>\n<\/p><\/div>\nGer\u00e7ek D\u00fcnya Senaryolar\u0131 ve Hata Giderme Stratejileri<\/h2>\n
Senaryo 1: Yo\u011fun Trafik Alt\u0131nda Bir E-ticaret Sitesi<\/h3>\n
\n
Idle timeout<\/code> s\u00fcresi, en yo\u011fun i\u015flem s\u00fcrenizden daha k\u0131sa m\u0131? E\u011fer \u00f6yleyse, 504 hatalar\u0131 buradan kaynaklan\u0131yor olabilir.<\/li>\n\/var\/log\/nginx\/access.log<\/code> ve \/var\/log\/nginx\/error.log<\/code> dosyalar\u0131 size hangi iste\u011fin ne zaman ve hangi hatayla kar\u015f\u0131la\u015ft\u0131\u011f\u0131n\u0131 g\u00f6sterecektir. Nginx’in proxy_read_timeout<\/code> de\u011feri yeterince y\u00fcksek mi? upstream<\/code> blo\u011funuzdaki max_fails<\/code> ve fail_timeout<\/code> ayarlar\u0131 \u00e7ok agresif mi? E\u011fer Nginx 504 veya 503 d\u00f6nd\u00fcr\u00fcyorsa, bu genellikle arka u\u00e7 uygulamas\u0131n\u0131n yava\u015f \u00e7al\u0131\u015ft\u0131\u011f\u0131 veya \u00e7\u00f6kt\u00fc\u011f\u00fc anlam\u0131na gelir.<\/li>\nSenaryo 2: Bak\u0131m \u00c7al\u0131\u015fmas\u0131 Sonras\u0131 Uygulama Ba\u015flatma Sorunlar\u0131<\/h3>\n
\n
pm2 status<\/code> veya bir Java uygulamas\u0131 i\u00e7in ilgili servis durumunu kontrol edin. Uygulama ba\u015flatma s\u0131ras\u0131nda bir hata m\u0131 verdi? Portu do\u011fru dinliyor mu?<\/li>\nProaktif \u00d6nlemler ve \u0130leri D\u00fczey \u0130pu\u00e7lar\u0131<\/h3>\n
\n
proxy_read_timeout<\/code>, ALB’deki Idle timeout<\/code> ve Cloudflare’\u0131n 100 saniyelik zaman a\u015f\u0131m\u0131 gibi de\u011ferleri uygulaman\u0131z\u0131n tipik ve maksimum yan\u0131t s\u00fcrelerine g\u00f6re ayarlay\u0131n. Uzun s\u00fcren i\u015flemler i\u00e7in asenkron yakla\u015f\u0131mlar\u0131 (mesaj kuyruklar\u0131, arka plan g\u00f6revleri) tercih edin.<\/li>\nerror_page<\/code> direktifi) kullanarak kullan\u0131c\u0131lar\u0131n\u0131za daha bilgilendirici ve markan\u0131za uygun mesajlar sunun.<\/li>\nSonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
proxy_read_timeout<\/code> ve upstream<\/code> blo\u011fundaki max_fails<\/code>\/fail_timeout<\/code> direktifleri arac\u0131l\u0131\u011f\u0131yla bu hatalar\u0131 tetikler. ALB ise hedef grubu sa\u011fl\u0131k kontrolleri ve Idle timeout<\/code> ayarlar\u0131yla 503 ve 504 hatalar\u0131n\u0131 \u00fcretir. Cloudflare ise kendi \u00f6zel 5xx hatalar\u0131n\u0131 (521, 522, 524) kullanarak origin sunucusuyla ilgili sorunlar\u0131 belirtir ve bu hatalar temel 503\/504 senaryolar\u0131na kar\u015f\u0131l\u0131k gelir. Bu bile\u015fenlerin her birinin hata y\u00f6netimindeki rol\u00fcn\u00fc anlamak, sorunun kayna\u011f\u0131n\u0131 do\u011fru bir \u015fekilde te\u015fhis etmek ve etkili \u00e7\u00f6z\u00fcmler \u00fcretmek i\u00e7in elzemdir. \u0130zleme ara\u00e7lar\u0131, proaktif \u00f6l\u00e7eklendirme, optimize edilmi\u015f sa\u011fl\u0131k kontrolleri ve do\u011fru zaman a\u015f\u0131m\u0131 ayarlar\u0131, bu hatalar\u0131n olu\u015fmas\u0131n\u0131 \u00f6nlemede veya olu\u015ftu\u011funda h\u0131zl\u0131ca gidermede kritik rol oynar. Unutmay\u0131n, iyi bir hata y\u00f6netimi stratejisi, sadece sorunlar\u0131 \u00e7\u00f6zmekle kalmaz, ayn\u0131 zamanda kullan\u0131c\u0131 g\u00fcvenini ve uygulama s\u00fcreklili\u011fini de sa\u011flar.<\/p>\nS\u0131k\u00e7a Sorulan Sorular<\/h3>\n
proxy_read_timeout<\/code>, proxy_connect_timeout<\/code> ve proxy_send_timeout<\/code> direktiflerini kontrol etmelisiniz. Bu de\u011ferlerin, arka u\u00e7 uygulaman\u0131z\u0131n en uzun s\u00fcren i\u015flemlerine yetecek kadar y\u00fcksek oldu\u011fundan emin olun.<\/p>\n