Server Load Balancer:Kode status error CLB

Lima pemeriksaan cepat

Sebelum melakukan troubleshooting kode status tertentu, periksa lima konfigurasi berikut secara berurutan karena merupakan penyebab kegagalan CLB yang paling umum.

1. Jalankan tool diagnosis instance CLB. Pada halaman instance CLB, temukan instance target dan klik Start Diagnostics di kolom Instance Diagnostics. Tool ini memeriksa masalah umum pada konfigurasi instance, listener, dan layanan backend.

2. Verifikasi bahwa Health Check Status untuk listener berstatus Healthy. Pada halaman listener instance, periksa Health Check Status kelompok server backend. Jika statusnya abnormal, lihat Health Check FAQ.

3. Pastikan instance ECS backend tidak memblokir blok CIDR 100.64.0.0/10. Ini adalah blok CIDR internal yang dicadangkan oleh Alibaba Cloud untuk komunikasi antara CLB dan server backend serta tidak menimbulkan risiko keamanan. Anda tidak perlu menambahkan aturan allow untuk blok CIDR ini di grup keamanan instance ECS. Namun, jika aturan iptables atau perangkat lunak keamanan pihak ketiga pada instance ECS backend memblokir blok CIDR ini, CLB tidak dapat mengakses backend, yang dapat memicu error 502, 504, atau error lainnya.

4. Verifikasi bahwa port yang dikonfigurasi untuk server backend dalam kelompok server sesuai dengan port tempat layanan backend benar-benar mendengarkan (listening). Port yang dikonfigurasi untuk setiap server backend dalam kelompok server CLB harus sesuai dengan port tempat proses layanan sedang listening. Misalnya, jika Anda mengonfigurasi port 8080 dalam kelompok server tetapi layanan backend sedang listening pada port 80, koneksi akan gagal. Anda dapat menjalankan ss -tlnp | grep ':<port> ' atau netstat -tlnp | grep ':<port> ' pada instance ECS backend untuk memeriksa port listening.

5. Untuk listener HTTPS: Verifikasi bahwa sertifikat belum kedaluwarsa dan nama domain yang terikat pada sertifikat sesuai dengan domain akses. Pada halaman detail listener, periksa sertifikat yang terikat dan tanggal kedaluwarsanya. Sertifikat yang kedaluwarsa atau ketidaksesuaian domain dapat menyebabkan kegagalan handshake SSL atau mengembalikan kode status error.

502 (Bad Gateway)

Error ini terjadi ketika listener HTTP atau HTTPS menerima permintaan dari client tetapi CLB tidak dapat meneruskannya ke server backend atau menerima respons.

Pendekatan troubleshooting: Periksa nilai bidang upstream_status dalam log akses dan tentukan langkah troubleshooting berikutnya berdasarkan nilainya.

• Jika upstream_status bernilai 502: Layanan backend itu sendiri mengembalikan error 502, dan CLB meneruskannya ke client. Lakukan investigasi terhadap log Nginx, gerbang, atau aplikasi backend Anda.

• Jika upstream_status bernilai lain (seperti 504, 444, atau 500): status yang dikembalikan oleh CLB dalam log akses tidak sesuai dengan upstream_status, yang menunjukkan bahwa CLB mengonversi kode status tersebut. Lakukan investigasi mengapa layanan backend mengembalikan kode status tersebut berdasarkan nilai aktual upstream_status (periksa log Nginx, gerbang, atau aplikasi backend).

