Cara Mengatasi Cloudflare Error 1015 Rate Limited di WordPress

Apa Itu Cloudflare Error 1015?

Cloudflare Error 1015 dengan pesan "You are being rate limited" muncul ketika sebuah situs menerima terlalu banyak permintaan dalam waktu singkat dan untuk sementara memblokir pengunjung tersebut. Pesan ini bukan berarti situs Anda rusak permanen, dan bukan pula berarti Cloudflare sedang bermasalah. Error 1015 adalah tanda bahwa sebuah aturan rate limiting yang dipasang pemilik situs sedang bekerja — hanya saja, aturan itu mungkin menangkap pengunjung yang sebenarnya sah.

Penting untuk memahami satu hal sejak awal: aturan rate limiting itu milik Anda sendiri. Cloudflare tidak memberlakukan pembatasan ini secara otomatis. Anda (atau seseorang yang memiliki akses ke akun Cloudflare Anda) yang menentukan berapa banyak permintaan yang diizinkan, dalam jangka waktu berapa lama, dihitung berdasarkan apa, dan berapa lama blokirnya berlangsung. Karena itu, solusinya bukan "mematikan rate limiting Cloudflare", melainkan menemukan aturan yang salah sasaran dan memperbaikinya.

Jawaban Singkat: Cara Mengatasi Error 1015

Jika Anda pengunjung situs orang lain: berhenti me-refresh halaman, tunggu beberapa saat, lalu coba lagi sekali. Jika masih terblokir, hubungi pemilik situs dan sertakan Ray ID yang tertera di halaman error. Jika Anda pemilik situs WordPress: buka dashboard Cloudflare, cari aturan rate limiting yang cocok dengan Ray ID pengunjung, lalu persempit cakupannya ke endpoint yang benar-benar perlu dilindungi, perbaiki cara penghitungannya, dan pertimbangkan aksi challenge daripada blokir langsung untuk lalu lintas yang mungkin sah.

Bedakan Dulu: 1015, 1020, atau 429 Biasa?

Sebelum mengubah apa pun, pastikan blokir yang Anda hadapi memang Error 1015. Tiga mekanisme berbeda menghasilkan tampilan yang mirip, tetapi diperbaiki di tempat yang berbeda:

Yang Terlihat PengunjungMekanismeTempat Memperbaikinya
Error 1015, "you are being rate limited"Aturan rate limiting Cloudflare melewati ambang batasMenu Security > Rate limiting rules di Cloudflare
Error 1020, "access denied"Aturan firewall/WAF yang cocokAturan firewall/WAF Cloudflare
HTTP 429 polos tanpa halaman CloudflarePembatasan dari aplikasi atau server Anda sendiri (misalnya Nginx atau plugin)Konfigurasi aplikasi/server, bukan Cloudflare

Cara cepat memeriksanya dari terminal:

curl -sS -o /dev/null -D - https://domainanda.com/wp-login.php | grep -iE '^(HTTP/|cf-ray|retry-after|server):'

Jika respons membawa header cf-ray, blokir itu berasal dari edge Cloudflare. Jika tidak ada header tersebut, blokir berasal dari tumpukan server Anda sendiri dan aturan Cloudflare bukan penyebabnya.

Persiapan Sebelum Mengubah Aturan

  • Catat aturan yang aktif. Buka Security > Rate limiting rules dan tangkap layar atau catat nama, ekspresi jalur, karakteristik penghitung, ambang batas, periode, dan aksi setiap aturan sebelum diubah.
  • Minta Ray ID dari pengunjung yang terdampak. Ray ID tertera di bagian bawah halaman error 1015. Dengan Ray ID ini, Anda bisa menyaring Security Events di dashboard Cloudflare dan melihat aturan mana yang persis memblokir permintaan itu.
  • Jangan menaikkan ambang batas secara membabi buta. Menaikkan angka memang menghentikan keluhan dengan cepat, tetapi juga melemahkan perlindungan yang memang Anda butuhkan. Perbaiki dulu cakupan dan cara penghitungannya, baru sesuaikan ambang batas berdasarkan pemakaian normal yang terukur.

Langkah 1: Temukan Aturan yang Memblokir

