{"id":564,"date":"2026-09-08T14:29:46","date_gmt":"2026-09-08T14:29:46","guid":{"rendered":"https:\/\/www.vps.tc\/blog\/?p=564"},"modified":"2026-09-08T09:40:08","modified_gmt":"2026-09-08T09:40:08","slug":"too-many-requests-ne-demek-429-hatasi-cozumu","status":"publish","type":"post","link":"https:\/\/www.vps.tc\/blog\/tr\/too-many-requests-ne-demek-429-hatasi-cozumu\/","title":{"rendered":"Too Many Requests Ne Demek? 429 Hatas\u0131 ve \u00c7\u00f6z\u00fcm\u00fc"},"content":{"rendered":"<div class=\"aiw-toc\" style=\"border:1px solid #dbe3ea;border-radius:8px;padding:16px 20px;margin:0 0 28px\"><strong>\u0130\u00e7indekiler<\/strong><\/p>\n<ol style=\"margin:10px 0 0;padding-left:22px\">\n<li><a href=\"#too-many-requests-ne-demek\">Too Many Requests ne demek?<\/a><\/li>\n<li><a href=\"#429-hatasi-neden-olusur\">429 hatas\u0131 neden olu\u015fur?<\/a><\/li>\n<li><a href=\"#429-hatasi-nasil-kontrol-edilir\">429 hatas\u0131 nas\u0131l kontrol edilir?<\/a><\/li>\n<li><a href=\"#429-hatasi-alan-kullanici-ne-yapmali\">429 hatas\u0131 alan kullan\u0131c\u0131 ne yapmal\u0131?<\/a><\/li>\n<li><a href=\"#sunucu-yoneticisi-429-sorununu-nasil-cozer\">Sunucu y\u00f6neticisi 429 sorununu nas\u0131l \u00e7\u00f6zer?<\/a><\/li>\n<li><a href=\"#rate-limit-degerleri-nasil-belirlenir\">Rate limit de\u011ferleri nas\u0131l belirlenir?<\/a><\/li>\n<li><a href=\"#429-hatasi-ddos-anlamina-mi-gelir\">429 hatas\u0131 DDoS anlam\u0131na m\u0131 gelir?<\/a><\/li>\n<li><a href=\"#istemci-tarafinda-sik-yapilan-hatalar\">\u0130stemci taraf\u0131nda s\u0131k yap\u0131lan hatalar<\/a><\/li>\n<li><a href=\"#sik-sorulan-sorular\">S\u0131k Sorulan Sorular<\/a><\/li>\n<li><a href=\"#kaynaklar\">Kaynaklar<\/a><\/li>\n<\/ol>\n<\/div>\n<h2 id=\"too-many-requests-ne-demek\">Too Many Requests ne demek?<\/h2>\n<p>Gece vardiyas\u0131nda bir API&#8217;nin neden yava\u015flad\u0131\u011f\u0131n\u0131 ara\u015ft\u0131r\u0131rken ilk g\u00f6rd\u00fc\u011f\u00fcm \u015fey 429 de\u011fildi; 429&#8217;a d\u00f6n\u00fc\u015fen 200 yan\u0131tlar\u0131yd\u0131. \u0130stemci, hata ald\u0131\u011f\u0131 her denemeden sonra daha h\u0131zl\u0131 tekrar ba\u011flan\u0131yordu. Rate limit devreye girince uygulama kendisini korumaya \u00e7al\u0131\u015fm\u0131\u015f, istemci de fark\u0131nda olmadan y\u00fck\u00fc art\u0131rm\u0131\u015ft\u0131.<\/p>\n<p><code>Too Many Requests<\/code>, bir istemcinin k\u0131sa s\u00fcre i\u00e7inde izin verilenden fazla istek g\u00f6nderdi\u011fini anlat\u0131r. HTTP 429 durum kodu, sunucunun iste\u011fi anlad\u0131\u011f\u0131n\u0131 fakat ge\u00e7ici olarak i\u015fleyemedi\u011fini belirtir. Kaynak taray\u0131c\u0131, API istemcisi, cron g\u00f6revi veya ortak kullan\u0131lan bir IP adresinin kotay\u0131 doldurmas\u0131 olabilir.<\/p>\n<p>Taray\u0131c\u0131da ya da API yan\u0131t\u0131nda <code>429 Too Many Requests<\/code> g\u00f6rd\u00fc\u011f\u00fcn\u00fczde ilk i\u015finiz sayfay\u0131 art arda yenilemek olmas\u0131n. Bu davran\u0131\u015f, ger\u00e7ekten bir istek s\u0131n\u0131r\u0131na tak\u0131ld\u0131ysan\u0131z bekleme s\u00fcresini uzatabilir. \u00d6nce yan\u0131t ba\u015fl\u0131klar\u0131n\u0131, uygulama loglar\u0131n\u0131 ve iste\u011fi \u00fcreten kayna\u011f\u0131 kontrol edin.<\/p>\n<h2 id=\"429-hatasi-neden-olusur\">429 hatas\u0131 neden olu\u015fur?<\/h2>\n<p>HTTP durum kodlar\u0131n\u0131 tan\u0131mlayan standartlarda 429, istemcinin belirli bir s\u00fcre i\u00e7inde \u00e7ok fazla istek g\u00f6nderdi\u011fini ifade eder. IETF&#8217;nin RFC 6585 belgesinde belirtildi\u011fi gibi sunucu, istemcinin tekrar ne zaman deneyebilece\u011fini <code>Retry-After<\/code> ba\u015fl\u0131\u011f\u0131yla bildirebilir. Bu ba\u015fl\u0131k saniye cinsinden bir de\u011fer veya HTTP tarih format\u0131 ta\u015f\u0131yabilir; her sunucunun bu ba\u015fl\u0131\u011f\u0131 eklemesi zorunlu de\u011fildir.<\/p>\n<p>Limitin neye g\u00f6re hesapland\u0131\u011f\u0131 sa\u011flay\u0131c\u0131ya ve uygulamaya g\u00f6re de\u011fi\u015fir. S\u0131k kar\u015f\u0131la\u015f\u0131lan \u00f6l\u00e7\u00fctler \u015funlard\u0131r:<\/p>\n<ul>\n<li>Tek bir IP adresinden gelen istek say\u0131s\u0131<\/li>\n<li>Kullan\u0131c\u0131 hesab\u0131, API anahtar\u0131 veya oturum ba\u015f\u0131na istek say\u0131s\u0131<\/li>\n<li>Belirli bir endpoint i\u00e7in saniye, dakika ya da saatlik kota<\/li>\n<li>Sunucunun e\u015fzamanl\u0131 ba\u011flant\u0131 veya \u00e7al\u0131\u015fan i\u015flem s\u0131n\u0131r\u0131<\/li>\n<li>Payla\u015f\u0131ml\u0131 hosting ya da NAT arkas\u0131ndaki kullan\u0131c\u0131lar\u0131n ortak kotas\u0131<\/li>\n<li>\u015e\u00fcpheli trafik alg\u0131layan WAF, CDN veya reverse proxy kurallar\u0131<\/li>\n<\/ul>\n<p>Bu y\u00fczden ayn\u0131 sayfa bir ba\u011flant\u0131da a\u00e7\u0131l\u0131rken ba\u015fka bir ba\u011flant\u0131da 429 verebilir. \u015eirket a\u011f\u0131, mobil operat\u00f6r veya ortak Wi-Fi arkas\u0131nda \u00e7ok say\u0131da kullan\u0131c\u0131 ayn\u0131 d\u0131\u015f IP&#8217;yi payla\u015fabilir. Sunucu kullan\u0131c\u0131lar\u0131 ayr\u0131 ayr\u0131 tan\u0131m\u0131yorsa b\u00fct\u00fcn bu trafik tek istemci gibi g\u00f6r\u00fcn\u00fcr.<\/p>\n<h3>429 ile 403 ve 503 aras\u0131ndaki fark nedir?<\/h3>\n<p>Bu kodlar bazen ayn\u0131 hata sayfas\u0131nda g\u00f6sterildi\u011fi i\u00e7in kar\u0131\u015ft\u0131r\u0131l\u0131yor. 429, do\u011frudan istek h\u0131z\u0131n\u0131n veya kotan\u0131n a\u015f\u0131ld\u0131\u011f\u0131 duruma i\u015faret eder. 403, sunucunun iste\u011fi anlad\u0131\u011f\u0131 fakat eri\u015fime izin vermedi\u011fi anlam\u0131na gelir. 503 ise hizmetin ge\u00e7ici olarak haz\u0131r olmad\u0131\u011f\u0131n\u0131 ifade eder; yo\u011funluk sebep olabilir ama her 503 yan\u0131t\u0131 rate limit anlam\u0131na gelmez.<\/p>\n<table>\n<thead>\n<tr>\n<th>Durum kodu<\/th>\n<th>Tipik anlam<\/th>\n<th>\u0130lk kontrol<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>429<\/td>\n<td>\u00c7ok fazla istek veya kota a\u015f\u0131m\u0131<\/td>\n<td>Rate limit, <code>Retry-After<\/code>, istemci s\u0131kl\u0131\u011f\u0131<\/td>\n<\/tr>\n<tr>\n<td>403<\/td>\n<td>\u0130zin yok veya g\u00fcvenlik kural\u0131 engelliyor<\/td>\n<td>Kimlik do\u011frulama, IP\/WAF kural\u0131<\/td>\n<\/tr>\n<tr>\n<td>503<\/td>\n<td>Hizmet ge\u00e7ici olarak haz\u0131r de\u011fil<\/td>\n<td>Uygulama, upstream ve kaynak kullan\u0131m\u0131<\/td>\n<\/tr>\n<tr>\n<td>502<\/td>\n<td>Proxy&#8217;nin upstream&#8217;den ge\u00e7erli yan\u0131t alamamas\u0131<\/td>\n<td>Backend durumu ve reverse proxy loglar\u0131<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>429 yerine 502 g\u00f6r\u00fcyorsan\u0131z konu farkl\u0131 olabilir. Bu ayr\u0131m i\u00e7in <strong><a href=\"https:\/\/www.vps.tc\/blog\/tr\/502-bad-gateway-hatasi-nedir-nasil-cozulur\/\">502 Bad Gateway Hatas\u0131 Nedir ve Nas\u0131l \u00c7\u00f6z\u00fcl\u00fcr?<\/a><\/strong> ba\u015fl\u0131kl\u0131 yaz\u0131daki upstream kontrolleri daha uygun olur. HTTP kodunu yaln\u0131zca hata sayfas\u0131n\u0131n ba\u015fl\u0131\u011f\u0131ndan de\u011fil, ger\u00e7ek yan\u0131t ba\u015fl\u0131\u011f\u0131ndan do\u011frulay\u0131n.<\/p>\n<h2 id=\"429-hatasi-nasil-kontrol-edilir\">429 hatas\u0131 nas\u0131l kontrol edilir?<\/h2>\n<p>Taray\u0131c\u0131 ekran\u0131 s\u0131n\u0131rl\u0131 bilgi verir. Ben sunucu veya API taraf\u0131nda \u00f6nce <code>curl<\/code> ile yan\u0131t ba\u015fl\u0131klar\u0131n\u0131 al\u0131r\u0131m. <code>-I<\/code> se\u00e7ene\u011fi yaln\u0131zca HEAD iste\u011fi g\u00f6nderir; baz\u0131 uygulamalar HEAD&#8217;i GET gibi ele almad\u0131\u011f\u0131 i\u00e7in gerekti\u011finde <code>-sS -D - -o \/dev\/null<\/code> bi\u00e7imini kullanmak daha g\u00fcvenlidir.<\/p>\n<pre><code>curl -sS -D - -o \/dev\/null https:\/\/example.com\/api\/items<\/code><\/pre>\n<p>\u00c7\u0131kt\u0131da \u00f6zellikle \u015fu alanlar\u0131 aray\u0131n:<\/p>\n<pre><code>HTTP\/2 429\nretry-after: 30\ncontent-type: application\/json\nx-ratelimit-limit: 60\nx-ratelimit-remaining: 0\nx-ratelimit-reset: 1710000030<\/code><\/pre>\n<p>Buradaki <code>retry-after: 30<\/code>, sunucunun yakla\u015f\u0131k 30 saniye beklenmesini istedi\u011fini g\u00f6sterir. <code>x-ratelimit-*<\/code> ba\u015fl\u0131klar\u0131 standart HTTP ba\u015fl\u0131klar\u0131 de\u011fildir; uygulama veya sa\u011flay\u0131c\u0131 taraf\u0131ndan eklenir. Bu alanlar\u0131 g\u00f6rmemeniz rate limit olmad\u0131\u011f\u0131 anlam\u0131na gelmez.<\/p>\n<p>\u0130stemcinin ger\u00e7ekte ne s\u0131kl\u0131kta istek g\u00f6nderdi\u011fini de \u00f6l\u00e7\u00fcn. \u00dcretim API&#8217;sine kontrols\u00fcz bir d\u00f6ng\u00fc \u00e7al\u0131\u015ft\u0131rmak yerine d\u00fc\u015f\u00fck say\u0131da istekle ve a\u00e7\u0131k bir beklemeyle ilerleyin:<\/p>\n<pre><code>for i in 1 2 3 4 5; do\n  date -Is\n  curl -sS -o \/dev\/null -w 'HTTP %{http_code}n' https:\/\/example.com\/api\/items\n  sleep 2\ndone<\/code><\/pre>\n<p>Bu komut te\u015fhis i\u00e7indir; limitleri a\u015fmak i\u00e7in kullan\u0131lmamal\u0131. Yan\u0131t kodlar\u0131 ve zaman damgalar\u0131, sorunun belirli bir istek yo\u011funlu\u011fuyla ba\u015flay\u0131p ba\u015flamad\u0131\u011f\u0131n\u0131 g\u00f6sterir. Ben bir m\u00fc\u015fteri API&#8217;sinde 429 sat\u0131rlar\u0131n\u0131 g\u00f6r\u00fcnce \u00f6nce sunucuyu su\u00e7lam\u0131\u015ft\u0131m. Ayn\u0131 dakikadaki User-Agent ve istek yollar\u0131n\u0131 kar\u015f\u0131la\u015ft\u0131r\u0131nca iki ayr\u0131 worker&#8217;\u0131n ayn\u0131 endpoint&#8217;i paralel bi\u00e7imde tarad\u0131\u011f\u0131n\u0131 g\u00f6rd\u00fcm. Sorun rate limit kural\u0131nda de\u011fil, istemcinin \u00e7al\u0131\u015fma modelindeydi.<\/p>\n<h3>Sunucu loglar\u0131nda hangi alanlara bak\u0131l\u0131r?<\/h3>\n<p>Web sunucusu, proxy ve uygulama farkl\u0131 \u015feyler kaydedebilir. Nginx eri\u015fim loglar\u0131nda durum kodu, istek yolu, istemci IP&#8217;si ve User-Agent birlikte incelenmelidir. Kulland\u0131\u011f\u0131n\u0131z log format\u0131 de\u011fi\u015febilir; a\u015fa\u011f\u0131daki komut tipik bir eri\u015fim logu i\u00e7in \u00f6rnektir.<\/p>\n<pre><code>grep ' 429 ' \/var\/log\/nginx\/access.log | tail -n 20<\/code><\/pre>\n<p>Belirli bir IP&#8217;nin tekrar\u0131n\u0131 g\u00f6rmek i\u00e7in:<\/p>\n<pre><code>awk '$9 == 429 {print $1}' \/var\/log\/nginx\/access.log | sort | uniq -c | sort -nr | head<\/code><\/pre>\n<p>Bu sat\u0131rdaki <code>$9<\/code> alan\u0131, standart combined log format\u0131nda HTTP durum kodudur. Kendi <code>log_format<\/code> tan\u0131m\u0131n\u0131z farkl\u0131ysa s\u00fctun numaras\u0131 de\u011fi\u015fir; bir log sat\u0131r\u0131n\u0131 a\u00e7\u0131p alanlar\u0131 saymadan komutu k\u00f6rlemesine kopyalamay\u0131n. Log okumadan servisi yeniden ba\u015flatmak, rate limit kural\u0131n\u0131 da uygulama davran\u0131\u015f\u0131n\u0131 da de\u011fi\u015ftirmez.<\/p>\n<h2 id=\"429-hatasi-alan-kullanici-ne-yapmali\">429 hatas\u0131 alan kullan\u0131c\u0131 ne yapmal\u0131?<\/h2>\n<p>Bir ziyaret\u00e7i veya API t\u00fcketicisi olarak yap\u0131lacaklar basit g\u00f6r\u00fcn\u00fcr, fakat s\u0131ran\u0131n \u00f6nemi var. \u00d6nce yan\u0131t\u0131n ge\u00e7ici mi, s\u00fcrekli mi oldu\u011funu ay\u0131r\u0131n.<\/p>\n<ol>\n<li><strong>Bekleyin:<\/strong> Yan\u0131tta <code>Retry-After<\/code> varsa belirtilen s\u00fcre dolmadan tekrar denemeyin.<\/li>\n<li><strong>\u0130stek say\u0131s\u0131n\u0131 azalt\u0131n:<\/strong> Sayfay\u0131 s\u00fcrekli yenilemeyin, paralel API \u00e7a\u011fr\u0131lar\u0131n\u0131 d\u00fc\u015f\u00fcr\u00fcn.<\/li>\n<li><strong>\u0130stemciyi kontrol edin:<\/strong> Taray\u0131c\u0131 eklentileri, mobil uygulamalar, script&#8217;ler ve arka planda \u00e7al\u0131\u015fan senkronizasyon g\u00f6revleri istek \u00fcretebilir.<\/li>\n<li><strong>Kimlik bilgisini do\u011frulay\u0131n:<\/strong> Ba\u015far\u0131s\u0131z kimlik do\u011frulama denemeleri baz\u0131 sistemlerde rate limit sayac\u0131n\u0131 art\u0131rabilir.<\/li>\n<li><strong>Yan\u0131t ba\u015fl\u0131klar\u0131n\u0131 kaydedin:<\/strong> Destek talebine URL, zaman, durum kodu ve varsa istek kimli\u011fini ekleyin.<\/li>\n<li><strong>VPN&#8217;i hemen \u00e7\u00f6z\u00fcm sanmay\u0131n:<\/strong> Yeni IP adresi de limitli olabilir; sa\u011flay\u0131c\u0131n\u0131n g\u00fcvenlik kurallar\u0131na da tak\u0131labilirsiniz.<\/li>\n<\/ol>\n<p>API kullanan bir uygulamada yeniden deneme davran\u0131\u015f\u0131 \u00f6zellikle \u00f6nemlidir. Sabit aral\u0131klarla tekrar tekrar denemek yerine exponential backoff kullan\u0131l\u0131r. \u0130lk bekleme k\u0131sa tutulur, sonraki denemelerde s\u00fcre art\u0131r\u0131l\u0131r ve ayn\u0131 anda \u00e7al\u0131\u015fan isteklerin hepsi birlikte tekrar g\u00f6nderilmez.<\/p>\n<pre><code>import random\nimport time\n\nimport requests\n\nurl = \"https:\/\/example.com\/api\/items\"\ndelay = 1\n\nfor attempt in range(5):\n    response = requests.get(url, timeout=10)\n\n    if response.status_code != 429:\n        response.raise_for_status()\n        data = response.json()\n        break\n\n    retry_after = response.headers.get(\"Retry-After\")\n    wait = int(retry_after) if retry_after and retry_after.isdigit() else delay\n    time.sleep(wait + random.uniform(0, 0.5))\n    delay = min(delay * 2, 60)<\/code><\/pre>\n<p>Bu \u00f6rnekte <code>Retry-After<\/code> say\u0131sal oldu\u011funda ona uyulur, ba\u015fl\u0131k yoksa bekleme katlanarak art\u0131r\u0131l\u0131r. Ger\u00e7ek uygulamada HTTP tarih bi\u00e7imini, g\u00fcvenli \u00fcst s\u0131n\u0131r\u0131 ve idempotent olmayan istekleri ayr\u0131ca ele al\u0131n. Bir \u00f6deme iste\u011fini yan\u0131t al\u0131namad\u0131 diye otomatik tekrar g\u00f6ndermek \u00e7ift i\u015flem \u00fcretebilir; yeniden deneme politikas\u0131 endpoint&#8217;in davran\u0131\u015f\u0131na g\u00f6re yaz\u0131lmal\u0131d\u0131r.<\/p>\n<h2 id=\"sunucu-yoneticisi-429-sorununu-nasil-cozer\">Sunucu y\u00f6neticisi 429 sorununu nas\u0131l \u00e7\u00f6zer?<\/h2>\n<p>Y\u00f6netici taraf\u0131ndaki ama\u00e7 limiti kald\u0131rmak de\u011fil, me\u015fru trafi\u011fi korurken kontrols\u00fcz istemciyi s\u0131n\u0131rlamakt\u0131r. \u00d6nce 429&#8217;u hangi katman\u0131n \u00fcretti\u011fini bulun: CDN, WAF, Nginx, uygulama framework&#8217;\u00fc, API gateway veya do\u011frudan upstream servis.<\/p>\n<h3>Nginx ile istek h\u0131z\u0131n\u0131 s\u0131n\u0131rlama<\/h3>\n<p>Nginx dok\u00fcmantasyonundaki <code>limit_req_zone<\/code> ve <code>limit_req<\/code> direktifleri, payla\u015f\u0131ml\u0131 bir bellek alan\u0131 ve istek oran\u0131 tan\u0131mlamak i\u00e7in kullan\u0131l\u0131r. Genel bir API alan\u0131 i\u00e7in basit bir \u00f6rnek:<\/p>\n<pre><code>http {\n    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r\/s;\n\n    server {\n        location \/api\/ {\n            limit_req zone=api_limit burst=20 nodelay;\n            proxy_pass http:\/\/backend;\n        }\n    }\n}<\/code><\/pre>\n<p><code>$binary_remote_addr<\/code> IP adresini daha az bellekle anahtar olarak tutar. <code>rate=10r\/s<\/code> ortalama h\u0131z\u0131 belirler; <code>burst=20<\/code> k\u0131sa s\u00fcreli birikmi\u015f isteklere alan a\u00e7ar. <code>nodelay<\/code> kullan\u0131ld\u0131\u011f\u0131nda burst i\u00e7indeki istekler bekletilmek yerine hemen i\u015flenir. Burst alan\u0131 da a\u015f\u0131ld\u0131\u011f\u0131nda Nginx 429 d\u00f6nd\u00fcrebilir. Bu de\u011ferleri kopyalay\u0131p b\u00fct\u00fcn siteye uygulamak do\u011fru de\u011fildir.<\/p>\n<p>Giri\u015f endpoint&#8217;i, arama endpoint&#8217;i ve statik dosyalar ayn\u0131 davran\u0131\u015fa sahip de\u011fildir. Giri\u015fte d\u00fc\u015f\u00fck bir h\u0131z ve ayr\u0131 bir limit gerekebilir. Statik dosyalar\u0131 ayn\u0131 rate limit alan\u0131na koyarsan\u0131z tek bir sayfa y\u00fcklemesi bile gereksiz saya\u00e7 t\u00fcketebilir.<\/p>\n<p>De\u011fi\u015fiklikten sonra Nginx yap\u0131land\u0131rmas\u0131n\u0131 test edin:<\/p>\n<pre><code>sudo nginx -t\nsudo systemctl reload nginx<\/code><\/pre>\n<p><code>reload<\/code>, \u00e7al\u0131\u015fan ba\u011flant\u0131lar\u0131 \u00e7o\u011fu durumda kesmeden yeni yap\u0131land\u0131rmay\u0131 y\u00fckler. Test ba\u015far\u0131s\u0131zsa reload ger\u00e7ekle\u015fmez; bu y\u00fczden \u00f6nce <code>nginx -t<\/code> \u00e7al\u0131\u015ft\u0131rmak k\u00fc\u00e7\u00fck ama de\u011ferli bir al\u0131\u015fkanl\u0131k. Production prompt&#8217;lar\u0131m\u0131n k\u0131rm\u0131z\u0131 olmas\u0131n\u0131n bir sebebi de bu t\u00fcr de\u011fi\u015fikliklerde yanl\u0131\u015f makineye dokunma korkusudur.<\/p>\n<h3>Uygulama taraf\u0131nda limit ve kuyruk tasar\u0131m\u0131<\/h3>\n<p>Rate limit&#8217;i yaln\u0131zca web sunucusuna b\u0131rakmak her zaman yeterli olmaz. API anahtar\u0131, kullan\u0131c\u0131 hesab\u0131 ve endpoint baz\u0131nda saya\u00e7 tutmak i\u00e7in uygulama katman\u0131nda Redis gibi payla\u015f\u0131ml\u0131 bir depolama kullan\u0131labilir. Birden fazla uygulama sunucusu varsa her makinenin belle\u011finde ayr\u0131 saya\u00e7 tutmak tutars\u0131z sonu\u00e7 verir; kullan\u0131c\u0131 bir sunucuda limite tak\u0131l\u0131rken di\u011ferinde tak\u0131lmayabilir.<\/p>\n<p>Uzun s\u00fcren i\u015fleri HTTP iste\u011finin i\u00e7inde tamamlamaya \u00e7al\u0131\u015fmak da 429 ve timeout problemlerini art\u0131r\u0131r. Dosya i\u015fleme, rapor \u00fcretme veya toplu veri aktarma gibi i\u015fleri kuyru\u011fa al\u0131p istemciye bir i\u015f kimli\u011fi d\u00f6nd\u00fcrmek daha kontroll\u00fcd\u00fcr. \u0130stemci i\u015fi sorgulayacaksa bu sorgunun da makul aral\u0131klarla yap\u0131lmas\u0131 gerekir. Yoksa kuyruk \u00e7\u00f6z\u00fcl\u00fcrken status endpoint&#8217;i yeni darbo\u011faz olur.<\/p>\n<h3>IP bazl\u0131 limitin sak\u0131ncalar\u0131<\/h3>\n<p>IP adresi pratik bir anahtard\u0131r ama kullan\u0131c\u0131 kimli\u011fi de\u011fildir. IPv4 NAT, kurumsal a\u011flar, mobil operat\u00f6rler ve IPv6 ge\u00e7i\u015fleri ayn\u0131 hesab\u0131n farkl\u0131 g\u00f6r\u00fcnmesine veya farkl\u0131 kullan\u0131c\u0131lar\u0131n tek IP gibi alg\u0131lanmas\u0131na yol a\u00e7abilir. G\u00fcvenilir bir kimlik do\u011frulama katman\u0131n\u0131z varsa kullan\u0131c\u0131 veya API anahtar\u0131 bazl\u0131 limiti, IP bazl\u0131 korumayla birlikte de\u011ferlendirin.<\/p>\n<p>Proxy arkas\u0131ndaki ger\u00e7ek istemci IP&#8217;sini almak i\u00e7in <code>X-Forwarded-For<\/code> ba\u015fl\u0131\u011f\u0131na k\u00f6r\u00fc k\u00f6r\u00fcne g\u00fcvenmeyin. Bu ba\u015fl\u0131k yaln\u0131zca g\u00fcvendi\u011finiz proxy taraf\u0131ndan set ediliyorsa kullan\u0131lmal\u0131; aksi halde istemci kendi sahte IP&#8217;sini g\u00f6nderip limiti a\u015fabilir. Proxy katmanlar\u0131n\u0131 ay\u0131rmak i\u00e7in <strong><a href=\"https:\/\/www.vps.tc\/blog\/tr\/proxy-nedir-proxy-sunucu-ne-ise-yarar\/\">Proxy Nedir? Proxy Sunucu Ne \u0130\u015fe Yarar?<\/a><\/strong> yaz\u0131s\u0131na bakabilirsiniz.<\/p>\n<h2 id=\"rate-limit-degerleri-nasil-belirlenir\">Rate limit de\u011ferleri nas\u0131l belirlenir?<\/h2>\n<p>Tek bir do\u011fru say\u0131 yoktur. Limit; endpoint&#8217;in i\u015f maliyeti, beklenen trafik, istemci davran\u0131\u015f\u0131 ve backend kapasitesi \u00f6l\u00e7\u00fclerek belirlenir. Ana sayfa i\u00e7in kabul edilebilir bir istek oran\u0131, pahal\u0131 bir arama sorgusu veya giri\u015f denemesi i\u00e7in uygun olmayabilir.<\/p>\n<p>Ba\u015flang\u0131\u00e7ta \u015fu verileri toplay\u0131n:<\/p>\n<ul>\n<li>Endpoint ba\u015f\u0131na dakika ve saniye baz\u0131nda istek say\u0131s\u0131<\/li>\n<li>Yan\u0131t s\u00fcreleri ve hata oranlar\u0131<\/li>\n<li>CPU, bellek, disk I\/O ve veritaban\u0131 ba\u011flant\u0131 say\u0131s\u0131<\/li>\n<li>\u0130steklerin kullan\u0131c\u0131, API anahtar\u0131 ve IP da\u011f\u0131l\u0131m\u0131<\/li>\n<li>Yo\u011fun saatlerdeki normal trafik ile ani s\u0131\u00e7ramalar<\/li>\n<\/ul>\n<p>Limitin istemciye a\u00e7\u0131k\u00e7a bildirilmesi de gerekir. Belgede kota birimi, pencere s\u00fcresi, 429 davran\u0131\u015f\u0131 ve <code>Retry-After<\/code> kullan\u0131m\u0131 yazs\u0131n. Yan\u0131t g\u00f6vdesi JSON ise makine taraf\u0131ndan okunabilir bir hata kodu sa\u011flay\u0131n:<\/p>\n<pre><code>{\n  \"error\": \"rate_limited\",\n  \"message\": \"Too many requests\",\n  \"retry_after\": 30\n}<\/code><\/pre>\n<p>\u0130stemci bu alan\u0131 okuyup kontroll\u00fc bi\u00e7imde bekleyebilir. Ger\u00e7ek tarih ve saniye bilgisinin hangi ba\u015fl\u0131kta ta\u015f\u0131nd\u0131\u011f\u0131n\u0131 dok\u00fcmante edin; farkl\u0131 servislerde ayn\u0131 isimlerin farkl\u0131 anlamlara gelmesi entegrasyonu zorla\u015ft\u0131r\u0131r.<\/p>\n<h2 id=\"429-hatasi-ddos-anlamina-mi-gelir\">429 hatas\u0131 DDoS anlam\u0131na m\u0131 gelir?<\/h2>\n<p>Hay\u0131r. 429, normal bir istemcinin a\u015f\u0131r\u0131 h\u0131zl\u0131 \u00e7al\u0131\u015fmas\u0131ndan da do\u011fabilir; tek ba\u015f\u0131na sald\u0131r\u0131 kan\u0131t\u0131 de\u011fildir. Bir DDoS olay\u0131nda \u00e7ok say\u0131da kaynak, farkl\u0131 URL&#8217;ler veya ba\u011flant\u0131 t\u00fcketimi g\u00f6r\u00fclebilir. 429 ise \u00e7o\u011funlukla bir katman\u0131n belirledi\u011fi istek politikas\u0131n\u0131n devreye girdi\u011fini s\u00f6yler.<\/p>\n<p>Yine de 429 kay\u0131tlar\u0131 trafik incelemesi i\u00e7in yararl\u0131d\u0131r. Ayn\u0131 zaman aral\u0131\u011f\u0131nda CPU, ba\u011flant\u0131 say\u0131s\u0131, upstream bekleme s\u00fcresi ve a\u011f trafi\u011fini kar\u015f\u0131la\u015ft\u0131r\u0131n. \u00c7ok say\u0131da farkl\u0131 IP ayn\u0131 endpoint&#8217;i ola\u011fand\u0131\u015f\u0131 h\u0131zda \u00e7a\u011f\u0131r\u0131yorsa CDN veya upstream filtreleme, bot do\u011frulama ve endpoint tasar\u0131m\u0131 birlikte de\u011ferlendirilmelidir. Sunucuyu refleks olarak yeniden ba\u015flatmak saya\u00e7lar\u0131 s\u0131f\u0131rlasa bile kayna\u011f\u0131 ortadan kald\u0131rmaz.<\/p>\n<p>Rate limiting, DDoS korumas\u0131n\u0131n tamam\u0131 de\u011fildir. B\u00fcy\u00fck hacimli sald\u0131r\u0131larda trafik sunucuya ula\u015fmadan \u00f6nce filtrelenmelidir; k\u00fc\u00e7\u00fck ve uygulama katman\u0131ndaki k\u00f6t\u00fcye kullan\u0131mlarda ise endpoint bazl\u0131 limit, kimlik do\u011frulama ve kuyruklama i\u015fe yarayabilir.<\/p>\n<h2 id=\"istemci-tarafinda-sik-yapilan-hatalar\">\u0130stemci taraf\u0131nda s\u0131k yap\u0131lan hatalar<\/h2>\n<ul>\n<li><strong>Her hatada an\u0131nda tekrar denemek:<\/strong> <code>Retry-After<\/code> de\u011ferini yok saymak y\u00fck\u00fc art\u0131r\u0131r.<\/li>\n<li><strong>Paralel istek say\u0131s\u0131n\u0131 s\u0131n\u0131rs\u0131z b\u0131rakmak:<\/strong> Promise veya worker havuzu kontrol edilmezse k\u0131sa s\u00fcrede kota t\u00fckenir.<\/li>\n<li><strong>Cache kullanmamak:<\/strong> De\u011fi\u015fmeyen veriyi her sayfa a\u00e7\u0131l\u0131\u015f\u0131nda yeniden istemek gereksizdir.<\/li>\n<li><strong>Sayfalama yerine b\u00fct\u00fcn veriyi \u00e7ekmek:<\/strong> B\u00fcy\u00fck kataloglar i\u00e7in pagination veya delta senkronizasyonu tercih edilmelidir.<\/li>\n<li><strong>Ba\u015far\u0131s\u0131z istekleri loglamamak:<\/strong> \u0130stemci taraf\u0131nda zaman damgas\u0131 ve yan\u0131t kodu yoksa kayna\u011f\u0131 bulmak zorla\u015f\u0131r.<\/li>\n<li><strong>H\u0131z limiti kald\u0131r\u0131l\u0131nca sorunun bitti\u011fini sanmak:<\/strong> Backend kapasitesi de\u011fi\u015fmediyse 429&#8217;un yerini 5xx hatalar\u0131 alabilir.<\/li>\n<\/ul>\n<p>\u00d6zellikle JavaScript taraf\u0131nda g\u00f6r\u00fcnmez polling d\u00f6ng\u00fclerini kontrol edin. Sekme arka plana ge\u00e7ti\u011finde de \u00e7al\u0131\u015fan timer&#8217;lar, iki kez ba\u015flat\u0131lm\u0131\u015f WebSocket yeniden ba\u011flanma kodlar\u0131 ve ba\u015far\u0131s\u0131z isteklerde s\u0131n\u0131rs\u0131z retry s\u0131k rastlad\u0131\u011f\u0131m nedenler aras\u0131nda.<\/p>\n<h2 id=\"sik-sorulan-sorular\">S\u0131k Sorulan Sorular<\/h2>\n<h3>Too Many Requests hatas\u0131 ne kadar s\u00fcrer?<\/h3>\n<p>Sabit bir s\u00fcre yoktur. Sunucu <code>Retry-After<\/code> ba\u015fl\u0131\u011f\u0131 veriyorsa belirtilen s\u00fcreyi esas al\u0131n; ba\u015fl\u0131k yoksa sa\u011flay\u0131c\u0131n\u0131n kota penceresini ve dok\u00fcmantasyonunu kontrol edin.<\/p>\n<h3>429 hatas\u0131n\u0131 sayfay\u0131 yenileyerek d\u00fczeltebilir miyim?<\/h3>\n<p>Genellikle hay\u0131r. Her yenileme yeni bir istek g\u00f6nderdi\u011fi i\u00e7in limit s\u00fcresini uzatabilir. Bir s\u00fcre bekleyin, arka plandaki otomasyonlar\u0131 durdurun ve farkl\u0131 bir a\u011fa ge\u00e7meden \u00f6nce sa\u011flay\u0131c\u0131daki kota durumunu do\u011frulay\u0131n.<\/p>\n<h3>API i\u00e7in 429 ald\u0131\u011f\u0131mda ne yapmal\u0131y\u0131m?<\/h3>\n<p><code>Retry-After<\/code> ve sa\u011flay\u0131c\u0131n\u0131n rate limit ba\u015fl\u0131klar\u0131n\u0131 okuyun. Exponential backoff, jitter, kontroll\u00fc paralellik ve endpoint&#8217;e uygun cache kullan\u0131n; idempotent olmayan istekleri otomatik tekrar g\u00f6ndermeyin.<\/p>\n<h3>Nginx 429 hatas\u0131n\u0131 nas\u0131l kapatabilirim?<\/h3>\n<p>\u00d6nce hangi <code>limit_req<\/code> kural\u0131n\u0131n yan\u0131t\u0131 \u00fcretti\u011fini ve neden devreye girdi\u011fini bulun. Limiti tamamen kald\u0131rmak yerine do\u011fru endpoint, istemci anahtar\u0131 ve burst de\u011ferini belirlemek daha g\u00fcvenlidir; de\u011fi\u015fiklikten \u00f6nce <code>nginx -t<\/code> ile yap\u0131land\u0131rmay\u0131 do\u011frulay\u0131n.<\/p>\n<p>Ben 429 g\u00f6rd\u00fc\u011f\u00fcmde art\u0131k ilk olarak bekleme s\u00fcresine de\u011fil, iste\u011fi kimin ve hangi s\u0131kl\u0131kta \u00fcretti\u011fine bak\u0131yorum. \u00c7\u00fcnk\u00fc do\u011fru limit \u00e7o\u011fu zaman sunucuda de\u011fil, istemcinin kontrols\u00fcz d\u00f6ng\u00fcs\u00fcnde sakl\u0131d\u0131r.<\/p>\n<h2 id=\"kaynaklar\">Kaynaklar<\/h2>\n<ul class=\"aiw-sources\">\n<li><a href=\"https:\/\/www.rfc-editor.org\/rfc\/rfc6585\" target=\"_blank\" rel=\"noopener nofollow\">IETF RFC 6585 &#8211; Additional HTTP Status Codes<\/a> \u2014 rfc-editor.org<\/li>\n<li><a href=\"https:\/\/nginx.org\/en\/docs\/http\/ngx_http_limit_req_module.html\" target=\"_blank\" rel=\"noopener nofollow\">NGINX &#8211; Request Rate Limiting<\/a> \u2014 nginx.org<\/li>\n<li><a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/HTTP\/Reference\/Status\/429\" target=\"_blank\" rel=\"noopener nofollow\">MDN &#8211; 429 Too Many Requests<\/a> \u2014 developer.mozilla.org<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>Too Many Requests ne demek? HTTP 429 hatas\u0131n\u0131n neden olu\u015ftu\u011funu, nas\u0131l te\u015fhis edilece\u011fini ve API ile Nginx taraf\u0131nda nas\u0131l \u00e7\u00f6z\u00fclece\u011fini anlat\u0131yorum.<\/p>\n","protected":false},"author":2,"featured_media":562,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[723],"tags":[1814,1808,41,1812,1810,1605],"class_list":["post-564","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-nasil-yapilir","tag-api","tag-http-429","tag-nginx","tag-rate-limit","tag-too-many-requests","tag-web-sunucusu"],"lang":"tr","translations":{"tr":564,"en":565},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/564","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/comments?post=564"}],"version-history":[{"count":1,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/564\/revisions"}],"predecessor-version":[{"id":566,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/posts\/564\/revisions\/566"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media\/562"}],"wp:attachment":[{"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/media?parent=564"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/categories?post=564"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.vps.tc\/blog\/wp-json\/wp\/v2\/tags?post=564"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}