Penyebab Mendasar dan Solusi untuk Error “Too Many Redirects”

Kesalahan "Too Many Redirects" — ditampilkan di browser sebagai ERR_TOO_MANY_REDIRECTS dan sesuai dengan loop pengalihan HTTP — terjadi ketika server web dan klien masuk ke dalam rantai pengalihan melingkar yang tidak pernah berakhir ke tujuan akhir. Browser membatalkan permintaan setelah melampaui batas pengalihan (biasanya 20 hop di Chrome) dan menampilkan kesalahan ini alih-alih memuat halaman.

Ini bukan gangguan jaringan yang samar. Ini adalah kegagalan deterministik yang disebabkan oleh kesalahan konfigurasi tertentu dalam aturan server, pengaturan SSL, nilai database CMS, konfigurasi CDN, atau data pengalihan yang tersimpan dalam cache. Setiap kejadian memiliki akar penyebab yang dapat dilacak, dan setiap akar penyebab memiliki perbaikan yang tepat. Panduan ini membahas semuanya dengan kedalaman teknis yang diperlukan untuk menyelesaikan masalah secara permanen — baik Anda menjalankan situs WordPress, aplikasi kustom, atau tumpukan server mentah di lingkungan VPS Hosting.

Apa yang Sebenarnya Terjadi Selama Loop Pengalihan

Ketika browser meminta URL, server mungkin merespons dengan kode status 301 Moved Permanently, 302 Found, atau 307 Temporary Redirect yang menunjuk ke lokasi baru. Browser mengikuti header lokasi tersebut, membuat permintaan lain, dan mengharapkan respons 200 OK di suatu titik dalam rantai.

Loop pengalihan terbentuk ketika:

• URL A mengalihkan ke URL B, dan URL B mengalihkan kembali ke URL A (loop dua hop)
• URL A mengalihkan ke URL B, yang mengalihkan ke URL C, yang mengalihkan kembali ke URL A (loop multi-hop)
• Sebuah URL mengalihkan ke dirinya sendiri (loop referensial-diri)

Browser tidak melakukan loop tanpa batas. Chrome dan Firefox keduanya berhenti setelah sekitar 20 pengalihan dan menampilkan ERR_TOO_MANY_REDIRECTS. Safari menampilkan "Safari Can't Open the Page." Perilaku HTTP yang mendasarinya identik di semua browser tersebut.

Akar Penyebab dan Perbaikan yang Tepat

1. Aturan Pengalihan yang Salah Dikonfigurasi di .htaccess atau Nginx

Penyebab teknis yang paling umum adalah aturan penulisan ulang yang bertentangan atau melingkar di lapisan konfigurasi server.

Contoh loop yang rusak di Apache .htaccess:

RewriteEngine On
RewriteRule ^page$ /page [R=301,L]

Aturan ini mengalihkan /page ke /page — sebuah loop referensial-diri. Demikian pula, dua aturan yang mengalihkan antara /old-url dan /new-url dalam arah berlawanan akan menyebabkan kegagalan yang sama.

Cara mendiagnosis:

Buka file .htaccess Anda dan lacak setiap direktif RewriteRule dan Redirect secara manual. Cari aturan mana pun di mana pola target dapat cocok dengan sumber aturan lain.

grep -n "Redirect|RewriteRule|RewriteCond" /var/www/html/.htaccess

Untuk Nginx, masalah yang setara muncul di blok server atau location:

# Broken example — loop between two location blocks
location /old {
    return 301 /new;
}
location /new {
    return 301 /old;
}

Audit konfigurasi Nginx Anda dengan:

nginx -T | grep -A3 "return 301|rewrite"

Perbaikan: Pastikan setiap aturan pengalihan memiliki sumber dan tujuan yang unik dan tidak tumpang tindih. Gunakan flag [L] di Apache untuk menghentikan pemrosesan aturan setelah kecocokan ditemukan. Di Nginx, lebih baik gunakan return 301 daripada rewrite untuk kejelasan dan menghindari rantai yang tidak disengaja.

2. Kesalahan Konfigurasi Pengalihan HTTP ke HTTPS

Ini adalah penyebab paling umum pada lingkungan hosting modern, terutama setelah menambahkan Sertifikat SSL tanpa memperbarui konfigurasi tingkat aplikasi.

Pola kegagalannya terlihat seperti ini:

• Server web memaksa semua lalu lintas HTTP ke HTTPS melalui .htaccess atau konfigurasi Nginx
• Aplikasi (misalnya, WordPress) memiliki opsi siteurl atau home yang diatur ke http:// di database
• Aplikasi kemudian mengalihkan permintaan HTTPS kembali ke HTTP
• Loopnya adalah: HTTP → HTTPS (server) → HTTP (app) → HTTPS (server) → ...

