Server Load Balancer:Kode status error ALB

Lima pemeriksaan cepat

Sebelum melakukan troubleshooting berdasarkan kode status, lakukan lima pemeriksaan berikut terlebih dahulu. Pemeriksaan ini mencakup penyebab paling umum dari kegagalan ALB.

1. Jalankan tool diagnostik instans ALB. Di halaman Instances, temukan instans target. Di kolom Instance Diagnostics, klik Diagnose untuk menjalankan pemeriksaan satu klik terhadap masalah umum pada konfigurasi instans, listener, dan layanan backend.

2. Verifikasi bahwa Health Check Status untuk listener adalah Healthy. Di halaman Listener Details, periksa Health Check Status grup server backend. Jika statusnya Unhealthy, lihat Troubleshoot ALB health check failures.

3. Pastikan ECS backend tidak memblokir Blok CIDR dari VSwitch tempat instans ALB berada. ALB berkomunikasi dengan server backend menggunakan Local IP yang ditetapkan oleh VSwitch-nya. Jika aturan iptables atau perangkat lunak keamanan pihak ketiga pada instans ECS backend memblokir Blok CIDR VSwitch tersebut, ALB tidak dapat menjangkau backend, yang dapat memicu error seperti 502 atau 504.

4. Konfirmasi bahwa port yang dikonfigurasi untuk server backend dalam grup server sesuai dengan port tempat layanan backend benar-benar mendengarkan. Port yang dikonfigurasi untuk setiap server backend dalam grup server ALB harus sesuai dengan port tempat proses aplikasi mendengarkan. Misalnya, jika port dikonfigurasi sebagai 8080 dalam grup server tetapi layanan backend mendengarkan di port 80, koneksi akan gagal. Anda dapat menjalankan ss -tlnp | grep ':<port> ' atau netstat -tlnp | grep ':<port> ' pada ECS backend untuk memverifikasi.

5. Untuk listener HTTPS, verifikasi bahwa sertifikat belum kedaluwarsa dan domain-nya sesuai dengan domain akses. Di halaman Listener Details, 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 klien, tetapi ALB gagal meneruskan permintaan tersebut ke server backend atau menerima respons darinya.

Pendekatan troubleshooting: Pertama, periksa nilai bidang upstream_status dalam log akses untuk menentukan langkah selanjutnya.

• Jika upstream_status = 502: ALB meneruskan kode status 502 dari server backend. Masalah terletak pada layanan backend itu sendiri. Selidiki layanan backend Anda. Misalnya, periksa apakah layer Nginx atau gateway backend mencoba melakukan reverse proxy ke upstream yang tidak dapat dijangkau.

• Jika upstream_status bernilai lain (seperti 504, 444, atau 500): status yang dikembalikan ALB ke klien berbeda dari upstream_status, yang berarti ALB mengubah kode status tersebut. Selidiki mengapa layanan backend mengembalikan kode status spesifik tersebut dengan memeriksa log Nginx backend, gateway, atau aplikasi.

• Jika upstream_status adalah - atau kosong: ALB tidak menerima respons apa pun dari backend. Artinya, permintaan tidak pernah sampai ke backend, atau koneksi backend diputus secara abnormal sebelum respons dikirim. Periksa penyebab berikut secara berurutan:

  • Komunikasi TCP antara ALB dan server backend gagal. Verifikasi bahwa layanan backend sedang berjalan, port layanan mendengarkan dengan benar, dan tidak ada aturan iptables atau perangkat lunak keamanan pihak ketiga pada ECS backend yang memblokir Blok CIDR VSwitch tempat instans ALB berada. ALB berkomunikasi dengan server backend menggunakan Local IP yang ditetapkan oleh VSwitch. Anda dapat menangkap paket untuk memeriksa apakah handshake TCP berhasil.

  • Backlog server backend penuh. Hal ini menyebabkan server membuang permintaan koneksi baru. Jalankan netstat -s | grep -i listen pada server backend dan periksa penghitung drop.

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

  • Ukuran paket permintaan klien melebihi MTU server backend. Hal ini dapat menyebabkan paket pendek (seperti pemeriksaan kesehatan) berhasil, sedangkan paket panjang gagal. Tangkap paket pada server backend untuk menganalisis apakah panjang paket berada dalam batas yang diperlukan.

  • Respons server backend memiliki format tidak valid atau berisi header HTTP yang tidak valid. Tangkap paket pada server backend untuk menganalisis apakah format respons sesuai standar.

