HTTP 429 Too Many Requests Artinya & Cara Mengatasinya

Apa Itu HTTP Error 429?

HTTP 429 Too Many Requests artinya server membatasi laju permintaan Anda: Anda, alamat IP Anda, atau aplikasi Anda mengirim permintaan lebih banyak daripada yang diizinkan dalam satu jangka waktu. Sifatnya sementara. Server tetap berjalan; hanya saja untuk sementara ia memilih tidak menjawab Anda.

Kode ini ditambahkan dalam RFC 6585 (2012) tepat untuk kasus ini, dan responsnya bisa membawa header Retry-After yang menyebutkan berapa lama harus menunggu. Anda akan menemuinya saat membuka situs yang ramai, memanggil API, mengunduh dalam jumlah besar, atau memakai VPN yang alamat IP-nya dipakai banyak orang.

Kode ini berbeda dari kode tetangganya: 401 berarti Anda belum login, 403 berarti Anda tidak diizinkan, dan 429 berarti Anda diizinkan, hanya terlalu cepat.

Seperti Apa Tampilan Error 429?

Pesannya bergantung pada siapa yang menjawab. Berikut yang paling sering dicari orang:

Berbeda dengan error 500 yang berarti ada yang rusak di server, 429 adalah error klien menurut istilah HTTP: server melindungi dirinya dari terlalu banyak permintaan.

Cara Kerja Rate Limiting

Rate limiting adalah teknik yang dipakai server untuk mengatur berapa banyak permintaan yang boleh dikirim klien dalam satu jangka waktu. Saat batas terlampaui, server biasanya menjawab 429 (sebagian menjawab 403 atau 503).

Ada beberapa algoritma rate limiting yang umum:

• Fixed Window — Server mengizinkan N permintaan per jangka waktu (misalnya 100 permintaan per menit). Penghitung di-reset pada interval tetap.
• Sliding Window — Mirip fixed window, tetapi jendela waktunya bergeser pada setiap permintaan. Ini mencegah lonjakan di batas jendela.
• Token Bucket — Server membagikan token yang terisi ulang dengan laju tetap. Setiap permintaan memakai satu token. Saat token habis, permintaan ditolak.
• Leaky Bucket — Permintaan diproses dengan laju konstan berapa pun ukuran lonjakannya. Kelebihan permintaan mengantre atau dibuang.

Banyak API mengumumkan batasnya lewat header respons. Milik GitHub, misalnya, adalah x-ratelimit-limit (permintaan yang diizinkan per jam), x-ratelimit-remaining, x-ratelimit-used, dan x-ratelimit-reset (kapan jendela di-reset, dalam detik Unix). Sebuah draf IETF mengusulkan header standar RateLimit dan RateLimit-Policy untuk fungsi yang sama.

Mengetahui algoritma dan jendela waktu yang dipakai suatu layanan membantu Anda merancang klien agar tetap di dalam batas.

Penyebab Umum HTTP Error 429

Penyebabnya bergantung pada siapa yang mengalaminya:

Cara Mengatasi Error 429 (Untuk Pengunjung)

Jika Anda melihat error 429 saat menjelajahi website, berikut solusi yang bisa dicoba. Mulai dari yang paling sederhana lalu lanjut ke bawah.

1. Tunggu dan Coba Lagi

Solusi paling sederhana adalah menunggu. Error 429 bersifat sementara: server meminta Anda memperlambat, bukan memblokir Anda.

Berapa lama bergantung pada batas situs: sebagian di-reset dalam semenit, sebagian per jam atau per hari. Jika halaman atau API mengirim header Retry-After, itulah waktu tunggu yang tepat. Setelah itu muat halaman satu kali saja.

Jangan terus me-refresh: setiap refresh adalah permintaan baru, dan dihitung terhadap batas yang sama.

2. Hapus Cookie Situs

Ini jarang berpengaruh, tetapi sebagian situs menghitung permintaan per cookie sesi. Hapus cookie situs itu saja untuk memulai sesi baru, tanpa keluar dari semua akun lain:

• Chrome / Edge: buka chrome://settings/content/all (Edge: edge://settings/content/all), cari situsnya, lalu hapus datanya
• Firefox: klik ikon gembok di address bar → "Clear cookies and site data…"
• Safari: Safari → Pengaturan → Privasi → Kelola Data Situs Web → cari situsnya → Hapus

