Error 522 Cloudflare: Penyebab Sebenarnya Saat Server Normal

Error 522 Cloudflare muncul bila edge Cloudflare timeout saat menghubungi origin — bukan otomatis artinya server overload. Bila SSH masih hidup dan CPU idle, urutan pemeriksaan yang masuk akal: tes origin lokal dengan curl --resolve, cocokkan timestamp access log, cek firewall khusus port 443, lalu bandingkan dengan status PoP Cloudflare terdekat.

Browser menampilkan Connection timed out — Error code 522. Panel Cloudflare menyatakan Browser Working, Cloudflare Working, Host Error. Di SSH, top justru menunjukkan CPU idle hampir penuh. Kalau server terlihat sehat, siapa yang bermasalah?

Insiden 6 September 2026 di VPS aaPanel + Nginx/Apache mengajarkan satu hal: aaPanel yang CPU 100% dan Cloudflare 522 bisa terjadi hampir bersamaan, tapi jangan anggap satu masalah tanpa bukti.

Apa Arti Error 522 Cloudflare?

Menurut dokumentasi Cloudflare Error 522, timeout terjadi bila edge tidak menerima SYN+ACK dari origin dalam 19 detik saat handshake TCP, atau bila koneksi sudah terbentuk tetapi acknowledgment request tidak datang dalam 90 detik.

Bukan berarti website pasti mati total. Artinya Cloudflare tidak menyelesaikan komunikasi dengan origin dalam batas waktu itu. Diagram sederhananya:

Browser ── OK ──> Cloudflare ── TIMEOUT ──> Origin

Halaman 522 menampilkan Host Error meski CPU origin tenang — overload hanya salah satu kemungkinan di antara firewall, routing, webserver tidak listen, atau gangguan jalur edge → origin.

Studi Kasus Error 522 Cloudflare: Server Normal

Pada 6 September 2026, domain domain.com (nama disamarkan) menampilkan 522 di browser. Kondisi server saat insiden:

CPU idle ≈ 99%
load average sangat rendah
RAM available masih banyak
SSH normal

Tetapi browser: Connection timed out — Error code 522. Inilah alasan diagnosis harus per layer — bukan sekadar melihat top lalu menyimpulkan “server sehat”.

BT-Panel aaPanel Memakai CPU Hampir 100%

Sebelum fokus ke error 522 Cloudflare, ada insiden terpisah: proses BT-Panel memakai ±99–100% satu core. Server punya banyak core sehingga load keseluruhan belum overload, tapi satu core terjebak busy-loop.

Identifikasi proses:

ps -fp PID

Hasil menunjukkan:

/www/server/panel/pyenv/bin/python3 /www/server/panel/BT-Panel

BT-Panel adalah backend aaPanel — bukan Nginx atau PHP.

Mencari Pola dengan strace

timeout 10 strace -f -p PID -tt -T -o /tmp/btpanel.strace
tail -n 80 /tmp/btpanel.strace

Output berulang sangat cepat:

epoll_wait(...)
getpid()
epoll_wait(...)
getpid()

BT-Panel terjebak busy-loop pada event loop — satu core CPU terpakai penuh. Investigasi ini membuktikan pola loop, bukan bug internal spesifik yang memicunya.

Socket Internal yang Memicu Loop

Pemeriksaan file descriptor:

ls -l /proc/PID/fd/6
grep -H 'inode' /proc/net/{tcp,tcp6,udp,udp6,unix}

FD tersebut merujuk ke UNIX domain socket (SOCK_STREAM, connected). Kesimpulan aman: loop terjadi pada socket internal/event loop aaPanel — bukan bukti bahwa Cloudflare memicu CPU 100% panel.

Restart aaPanel Mengembalikan CPU Normal

Perintah bt restart sempat gagal total (Bt-Panel not running, port 7xxx tidak listen). Setelah bt start, panel hidup kembali dan CPU turun. Dokumentasi perintah bt tersedia di aaPanel Panel Related FAQ.

Apakah BT-Panel Penyebab Error 522 Cloudflare?

Tidak ada bukti demikian. Setelah BT-Panel kembali ke ±0,x% CPU dan idle server ≈99%, website masih 522, lambat, dan intermittent.

Pisahkan dua masalah ini — jangan gabungkan hanya karena waktunya berdekatan.

Langkah 1: Pastikan Origin Bisa Diakses Tanpa Cloudflare