400 Bad Request

Format permintaan tidak valid.

• Backend mengembalikan 400 secara langsung: Periksa log akses. Jika upstream_status adalah 400, kemungkinan besar ALB meneruskan kode status tersebut dari backend. Selidiki layanan backend.

• Permintaan HTTP dikirim ke listener HTTPS: Listener HTTPS ALB menolak permintaan non-HTTPS dan mengembalikan kode status 400. Periksa apakah klien salah mengirim permintaan HTTP ke port HTTPS.

• Ukuran header permintaan melebihi batas: ALB mensyaratkan setiap header permintaan HTTP tidak lebih dari 32 KB. Jika batas ini dilampaui, ALB mengembalikan kode status 400. Kurangi ukuran header permintaan.

• Klien tidak mengirim permintaan lengkap: Klien menutup koneksi sebelum mengirim permintaan HTTP lengkap. Tangkap paket pada klien untuk mengidentifikasi penyebabnya.

• Format header permintaan tidak valid: Misalnya, nilai Content-Length tidak sesuai dengan panjang aktual badan permintaan. Tangkap paket pada klien, analisis format permintaan HTTP, dan bandingkan dengan permintaan yang valid.

405 Method Not Allowed

Metode permintaan tidak didukung.

• Pembatasan ALB: ALB tidak mendukung metode permintaan TRACE. Gunakan metode lain.

• Pembatasan layanan backend: Selain TRACE, dukungan terhadap metode permintaan lain bergantung pada server backend. Untuk memverifikasi, jalankan curl -X METHOD http://<backend_service_IP>:<service_port>, dengan METHOD adalah metode permintaan yang digunakan klien.

408 Request Timeout

Permintaan mengalami timeout, dan ALB menutup koneksi.

• Transmisi data klien lambat: Dalam periode timeout permintaan klien ke ALB (default: 60 detik), klien hanya mengirim data sebagian, seperti hanya mengirim HTTP Header tetapi tidak mengirim HTTP Body. Tangkap paket pada klien untuk memeriksa hambatan kinerja atau masalah lainnya.

• Kualitas jaringan antara klien dan ALB buruk: Round Trip Time (RTT) TCP tinggi, atau terdapat masalah jaringan lain seperti kehilangan paket. Kami menyarankan Anda memeriksa bidang request_time dan tcpinfo_rtt dalam log akses, atau menjalankan diagnostik jaringan pada klien.

• Pembatasan bandwidth instans ALB: Trafik tinggi ke instans ALB telah memicu pembatasan bandwidth dan kehilangan paket. Periksa metrik outbound bandwidth dan Dropped Connections di Cloud Monitor.

414 URI Too Long

Panjang URI permintaan melebihi batas, dan ALB atau server backend menolak permintaan tersebut.

• Pembatasan ALB: ALB mensyaratkan URI permintaan tidak lebih dari 32 KB. Jika tidak, kode status 414 dikembalikan. Perpendek URI tersebut. Untuk mentransmisikan data dalam jumlah besar, Anda dapat menggunakan metode POST dan menempatkan data dalam badan permintaan. ALB mendukung badan permintaan POST hingga 50 GB.

• Pembatasan layanan backend: Jika panjang URI tidak melebihi batas ALB tetapi layanan backend memiliki batas yang lebih ketat, ALB meneruskan kode status 414 yang dikembalikan oleh backend. Selidiki layanan backend.

463

Kode status 463 hanya dikembalikan ketika listener dikaitkan dengan grup server bertipe IP.

Terdapat loop dalam jalur permintaan. Saat permintaan melewati ALB, sistem menambahkan bidang ALICLOUD-ALB-TRACE ke HTTP Header. Nilai bidang tersebut adalah hash 16 karakter yang dihasilkan dari ID aturan. Jika ID aturan duplikat terdeteksi, atau jumlah bidang ALICLOUD-ALB-TRACE melebihi 16, ALB mengidentifikasi adanya loop. ALB kemudian menghentikan penerusan permintaan untuk mencegah badai jaringan dan mengembalikan kode status 463.

• Kesalahan konfigurasi layanan backend: Layanan backend dikonfigurasi secara salah sehingga mengirim permintaan kembali ke ALB secara berulang. Periksa konfigurasi layanan backend ALB Anda.

