Situs di Belakang Cloudflare Timeout Massal, Masalah di Origin atau di Jalur Edge?

Tiket masuk hampir bersamaan. Sebagian pengunjung dapat error 522, sebagian cuma melihat loading lama lalu timeout, dan sebagian lagi bisa membuka situs dengan normal. Kamu login ke server: CPU santai, RAM longgar, Nginx dan PHP-FPM aktif. Refleksnya biasanya restart service atau mengubah config, padahal pertanyaan yang lebih berguna adalah ini: request pengunjung sebenarnya berhenti di titik mana? Untuk situs yang di-proxy Cloudflare, jawabannya tidak bisa ditebak dari kondisi server saja. Satu request melewati dua jalur yang terpisah, dan masing-masing bisa gagal tanpa jalur lainnya ikut bermasalah.

Satu request, dua koneksi TCP yang terpisah

Kalau record DNS dalam mode proxied, resolver pengunjung tidak menerima IP origin. Yang didapat adalah IP anycast milik Cloudflare. Anycast artinya satu IP yang sama diumumkan lewat BGP (Border Gateway Protocol, protokol yang dipakai antar-jaringan untuk saling memberi tahu rute) dari banyak lokasi sekaligus. Router di ISP pengunjung memilih rute terbaik menurut BGP, dan paket akhirnya mendarat di salah satu datacenter edge. Kalau kamu ingin pembahasan lebih dalam soal pemilihan jalur anycast, ada di artikel Global Edge Engineering: BGP Anycast Routing, Path Selection, and TCP BBR vs Cubic Tuning. Urutan kejadiannya kira-kira seperti ini:

Browser mengirim SYN ke IP anycast. Edge membalas SYN-ACK, browser mengirim ACK, dan koneksi TCP pertama terbentuk.
Handshake TLS terjadi dan berakhir di edge, bukan di server kamu.
Edge membaca request HTTP, mengecek cache, lalu kalau perlu membuka koneksi TCP kedua ke IP origin (atau memakai ulang koneksi yang sudah ada).
Origin memproses request dan membalas ke edge. Edge meneruskan balasan itu ke browser lewat koneksi pertama.

Koneksi pertama dan kedua tidak berbagi state. Kalau koneksi kedua gagal, edge masih punya koneksi sehat ke browser, jadi edge bisa menyusun halaman error sendiri. Kalau koneksi pertama yang gagal, tidak ada pihak yang sempat membuat halaman error. Browser hanya menunggu sampai menyerah. Perbedaan inilah yang paling berguna untuk diagnosis awal.

Membaca error: siapa yang sebenarnya bicara

Kode 52x adalah kode buatan Cloudflare, bukan dari web server kamu. Halaman error-nya biasanya menampilkan tiga status, yaitu Browser, Cloudflare, dan Host, lengkap dengan Ray ID dan lokasi datacenter. Kalau status Host yang ditandai bermasalah, edge sudah berhasil dijangkau dan kegagalannya ada di koneksi kedua.

Gejala yang dilihat pengunjung	Lokasi masalah yang paling mungkin
521	Origin menolak koneksi: service mati, port tertutup, atau firewall mengirim RST
522	SYN dari edge ke origin tidak dibalas: firewall drop, server overload, atau jalur edge ke origin terganggu
524	TCP ke origin terbentuk, tapi respons HTTP tidak datang tepat waktu: query lambat, worker penuh
502/504 dengan halaman bawaan Nginx atau Apache	Reverse proxy di origin tidak bisa menjangkau upstream-nya, misalnya PHP-FPM
Timeout tanpa halaman Cloudflare, hanya di ISP atau wilayah tertentu	Jalur pengunjung ke edge bermasalah, bisa karena routing

Baris terakhir adalah yang paling sering disalahpahami. Pengunjung melihat ERR_CONNECTION_TIMED_OUT, lalu menyimpulkan server mati. Padahal paket mereka mungkin tidak pernah sampai ke datacenter Cloudflare mana pun, apalagi ke server kamu. Perlu dicatat, 522 juga tidak otomatis berarti origin bermasalah. Kalau jalur dari edge ke jaringan origin ikut terdampak masalah routing, SYN dari edge bisa hilang di tengah jalan walaupun server kamu sehat. Karena itu, kode error hanya memberi petunjuk awal. Bukti yang lebih kuat ada di origin.

Bagaimana route leak BGP memutus jalur ke edge