Pengalihan HTTPS .htaccess Apache yang benar:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Pengalihan HTTPS Nginx yang benar:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Jebakan kritis: Jika Anda berada di belakang load balancer atau reverse proxy (termasuk Cloudflare), server backend mungkin tidak melihat HTTPS secara langsung. Proxy mengakhiri SSL dan meneruskan permintaan sebagai HTTP ke origin Anda. Server Anda kemudian melihat %{HTTPS} = off dan mengalihkan ke HTTPS lagi — menciptakan loop.

Perbaikannya adalah memeriksa header X-Forwarded-Proto sebagai gantinya:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

3. Ketidakcocokan Mode SSL Cloudflare dan CDN

Jika Anda menggunakan Cloudflare atau CDN lain di depan server origin Anda, mode enkripsi SSL/TLS harus sesuai dengan status sertifikat aktual origin Anda.

Skenario loop Cloudflare yang paling umum: Mode SSL diatur ke Flexible, dan server origin memiliki aturan .htaccess yang memaksa HTTP ke HTTPS. Cloudflare mengirim HTTP ke origin, origin mengalihkan ke HTTPS, Cloudflare menerima pengalihan tersebut, mengirim HTTP lagi — loop tak terbatas.

Perbaikan: Atur mode SSL Cloudflare ke Full (Strict) dan pastikan origin Anda memiliki sertifikat yang valid. Atau, jika Anda harus menggunakan Flexible, hapus pengalihan HTTP→HTTPS dari server origin Anda sepenuhnya dan biarkan Cloudflare menanganinya melalui Page Rule atau tombol "Always Use HTTPS".

Juga nonaktifkan Automatic HTTPS Rewrites di Cloudflare jika origin Anda sudah menangani pengalihan — mengaktifkan keduanya akan menggandakan logika pengalihan.

4. Ketidakcocokan Pengaturan URL WordPress

WordPress menyimpan URL kanoniknya di dua field database: siteurl (URL instalasi inti WordPress) dan home (URL yang menghadap publik). Ketika nilai-nilai ini bertentangan dengan aturan pengalihan server atau satu sama lain, loop hampir pasti terjadi.

Periksa nilai saat ini melalui WP-CLI:

wp option get siteurl
wp option get home

Atau query database secara langsung:

mysql -u dbuser -p dbname -e "SELECT option_name, option_value FROM wp_options WHERE option_name IN ('siteurl','home');"