curl -k --resolve domain.com:443:127.0.0.1 \
  -sS -o /dev/null \
  -w 'HTTP: %{http_code} | connect: %{time_connect}s | total: %{time_total}s\n' \
  https://domain.com/

Flag --resolve memaksa domain.com → 127.0.0.1 tetapi tetap memakai hostname untuk HTTP Host header dan SNI TLS. Request tidak melewati DNS publik maupun Cloudflare — ini tes origin murni.

Hasil Origin Sangat Cepat

HTTP: 200
connect:       0.000080s
ssl:           0.003761s
starttransfer: 0.005971s
total:         0.006280s

TCP lokal normal, TLS normal, Nginx merespons, total ~6 ms. Bukti kuat: origin tidak overload saat tes. Bila origin cepat tetapi Cloudflare timeout, jangan langsung menyalahkan WordPress — periksa jalur edge → origin. Konfigurasi DNS Cloudflare yang salah bisa memicu gejala serupa; lihat panduan DNS Record Cloudflare bila origin IP berubah.

Cara Membaca Timing curl

Connect cepat + SSL cepat + starttransfer 20 detik → backend/application kemungkinan lambat. Sebaliknya origin 6 ms + Cloudflare timeout → fokus ke network/firewall/edge, bukan PHP.

Access Log Nginx vs Error 522 Cloudflare

Error browser sekitar 16:56:35 UTC. Pemeriksaan access log:

grep -H '06/Sep/2026:16:56:' \
  /www/wwwlogs/domain.com-access_log \
  /www/wwwlogs/domain.com.log

Beberapa detik kemudian, IP Cloudflare (162.158.x.x, 172.71.x.x) muncul dengan respons 302/304 — artinya request Cloudflare bisa mencapai Nginx. Namun request tepat saat halaman 522 tampil tidak terlihat di log.

Interpretasi berbasis bukti: request bermasalah kemungkinan berhenti sebelum Nginx memprosesnya — bukan kepastian absolut tanpa packet capture.

Nginx error log pada timestamp yang sama: kosong. Tidak ada error aplikasi/webserver terdeteksi.

Firewall dan Error 522 Cloudflare (Port 443)

Kernel mencatat UFW BLOCK, tapi yang diblokir menuju port 8000 dan 10008 — bukan HTTPS 443. Kemungkinan scanning internet biasa.

journalctl -k \
  --since "2026-09-06 16:55:00" \
  --until "2026-09-06 16:58:00" \
  | grep 'UFW BLOCK' \
  | grep 'DPT=443'

Hasil: kosong pada periode insiden. Pemeriksaan journalctl tidak menemukan bukti UFW memblokir HTTPS 443 saat itu — bukan berarti UFW tidak pernah jadi masalah pada insiden lain.

Aturan WAF Cloudflare yang terlalu agresif pun perlu Anda cek; baca panduan konfigurasi Cloudflare WAF sebelum menambah rule baru saat troubleshooting.

Cloudflare Jakarta Partially Re-routed

Pada waktu kejadian, status Cloudflare menunjukkan Jakarta — Partially Re-routed, sementara halaman 522 menampilkan edge Singapore. PoP (Point of Presence) ialah lokasi edge Cloudflare; bila satu lokasi di-re-route, PoP lain bisa melayani trafik.

Status re-route relevan dengan insiden dan mendukung dugaan perubahan jalur jaringan — tetapi sendirian tidak membuktikan penyebab error 522 dari Cloudflare secara definitif.

Sementara itu, bila edge Singapore melayani trafik yang seharusnya lewat Jakarta, latency bisa naik tanpa ada perubahan di origin.

Mengapa Website Kembali Cepat Tanpa Ubah Server?

Kami tidak merestart server. Nginx, Apache, WordPress, dan firewall tidak kami ubah. Beberapa menit kemudian website kembali sangat cepat.

Polanya intermittent ini lebih konsisten dengan network path, routing edge, packet loss, atau transient connection issue — bukan aplikasi yang permanen rusak. Namun gejala cloudflare error 522 serupa juga muncul bila origin sempat tidak listen port 443; tes ss -lntp tetap wajib.

Akses tidak stabil kadang terasa seperti masalah SEO atau ranking, padahal sumbernya infrastruktur — bukan konten; gejala serupa dibahas di artikel tentang posisi website turun naik dari sudut SEO, bukan uptime server.

