Cara Memperbaiki Cloudflare Error 520: Panduan Diagnostik dan Resolusi Lengkap

Cloudflare Error 520 adalah kode status HTTP yang dikembalikan ketika jaringan edge Cloudflare menerima respons kosong, tidak terduga, atau tidak dapat diinterpretasikan dari server asal Anda. Tidak seperti 502 atau 504, yang menunjukkan timeout gateway atau bad gateway, 520 adalah tangkapan semua Cloudflare untuk respons yang berada di luar spesifikasi HTTP yang dikenali — artinya server asal secara teknis merespons, tetapi apa yang dikirimnya kembali tidak valid, terpotong, atau cacat secara struktural.

Dari sudut pandang praktis, Error 520 berarti koneksi TCP antara Cloudflare dan server asal Anda telah terbentuk, tetapi handshake lapisan HTTP gagal. Pengguna melihat halaman error bermerek Cloudflare dengan pesan "Web server is returning an unknown error" — dan situs Anda secara efektif offline bagi mereka.

Apa yang Memicu Error 520: Penjelasan Penyebab Utama

Memahami mode kegagalan yang tepat sangat penting sebelum menyentuh konfigurasi apa pun. Error 520 bukan masalah tunggal — ini adalah kelas gejala. Penyebab berikut adalah yang paling umum, diurutkan berdasarkan frekuensi di lingkungan produksi.

Server asal mengembalikan badan respons kosong tanpa baris status HTTP. Ini adalah pemicu paling sering. Apache atau Nginx mungkin crash di tengah respons, membuat Cloudflare memegang socket TCP terbuka tanpa data yang masuk.

Firewall atau perangkat lunak keamanan memblokir rentang IP Cloudflare. Alat seperti ModSecurity, Fail2Ban, CSF (ConfigServer Security & Firewall), atau plugin lapisan aplikasi seperti Wordfence dapat secara diam-diam membuang paket dari IP egress Cloudflare, menyebabkan koneksi direset tanpa respons HTTP yang tepat.

Ketidakcocokan handshake SSL/TLS antara Cloudflare dan asal. Jika Cloudflare diatur ke mode "Full (Strict)" tetapi server asal Anda memiliki sertifikat yang kedaluwarsa, self-signed, atau salah dikonfigurasi, negosiasi TLS gagal sebelum data HTTP apa pun dipertukarkan.

Header respons HTTP yang cacat atau terlalu besar. Cloudflare memberlakukan batas keras sebesar 32 KB pada header respons. Header tunggal atau kumpulan header gabungan yang melebihi batas ini menyebabkan 520. Ini adalah kasus tepi yang umum dengan aplikasi PHP yang ditulis dengan buruk yang membuang data sesi besar atau output debug ke dalam header.

Crash proses server asal atau kill OOM (Out-of-Memory). Jika proses worker server web (misalnya, worker Nginx atau pool PHP-FPM) dimatikan oleh OOM killer Linux di tengah permintaan, koneksi terputus secara tiba-tiba.

Pengecualian tingkat aplikasi sebelum header dikirim. Error fatal PHP, pengecualian Python yang tidak ditangani, atau crash Node.js yang terjadi sebelum res.writeHead() dipanggil menghasilkan respons kosong yang tidak dapat diurai oleh Cloudflare.

Koneksi direset oleh asal (TCP RST). Server asal secara aktif mereset koneksi TCP, yang diinterpretasikan oleh Cloudflare sebagai respons yang tidak diketahui.

Error 520 vs. Error Cloudflare 5xx Lainnya

Membedakan 520 dari error Cloudflare serupa mencegah upaya diagnostik yang terbuang sia-sia.

Jika Anda melihat 521, proses server web Anda tidak berjalan. Jika Anda melihat 524, aplikasi Anda berjalan tetapi terlalu lambat. Jika Anda melihat 520, server berjalan dan merespons — tetapi apa yang dikirimnya kembali rusak.

Perbaikan Langkah demi Langkah untuk Error 520

Langkah 1: Verifikasi Kesehatan dan Konektivitas Server Asal

Sebelum menyentuh Cloudflare, konfirmasi server asal masih aktif dan daemon server web sedang berjalan.

Periksa apakah proses server web aktif:

# For Nginx
sudo systemctl status nginx

# For Apache
sudo systemctl status apache2

# For LiteSpeed
sudo systemctl status lsws

Uji konektivitas langsung ke IP asal, melewati proxy Cloudflare. Ambil IP asal Anda dari dashboard DNS Cloudflare, lalu uji secara langsung:

curl -I --resolve yourdomain.com:80:YOUR_ORIGIN_IP http://yourdomain.com/
curl -I --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/