• Jika upstream_status bernilai - atau kosong: CLB tidak menerima respons dari backend, yang menunjukkan bahwa permintaan tidak sampai ke backend atau backend menutup koneksi secara tak terduga sebelum memberikan respons. Periksa item berikut secara berurutan:

  • Komunikasi TCP antara CLB dan server backend tidak normal. Periksa apakah layanan backend sedang berjalan, port layanan listening dengan benar, dan aturan iptables atau perangkat lunak keamanan pihak ketiga pada instance ECS backend memblokir blok CIDR 100.64.0.0/10. Anda juga dapat melakukan Pengambilan paket untuk memverifikasi apakah handshake TCP berhasil.

  • Backlog server backend penuh. Hal ini menyebabkan permintaan koneksi baru ditolak atau dibuang. Anda dapat menjalankan netstat -s | grep -i listen pada server backend untuk memeriksa jumlah drop.

  • Server backend tidak memproses permintaan tepat waktu. Periksa log server backend dan tinjau pemanfaatan CPU serta memori untuk mengidentifikasi hambatan kinerja.

  • Paket yang dikirim oleh client melebihi MTU server backend. Hal ini dapat terlihat sebagai Pemeriksaan kesehatan yang berhasil dan pemrosesan paket kecil yang normal, tetapi kegagalan untuk paket yang lebih besar. Kami merekomendasikan untuk melakukan Pengambilan paket pada server backend guna menganalisis apakah ukuran paket sesuai.

  • Respons server backend memiliki format tidak valid atau header HTTP tidak valid. Lakukan Pengambilan paket pada server backend untuk menganalisis apakah format respons valid.

  • Semua server backend dalam kelompok server gagal dalam Pemeriksaan kesehatan. Tanpa backend yang tersedia, CLB mengembalikan error 502. Lakukan troubleshooting terhadap konfigurasi Pemeriksaan kesehatan listener dan status layanan backend Anda. Untuk informasi selengkapnya, lihat Bagaimana cara melakukan troubleshooting kegagalan Pemeriksaan kesehatan?

  • Pemeriksaan kesehatan listener normal, tetapi kelompok server yang terkait dengan aturan pengalihan tidak normal. Pemeriksaan kesehatan hanya berlaku untuk kelompok server default yang terikat pada listener dan tidak mencakup kelompok server yang dikonfigurasi dalam aturan pengalihan. Jika permintaan sesuai dengan aturan pengalihan, Anda harus memeriksa status server backend dalam kelompok server yang terkait dengan aturan tersebut.

400 (Bad Request)

Permintaan HTTP memiliki format tidak valid.

• Server backend mengembalikan error 400. upstream_status bernilai 400, dan CLB meneruskan respons tersebut. Masalah ini umum terjadi ketika CLB menggunakan protokol HTTP untuk mengakses server backend yang menggunakan protokol HTTPS, atau ketika server backend memiliki logika validasi pesan khusus. Lakukan investigasi mengapa layanan backend mengembalikan error 400.

• Format header HTTP dari permintaan yang dikirim client salah. Misalnya, nilai header Content-Length tidak sesuai dengan panjang badan permintaan, metode permintaan tidak ditentukan dalam huruf kapital, atau ukuran header melebihi batas 32 KB. Kami merekomendasikan untuk melakukan Pengambilan paket pada client guna menganalisis format permintaan HTTP dan membandingkannya dengan permintaan yang valid.

• Client mengirim permintaan HTTP ke port listener HTTPS instance CLB. CLB menolak permintaan tersebut dan mengembalikan error 400. Periksa apakah client menggunakan protokol yang benar.

• Client secara aktif menutup koneksi sebelum permintaan HTTP sepenuhnya dikirim. Kami merekomendasikan untuk melakukan Pengambilan paket guna menyelidiki mengapa client terputus.

405 (Method Not Allowed)

Metode permintaan tidak didukung.

• Server backend tidak mendukung metode permintaan yang digunakan client. upstream_status bernilai 405. Anda dapat menjalankan perintah curl -X method ip:port pada server backend untuk memverifikasi, dengan method adalah metode permintaan client, ip adalah alamat IP backend, dan port adalah port backend. Periksa apakah metode permintaan client didukung oleh server backend.

• CLB tidak mendukung metode permintaan TRACE. Gunakan metode lain.

408 (Request Timeout)

Permintaan mengalami timeout, dan CLB secara aktif menutup koneksi.