DNS Resolver Outbound Bukan Penyebab Langsung 522

Server memakai nameserver 8.8.8.8. Tes dig @8.8.8.8 domain.com A kadang 12–40 ms, kadang timeout. curl outbound juga pernah gagal: Could not resolve host setelah ~20 detik.

/etc/resolv.conf dipakai server untuk lookup outbound (Telegram aaPanel, API eksternal). Cloudflare 522 inbound terjadi di jalur Cloudflare → IP origin — Cloudflare tidak bergantung pada resolver server Anda untuk koneksi masuk itu.

DNS intermittent menjelaskan timeout Telegram aaPanel dan gagal curl outbound, bukan 522 inbound secara langsung.

Telegram Timeout di Log aaPanel

Log aaPanel mencatat httpx.ConnectTimeout dan telegram.error.TimedOut — konektivitas outbound juga terganggu. Akhirnya, data yang ada belum cukup membuktikan Telegram timeout memicu busy-loop BT-Panel.

Urutan Troubleshooting Error 522 Cloudflare

Berikut urutan pemeriksaan yang kami pakai saat edge Cloudflare timeout ke origin:

1. Jangan restart server dulu — jalankan top dan catat load.
2. Pastikan port 80/443 listen: ss -lntp.
3. Tes origin lokal: curl --resolve domain.com:443:127.0.0.1 …
4. Ukur timing: connect, ssl, starttransfer, total.
5. Cocokkan timestamp 522 browser dengan access log Nginx.
6. Periksa Nginx error log pada waktu yang sama.
7. Cek firewall khusus DPT=443 pada periode insiden.
8. Catat IP Cloudflare yang berhasil masuk log.
9. Lihat status PoP Cloudflare terdekat (mis. Jakarta, Singapore).
10. Bila tetap intermittent, jalankan MTR/traceroute origin → Cloudflare — rekomendasi resmi Cloudflare bila pemeriksaan awal tidak menemukan penyebab.

Tabel Diagnosis Error 522 Cloudflare

Mitos dan Fakta Error 522 Cloudflare

• Mitos: 522 berarti server overload. Fakta: timeout komunikasi edge-origin; overload hanya salah satu kemungkinan.
• Mitos: CPU 99% idle = website pasti normal. Fakta: network, firewall, routing, dan backend blocking tetap relevan.
• Mitos: Ada UFW BLOCK = firewall penyebab 522. Fakta: cek destination port dan timestamp — block port 8000 ≠ block 443.
• Mitos: Status Cloudflare global hijau = semua PoP normal. Fakta: status per lokasi bisa berbeda.
• Mitos: Restart server solusi pertama. Fakta: restart menghilangkan bukti yang dibutuhkan investigasi.

Ringkasan Investigasi Error 522 Cloudflare

aaPanel — terbukti: BT-Panel busy-loop memakai hampir satu core; bt start menghilangkan gejala. Pemicu internal belum teridentifikasi.

Cloudflare 522 — terbukti: origin lokal ~6 ms; CPU/RAM normal; tidak ada UFW block 443 pada periode diperiksa; Nginx error log kosong; request Cloudflare kembali masuk log beberapa detik kemudian; gangguan intermittent; Jakarta Partially Re-routed pada periode yang sama.

Kesimpulan paling aman: bukti lebih kuat mengarah ke gangguan sementara jalur Cloudflare → origin/network daripada WordPress, Nginx, Apache, atau beban CPU. Tanpa packet capture/MTR tepat saat insiden, Cloudflare tidak bisa dibuktikan 100% sebagai satu-satunya penyebab.

Pelajaran dari kasus ini: Error Cloudflare tidak boleh didiagnosis hanya dengan top. Cocokkan timestamp, bypass Cloudflare untuk tes origin, baca access log, periksa firewall pada port yang benar, bandingkan status PoP. Persempit masalah berdasarkan bukti — bukan restart lalu menebak.

Bila stack WordPress ikut diselidiki setelah origin terbukti sehat, error permission pasca migrasi pun punya pola diagnosis berbeda — lihat panduan error WordPress pasca migrasi. Untuk kebutuhan website company profile dengan uptime stabil, tim CodeF sering membantu klien memisahkan masalah hosting, DNS, dan aplikasi sebelum upgrade server yang tidak perlu. Diskusi teknis lanjut via CodeF.