Jika curl mengembalikan status HTTP yang valid (200, 301, dll.), server asal berfungsi dan masalahnya ada di lapisan komunikasi Cloudflare-ke-asal. Jika curl mengembalikan balasan kosong atau reset koneksi, masalahnya ada di sisi asal.

Periksa tekanan sumber daya sistem:

# Memory usage
free -h

# CPU load
uptime

# Check for OOM kills in the last boot
dmesg | grep -i "oom|killed process"

# Check for PHP-FPM pool exhaustion
sudo systemctl status php8.1-fpm

Langkah 2: Periksa Log Error Server Asal

Log server asal adalah sumber diagnostik paling berharga. Jangan lewati langkah ini.

Untuk Nginx:

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/nginx/access.log

Untuk Apache:

sudo tail -n 100 /var/log/apache2/error.log
sudo tail -n 100 /var/log/apache2/access.log

Cari secara khusus:

• Entri level [crit] atau [emerg]

upstream prematurely closed connection (Nginx + PHP-FPM)
Premature end of script headers (Apache + CGI/PHP)
worker_connections are not enough (batas worker Nginx tercapai)
Error fatal PHP yang dicatat ke log error server web

Referensi silang timestamp log dengan saat error 520 terjadi. Dashboard Cloudflare di bawah Analytics > Traffic menampilkan timestamp lonjakan 520 yang dapat Anda gunakan untuk korelasi.
Langkah 3: Whitelist Rentang IP Cloudflare di Firewall Anda
Jika firewall memblokir IP egress Cloudflare, koneksi akan direset secara diam-diam. Cloudflare mempublikasikan rentang IP saat ini di https://www.cloudflare.com/ips/.
Untuk UFW (Ubuntu/Debian):
# Download Cloudflare IPv4 ranges and whitelist them
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

# Repeat for IPv6
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 CSF (ConfigServer Firewall):
Tambahkan rentang IP Cloudflare ke /etc/csf/csf.allow, lalu restart CSF:
sudo csf -r
Untuk ModSecurity: Jika Anda mencurigai ModSecurity sebagai penyebabnya, periksa log auditnya:
sudo tail -n 200 /var/log/modsec_audit.log
Cari kecocokan aturan terhadap alamat IP Cloudflare. Anda dapat memasukkan IP Cloudflare ke whitelist dalam konfigurasi ModSecurity atau mengatur direktif SecRemoteRules untuk mengecualikannya.
Catatan penting: Jangan pernah menonaktifkan firewall atau ModSecurity secara permanen. Whitelist hanya rentang IP Cloudflare yang dipublikasikan, dan aktifkan kembali semua kontrol keamanan segera setelah pengujian.
Langkah 4: Audit dan Perbaiki Header Respons HTTP
Header yang cacat atau terlalu besar adalah penyebab error 520 yang sering diabaikan. Gunakan curl dengan output verbose untuk memeriksa dengan tepat apa yang dikirim asal Anda:
curl -v --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/ 2>&1 | head -80
Perhatikan:

Header dengan karakter non-ASCII atau karakter kontrol
Header Set-Cookie dengan nilai yang sangat panjang (umum dalam miskonfigurasi sesi PHP)
Header Content-Type yang hilang atau cacat
Header Content-Length duplikat dengan nilai yang bertentangan

Jika Anda menjalankan aplikasi PHP, periksa php.ini untuk pengaturan output_buffering. Buffer output yang dinonaktifkan dikombinasikan dengan error fatal di tengah respons dapat menyebabkan transmisi header parsial.
Khusus untuk situs WordPress: Plugin yang menyuntikkan data dalam jumlah besar ke header HTTP (beberapa plugin keamanan atau caching melakukan ini) dapat mendorong ukuran header melampaui batas 32 KB Cloudflare. Audit plugin aktif dan uji dalam mode aman.
Langkah 5: Validasi Konfigurasi SSL/TLS Cloudflare
Ketidakcocokan SSL antara Cloudflare dan asal adalah sumber umum kegagalan kelas 520 yang menyamar sebagai error tidak diketahui generik.
Navigasi ke Cloudflare Dashboard > SSL/TLS > Overview dan verifikasi mode enkripsi:



Mode SSL Cloudflare
Persyaratan Asal
Direkomendasikan Untuk








—
—
—








Off
Tidak ada SSL di asal
Tidak pernah direkomendasikan








Flexible
Tidak perlu SSL di asal
Hanya untuk pengaturan lama; risiko keamanan








Full
Sertifikat SSL apa pun di asal (termasuk self-signed)
Lingkungan pengembangan