• Cacat arsitektur jaringan: Misalnya, terdapat beberapa instans load balancing dalam jalur penerusan satu permintaan. Kami menyarankan Anda mengoptimalkan arsitektur jaringan.

499 Client Closed Request

Klien secara aktif menutup koneksi.

• Kualitas jaringan antara klien dan ALB buruk: RTT TCP tinggi, atau terdapat masalah jaringan lain seperti kehilangan paket. Kami menyarankan Anda memeriksa bidang request_time dan tcpinfo_rtt dalam log akses, atau menjalankan diagnostik jaringan pada klien.

• Pembatasan bandwidth instans ALB: Trafik tinggi ke instans ALB telah memicu pembatasan bandwidth dan kehilangan paket. Periksa metrik outbound bandwidth dan Dropped Connections di Cloud Monitor.

• Waktu pemrosesan backend lama: Waktu pemrosesan backend melebihi periode timeout klien. Periksa bidang upstream_response_time dalam log akses, yang menunjukkan waktu pemrosesan backend. Jika nilai ini secara konsisten tinggi, selidiki layanan backend untuk hambatan kinerja.

• Timeout permintaan klien terlalu singkat: Klien menutup koneksi karena timeout sebelum menyelesaikan pengiriman permintaan. Periksa bidang request_time dalam log akses, yang menunjukkan total waktu permintaan. Gunakan nilai ini sebagai referensi untuk mengatur timeout permintaan sisi klien yang lebih sesuai.

• Klien mengalami masalah tak dikenal: Klien menutup koneksi sebelum permintaan selesai. Selidiki klien terhadap perilaku yang dapat menyebabkan penutupan koneksi prematur.

500 Internal Server Error

Server backend mengalami error internal dan tidak dapat memproses permintaan.

• Backend mengembalikan 500 secara langsung: Periksa log akses. Jika upstream_status adalah 500, kemungkinan besar ALB meneruskan kode status tersebut dari backend. Selidiki layanan backend.

• Server backend menutup koneksi secara tak terduga: Server backend menutup koneksi sebelum mengirim respons lengkap. Tangkap paket pada server backend untuk mengidentifikasi penyebab penutupan koneksi yang tak terduga.

503 Service Temporarily Unavailable

Server sementara tidak tersedia, biasanya karena trafik melebihi batas atau layanan backend tidak tersedia.

• Backend mengembalikan 503 secara langsung: Periksa log akses. Jika upstream_status adalah 503, kemungkinan besar ALB meneruskan kode status tersebut dari backend. Selidiki layanan backend.

• Permintaan klien memicu pembatasan kecepatan ALB:

  • Di Cloud Monitor, periksa metrik Requests per second.

  • Cloud Monitor menampilkan data per menit dan mungkin tidak mencerminkan lonjakan per detik. Periksa log akses. Jika bidang upstream_status adalah -, permintaan tidak mencapai server backend.

  • Periksa header paket respons. Jika berisi bidang ALB-QPS-Limited:Limited, permintaan tersebut memicu pembatasan kecepatan ALB.

• Akses IP langsung atau resolusi DNS abnormal: Hal ini dapat memusatkan trafik hanya pada beberapa alamat IP dan memicu pembatasan kecepatan. Akses ALB melalui nama domain-nya (lihat Configure a CNAME for an ALB instance) dan verifikasi bahwa resolusi DNS berfungsi sebagaimana mestinya.

• Listener tidak memiliki server backend yang dikonfigurasi, atau server backend yang dikonfigurasi memiliki bobot 0.

504 Gateway Timeout

ALB mengalami timeout saat menunggu respons dari server backend.

• Backend mengembalikan 504 secara langsung: Periksa log akses. Jika upstream_status adalah 504, kemungkinan besar ALB meneruskan kode status tersebut dari backend. Selidiki layanan backend.

• Upaya koneksi dari ALB ke server backend mengalami timeout: Timeout ini adalah 5 detik secara default dan tidak dapat diubah. Tangkap paket untuk mengidentifikasi mengapa server backend tidak merespons tepat waktu.

• Timeout respons backend: connection request timeout adalah 60 detik secara default. Anda dapat memeriksa metrik UpstreamResponseTime di Cloud Monitor dan bidang upstream_response_time dalam log akses untuk menentukan apakah respons server backend mengalami timeout.