Anda membuka situs WordPress, lalu yang muncul bukan beranda, melainkan halaman bertuliskan Error 521: Web Server Is Down. Pesan ini sering membuat pemilik situs panik karena terdengar seperti servernya benar-benar mati total. Padahal artinya lebih spesifik dari itu.
Daftar Isi
- Jawaban Singkat: Tiga Penyebab Utama Error 521
- Bedakan 521 dari 522, 524, dan 526
- Tabel Diagnosis: Gejala, Penyebab, dan Cara Memeriksanya
- Persiapan dan Backup Sebelum Mengubah Server
- Langkah 1: Pastikan Web Server Benar-Benar Berjalan
- Langkah 2: Pastikan Server Mendengarkan Port yang Benar
- Langkah 3: Uji Origin Secara Langsung, Melewati Cloudflare
- Langkah 4: Izinkan Rentang IP Cloudflare di Firewall
- Langkah 5: Periksa Mode SSL/TLS di Dashboard Cloudflare
- Langkah 6: Bila Server Sudah Hidup tetapi WordPress Tetap Bermasalah
- Verifikasi Hasil: Tanda Error 521 Benar-Benar Hilang
- Troubleshooting Lanjutan Bila 521 Masih Muncul
- Alternatif Bila Anda Tidak Punya Akses Root ke VPS
- FAQ Seputar Cloudflare Error 521
- Kesimpulan
Menurut dokumentasi resmi Cloudflare, Error 521 terjadi ketika server asal (origin) menolak koneksi dari Cloudflare. Artinya, pengunjung sudah berhasil sampai ke Cloudflare, Cloudflare sudah mencoba meneruskan permintaan ke server VPS Anda, tetapi server itu menolak atau tidak menerima koneksi tersebut. Karena koneksi tidak pernah terbentuk, WordPress Anda bahkan tidak sempat memproses apa pun.
Ciri yang membedakan 521 dari error Cloudflare lainnya adalah kecepatannya: halaman error biasanya muncul hampir seketika, bukan setelah menunggu lama. Kalau halaman baru gagal setelah menunggu belasan detik atau lebih dari satu menit, itu kemungkinan besar bukan 521, melainkan 522 atau 524. Perbedaan ini penting, karena obat untuk "koneksi ditolak" berbeda dengan obat untuk "koneksi lambat".
Jawaban Singkat: Tiga Penyebab Utama Error 521
Dalam sebagian besar kasus WordPress di VPS, Error 521 berasal dari salah satu dari tiga hal berikut:
- Web server tidak berjalan. Nginx atau Apache berhenti, crash, atau gagal start setelah update atau restart server.
- IP Cloudflare diblokir. Firewall VPS, fail2ban, atau plugin keamanan mengira trafik dari IP Cloudflare sebagai serangan, lalu memblokirnya.
- Port atau mode SSL tidak cocok. Cloudflare mencoba menghubungi port yang tidak didengarkan server, misalnya Cloudflare memakai mode Full atau Full (Strict) yang membutuhkan port 443, tetapi server hanya mendengarkan port 80.
Urutan perbaikan dalam artikel ini mengikuti urutan itu: periksa dulu apakah server hidup, lalu apakah firewall memblokir Cloudflare, lalu apakah port dan mode SSL-nya cocok. Jangan mengubah konfigurasi WordPress dulu sebelum tiga hal di atas diperiksa, karena WordPress tidak terlibat sama sekali bila koneksi ditolak di gerbang server.
Bedakan 521 dari 522, 524, dan 526
Salah mendiagnosis kode error adalah kesalahan paling umum. Tabel berikut membantu Anda memastikan bahwa yang Anda hadapi memang 521.
| Kode | Arti singkat | Ciri yang terasa | Arah perbaikan |
|---|---|---|---|
| 521 | Origin menolak koneksi | Muncul seketika; koneksi tidak terbentuk | Server hidup? Firewall? Port/SSL? |
| 522 | Koneksi timeout | Menunggu lama, lalu gagal; paket di-drop atau server tidak menjawab | Keepalive, IP origin di DNS, beban server, routing |
| 524 | Origin terlalu lama merespons | Koneksi terbentuk, tetapi respons tidak selesai tepat waktu | Performa PHP/MySQL, proses berat, timeout upstream |
| 526 | Sertifikat origin tidak valid | Koneksi terbentuk, tetapi sertifikat ditolak pada mode Full (Strict) | Perbaiki atau ganti sertifikat origin |
Kalau situs Anda menampilkan 526, artikel ini bukan panduan yang tepat — masalahnya ada pada sertifikat, bukan pada penolakan koneksi. Begitu pula bila halaman baru gagal setelah menunggu lama: periksa panduan 522 atau 524, bukan mengulang langkah 521.
Tabel Diagnosis: Gejala, Penyebab, dan Cara Memeriksanya
| Gejala yang Anda lihat | Kemungkinan penyebab | Cara memeriksa | Solusi yang sesuai |
|---|---|---|---|
| Error 521 di semua halaman, termasuk wp-admin | Nginx/Apache berhenti | systemctl status nginx atau systemctl status apache2 | Perbaiki penyebab gagal start dari log, lalu jalankan kembali layanannya |
| Situs bisa dibuka lewat IP origin langsung, tetapi 521 lewat domain Cloudflare | IP Cloudflare diblokir firewall | Periksa aturan UFW/iptables dan log fail2ban | Izinkan semua rentang IP Cloudflare (lihat langkah 4) |
| 521 muncul tepat setelah mengubah mode SSL di Cloudflare | Port tidak cocok dengan mode SSL | ss -tlnp untuk melihat port yang didengarkan | Sesuaikan listener origin dengan mode: 80 untuk Flexible, 443 untuk Full/Full (Strict) |
| 521 muncul setelah instalasi plugin keamanan atau perubahan firewall | Plugin/firewall memblokir IP proxy | Nonaktifkan sementara komponen yang baru diubah, lalu uji lagi | Tambahkan IP Cloudflare ke daftar izin komponen itu |
| 521 hanya sesekali, lalu hilang sendiri | Server kehabisan resource atau proses crash berulang | free -h, df -h, dan log error web server | Atasi penyebab crash (memori, disk penuh, proses berat), bukan sekadar restart |
Persiapan dan Backup Sebelum Mengubah Server
Sebelum menyentuh konfigurasi apa pun, lakukan tiga hal ini:
- Cadangkan WordPress. Salin folder situs dan ekspor database, atau gunakan backup dari panel/VPS Anda. Jangan mengandalkan ingatan bahwa "tadi masih jalan".
- Catat apa yang terakhir diubah. Update plugin, perubahan firewall, penggantian sertifikat, migrasi VPS, atau perubahan mode SSL di Cloudflare — salah satu dari perubahan terakhir itu hampir selalu menjadi petunjuk penyebabnya.
- Pastikan Anda punya akses SSH. Sebagian besar diagnosis 521 dilakukan dari terminal server, bukan dari dashboard WordPress, karena wp-admin pun tidak bisa diakses saat error ini terjadi.
Perintah-perintah di bawah ini adalah contoh umum untuk Ubuntu dengan Nginx dan UFW. Sesuaikan nama layanan, jalur file, dan versi PHP dengan VPS Anda. Jangan menyalin perintah yang memakai jalur berbeda tanpa memeriksa dulu bahwa jalur itu ada di server Anda.
Langkah 1: Pastikan Web Server Benar-Benar Berjalan
Masuk ke VPS lewat SSH, lalu periksa status web server Anda:
sudo systemctl status nginx
sudo systemctl status apache2
Perintah di atas cukup dijalankan salah satunya, sesuai web server yang Anda pakai. Bila statusnya active (running), lanjut ke langkah 2 — server Anda hidup, jadi penyebabnya ada di tempat lain. Bila statusnya inactive atau failed, jangan langsung restart membabi buta. Cari dulu penyebab gagalnya di log:
sudo journalctl -u nginx --no-pager -n 50
sudo tail -n 100 /var/log/nginx/error.log
Untuk Apache, log yang setara biasanya berada di /var/log/apache2/error.log. Pesan log seperti "port already in use", "certificate file not found", atau "syntax error" memberi tahu Anda persis apa yang harus diperbaiki. Setelah penyebabnya diperbaiki, barulah jalankan ulang layanannya:
sudo systemctl start nginx
sudo nginx -t && sudo systemctl reload nginx
Perintah nginx -t menguji konfigurasi sebelum reload, sehingga kesalahan sintaks tidak membuat server yang tadinya jalan ikut tumbang. Hasil yang diharapkan: syntax is ok dan test is successful.
Langkah 2: Pastikan Server Mendengarkan Port yang Benar
Server yang "hidup" belum tentu mendengarkan port yang dicari Cloudflare. Periksa port yang aktif:
sudo ss -tlnp | grep -E ':80|:443'
Yang perlu Anda cocokkan dengan mode SSL/TLS di Cloudflare (menurut dokumentasi resmi Cloudflare):
- Flexible: Cloudflare menghubungi origin lewat HTTP, jadi origin harus mendengarkan port 80.
- Full dan Full (Strict): Cloudflare menghubungi origin lewat HTTPS, jadi origin harus mendengarkan port 443 dan memiliki sertifikat.
Contoh kasus yang sering terjadi: pemilik situs baru saja beralih dari Flexible ke Full (Strict) karena ingin enkripsi ujung-ke-ujung, tetapi VPS-nya belum pernah dipasangi sertifikat dan tidak memiliki listener port 443. Hasilnya 521 di seluruh situs, karena Cloudflare hanya mencoba port 443 dan tidak menemukan apa pun di sana. Solusinya bukan kembali ke Flexible secara permanen — itu hanya menghilangkan enkripsi antara Cloudflare dan origin — melainkan memasang sertifikat origin yang benar (misalnya dari Let's Encrypt atau Cloudflare Origin CA) dan memastikan Nginx mendengarkan port 443, lalu memakai Full (Strict).
Untuk memeriksa konfigurasi Nginx secara langsung, lihat blok server situs Anda:
sudo nginx -T | grep -E 'listen|server_name|ssl_certificate'
Pastikan ada baris listen 443 ssl; bila Anda memakai Full atau Full (Strict), dan baris listen 80; bila Anda memakai Flexible. Bila tidak ada, tambahkan listener yang sesuai di konfigurasi situs, uji dengan nginx -t, lalu reload.
Langkah 3: Uji Origin Secara Langsung, Melewati Cloudflare
Cara tercepat membedakan "server mati" dari "Cloudflare diblokir" adalah menguji origin secara langsung. Dari terminal Anda (bukan dari browser pengunjung), arahkan permintaan ke IP origin dengan nama domain yang benar:
curl -I --resolve namadomainanda.com:443:IP-ORIGIN-ANDA https://namadomainanda.com/
curl -I --resolve namadomainanda.com:80:IP-ORIGIN-ANDA http://namadomainanda.com/
Ganti namadomainanda.com dengan domain Anda dan IP-ORIGIN-ANDA dengan IP VPS Anda. Jangan membagikan IP origin ini ke publik — perintah ini hanya untuk diagnosis dari perangkat Anda sendiri.
Cara membaca hasilnya:
- curl berhasil menampilkan header HTTP (misalnya 200 atau 301): server Anda hidup dan bisa dihubungi langsung. Berarti kemungkinan besar firewall atau lapisan keamananlah yang menolak koneksi dari IP Cloudflare. Lanjut ke langkah 4.
- curl gagal dengan "Connection refused": tidak ada layanan yang mendengarkan port itu. Kembali ke langkah 1 dan 2.
- curl menggantung tanpa respons: koneksi tidak ditolak secara eksplisit, tetapi juga tidak dijawab. Pola ini lebih mengarah ke 522 (paket di-drop) daripada 521 — periksa firewall yang melakukan drop diam-diam dan kondisi beban server.
Langkah 4: Izinkan Rentang IP Cloudflare di Firewall
Ini adalah penyebab 521 yang paling sering terlewat, karena server terlihat baik-baik saja saat diuji langsung. Penjelasannya sederhana: begitu domain diproksi Cloudflare, semua permintaan pengunjung tiba di origin dari IP Cloudflare, bukan dari IP pengunjung asli. Bagi firewall, itu terlihat seperti segelintir sumber yang mengirim trafik sangat besar — pola yang persis seperti serangan — sehingga firewall, fail2ban, atau plugin keamanan bisa memblokirnya secara otomatis.
Dokumentasi Cloudflare menegaskan: izinkan semua rentang IP Cloudflare, bukan hanya satu atau dua alamat yang sempat terlihat di log. Rentang ini sesekali berubah, jadi ambillah daftar terbaru dari halaman resmi Cloudflare pada saat Anda memperbaiki, jangan menyalin daftar lama dari forum.
Contoh untuk UFW di Ubuntu (ambil daftar terbaru, lalu izinkan port 80 dan 443):
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
sudo ufw allow from $ip to any port 80,443 proto tcp
done
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
sudo ufw allow from $ip to any port 80,443 proto tcp
done
sudo ufw reload
Untuk iptables, pola yang setara menurut dokumentasi Cloudflare adalah:
sudo iptables -I INPUT -p tcp -m multiport --dports http,https -s RENTANG-IP-CLOUDFLARE -j ACCEPT
Ulangi perintah itu sekali untuk setiap rentang IP dari daftar resmi, ganti RENTANG-IP-CLOUDFLARE dengan masing-masing rentang. Setelah aturan ditambahkan, periksa status firewall dan pastikan aturan baru itu benar-benar aktif sebelum menguji situs lagi.
Selain firewall sistem operasi, periksa juga lapisan lain yang bisa memblokir:
- fail2ban: periksa apakah IP Cloudflare masuk daftar banned (
sudo fail2ban-client statusdan jail yang relevan), lalu tambahkan pengecualian bila perlu. - Plugin keamanan WordPress: beberapa plugin memblokir IP berdasarkan jumlah permintaan. Karena semua trafik Cloudflare datang dari IP yang sama, plugin semacam ini sangat mudah salah memblokir. Tambahkan IP Cloudflare ke daftar izin plugin, atau nonaktifkan fitur pemblokiran otomatisnya untuk sementara saat diagnosis.
- Firewall panel hosting atau penyedia VPS: bila VPS Anda punya firewall di panel (misalnya security group), pastikan port 80 dan 443 terbuka untuk rentang IP Cloudflare di sana juga, bukan hanya di UFW.
Langkah 5: Periksa Mode SSL/TLS di Dashboard Cloudflare
Buka dashboard Cloudflare, pilih domain Anda, lalu masuk ke SSL/TLS → Overview. Cocokkan mode yang aktif dengan kondisi origin Anda:
| Mode | Cloudflare menghubungi origin lewat | Yang dibutuhkan origin |
|---|---|---|
| Flexible | HTTP (port 80) | Listener port 80; trafik origin tidak terenkripsi |
| Full | Sesuai skema pengunjung; HTTPS tanpa validasi sertifikat | Listener port 443 dan sertifikat apa pun, termasuk self-signed |
| Full (Strict) | HTTPS dengan validasi sertifikat | Listener port 443 dan sertifikat valid dari CA publik atau Cloudflare Origin CA |
Catatan penting: jangan menjadikan Flexible sebagai "solusi permanen" hanya karena 521 hilang setelah beralih ke sana. Flexible menghilangkan enkripsi pada segmen Cloudflare→origin, sehingga pengunjung tetap melihat gembok padahal jalur ke server Anda tidak terenkripsi. Solusi yang benar adalah memperbaiki listener dan sertifikat origin, lalu kembali ke Full (Strict).
Perhatian khusus untuk WordPress: bila situs Anda memaksa redirect HTTP→HTTPS di level aplikasi (misalnya siteurl sudah https://) sementara Cloudflare masih Flexible, Anda bisa mendapat redirect loop setelah 521 teratasi. Itu bukan lagi 521, melainkan masalah mode SSL yang tidak konsisten — selesaikan dengan beralih ke Full (Strict) setelah sertifikat origin terpasang.
Langkah 6: Bila Server Sudah Hidup tetapi WordPress Tetap Bermasalah
Ingat: bila Cloudflare sudah bisa terhubung ke origin, error yang muncul bukan lagi 521. Tetapi ada satu skenario peralihan yang layak diperiksa: web server hidup, tetapi proses PHP-nya crash berulang sehingga Nginx tidak punya backend untuk diteruskan. Dalam kasus itu Anda mungkin melihat 502, bukan 521, dan langkah yang tepat adalah memeriksa PHP-FPM (systemctl status php8.3-fpm, sesuaikan versinya) dan log PHP. Jangan memaksakan langkah 521 ke masalah yang sudah bergeser ke lapisan aplikasi.
Yang masih relevan di sini adalah memeriksa apakah perubahan terakhir di WordPress (update plugin, tema, atau konfigurasi) bertepatan dengan munculnya 521. Bila ya, kemungkinan besar perubahan itu menyentuh firewall, sertifikat, atau konfigurasi web server — bukan sekadar isi artikel — jadi telusuri perubahan itu di log server, bukan menebak-nebak plugin mana yang "menyebabkan 521".
Verifikasi Hasil: Tanda Error 521 Benar-Benar Hilang
Jangan berhenti pada "halaman depan sudah terbuka sekali". Lakukan verifikasi berikut:
- Muat ulang beranda di browser mode privat dan pastikan tidak ada lagi halaman Error 521.
- Buka
wp-admindan satu artikel dalam situs, untuk memastikan bukan hanya halaman cache Cloudflare yang tampil. - Ulangi perintah
curldari langkah 3 dan pastikan responsnya konsisten, bukan hanya sesekali berhasil. - Periksa log Nginx beberapa menit setelah perbaikan untuk memastikan tidak ada lagi penolakan koneksi dari IP Cloudflare.
- Bila memakai Cloudflare, lakukan Purge Cache bila halaman error lama masih tersimpan di cache, lalu muat ulang.
Bila situs sudah pulih di semua pemeriksaan itu, barulah perbaikan bisa dianggap selesai. Bila hanya beranda yang pulih tetapi wp-admin masih 521, kemungkinan ada aturan firewall atau plugin yang masih memblokir jalur tertentu — kembali ke langkah 4 dan periksa aturan per jalur, bukan hanya per port.
Troubleshooting Lanjutan Bila 521 Masih Muncul
Server kehabisan memori atau disk
Server yang kehabisan RAM atau disk bisa membuat proses web server crash berulang. Periksa dengan free -h dan df -h. Bila disk penuh, cari penyebabnya (log yang membengkak, backup lama, file upload) sebelum sekadar me-restart layanan, karena restart tanpa membebaskan resource hanya menunda crash berikutnya.
IP origin berubah setelah migrasi atau restart VPS
Bila VPS Anda mendapat IP baru (misalnya setelah migrasi atau penggantian instance), record A/AAAA di dashboard Cloudflare (menu DNS) harus diperbarui ke IP yang baru. Cloudflare yang masih mengarah ke IP lama akan gagal terhubung, dan gejalanya mirip 521. Pastikan record DNS yang diproksi (awan oranye) menunjuk ke IP VPS yang aktif saat ini.
Rate limiting dari penyedia hosting
Beberapa penyedia membatasi jumlah koneksi dari satu sumber. Karena semua trafik Cloudflare datang dari IP yang terbatas, pembatasan ini bisa ikut memblokir Cloudflare. Bila semua langkah di atas sudah benar tetapi 521 tetap muncul, hubungi penyedia hosting Anda dan tanyakan apakah ada rate limiting terhadap IP Cloudflare, serta mintalah pengecualian untuk rentang IP tersebut.
Kapan harus menghubungi dukungan Cloudflare
Bila origin sudah terbukti hidup, port sudah benar, firewall sudah mengizinkan semua IP Cloudflare, dan mode SSL sudah cocok, tetapi 521 tetap muncul, kumpulkan bukti berikut sebelum menghubungi dukungan: waktu kejadian, Ray ID dari halaman error, hasil curl langsung ke origin, dan potongan log server pada jam yang sama. Bukti ini jauh lebih mempercepat proses dukungan daripada sekadar melaporkan "situs saya 521".
Alternatif Bila Anda Tidak Punya Akses Root ke VPS
Tidak semua pemilik WordPress mengelola VPS sendiri. Bila Anda memakai hosting terkelola atau tidak punya akses SSH:
- Gunakan fitur pause Cloudflare sementara (ikon awan abu-abu di DNS Cloudflare) untuk memastikan situs bisa dibuka langsung — bila bisa, masalahnya hampir pasti ada di lapisan antara Cloudflare dan origin, dan Anda bisa melaporkannya ke hosting dengan bukti itu.
- Minta penyedia hosting memeriksa status web server, firewall, dan apakah IP Cloudflare diblokir — sebutkan tiga penyebab di artikel ini agar teknisi tidak memulai dari nol.
- Jangan mengubah mode SSL ke Flexible sebagai "jalan pintas" tanpa memahami risikonya; mintalah hosting memasang sertifikat origin yang benar bila Anda ingin memakai Full (Strict).
FAQ Seputar Cloudflare Error 521
Apakah Error 521 berarti situs saya dihapus atau datanya hilang?
Tidak. Error 521 berarti koneksi ditolak, bukan berarti file atau database WordPress Anda hilang. Data Anda tetap ada di server selama server itu sendiri tidak mengalami kerusakan disk atau penghapusan. Fokus perbaikan adalah mengembalikan koneksi, bukan memulihkan data — kecuali log menunjukkan kerusakan yang lebih serius.
Kenapa situs saya bisa dibuka lewat IP langsung, tetapi 521 lewat domain?
Karena jalur lewat domain melewati Cloudflare, sedangkan akses langsung tidak. Bila akses langsung berhasil, server Anda hidup; yang bermasalah adalah jalur Cloudflare→origin, paling sering firewall yang memblokir IP Cloudflare. Itu sebabnya langkah 4 (allowlist IP Cloudflare) menjadi kunci dalam skenario ini.
Apakah restart Nginx selalu memperbaiki 521?
Tidak selalu. Restart hanya membantu bila penyebabnya memang proses web server yang berhenti. Bila penyebabnya firewall, port, atau mode SSL yang tidak cocok, restart tidak mengubah apa pun dan 521 akan kembali. Selalu diagnosis dulu dari log dan tabel diagnosis di atas sebelum me-restart.
Apakah saya harus mengizinkan semua rentang IP Cloudflare, atau cukup satu?
Semua. Cloudflare melayani permintaan dari banyak data center dengan IP yang berbeda-beda, sehingga mengizinkan satu IP saja akan membuat 521 muncul sesekali tergantung data center mana yang menangani pengunjung. Ambil daftar terbaru dari halaman resmi Cloudflare setiap kali Anda mengatur ulang firewall.
Apakah Error 521 sama dengan situs saya diblokir Cloudflare?
Bukan. Pemblokiran oleh Cloudflare sendiri biasanya menampilkan halaman challenge atau kode lain, bukan 521. Error 521 secara spesifik menunjuk ke penolakan di sisi origin — server Anda atau lapisan keamanan di depannya.
Setelah 521 hilang, apakah saya perlu melakukan sesuatu lagi?
Ya, dua hal: pertama, pastikan mode SSL Anda berada di Full (Strict) bila sertifikat origin sudah benar, bukan tertinggal di Flexible sebagai jalan pintas. Kedua, catat penyebab yang Anda temukan, agar bila 521 muncul lagi setelah perubahan serupa, Anda tidak mengulang diagnosis dari nol.
Kesimpulan
Cloudflare Error 521 berarti satu hal yang spesifik: server asal menolak koneksi dari Cloudflare. Dalam praktiknya, hampir semua kasus WordPress di VPS bermuara pada tiga penyebab — web server berhenti, IP Cloudflare diblokir, atau port dan mode SSL tidak cocok. Perbaiki dengan urutan diagnosis: pastikan server hidup dan mendengarkan port yang benar, uji origin secara langsung, izinkan semua rentang IP Cloudflare di firewall, lalu cocokkan mode SSL/TLS dengan kondisi origin.
Hindari dua jalan pintas yang sering merugikan: me-restart server tanpa membaca log, dan beralih permanen ke Flexible hanya karena errornya hilang. Keduanya menutupi gejala tanpa memperbaiki penyebabnya. Bila setelah semua langkah di atas 521 tetap muncul, kumpulkan Ray ID, hasil curl, dan log server, lalu libatkan penyedia hosting atau dukungan Cloudflare dengan bukti tersebut.
Untuk membedakan kasus ini dari masalah sertifikat, baca juga panduan terkait di The Last Digital tentang cara mengatasi Cloudflare Error 526, dan kunjungi beranda The Last Digital untuk panduan troubleshooting WordPress dan VPS lainnya.