Full (Strict)
Sertifikat SSL yang valid dan tepercaya di asal
Semua situs produksi





Jika asal Anda menggunakan sertifikat self-signed dan Cloudflare diatur ke Full (Strict), handshake TLS akan gagal. Instal sertifikat yang valid di asal (sertifikat Let’s Encrypt gratis berfungsi) atau beralih ke mode Full sementara saat Anda memperbaiki sertifikat.
Jika Anda memerlukan sertifikat yang dipercaya dengan benar untuk server asal Anda, SSL Certificates dari CA tepercaya sepenuhnya menghilangkan masalah sertifikat self-signed dan kompatibel dengan mode Full (Strict) Cloudflare.
Langkah 6: Jeda Proxy Cloudflare untuk Diagnosis Terarah
Menghapus Cloudflare sementara dari jalur permintaan mengisolasi apakah masalah ada di konfigurasi Cloudflare atau di server asal.
Metode 1: Nonaktifkan proxy pada rekaman DNS tertentu
Di dashboard DNS Cloudflare, klik ikon awan oranye di sebelah rekaman A atau CNAME Anda untuk membuatnya menjadi abu-abu. Ini melewati proxy Cloudflare sambil tetap menjaga resolusi DNS melalui Cloudflare. Propagasi DNS membutuhkan waktu hingga 5 menit.
Metode 2: Jeda Cloudflare secara global untuk domain
Navigasi ke Cloudflare Dashboard > Overview > Advanced Actions > Pause Cloudflare on Site. Ini merutekan semua lalu lintas langsung ke asal Anda.
Setelah dijeda, uji situs Anda. Jika dimuat dengan benar, masalahnya ada di konfigurasi Cloudflare. Jika masih gagal, masalahnya ada di server asal terlepas dari Cloudflare.
Aktifkan kembali Cloudflare segera setelah pengujian — Cloudflare yang dijeda berarti situs Anda kehilangan perlindungan DDoS, caching CDN, dan cakupan WAF.
Langkah 7: Periksa Akurasi Rekaman DNS
Rekaman DNS A yang salah dikonfigurasi yang menunjuk ke alamat IP yang salah atau usang menyebabkan Cloudflare meneruskan lalu lintas ke server yang salah, yang akan mengembalikan respons yang tidak terduga.
Di dashboard DNS Cloudflare:

Verifikasi bahwa rekaman A untuk domain root Anda (@) menunjuk ke IP server asal Anda saat ini
Verifikasi bahwa CNAME untuk www diselesaikan dengan benar
Jika Anda baru saja memigrasikan server, konfirmasi IP lama tidak lagi direferensikan di mana pun

Konfirmasi IP mana yang sebenarnya dikirimkan lalu lintas oleh Cloudflare:
dig +short yourdomain.com @1.1.1.1
Bandingkan ini dengan IP server asal Anda yang sebenarnya. Jika berbeda, perbarui rekaman DNS di Cloudflare.
Langkah 8: Skalakan Sumber Daya Server Asal
Jika server asal Anda secara konsisten berada di bawah beban tinggi, error 520 akan terjadi secara intermiten selama lonjakan lalu lintas saat proses worker kelelahan dan koneksi terputus.
Diagnosis kelelahan sumber daya:
# Check Nginx worker connections
sudo nginx -T | grep worker_connections

# Check PHP-FPM pool limits
cat /etc/php/8.1/fpm/pool.d/www.conf | grep -E "pm.|max_children"

# Monitor real-time connections
ss -s
Opsi penyetelan tanpa peningkatan perangkat keras:

Tingkatkan worker_connections di /etc/nginx/nginx.conf

• Tingkatkan pm.max_children dalam konfigurasi pool PHP-FPM
• Aktifkan direktif keepalive Nginx untuk koneksi upstream
• Implementasikan object caching (Redis atau Memcached) untuk mengurangi tekanan database
• Aktifkan aturan halaman Cache Everything Cloudflare untuk memindahkan pengiriman aset statis

Untuk aplikasi yang telah melampaui infrastruktur bersama, migrasi ke lingkungan VPS Hosting memberi Anda kontrol penuh atas batas proses worker, alokasi memori, dan penyetelan TCP tingkat kernel — yang tidak tersedia di paket bersama.

Jika aplikasi Anda menangani beban kerja intensif komputasi (inferensi ML, pemrosesan video, operasi dataset besar) yang menyebabkan crash worker intermiten, GPU Hosting memindahkan tugas-tugas tersebut dari proses server web Anda, menghilangkan sumber umum crash di tengah respons.

Langkah 9: Tinjau Aturan Firewall dan Keamanan Cloudflare