BGP pada dasarnya berjalan atas dasar kepercayaan. Setiap jaringan mengumumkan prefix (blok IP) yang bisa dijangkau lewat dirinya, dan tetangganya cenderung percaya. Route leak terjadi saat rute diumumkan melewati cakupan yang seharusnya. Contohnya, rute yang mestinya hanya untuk peer atau hanya untuk internal ikut diteruskan ke transit provider, lalu menyebar lebih jauh. Penyebabnya bisa kesalahan konfigurasi routing policy atau skrip otomasi yang tanpa sengaja menghapus export filter. Masalahnya makin besar karena aturan longest-prefix-match. Router selalu memilih rute yang paling spesifik. Kalau yang bocor adalah prefix yang lebih spesifik daripada rute agregat yang normal, router di seluruh internet akan lebih memilih rute bocor itu tanpa perlu dibujuk. Trafik dari banyak wilayah tiba-tiba ditarik ke satu titik, misalnya satu datacenter regional yang kapasitas link-nya tidak dirancang untuk beban sebesar itu. Dari sisi paket, efeknya seperti ini. Link di titik tersebut jenuh dan antrean di router penuh, sehingga paket mulai di-drop. Filter keamanan di jaringan internal juga bisa membuang trafik yang datang dari arah tidak terduga. Server aplikasi di belakangnya tetap sehat, tapi pengunjung tetap tidak bisa menjangkaunya. Di sisi klien, SYN yang hilang tidak langsung jadi error. Kernel mengirim ulang SYN dengan jeda yang terus membesar, mulai dari sekitar satu detik lalu berlipat dua. Di Linux, jumlah percobaannya diatur oleh net.ipv4.tcp_syn_retries. Browser biasanya punya timeout sendiri dan menyerah lebih dulu. Karena loss-nya sering parsial, sebagian SYN lolos dan sebagian tidak. Hasilnya adalah pola khas: kadang bisa, kadang tidak, kadang lambat sekali. Koneksi yang sudah terbentuk pun bisa tersendat di tengah handshake TLS atau saat transfer data, karena setiap segmen yang hilang harus menunggu retransmisi. Satu hal yang membuat insiden seperti ini lama ditangani: jalur manajemen dan telemetri milik operator jaringan bisa ikut melewati link yang sama-sama macet. Untuk pembahasan kenapa route leak terlihat persis seperti hosting down, lihat Why a BGP Route Leak Looks Like Your Host's Outage But Isn't.

Cek dari origin: apakah request masih sampai

Ini langkah paling murah dan paling meyakinkan. Kalau masalahnya di origin, request dari edge biasanya tetap datang lalu gagal di server, misalnya antre di worker atau timeout di upstream. Kalau masalahnya di jalur menuju edge, jumlah request yang masuk ke origin akan turun drastis, sementara server terlihat lebih santai dari biasanya. Cara pertama adalah melihat access log web server. Perhatikan apakah baris baru masih terus bertambah dan apakah jumlahnya per menit turun dibanding biasanya. Kalau log format kamu mencatat header CF-Connecting-IP, kamu juga bisa melihat apakah pengunjung dari wilayah tertentu hilang sama sekali. Lokasi file log dan formatnya tergantung web server dan control panel yang dipakai. Cara kedua lebih rendah lagi levelnya. Lihat apakah SYN masih masuk ke port 443:

BASH

sudo tcpdump -ni any -c 50 'dst port 443 and tcp[tcpflags] & tcp-syn != 0'

Perintah ini read-only dan akan berhenti setelah 50 paket. Kalau SYN dari rentang IP Cloudflare masih masuk dan server membalasnya, berarti koneksi kedua masih hidup. Kalau tidak ada SYN sama sekali, padahal biasanya ramai, kemungkinan besar masalahnya ada sebelum origin. Cara ketiga adalah melewati edge dan menguji origin secara langsung dari mesin lain, misalnya VPS di jaringan berbeda:

BASH

curl -s -o /dev/null --resolve 'example.com:443:198.51.100.20' https://example.com/ -w 'connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} code=%{http_code}
'

Ganti nama domain dan IP dengan milik kamu. Flag --resolve memaksa curl memakai IP origin tanpa mengubah SNI dan header Host. Ada dua catatan. Pertama, kalau firewall origin hanya mengizinkan IP Cloudflare, tes ini memang akan gagal dari luar, dan itu wajar. Kedua, kalau origin memakai sertifikat Origin CA, verifikasi TLS di curl akan gagal. Untuk diagnosis sementara kamu boleh menambahkan -k, asalkan paham bahwa verifikasi sertifikat sedang dilewati. Kalau origin merespons cepat dari luar sementara pengunjung timeout, server kamu bukan masalahnya.

Cek dari sisi pengunjung: edge mana yang mereka temui

Minta pengunjung yang terdampak membuka path berikut di domain kamu, atau jalankan sendiri dari jaringan yang bermasalah:

BASH

curl -s https://example.com/cdn-cgi/trace

Output-nya berupa baris key=value. Field colo berisi kode tiga huruf lokasi datacenter yang melayani request, dan field ip menunjukkan IP publik klien. Kalau perintah ini juga timeout, pengunjung memang tidak bisa menjangkau edge, jadi tidak ada yang bisa diperbaiki di origin. Kalau berhasil tapi colo menunjukkan lokasi yang jauh dan tidak biasa, misalnya pengunjung dari Indonesia mendarat di benua lain, itu tanda routing sedang tidak normal. Bandingkan hasilnya dari beberapa ISP. Pola yang hanya muncul di ISP atau wilayah tertentu hampir selalu mengarah ke masalah jalur, bukan masalah server. Dari sisi support, langkah ini juga membantu menjelaskan ke customer dengan bukti, bukan dugaan. Kalimat seperti log server tidak menerima request dari jaringan Anda, dan datacenter edge yang Anda jangkau tidak sesuai lokasi Anda jauh lebih jelas daripada sekadar bilang server kami normal. Setelah itu, cek halaman status resmi provider CDN untuk melihat apakah ada insiden routing yang sedang diumumkan. Sebagai aturan praktis, sebelum restart atau mengubah config apa pun, cari tahu dulu apakah request masih sampai ke origin. Kalau masih sampai dan gagal di sana, telusuri worker, upstream, dan database. Kalau tidak sampai, restart hanya menambah downtime dan menghapus jejak yang sebenarnya kamu butuhkan. Yang perlu dilakukan adalah mengumpulkan data dari beberapa jaringan, mencatat colo dan Ray ID, lalu menunggu atau mengeskalasi ke pihak yang memegang jalurnya.