Di dashboard Cloudflare, buka Security > Events, lalu saring berdasarkan Ray ID yang dilaporkan pengunjung. Dari entri tersebut Anda akan tahu nama aturan, jalur yang cocok, dan karakteristik penghitungnya. Hampir semua blokir palsu dijelaskan oleh dua hal pertama ini, bukan oleh angka ambang batasnya.

Langkah 2: Persempit Cakupan ke Endpoint yang Perlu Dilindungi

Kesalahan paling umum adalah aturan yang mencocokkan seluruh situs. Satu kali memuat halaman WordPress bukan satu permintaan — dokumen HTML ditambah stylesheet, skrip, font, gambar, dan panggilan latar bisa berjumlah puluhan permintaan. Aturan "50 permintaan per menit" yang berlaku untuk semua jalur praktis hanya mengizinkan sekitar satu kali tampilan halaman per menit.

Sebagai gantinya, batasi aturan pada endpoint yang memang layak dilindungi, misalnya:

  • /wp-login.php — perlindungan dari percobaan login massal (credential stuffing).
  • /wp-json/ atau endpoint API yang mahal diproses.
  • Formulir pencarian atau formulir kontak yang sering diserang bot.

Aset statis seperti gambar, CSS, dan JavaScript hampir tidak pernah perlu dihitung dalam rate limiting.

Langkah 3: Perbaiki Karakteristik Penghitung

Secara default aturan menghitung berdasarkan alamat IP. Masalahnya, satu alamat IP belum tentu satu orang:

  • Jaringan kantor bisa menampung ratusan karyawan di balik satu alamat IP publik.
  • Operator seluler memakai carrier-grade NAT, sehingga ribuan pelanggan berbagi satu alamat.
  • Sekolah, hotel, dan WiFi publik punya pola yang sama dalam skala lebih kecil.

Jika endpoint Anda bisa mengenali pengguna — misalnya API yang sudah diautentikasi atau sesi login — hitung berdasarkan sesuatu yang lebih spesifik daripada alamat IP, misalnya header atau karakteristik sesi yang tersedia di aturan Anda. Untuk endpoint publik yang tidak bisa membedakan pengguna, pertimbangkan aksi challenge (tantangan) daripada blokir: manusia asli bisa melanjutkan setelah menyelesaikan tantangan singkat, sementara bot tetap terbebani biayanya.

Langkah 4: Atur Periode dan Durasi Blokir dengan Sengaja

Dokumentasi Cloudflare menyarankan: jika aturan memblokir permintaan dalam periode yang sangat singkat (misalnya satu detik), coba naikkan periodenya menjadi 10 detik. Periode yang terlalu pendek mudah terpicu oleh lonjakan normal, misalnya beberapa tab dibuka bersamaan atau koneksi yang memuat ulang aset.

Durasi blokir juga perlu dipikirkan. Blokir yang terlalu lama mengubah ledakan sesaat menjadi "gangguan" berjam-jam bagi pengunjung itu, apalagi karena klien yang terus mencoba ulang selama masa blokir bisa memperpanjang sendiri pemblokirannya. Tetapkan durasi yang proporsional dengan ancaman yang Anda hadapi, bukan angka terpanjang yang tersedia.

Langkah 5: Kecualikan Infrastruktur Anda Sendiri

Uptime monitor, pengujian sintetis, dan integrasi internal Anda sendiri menghantam situs sesuai jadwal. Jika tidak dikecualikan, mereka menghabiskan anggaran permintaan yang sama dengan pengunjung — dan lebih buruk lagi, monitor yang menerima 1015 akan melaporkan situs Anda "down" padahal situs melayani semua orang lain dengan normal. Kecualikan alamat IP monitor Anda secara eksplisit, dan periksa ulang setiap kali Anda menambah wilayah pemantauan baru.

Langkah 6: Uji Aturan Sebelum Mempercayainya

Uji aturan secara sengaja dari alamat yang Anda kendalikan, dengan jumlah permintaan kecil dulu — Anda sedang menguji aturan, bukan melakukan load test:

for i in $(seq 1 25); do
  printf '%s ' "$(curl -sS -o /dev/null -w '%{http_code}' https://domainanda.com/wp-login.php)"
  sleep 0.2