• Client hanya mengirimkan sebagian data. Client hanya mengirimkan sebagian data (misalnya hanya header HTTP) dalam periode timeout permintaan (default 60 detik). Lakukan Pengambilan paket untuk memeriksa hambatan kinerja atau perilaku tidak normal di sisi client.

• Kualitas tautan jaringan dari client ke CLB buruk. Round Trip Time (RTT) TCP tinggi atau terjadi kehilangan paket. Anda dapat memeriksa bidang request_time dan tcpinfo_rtt dalam log akses, atau melakukan diagnosa jaringan pada client.

• Trafik berlebihan ke instance CLB memicu pembatasan bandwidth dan kehilangan paket. Gunakan CloudMonitor untuk memeriksa bandwidth keluar instance dan metrik koneksi yang dibuang.

414 (URI Too Long)

Panjang URI permintaan client melebihi batas, dan CLB menolak permintaan tersebut.

• Server backend itu sendiri mengembalikan error 414. upstream_status=414. Server backend memiliki batas panjang URI yang lebih ketat daripada CLB. Anda dapat memperpendek URI client atau meningkatkan batas panjang URI server backend.

• URI permintaan client melebihi batas 32 KB CLB. Perpendek panjang URI. Jika Anda harus mengirim data dalam jumlah besar, gunakan metode POST untuk menempatkannya dalam badan permintaan.

499 (Client Closed Request)

Client secara aktif menutup koneksi.

Pendekatan troubleshooting: Gunakan bidang log akses—seperti request_time (total waktu berlalu hingga client menutup koneksi), upstream_response_time (waktu pemrosesan backend), dan client_ip (sumber trafik)—untuk mengidentifikasi akar penyebab secara cepat, mulai dari lapisan jaringan hingga lapisan aplikasi. Jika upstream_response_time tinggi dan mendekati request_time, backend merespons terlalu lambat — fokuslah pada item kinerja backend di bawah ini. Jika request_time sangat singkat, client terputus lebih awal karena pengaturan timeout di sisi client atau masalah jaringan — fokuslah pada item sisi client dan jaringan di bawah ini. Jika tcpinfo_rtt jauh lebih tinggi daripada level normal untuk jalur yang sama, terdapat degradasi jalur jaringan antara client dan CLB.

• Kualitas tautan jaringan antara client dan CLB buruk. Hal ini ditunjukkan oleh RTT TCP tinggi atau kehilangan paket. Periksa bidang request_time dan tcpinfo_rtt dalam log akses, atau lakukan Pengambilan paket untuk mendiagnosis jaringan client. Periksa juga bidang client_ip dalam log akses untuk mengidentifikasi sumber trafik: jika client_ip adalah alamat IP publik, fokuslah pada kualitas tautan Internet antara client dan CLB (misalnya kehilangan paket ISP atau latensi akses cross-region); jika client_ip adalah alamat IP pribadi, fokuslah pada konfigurasi jaringan VPC seperti aturan grup keamanan dan ACL jaringan yang mungkin memengaruhi stabilitas koneksi.

• Trafik berlebihan ke instance CLB memicu pembatasan bandwidth dan kehilangan paket. Gunakan CloudMonitor untuk memeriksa bandwidth keluar instance dan metrik koneksi yang dibuang.

• Server backend membutuhkan waktu terlalu lama untuk memproses permintaan. Waktu pemrosesan melebihi timeout permintaan client. (Dalam log akses, upstream_response_time merepresentasikan waktu pemrosesan backend.) Untuk membedakan timeout client dari masalah jaringan, bandingkan nilai request_time dalam log akses dengan timeout yang dikonfigurasi di client — jika kedua nilai tersebut mendekati, client menutup koneksi karena timeout, bukan karena masalah jaringan. Periksa server backend untuk hambatan kinerja pada CPU, memori, dan jaringan. Periksa juga apakah antarmuka jaringan instance ECS mengalami packet drop (jalankan ifconfig atau ethtool -S <interface> untuk melihat counter drop) dan apakah antrian backlog SYN kernel penuh (jalankan netstat -s | grep -i syn untuk memeriksa statistik terkait SYN).

