Fix ERR_TOO_MANY_REDIRECTS: WordPress di Belakang AWS ALB

Kalau lo migrasi WordPress yang tadinya pakai Nginx sebagai SSL terminator ke setup dengan AWS Application Load Balancer (ALB) di depannya, ada satu masalah klasik yang hampir pasti muncul: ERR_TOO_MANY_REDIRECTS.

Artikel ini dokumentasi troubleshooting langsung dari production, mulai dari health check gagal, redirect loop, sampai fix di level Nginx dan WordPress.

Arsitektur Sebelum dan Sesudah

Sebelumnya:

Client → HTTPS → Nginx (SSL termination) → WordPress HTTP

Sesudah pakai ALB:

Client → HTTPS → ALB (SSL termination) → HTTP 80 → Nginx → WordPress

Di setup baru, ALB yang handle SSL. Nginx dan WordPress tidak perlu tahu soal SSL, mereka cukup terima traffic HTTP biasa dari ALB.

Masalah 1: Health Check Gagal dengan Kode 301

Setelah EC2 didaftarkan ke target group ALB, health check langsung Unhealthy dengan pesan:

Health checks failed with these codes: [301]

Kenapa Terjadi?

ALB secara default expect response 200 dari health check path. Tapi WordPress melakukan redirect (301), misalnya ke /en/ atau ke HTTPS, sehingga dianggap gagal.

Solusinya

Pergi ke EC2 > Target Groups > Health checks, lalu edit:

Health check path : /
Success codes     : 200,301

Atau ganti path ke endpoint yang langsung return 200. Tidak perlu menyentuh WordPress sama sekali.

Masalah 2: ERR_TOO_MANY_REDIRECTS

Setelah domain di-point ke ALB, browser langsung menampilkan ERR_TOO_MANY_REDIRECTS. Ini terjadi karena redirect loop:

ALB kirim HTTP ke Nginx
→ Nginx redirect ke HTTPS
→ ALB nerima HTTPS, forward lagi ke Nginx sebagai HTTP
→ Loop tidak berhenti

Fix Bagian 1: Bersihkan Config Nginx

Cek di mana redirect HTTPS berada:

sudo grep -rn "return 301" /etc/nginx/

Output:

/etc/nginx/sites-available/wordpress:5:    return 301 https://$host$request_uri;

Karena ALB sudah handle SSL termination, Nginx tidak perlu lagi melakukan redirect HTTPS. Backup dulu, lalu edit config-nya:

sudo cp /etc/nginx/sites-available/wordpress /etc/nginx/sites-available/wordpress.bak
sudo nano /etc/nginx/sites-available/wordpress

Ganti seluruh isi config dengan versi yang hanya listen di port 80 tanpa redirect:

server {
    listen 80;
    server_name example.com www.example.com;

    client_max_body_size 50M;
    root /var/www/html/wordpress;
    index index.php index.html index.htm;

    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HTTPS on;
        include fastcgi_params;
    }
}

Poin penting:

• Hapus server block port 443 karena SSL sekarang di ALB
• Hapus return 301 https://... karena ini biang kerok redirect loop
• Tambah fastcgi_param HTTPS on biar PHP/WordPress tahu request-nya HTTPS

Test dan reload:

sudo nginx -t
sudo systemctl reload nginx

Fix Bagian 2: wp-config.php

Setelah Nginx beres, masih bisa terjadi redirect loop dari sisi WordPress sendiri. Ini karena WordPress melihat request datang via HTTP (dari ALB ke Nginx), tapi WordPress dikonfigurasi untuk berjalan di HTTPS.

WordPress butuh dikasih tahu bahwa request originalnya adalah HTTPS melalui header X-Forwarded-Proto yang dikirim ALB.

Buka wp-config.php:

sudo nano /var/www/html/wordpress/wp-config.php

Tambahkan snippet ini sebelum baris require_once ABSPATH . 'wp-settings.php';:

/* Fix HTTPS detection behind ALB/reverse proxy */
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Setelah save, refresh browser dan redirect loop selesai.

Kenapa Dua Fix Diperlukan?

Keduanya saling terkait. Nginx fix menghentikan redirect di level server, tapi WordPress masih bisa generate URL HTTP dan redirect sendiri kalau tidak tahu konteks HTTPS-nya.

Lessons Learned

Masalah ini sebenarnya bisa dicegah jauh lebih cepat kalau dari awal sudah tahu detail setup server yang dipasang vendor.

Dalam kasus ini, vendor sebelumnya menginstall Nginx sebagai SSL terminator langsung di EC2. Tidak ada dokumentasi yang diserahkan, tidak ada catatan soal config apa yang aktif. Ketika infrastruktur berubah (masuk ALB), asumsinya server tinggal disambungkan. Ternyata ada konfigurasi lama yang konflik.

Beberapa hal yang sebaiknya didokumentasikan atau ditanyakan ke vendor sebelum migrasi:

Soal web server:

• Nginx atau Apache? Versi berapa?
• Ada berapa config file aktif di sites-enabled?
• Apakah ada redirect HTTPS di level Nginx?
• SSL terminate di mana, Nginx langsung atau ada layer lain?

Soal WordPress:

• Ada custom snippet di wp-config.php selain yang default?
• siteurl dan home di database point ke HTTP atau HTTPS?
• Ada plugin caching atau security yang bisa interfere dengan redirect?

Soal server secara umum:

• Service apa saja yang berjalan (systemctl list-units --type=service)?
• PHP versi berapa, dan pakai FPM socket atau TCP?

Minta handover document atau minimal akses SSH sebelum mulai integrasi. Troubleshooting config orang lain tanpa dokumentasi itu bisa makan waktu jauh lebih lama dari yang seharusnya.

Catatan Tambahan

• Kalau ada dua config file untuk domain yang sama (misalnya mysite dan mysite-old.conf), cek symlink di /etc/nginx/sites-enabled/ dan pastikan hanya satu yang aktif
• Header X-Forwarded-Proto dikirim otomatis oleh ALB, tidak perlu konfigurasi tambahan di sisi ALB
• Setelah semua beres, update juga ALB Listener Rules agar traffic untuk domain tersebut di-forward ke target group yang benar

Tested on: Ubuntu 22.04, Nginx 1.24, WordPress 6.x, AWS ALB