done; echo

Periksa dua hal: aturan aktif di jalur yang Anda harapkan, dan satu kunjungan normal tidak menghabiskan porsi anggaran yang berarti. Jika satu kunjungan biasa sudah mendekati ambang batas, cakupan aturannya salah, berapa pun angkanya.

Cara Memverifikasi Hasil Perbaikan

  1. Minta pengunjung yang sebelumnya terblokir untuk mencoba lagi setelah periode blokir berakhir — tanpa me-refresh berulang selama masa blokir.
  2. Periksa Security Events: tidak ada lagi entri 1015 untuk alamat IP atau jalur yang seharusnya sah.
  3. Buka situs dari jaringan seluler dan dari jaringan kantor (jika memungkinkan) untuk memastikan pengguna di balik NAT bersama tidak lagi ikut terblokir.
  4. Pastikan monitor uptime Anda kembali hijau dan tidak lagi melaporkan downtime palsu.

Troubleshooting Lanjutan

Pengunjung mengaku terblokir berjam-jam padahal durasi blokir pendek

Periksa apakah kliennya terus mencoba ulang selama masa blokir — percobaan yang berlanjut umumnya membuat penghitung tetap berjalan dan memperpanjang blokirnya sendiri. Mintalah pengunjung berhenti total selama beberapa menit, lalu mencoba sekali saja.

Hanya satu pelanggan yang selalu kena, yang lain tidak

Periksa karakteristik penghitung sebelum berasumsi soal perilaku pelanggan itu. Jika aturan menghitung berdasarkan alamat IP dan pelanggan berada di jaringan korporat atau operator seluler, satu alamat itu mewakili banyak orang sekaligus.

Error muncul hanya di halaman login WordPress

Itu justru pertanda aturan bekerja di tempat yang tepat — halaman login memang target umum serangan. Persempit ambang batas khusus untuk /wp-login.php berdasarkan pola login normal, dan pastikan plugin keamanan WordPress Anda tidak ikut membatasi alamat yang sama secara berlapis sehingga efeknya berlipat.

FAQ

Apakah Error 1015 bisa dimatikan?

Tidak ada tombol "matikan rate limiting Cloudflare" karena pembatasan ini bukan bawaan Cloudflare — ia berasal dari aturan di akun Anda sendiri. Solusinya adalah menemukan aturan itu, lalu mempersempit atau menghapusnya.

Berapa lama blokir 1015 berlangsung?

Persis selama durasi yang Anda tentukan di aturan tersebut — tidak ada durasi universal. Jika pengunjung mengaku terblokir jauh lebih lama dari durasi yang dikonfigurasi, kemungkinan besar kliennya terus mencoba ulang sehingga penghitungnya tetap hidup.

Apakah Error 1015 sama dengan HTTP 429?

Tidak persis. 429 adalah kode status standar untuk pembatasan laju yang bisa berasal dari mana saja di tumpukan server. 1015 adalah halaman bermerek Cloudflare untuk aturan miliknya sendiri yang aktif di edge. Keberadaan header cf-ray membedakan keduanya.

Sebagai pengunjung, apa yang bisa saya lakukan?

Berhenti me-refresh halaman, tunggu beberapa saat, lalu coba sekali lagi. Jangan mencoba berulang dalam waktu singkat karena itu bisa memperpanjang blokir. Jika masih terblokir, hubungi pemilik situs dan sertakan Ray ID dari halaman error.

Kesimpulan

Error 1015 hampir selalu berarti aturan rate limiting Anda sendiri menangkap lalu lintas yang tidak Anda maksudkan. Jangan langsung menaikkan ambang batas: cari aturan yang aktif lewat Ray ID, persempit cakupannya ke endpoint yang benar-benar perlu dilindungi, perbaiki karakteristik penghitungnya, kecualikan monitor Anda sendiri, dan uji aturannya sebelum memercayainya. Dengan begitu, perlindungan terhadap bot tetap berjalan tanpa mengorbankan pengunjung asli — termasuk mereka yang berselancar dari jaringan kantor atau operator seluler.

Lebih lamaTerbaru
Cookie Consent