• Periode timeout permintaan yang dikonfigurasi pada client terlalu singkat. Hal ini menyebabkan client menutup koneksi sebelum permintaan selesai. Bidang request_time dalam log akses menunjukkan total waktu permintaan. Kami merekomendasikan agar Anda menyesuaikan konfigurasi timeout client berdasarkan bidang ini.

• Client mengalami masalah tidak dikenal. Hal ini menyebabkan client menutup koneksi lebih awal. Lakukan investigasi terhadap client untuk perilaku yang dapat menyebabkan terminasi koneksi dini.

• Pengambilan paket simultan. Jika langkah-langkah sebelumnya tidak mengidentifikasi akar penyebab, jalankan tcpdump secara bersamaan pada client dan server backend, lalu bandingkan urutan pembentukan dan penutupan koneksi TCP. Jika client mengirim paket FIN saat server backend masih memproses permintaan, penyebabnya dipastikan sebagai client yang secara aktif menutup koneksi karena timeout.

500 (Internal Server Error)

Terjadi error internal pada server backend.

• Server backend itu sendiri mengembalikan error 500. upstream_status bernilai 500, dan CLB meneruskan respons tersebut. Periksa log error server backend untuk melakukan troubleshooting akar penyebab.

• Server backend menutup koneksi secara tak terduga sebelum mengirimkan respons lengkap. Lakukan Pengambilan paket pada server backend untuk menyelidiki penyebab penutupan koneksi yang tak terduga.

503 (Service Temporarily Unavailable)

Layanan sementara tidak tersedia, biasanya karena batas trafik terlampaui atau layanan backend tidak tersedia.

• Server backend itu sendiri mengembalikan error 503. upstream_status bernilai 503, dan CLB meneruskan respons tersebut. Periksa log server backend untuk melakukan troubleshooting akar penyebab.

• Trafik permintaan client memicu rate limiting CLB. Anda dapat melihat metrik requests per second di CloudMonitor. Karena CloudMonitor menampilkan data dengan granularitas per menit, metrik tersebut mungkin tidak menunjukkan saat batas per detik terlampaui. Anda dapat melihat jumlah permintaan per detik dalam log akses. Nilai - untuk bidang upstream_status menunjukkan bahwa permintaan tidak dikirim ke server backend.

  Solusi:

  • Tingkatkan spesifikasi instance CLB.

  • Gunakan Alibaba Cloud DNS untuk mengarahkan nama domain ke beberapa instance CLB guna mendistribusikan trafik.

  • Untuk layanan Lapisan 4, pertimbangkan menggunakan NLB untuk menangani lebih banyak koneksi bersamaan.

  • Untuk layanan Lapisan 7, pertimbangkan menggunakan ALB untuk mencapai QPS yang lebih tinggi.

• Tidak ada server backend yang dikonfigurasi untuk listener CLB, atau server backend yang dikonfigurasi memiliki bobot 0.

504 (Gateway Timeout)

Server backend mengalami timeout saat memberikan respons.

• Server backend itu sendiri mengembalikan error 504. upstream_status bernilai 504, dan CLB meneruskan respons tersebut. Penyebab umum adalah server backend mengalami timeout saat mengakses layanan internal lainnya. Lakukan troubleshooting terhadap layanan internal tersebut.

• Terjadi timeout saat CLB menghubungkan ke server backend. Timeout koneksi default adalah 5 detik dan tidak dapat diubah. Anda dapat memeriksa log akses untuk melihat apakah nilai bidang upstream_connect_time mendekati 5 detik. Kami merekomendasikan agar Anda menggunakan Pengambilan paket untuk menyelidiki mengapa server backend merespons lambat.

• Waktu respons server backend melebihi periode timeout permintaan CLB. Defaultnya adalah 60 detik. Anda dapat mengonfirmasi hal ini dengan memeriksa metrik upstream_rt di CloudMonitor atau bidang upstream_response_time dalam log akses.