Fitur keamanan Cloudflare sendiri terkadang dapat mengganggu komunikasi asal yang sah, terutama jika Aturan Firewall kustom atau aturan WAF salah dikonfigurasi.

Periksa Cloudflare Dashboard > Security > WAF > Custom Rules untuk aturan apa pun yang mungkin mencegat permintaan sebelum mencapai asal. Tinjau juga Security > Settings > Browser Integrity Check — dalam kasus yang jarang terjadi, ini dapat menyebabkan perilaku tak terduga dengan agen pengguna tertentu atau permintaan otomatis.

Tinjau log Security > Events untuk melihat apakah Cloudflare memblokir atau menantang permintaan yang seharusnya mencapai asal Anda.

Langkah 10: Eskalasi ke Penyedia Hosting atau Dukungan Cloudflare Anda

Jika semua langkah di atas telah habis tanpa resolusi, eskalasi dengan informasi yang tepat.

Saat menghubungi penyedia hosting Anda, berikan:

• Timestamp tepat dari kejadian 520 (dari Cloudflare Analytics)
• Kutipan relevan dari log error server web Anda
• Output dari curl -v terhadap IP asal Anda
• Metrik penggunaan sumber daya saat ini (CPU, RAM, jumlah koneksi)

Penyedia yang menjalankan infrastruktur terkelola di Dedicated Servers dapat melakukan diagnostik tingkat kernel, tangkapan paket (tcpdump), dan inspeksi tingkat socket yang tidak tersedia di lingkungan bersama.

Saat menghubungi Dukungan Cloudflare, sertakan:

• Ray ID Anda dari halaman error 520 (terlihat dalam HTML error Cloudflare)
• File HAR yang diambil dari Chrome DevTools selama error
• Mode SSL/TLS Anda saat ini dan Aturan Firewall kustom apa pun

Ray ID sangat penting — ini memungkinkan insinyur Cloudflare menarik entri log node edge yang tepat untuk permintaan Anda yang gagal.

Diagnostik Lanjutan: Menangkap Kegagalan Tepat dengan tcpdump

Untuk error 520 yang persisten atau intermiten yang menolak pemecahan masalah standar, tangkapan paket di server asal mengungkapkan dengan tepat apa yang terjadi di lapisan TCP/HTTP saat Cloudflare terhubung.

# Capture traffic from Cloudflare IPs on port 443
sudo tcpdump -i eth0 -w /tmp/cloudflare_capture.pcap 'src net 103.21.244.0/22 or src net 103.22.200.0/22 or src net 103.31.4.0/22 or src net 104.16.0.0/13 or src net 104.24.0.0/14' and port 443

Buka file .pcap yang dihasilkan di Wireshark dan filter untuk tcp.flags.reset == 1 untuk mengidentifikasi paket TCP RST, yang menunjukkan asal secara aktif mereset koneksi. Filter untuk http untuk memeriksa respons HTTP parsial apa pun yang dikirim.

Tingkat analisis ini secara definitif mengidentifikasi apakah 520 disebabkan oleh RST firewall, crash aplikasi di tengah respons, atau kegagalan TLS.

Mencegah Error 520: Tindakan Proaktif

Pemecahan masalah reaktif itu mahal. Tindakan-tindakan ini secara signifikan mengurangi probabilitas terjadinya 520.

Implementasikan Health Check Cloudflare. Di bawah Traffic > Health Checks, konfigurasikan health check terhadap asal Anda. Cloudflare akan memberi tahu Anda sebelum pengguna mulai melihat error 520.

Aktifkan fitur Always Online Cloudflare (di bawah Caching > Configuration). Meskipun tidak memperbaiki masalah yang mendasarinya, fitur ini menyajikan versi cache halaman Anda kepada pengguna selama pemadaman asal, mencegah pemadaman layanan total.

Siapkan pemantauan server asal dengan alat seperti UptimeRobot, Pingdom, atau solusi yang di-host sendiri seperti Uptime Kuma. Pantau IP asal secara langsung (bukan domain yang diproksikan Cloudflare) untuk mendeteksi kegagalan asal secara independen dari Cloudflare.

Otomatiskan whitelisting IP Cloudflare. Rentang IP Cloudflare kadang-kadang berubah. Gunakan cron job untuk menyegarkan whitelist firewall Anda:

# /etc/cron.weekly/update-cloudflare-ips
#!/bin/bash
CF_IPS=$(curl -s https://www.cloudflare.com/ips-v4)
# Add logic to update UFW/CSF/iptables rules

Gunakan Authenticated Origin Pulls Cloudflare. Fitur ini mengonfigurasi asal Anda untuk hanya menerima koneksi HTTPS yang menyajikan sertifikat klien Cloudflare, memblokir permintaan langsung-ke-asal yang melewati proxy. Ini juga menghilangkan kelas error 520 yang disebabkan oleh lalu lintas non-Cloudflare yang mengenai asal Anda dan memicu respons perangkat lunak keamanan.

Untuk tim yang mengelola beberapa domain dan aplikasi web, VPS dengan cPanel menyediakan akses log terpusat, manajemen firewall, dan manajemen sertifikat SSL di semua domain yang di-host — secara signifikan mengurangi waktu-ke-diagnosis untuk kejadian 520.

Matriks Keputusan: Mendiagnosis Skenario 520 Spesifik Anda

Daftar Periksa Poin Penting Teknis

Sebelum eskalasi ke dukungan, konfirmasi Anda telah menyelesaikan masing-masing hal berikut:

• Memverifikasi proses server web asal sedang berjalan (systemctl status)
• Menguji konektivitas asal langsung dengan curl -v --resolve melewati Cloudflare
• Meninjau log error asal untuk timestamp tepat dari kejadian 520
• Mengonfirmasi rentang IP Cloudflare di-whitelist di semua firewall aktif (UFW, CSF, iptables, ModSecurity)
• Memvalidasi bahwa header respons di bawah 32 KB dan tidak mengandung nilai yang cacat
• Mengonfirmasi mode SSL/TLS Cloudflare sesuai dengan jenis sertifikat asal
• Memverifikasi rekaman DNS A menunjuk ke IP asal yang benar dan saat ini
• Memeriksa memori sistem dan CPU untuk kill OOM atau kelelahan sumber daya
• Menangkap Ray ID dari halaman error 520 untuk eskalasi dukungan Cloudflare
• Meninjau log Security Events Cloudflare untuk interferensi aturan WAF

Pertanyaan yang Sering Diajukan

Apa perbedaan antara Cloudflare Error 520 dan Error 521?

Error 521 berarti Cloudflare berhasil mencapai IP server asal Anda tetapi proses server web menolak koneksi TCP — biasanya karena Nginx atau Apache tidak berjalan. Error 520 berarti koneksi TCP terbentuk tetapi respons HTTP kosong, terpotong, atau cacat. Jika Anda melihat 521, mulai server web Anda. Jika Anda melihat 520, server berjalan tetapi mengirimkan respons yang rusak.

Bisakah Error 520 disebabkan oleh Cloudflare sendiri, bukan server asal?

Jarang, tetapi ya. Masalah node edge Cloudflare dapat menyebabkan error 520 yang tidak dapat direproduksi saat mengakses asal secara langsung. Periksa cloudflarestatus.com untuk insiden aktif. Jika asal merespons dengan benar melalui curl langsung dan halaman status Cloudflare menampilkan insiden aktif, tunggu Cloudflare menyelesaikannya daripada membuat perubahan pada server Anda.

Mengapa Error 520 hanya terjadi secara intermiten dan tidak konsisten?

Error 520 intermiten hampir selalu menunjukkan kelelahan sumber daya — pool worker PHP-FPM kehabisan child yang tersedia, Nginx mencapai batas worker_connections, atau OOM killer Linux mengakhiri proses di bawah tekanan memori. Kondisi ini terjadi selama lonjakan beban dan teratasi saat lalu lintas turun, menciptakan pola intermiten. Error 520 yang konsisten menunjuk ke masalah konfigurasi.

Apakah menjeda Cloudflare memperbaiki Error 520?

Menjeda Cloudflare menghapusnya dari jalur permintaan, jadi jika situs Anda berfungsi setelah dijeda, masalahnya ada di konfigurasi Cloudflare (mode SSL, aturan WAF, rekaman DNS). Jika situs Anda masih gagal setelah dijeda, masalahnya ada di server asal. Menjeda Cloudflare adalah langkah diagnostik, bukan perbaikan — ini menghapus perlindungan DDoS dan caching CDN saat aktif.

Bagaimana cara menemukan Ray ID untuk melaporkan error 520 ke Cloudflare?

Ray ID ditampilkan di bagian bawah halaman error 520 Cloudflare yang ditampilkan kepada pengguna. Tampilannya seperti string heksadesimal 16 karakter (misalnya, 7a3f2b9c1d4e8f0a). Anda juga dapat menemukannya di header respons CF-Ray, terlihat di Chrome DevTools di bawah tab Network. Selalu sertakan ID ini saat membuka tiket dukungan Cloudflare — ini memungkinkan insinyur Cloudflare mengambil entri log edge yang tepat untuk permintaan Anda yang gagal.