Setelah dihapus, tutup dan buka kembali browser sebelum mengunjungi situs lagi.

3. Putuskan Koneksi VPN atau Proxy

Jika Anda memakai VPN atau proxy, bisa jadi Anda berbagi alamat IP dengan ratusan pengguna lain. Saat gabungan permintaan mereka melampaui batas server, semua orang di IP itu terkena rate limit.

Coba putuskan VPN dan akses situs lewat koneksi internet biasa. Jika error 429 hilang, IP VPN-lah masalahnya.

Jika Anda memerlukan VPN, pindah ke lokasi server lain: alamatnya mungkin dibagi dengan lebih sedikit orang.

4. Nonaktifkan Ekstensi Browser

Sebagian ekstensi mengirim permintaan di latar belakang ke situs yang Anda buka: pelacak harga, alat SEO, dan ekstensi auto-refresh bisa menumpuk hingga mencapai rate limit. (Pemblokir iklan biasanya justru sebaliknya dan mengurangi permintaan.)

Untuk menguji, buka situs di jendela incognito/privat, tempat sebagian besar ekstensi nonaktif. Incognito juga dimulai tanpa cookie, jadi jika 429 hilang, berarti ada ekstensi atau batas berbasis sesi yang terlibat.

Nonaktifkan ekstensi satu per satu untuk menemukan yang bermasalah. Di Chrome, buka chrome://extensions/ dan matikan satu per satu.

5. Periksa Apakah Alamat IP Anda Dipakai Bersama

Banyak orang bisa berbagi satu alamat IP publik: jaringan kantor atau sekolah, jaringan operator seluler (CGNAT), atau server VPN. Permintaan mereka dihitung terhadap batas yang sama dengan permintaan Anda.

Jika Anda berada di jaringan seperti itu, membuka situs dari koneksi rumah sendiri atau data seluler akan menunjukkan apakah alamat bersama itu masalahnya. Jika batas ada pada alamat Anda sendiri, tunggu hingga di-reset, jangan berpindah jaringan untuk menyiasatinya. Cek IP publik Anda saat ini dengan Apa Alamat IP Saya.

Cara Mengatasi Error 429 (Untuk Developer)

Jika kode Anda mendapat 429, berarti kode itu mengirim permintaan lebih cepat daripada yang diizinkan API. Tanganinya berurutan: baca Retry-After, lakukan backoff dengan jitter, lalu kurangi jumlah permintaan.

1. Terapkan Exponential Backoff

Exponential backoff adalah strategi retry standar: alih-alih langsung mengulang setelah 429, gandakan waktu tunggu setiap kali (1 detik, 2, 4, 8…), dan tambahkan jitter, yaitu jeda acak tambahan, agar banyak klien tidak mengulang pada saat yang sama.

Versi ini memakai Retry-After jika server mengirim yang valid, dalam salah satu dari dua formatnya, beralih ke backoff dengan jitter jika tidak, dan menyerah setelah beberapa percobaan. (Di browser yang memanggil API situs lain, Retry-After hanya bisa dibaca jika API mengeksposnya dengan Access-Control-Expose-Headers.)

async function fetchWithBackoff(url, options = {}, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    const response = await fetch(url, options);
    if (response.status !== 429 || attempt === maxRetries) return response;

    // Retry-After is either a number of seconds or an HTTP date
    const header = response.headers.get('Retry-After');
    let delay = NaN;
    if (header) {
      const seconds = Number(header);
      delay = Number.isNaN(seconds) ? Date.parse(header) - Date.now() : seconds * 1000;
    }
    if (!Number.isFinite(delay)) delay = 2 ** attempt * 1000 + Math.random() * 1000; // backoff + jitter
    await new Promise((resolve) => setTimeout(resolve, Math.max(delay, 0)));
  }
}

2. Patuhi Header Retry-After

Saat server mengirim Retry-After bersama 429, ia menyebutkan persis berapa lama harus menunggu. RFC 9110 mengizinkan dua bentuk: jumlah detik, atau tanggal HTTP.

Retry-After: 60 berarti tunggu 60 detik. Retry-After: Wed, 21 Oct 2026 07:28:00 GMT berarti tunggu sampai waktu itu. Periksa sebelum logika backoff Anda sendiri: server lebih tahu daripada kode Anda.

Di Python, tangani kedua bentuk dan berhenti setelah beberapa percobaan alih-alih rekursi tanpa akhir:

import random
import time
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_retry(url, max_retries=5):
    for attempt in range(max_retries + 1):
        response = requests.get(url)
        if response.status_code != 429 or attempt == max_retries:
            return response
        retry_after = response.headers.get("Retry-After", "")
        try:
            if retry_after.isdigit():
                wait = int(retry_after)
            else:  # an HTTP date
                wait = (parsedate_to_datetime(retry_after) - datetime.now(timezone.utc)).total_seconds()
        except (TypeError, ValueError):  # missing or unparseable: back off with jitter
            wait = 2 ** attempt + random.random()
        time.sleep(max(wait, 0))

3. Cache Respons API

Jika aplikasi Anda memanggil API yang sama berkali-kali, cache responsnya alih-alih memanggil API setiap kali. Ini mengurangi jumlah permintaan secara drastis.

Gunakan cache in-memory (seperti Redis atau Map sederhana) untuk data yang sering diakses. Atur TTL (time-to-live) yang wajar sesuai seberapa sering data berubah.

Misalnya, jika Anda memeriksa DNS record suatu domain, hasilnya kemungkinan besar tidak berubah dalam 5 menit ke depan — cache saja.

const cache = new Map();
const CACHE_TTL = 5 * 60 * 1000; // 5 minutes

async function cachedFetch(url) {
  const cached = cache.get(url);
  if (cached && Date.now() - cached.time < CACHE_TTL) return cached.data;

  const response = await fetch(url);
  if (!response.ok) throw new Error(`HTTP ${response.status}`); // never cache errors (a 429 included)
  const data = await response.json();
  cache.set(url, { data, time: Date.now() });
  return data;
}

4. Gunakan Webhook, Bukan Polling

Jika Anda terus-menerus melakukan polling ke API untuk mengecek perubahan (misalnya, mengecek status pesanan setiap 10 detik), beralihlah ke webhook jika layanan mendukungnya.

Dengan webhook, server mengirim pembaruan ke aplikasi Anda ketika ada perubahan — tidak perlu polling terus-menerus. Ini bisa mengurangi panggilan API Anda dari ribuan per jam menjadi hanya beberapa saja.

Sebagian besar API modern (Stripe, GitHub, Twilio, Shopify) mendukung webhook. Periksa dokumentasi API untuk konfigurasi webhook.

5. Minta Batas Rate yang Lebih Tinggi

Jika Anda memang membutuhkan lebih banyak panggilan API, hubungi penyedia layanan. Banyak API menawarkan rate limit lebih tinggi untuk paket berbayar atau aplikasi terverifikasi.

Saat meminta batas lebih tinggi, jelaskan kasus penggunaan Anda dan sertakan perkiraan volume permintaan. Banyak API, termasuk milik Google, memiliki formulir atau paket berbayar untuk batas yang lebih tinggi.

Sebagian API juga menyediakan bulk endpoint yang memungkinkan Anda mengambil beberapa resource dalam satu permintaan, sehingga total panggilan berkurang.

Cara Mengatasi Error 429 (Untuk Pemilik Website)

Jika pengunjung atau pengguna API Anda mendapat error 429, masalahnya ada pada konfigurasi server Anda. Berikut cara mendiagnosis dan memperbaikinya.

1. Sesuaikan Rate Limit Anda

Jika pengguna asli terkena 429, cari tahu lapisan mana yang menjawab lebih dulu: CDN atau WAF, web server, atau aplikasi Anda. Lalu sesuaikan batas di lapisan itu.

Di nginx, limit_req yang bekerja. Perhatikan bahwa secara default ia menjawab 503: tambahkan limit_req_status 429; agar klien tahu harus memperlambat, bukan mengira server mati:

# Define rate limit zone: 10 requests per second per IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    location /api/ {
        # Up to 20 extra requests pass at once (nodelay); more than that get 429
        limit_req zone=api burst=20 nodelay;
        limit_req_status 429;
    }
}

Parameter burst membiarkan lonjakan singkat lewat tanpa 429; tanpanya, pemuatan halaman biasa dengan banyak permintaan bisa mencapai batas.

Apache tidak punya pembatas laju permintaan bawaan: mod_ratelimit membatasi bandwidth, bukan jumlah permintaan, dan mod_evasive pihak ketiga menjawab 403. Gunakan reverse proxy, WAF, atau aplikasi Anda untuk 429. Di Node.js, express-rate-limit menjawab 429 secara default.

