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 paling umum kegagalan CLB.

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 adalah 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 security group 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. Port yang dikonfigurasi untuk setiap server backend dalam kelompok server CLB harus sesuai dengan port tempat proses layanan mendengarkan. Misalnya, jika Anda mengonfigurasi port 8080 dalam kelompok server tetapi layanan backend mendengarkan 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 yang sedang mendengarkan.

5. Untuk listener HTTPS: Verifikasi bahwa sertifikat belum kedaluwarsa dan nama domain yang ditautkan ke sertifikat sesuai dengan domain akses. Pada halaman detail listener, periksa sertifikat yang ditautkan 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 pada log Nginx, gerbang, atau aplikasi backend Anda.

• Ketika 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 ini 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 mencapai backend atau backend menutup koneksi secara tak terduga sebelum memberikan respons. Periksa item-item berikut secara berurutan:

  • Komunikasi TCP antara CLB dan server backend tidak normal. Periksa apakah layanan backend sedang berjalan, port layanan mendengarkan 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 keberhasilan handshake TCP.

  • 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 performa.

  • Paket yang dikirim oleh client melebihi MTU server backend. Hal ini dapat terlihat sebagai health check yang berhasil dan pemrosesan paket kecil yang normal, tetapi kegagalan pada paket yang lebih besar. Kami menyarankan 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 validitas format respons.

  • Semua server backend dalam kelompok server gagal dalam health check. Tanpa backend yang tersedia, CLB mengembalikan error 502. Lakukan troubleshooting pada konfigurasi health check listener dan status layanan backend Anda. Untuk informasi lebih lanjut, lihat Bagaimana cara melakukan troubleshooting kegagalan health check?

  • Health check listener normal, tetapi kelompok server yang terkait dengan aturan pengalihan abnormal. Health check hanya berlaku untuk kelompok server default yang ditautkan ke 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 permintaan yang dikirim dari client salah. Misalnya, nilai header Content-Length tidak sesuai dengan panjang badan permintaan, metode permintaan tidak ditulis dalam huruf kapital, atau ukuran header melebihi batas 32 KB. Kami menyarankan agar Anda melakukan pengambilan paket pada client untuk 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 menyarankan untuk melakukan pengambilan paket guna menyelidiki alasan client memutus koneksi.

405 (Method Not Allowed)

Metode permintaan tidak didukung.

• Server backend tidak mendukung metode permintaan yang digunakan oleh 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 performa atau perilaku abnormal 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 diagnostik 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.

413 (Request Entity Too Large)

Badan permintaan terlalu besar. Periksa terlebih dahulu nilai bidang upstream_status dalam log akses, lalu tentukan langkah troubleshooting berikutnya berdasarkan nilainya.

• Ketika upstream_status bernilai 413: Server backend itu sendiri mengembalikan error 413, dan CLB meneruskannya ke client. Hal ini biasanya dipicu oleh pengaturan client_max_body_size pada server proxy backend (seperti Nginx). Periksa batas ukuran badan yang dikonfigurasi pada server backend, lalu tingkatkan batas tersebut atau kurangi ukuran badan permintaan client.

• Ketika upstream_status bernilai - atau kosong: CLB secara aktif mengembalikan error 413, yang menunjukkan bahwa badan permintaan melebihi batas CLB itu sendiri. Skenario ini jarang terjadi. Kami menyarankan agar Anda mengurangi ukuran badan permintaan client.

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.

• Kualitas tautan jaringan antara client dan CLB buruk. Hal ini ditunjukkan oleh RTT TCP tinggi atau kehilangan paket. Anda dapat memeriksa bidang request_time dan tcpinfo_rtt dalam log akses, atau melakukan pengambilan paket untuk mendiagnosis jaringan client.

• 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). Kami menyarankan agar Anda memeriksa server backend untuk hambatan performa pada CPU, memori, atau jaringan.

• 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 menyarankan agar Anda menyesuaikan konfigurasi timeout client berdasarkan bidang ini.

• Client mengalami masalah tak dikenal. Hal ini menyebabkannya menutup koneksi lebih awal. Lakukan investigasi pada client untuk perilaku yang dapat menyebabkan pemutusan koneksi dini.

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 mengidentifikasi akar penyebabnya.

• 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 mengidentifikasi akar penyebabnya.

• Trafik permintaan client memicu pembatasan laju CLB. Anda dapat melihat metrik permintaan per detik di CloudMonitor. Karena CloudMonitor menampilkan data dengan granularitas per menit, mungkin tidak menunjukkan saat batas per detik terlampaui. Anda dapat melihat jumlah permintaan per detik dalam log akses. Nilai - pada 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 umumnya adalah server backend mengalami timeout saat mengakses layanan internal lainnya. Lakukan troubleshooting pada 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 menyarankan agar Anda menggunakan pengambilan paket untuk menyelidiki alasan 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.