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 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 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 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 pada 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 tiba-tiba 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 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 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 gagal untuk 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 apakah format respons valid.

  • Semua server backend dalam kelompok server gagal dalam pemeriksaan kesehatan. Tanpa backend yang tersedia, CLB mengembalikan error 502. Lakukan troubleshooting pada 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 abnormal. 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 menyarankan 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 melakukan pengambilan paket untuk menyelidiki mengapa client memutus koneksi.

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 melebihi waktu tunggu, 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 adanya 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 pada 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 Anda memeriksa server backend untuk mencari hambatan kinerja 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 Anda menyesuaikan konfigurasi timeout client berdasarkan bidang ini.

• Client mengalami masalah tidak dikenal. Hal ini menyebabkannya menutup koneksi lebih awal. Lakukan investigasi pada client untuk mencari 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 melakukan troubleshooting akar permasalahan.

• Server backend menutup koneksi secara tiba-tiba sebelum mengirimkan respons lengkap. Lakukan pengambilan paket pada server backend untuk menyelidiki penyebab penutupan koneksi yang tidak 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 permasalahan.

• Trafik permintaan client memicu pembatasan laju CLB. Anda dapat melihat metrik requests per second 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 DNS Alibaba Cloud 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 melebihi waktu tunggu saat memberikan respons.

• Server backend itu sendiri mengembalikan error 504. upstream_status bernilai 504, dan CLB meneruskan respons tersebut. Penyebab umum adalah server backend melebihi waktu tunggu 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 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.