2. Whitelist IP Terpercaya

Jika klien tertentu (layanan monitoring, payment processor, microservice Anda sendiri) terkena rate limit, whitelist alamat IP mereka.

Di nginx, geo dan map memberi alamat tepercaya kunci kosong, dan nginx tidak menghitung permintaan dengan kunci kosong. Ini menggantikan baris limit_req_zone dari contoh sebelumnya:

geo $rate_limit {
    default        1;
    192.168.0.0/16 0;  # Internal network
    10.0.0.0/8     0;  # Internal network
    203.0.113.50   0;  # Payment processor
}

map $rate_limit $limit_key {
    0 "";
    1 $binary_remote_addr;
}

limit_req_zone $limit_key zone=api:10m rate=10r/s;

Jangan sampai tanpa sengaja membatasi crawler mesin pencari: Google memperlakukan 429 sebagai error server dan memperlambat crawling (Google Search Central). Verifikasi permintaan Googlebot dan Bingbot yang asli dengan pencarian reverse DNS yang dikonfirmasi oleh pencarian maju atas nama itu, atau kecualikan rentang IP yang dipublikasikan crawler tersebut.

3. Periksa Pengaturan WAF dan CDN

Jika Anda memakai Cloudflare, AWS WAF, Sucuri, atau layanan keamanan lain, aturan rate limiting-nya bisa menjawab sebelum server Anda sempat melihat permintaan.

Cloudflare menampilkan "Error 1015: You are being rate limited" kepada pengunjung saat aturan rate limiting terpicu. Temukan aturannya di aturan keamanan dashboard, periksa event-nya, lalu naikkan ambang batas atau persempit cakupannya.

Aturan berbasis rate di AWS WAF menghitung permintaan per IP (atau kunci lain) dalam jendela 1, 2, 5, atau 10 menit, dengan batas minimum 10. Permintaan yang diblokir mendapat 403 secara default; atur respons kustom 429 agar klien tahu harus mundur.

Lihat analitik CDN untuk memisahkan pengunjung asli dari bot sebelum Anda mengubah apa pun.

4. Optimalkan Performa Server

Sebagian layanan menerapkan rate limit lebih ketat saat sedang berbeban, sebagai katup pengaman. Memperbaiki performa server memungkinkan Anda menaikkan batas dengan aman.

Optimasi utama meliputi: aktifkan response caching untuk mengurangi beban backend, gunakan CDN untuk aset statis, tambahkan database query caching dengan Redis atau Memcached, terapkan connection pooling untuk koneksi database, dan skalakan secara horizontal dengan load balancing jika lalu lintas menuntutnya.

Gunakan alat Cek HTTP Header kami untuk memastikan header caching Anda sudah benar.

Error 429 vs Error HTTP Lainnya

Error 429 mudah tertukar dengan kode status HTTP lain. Berikut perbedaannya:

Perbedaan utamanya: 429 disengaja dan sementara: server memilih menolak Anda untuk sementara. Sebagian besar kode 5xx berarti ada yang gagal di server, meskipun 503 juga bisa berupa maintenance terencana atau, di nginx, rate limit.

Cara Mencegah Error 429

Mencegah lebih baik daripada mengobati. Berikut praktik terbaik untuk menghindari error 429 sejak awal:

• Baca dokumentasi API — Ketahui batas rate sebelum menulis kode. Sebagian besar layanan mempublikasikan batas mereka dengan jelas.
• Pantau penggunaan Anda — Lacak header X-RateLimit-Remaining untuk mengetahui seberapa dekat Anda dengan batas.
• Batch permintaan — Gunakan bulk endpoint jika tersedia alih-alih melakukan panggilan individual.
• Distribusikan permintaan — Sebarkan panggilan API secara merata dari waktu ke waktu, bukan mengirim sekaligus.
• Gunakan API key — Permintaan yang terautentikasi biasanya mendapat batas rate yang lebih tinggi dibanding yang anonim.
• Terapkan circuit breaker — Jika Anda mendapat 429 berulang kali, hentikan pengiriman permintaan sepenuhnya selama periode cooldown.
• Uji dengan simulator rate limit — Simulasikan respons 429 di development untuk memastikan error handling Anda berfungsi.
• Catat respons 429 — Lacak kapan dan di mana rate limiting terjadi untuk mengoptimalkan pola permintaan Anda.