Kedua nilai harus menggunakan protokol yang sama (https://) dan format domain yang sama (dengan atau tanpa www) yang diterapkan oleh konfigurasi server Anda.

Perbaikan melalui WP-CLI:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Perbaikan melalui wp-config.php (mengganti nilai database, berguna saat terkunci dari admin):

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Konflik plugin: Plugin manajer pengalihan (Redirection, Simple 301 Redirects, modul pengalihan Yoast SEO) dapat membuat aturan pengalihan yang tersimpan di database yang bertentangan dengan aturan tingkat server. Sementara ganti nama direktori plugins untuk mengisolasi masalah:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Aktifkan kembali plugin satu per satu setelah memastikan loop sudah hilang.

5. Cache Browser dan Pengalihan 301 yang Tersimpan dalam Cache

Browser menyimpan respons 301 Moved Permanently secara agresif — sesuai desainnya. Jika pengalihan 301 sebelumnya disajikan untuk sebuah URL dan kemudian target pengalihan diubah, browser mungkin masih mengikuti pengalihan lama yang tersimpan dalam cache, yang dapat menunjuk ke tujuan yang kini membuat loop.

Ini adalah skenario yang sangat menipu karena loop mungkin tidak dapat direproduksi di browser baru atau perangkat lain, sehingga administrator salah menyimpulkan bahwa server baik-baik saja.

Langkah diagnosis:

1. Buka URL di jendela incognito/private (tidak ada data yang tersimpan dalam cache)
2. Uji dengan curl untuk melewati cache browser sepenuhnya:

curl -I -L --max-redirs 10 https://example.com

1. Gunakan pelacak rantai pengalihan online (misalnya, redirect-checker.org atau httpstatus.io) untuk melihat setiap hop di sisi server

Perbaikan: Hapus cache browser dan cookie untuk domain yang terpengaruh. Di Chrome: Pengaturan > Privasi dan Keamanan > Hapus Data Penjelajahan > pilih Gambar dan File yang Tersimpan dalam Cache + Cookie.

Untuk cache sisi server (Varnish, Redis, OPcache, atau plugin caching seperti W3 Total Cache):

# Flush Varnish cache
varnishadm ban req.url ~ .

# Flush OPcache via PHP CLI
php -r "opcache_reset();"

6. Konflik Pengalihan www vs. Non-www

Sumber loop pengalihan yang sering diabaikan adalah penanganan subdomain www yang tidak konsisten. Jika server Anda mengalihkan www.example.com ke example.com dan secara bersamaan mengalihkan example.com ke www.example.com, Anda memiliki loop.

Periksa konfigurasi DNS dan pengalihan Anda saat ini:

curl -sI http://www.example.com | grep -i location
curl -sI http://example.com | grep -i location

Konfigurasi Apache yang benar (non-www kanonik):

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Pastikan aturan ini tidak dipasangkan dengan aturan lain yang mengalihkan versi non-www kembali ke www.

7. Cookie yang Rusak atau Bertentangan

Beberapa aplikasi menggunakan cookie untuk mengelola status pengalihan (misalnya, pengalihan login, deteksi lokal, kerangka kerja pengujian A/B). Jika sebuah cookie menyimpan target pengalihan yang sendirinya memicu pengalihan lain, loop didorong oleh logika aplikasi daripada konfigurasi server.

Diagnosis: Uji URL dengan semua cookie dihapus untuk domain tersebut. Di Chrome DevTools (F12), buka Application > Storage > Cookies, pilih domain, dan hapus semua entri. Muat ulang halaman.

Jika kesalahan hilang setelah menghapus cookie, masalahnya ada di sesi atau logika pengalihan aplikasi Anda, bukan konfigurasi server.

Perbandingan: Skenario Loop Pengalihan Umum dan Perbaikannya

Alur Kerja Diagnosis Sistematis

Sebelum menyentuh file konfigurasi apa pun, ikuti urutan ini untuk mengisolasi penyebabnya:

Langkah 1 — Reproduksi tanpa cache:

curl -v -L --max-redirs 25 https://example.com 2>&1 | grep -E "Location:|< HTTP"

Ini menampilkan setiap hop pengalihan dan kode respons akhir. Jika Anda melihat URL yang sama berulang, Anda telah mengonfirmasi loop dan mengidentifikasi URL mana yang terlibat.

Langkah 2 — Periksa log kesalahan server:

# Apache
tail -100 /var/log/apache2/error.log | grep -i redirect

# Nginx
tail -100 /var/log/nginx/error.log | grep -i rewrite

Langkah 3 — Isolasi lapisannya:

• Jika loop hilang saat Anda mengomentari aturan .htaccess, masalahnya ada di konfigurasi Apache
• Jika hilang saat Anda melewati Cloudflare (uji melalui IP langsung), masalahnya ada di pengaturan CDN
• Jika hilang saat Anda mengganti nama direktori plugins, masalahnya ada di plugin WordPress
• Jika hilang di mode incognito tetapi tidak di mode normal, masalahnya adalah cache browser atau cookie

Langkah 4 — Validasi pengikatan sertifikat SSL:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -E "subject|issuer|Verify"

Sertifikat yang tidak valid atau tidak cocok dapat menyebabkan kegagalan pengalihan HTTPS yang bermanifestasi sebagai loop.

Mencegah Loop Pengalihan di Produksi

Setelah diselesaikan, praktik-praktik ini mencegah terulangnya masalah:

• Gunakan satu aturan pengalihan kanonik yang menangani HTTP→HTTPS dan www→non-www dalam satu langkah, bukan dua aturan terpisah yang dapat berinteraksi
• Uji rantai pengalihan sebelum diterapkan menggunakan curl -L atau pemeriksa pengalihan online setelah perubahan konfigurasi apa pun
• Tetapkan pengalihan 301 hanya jika permanen — gunakan 302 selama pengujian agar browser tidak menyimpan pengalihan dalam cache
• Dokumentasikan setiap aturan pengalihan di .htaccess atau konfigurasi Nginx Anda dengan komentar inline yang menjelaskan tujuannya
• Pantau dengan alat uptime yang mengikuti rantai pengalihan dan memberi peringatan ketika jumlah hop melebihi ambang batas

Untuk tim yang mengelola beberapa situs di VPS dengan cPanel, modul Redirects cPanel menyediakan antarmuka visual untuk mengelola aturan pengalihan, tetapi ia menulis ke .htaccess — selalu verifikasi hasilnya secara manual setelah menggunakan GUI.

Jika Anda menjalankan situs dengan lalu lintas tinggi atau beberapa domain, Server Dedicated memberi Anda kendali penuh atas konfigurasi Nginx atau Apache di tingkat sistem, menghilangkan kendala lingkungan bersama yang dapat mempersulit debugging pengalihan.

Untuk situs yang menggunakan Panel Kontrol VPS seperti Plesk atau DirectAdmin, aturan pengalihan mungkin dikelola melalui antarmuka panel maupun langsung di file konfigurasi — periksa kedua lokasi untuk memastikan keduanya tidak saling bertentangan.

Daftar Periksa Teknis Poin Utama

Gunakan ini sebagai daftar periksa pra-terbang saat mendiagnosis ERR_TOO_MANY_REDIRECTS:

• [ ] Jalankan curl -v -L --max-redirs 25 untuk memetakan rantai pengalihan lengkap sebelum menyentuh konfigurasi apa pun
• [ ] Konfirmasi bahwa siteurl dan home di WordPress cocok dengan protokol dan domain yang diterapkan server Anda
• [ ] Verifikasi mode SSL Cloudflare adalah Full (Strict) jika origin Anda memiliki sertifikat yang valid
• [ ] Periksa bahwa konfigurasi .htaccess atau Nginx menggunakan X-Forwarded-Proto daripada %{HTTPS} saat berada di belakang proxy
• [ ] Pastikan pengalihan www dan non-www bersifat satu arah — hanya satu bentuk kanonik
• [ ] Nonaktifkan sementara semua plugin terkait pengalihan dan aktifkan kembali satu per satu
• [ ] Hapus cache browser dan uji di incognito untuk menyingkirkan respons 301 yang tersimpan dalam cache
• [ ] Periksa cookie aplikasi untuk status pengalihan yang mungkin mendorong loop
• [ ] Validasi bahwa sertifikat SSL valid dan terikat dengan benar ke domain
• [ ] Setelah diperbaiki, gunakan 302 sementara sebelum beralih ke 301 untuk mencegah penyimpanan ulang pengalihan yang rusak dalam cache

FAQ

Apa perbedaan antara ERR_TOO_MANY_REDIRECTS dan kode status HTTP 310?

ERR_TOO_MANY_REDIRECTS adalah kesalahan browser sisi klien yang dipicu setelah browser melampaui batas pengalihan yang diikutinya (biasanya 20). HTTP 310 adalah kode status yang jarang digunakan yang berarti "Too Many Redirects" di tingkat protokol. Dalam praktiknya, hampir semua kesalahan loop pengalihan yang Anda temui di produksi adalah ERR_TOO_MANY_REDIRECTS sisi browser — bukan respons 310 yang dikeluarkan server.

Mengapa loop pengalihan hanya muncul di beberapa browser atau perangkat tetapi tidak di yang lain?

Alasan paling umum adalah pengalihan 301 yang tersimpan dalam cache browser yang menunjuk ke tujuan yang kini tidak valid. Karena respons 301 disimpan dalam cache tanpa batas waktu secara default, browser yang sebelumnya mengunjungi URL tersebut mungkin mengikuti rantai pengalihan yang sudah usang. Pengujian di mode incognito atau di perangkat baru melewati cache ini dan mengungkapkan perilaku server saat ini.

Bagaimana cara memperbaiki loop pengalihan di WordPress ketika saya tidak dapat mengakses panel admin?

Tambahkan baris berikut langsung ke wp-config.php untuk mengganti nilai URL database, kemudian akses panel admin untuk memperbaiki pengaturan dengan benar:

define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');

Atau, perbarui nilai langsung di database menggunakan wp-cli atau query MySQL langsung terhadap tabel wp_options.

Apakah loop pengalihan dapat memengaruhi peringkat SEO?

Ya. Loop pengalihan tidak mengembalikan respons 200 OK, yang berarti Googlebot tidak dapat merayapi atau mengindeks URL yang terpengaruh. Jika loop memengaruhi halaman beranda atau halaman landing utama Anda, hal itu akan mengakibatkan penghapusan indeks seiring waktu. Selain itu, ekuitas tautan 301 yang melewati URL yang membuat loop secara efektif hilang. Menyelesaikan loop dengan segera dan memverifikasi kemampuan perayapan di Google Search Console sangat penting.

Bagaimana cara mencegah Cloudflare menyebabkan loop pengalihan dengan pengaturan SSL saya?

Atur mode enkripsi SSL/TLS Cloudflare ke Full (Strict) di dashboard SSL/TLS. Ini memastikan Cloudflare berkomunikasi dengan origin Anda melalui HTTPS menggunakan sertifikat yang divalidasi, menghilangkan loop HTTP↔HTTPS yang dibuat mode Flexible ketika server origin juga menerapkan HTTPS. Selain itu, nonaktifkan "Automatic HTTPS Rewrites" jika origin atau .htaccess Anda sudah menangani pengalihan HTTP-ke-HTTPS untuk menghindari logika pengalihan ganda.