Kode respons HTTP di Application Gateway

  • Artikel

Artikel ini memberikan alasan mengapa Azure Application Gateway mengembalikan kode respons HTTP tertentu. Penyebab umum dan langkah-langkah pemecahan masalah disediakan untuk membantu Anda menentukan akar penyebab kesalahan kode Respons HTTP. Kode respons HTTP dapat dikembalikan ke permintaan klien apakah koneksi dimulai ke target backend atau tidak.

Kode respons 3XX (pengalihan)

Respons 300-399 disajikan ketika permintaan klien cocok dengan aturan gateway aplikasi yang telah mengalihkan konfigurasi. Pengalihan dapat dikonfigurasi pada aturan apa adanya atau melalui aturan peta jalur. Untuk informasi selengkapnya tentang pengalihan, lihat gambaran umum pengalihan Application Gateway.

301 Pengalihan Permanen

Respons HTTP 301 disajikan ketika aturan pengalihan ditentukan dengan nilai Permanen .

302 Ditemukan

Respons HTTP 302 disajikan ketika aturan pengalihan ditentukan dengan nilai Ditemukan .

303 Lihat Lainnya

Respons HTTP 302 disajikan saat aturan pengalihan ditentukan dengan Lihat Nilai lainnya .

307 Pengalihan Sementara

Respons HTTP 307 disajikan ketika aturan pengalihan ditentukan dengan nilai Sementara .

Kode respons 4XX (kesalahan klien)

Kode respons 400-499 menunjukkan masalah yang dimulai dari klien. Masalah ini dapat berkisar dari klien yang memulai permintaan hingga nama host yang tidak cocok, batas waktu permintaan, permintaan yang tidak diautentikasi, permintaan berbahaya, dan banyak lagi.

Application Gateway mengumpulkan metrik yang menangkap distribusi kode status 4xx/5xx memiliki mekanisme pengelogan yang menangkap informasi seperti alamat IP klien URI dengan kode respons. Metrik dan pengelogan memungkinkan pemecahan masalah lebih lanjut. Klien juga dapat menerima respons 4xx dari proksi lain antara perangkat klien dan Application Gateway. Misalnya, CDN dan penyedia autentikasi lainnya. Lihat artikel berikut untuk informasi lebih lanjut.

Metrik yang didukung oleh log Diagnostik SKUApplication Gateway V2

400 – Permintaan Buruk

Kode respons HTTP 400 umumnya diamati ketika:

  • Lalu lintas non-HTTP/HTTPS dimulai ke gateway aplikasi dengan pendengar HTTP atau HTTPS.
  • Lalu lintas HTTP dimulai ke pendengar dengan HTTPS, tanpa pengalihan yang dikonfigurasi.
  • Autentikasi timbal balik dikonfigurasi dan tidak dapat bernegosiasi dengan benar.
  • Permintaan tidak sesuai dengan RFC.

Beberapa alasan umum agar permintaan tidak sesuai dengan RFC adalah:

Category Contoh
Host tidak valid di baris permintaan Host yang berisi dua titik dua (example.com:8090:8080)
Header Host Hilang Permintaan tidak memiliki Header Host
Kehadiran karakter cacat atau ilegal Karakter yang dipesan adalah &,!. Solusinya adalah mengkodekannya sebagai persentase. Misalnya: %&
Versi HTTP tidak valid Dapatkan /content.css HTTP/0.3
Nama bidang header dan URI berisi Karakter non-ASCII GET /«úüü»¿.doc HTTP/1.1
Header Panjang Konten hilang untuk permintaan POST Penjelasan Mandiri
Metode HTTP tidak valid GET123 /index.html HTTP/1.1
Header Duplikat Otorisasi:<konten> yang dikodekan base64, Otorisasi: <konten yang dikodekan base64>
Nilai tidak valid dalam Panjang Konten Panjang Konten: abc,Content-Length: -10

Untuk kasus ketika autentikasi timbal balik dikonfigurasi, beberapa skenario dapat menyebabkan respons HTTP 400 dikembalikan klien, seperti:

  • Sertifikat klien tidak disajikan, tetapi autentikasi bersama diaktifkan.
  • Validasi DN diaktifkan dan DN sertifikat klien tidak cocok dengan DN dari rantai sertifikat yang ditentukan.
  • Rantai sertifikat klien tidak cocok dengan rantai sertifikat yang dikonfigurasi dalam Kebijakan SSL yang ditentukan.
  • Sertifikat klien kedaluwarsa.
  • Pemeriksaan Pencabutan Klien OCSP diaktifkan dan sertifikat dicabut.
  • Pemeriksaan Pencabutan Klien OCSP diaktifkan, tetapi tidak dapat dihubungi.
  • Pemeriksaan Pencabutan Klien OCSP diaktifkan, tetapi responden OCSP tidak disediakan dalam sertifikat.

Untuk informasi selengkapnya tentang pemecahan masalah autentikasi bersama, lihat Pemecahan masalah Kode kesalahan.

401 – Tidak sah

Respons http 401 yang tidak sah dikembalikan ke klien jika klien tidak berwenang untuk mengakses sumber daya. Ada beberapa alasan untuk 401 dikembalikan. Berikut ini adalah beberapa alasan dengan potensi perbaikan.

  • Jika klien memiliki akses, klien mungkin memiliki cache browser yang kedaluarsa. Hapus cache browser dan coba akses aplikasi lagi.

Respons http 401 yang tidak sah dapat dikembalikan ke permintaan pemeriksaan AppGW jika kumpulan backend dikonfigurasi dengan autentikasi NTLM . Dalam skenario ini, backend ditandai sebagai sehat. Ada beberapa cara untuk mengatasi masalah ini:

  • Izinkan akses anonim pada kumpulan backend.
  • Konfigurasikan pemeriksaan untuk mengirim permintaan ke situs "palsu" lain yang tidak memerlukan NTLM.
  • Tidak disarankan, karena ini tidak akan memberi tahu kami apakah situs aktual di belakang gateway aplikasi aktif atau tidak.
  • Konfigurasikan gateway aplikasi untuk mengizinkan 401 respons sebagai valid untuk pemeriksaan: Kondisi pencocokan probe.

403 – Terlarang

HTTP 403 Terlarang disajikan ketika pelanggan menggunakan sku WAF dan memiliki WAF yang dikonfigurasi dalam mode Pencegahan. Jika aturan WAF yang diaktifkan atau aturan WAF penolakan kustom cocok dengan karakteristik permintaan masuk, klien akan memberikan respons terlarang 403.

Alasan lain untuk klien yang menerima respons 403 meliputi:

  • Anda menggunakan App Service sebagai backend dan dikonfigurasi untuk mengizinkan akses hanya dari Application Gateway. Ini dapat mengembalikan kesalahan 403 oleh App Services. Ini biasanya terjadi karena tautan pengalihan/href yang mengarah langsung ke App Services alih-alih mengarahkan ke alamat IP Application Gateway.
  • Jika Anda mengakses blog penyimpanan dan Application Gateway dan titik akhir penyimpanan berada di wilayah yang berbeda, maka kesalahan 403 dikembalikan jika alamat IP publik Application Gateway tidak diizinkan terdaftar. Lihat Memberikan akses dari rentang IP internet.

404 – Halaman tidak ditemukan

Respons HTTP 404 dapat dikembalikan jika permintaan dikirim ke gateway aplikasi yaitu:

408 – Batas Waktu Permintaan

Respons HTTP 408 dapat diamati ketika klien meminta pendengar frontend gateway aplikasi tidak merespons kembali dalam waktu 60 detik. Kesalahan ini dapat diamati karena kemacetan lalu lintas antara jaringan lokal dan Azure, ketika appliance virtual memeriksa lalu lintas, atau klien itu sendiri menjadi kewalahan.

413 – Entitas Permintaan Terlalu Besar

Respons HTTP 413 dapat diamati saat menggunakan Azure Web Application Firewall di Application Gateway dan ukuran permintaan klien melebihi batas ukuran isi permintaan maksimum. Bidang ukuran isi permintaan maksimum mengontrol batas ukuran permintaan keseluruhan tidak termasuk unggahan file apa pun. Nilai default untuk ukuran isi permintaan adalah 128 KB. Untuk informasi selengkapnya, lihat Batas ukuran permintaan Web Application Firewall.

499 – Klien menutup koneksi

Respons HTTP 499 ditampilkan jika permintaan klien yang dikirim ke gateway aplikasi menggunakan sku v2 ditutup sebelum server selesai merespons. Kesalahan ini dapat diamati dalam 2 skenario. Skenario pertama adalah ketika respons besar dikembalikan ke klien dan klien mungkin telah menutup atau menyegarkan aplikasi sebelum server selesai mengirim respons besar. Skenario kedua adalah ketika waktu habis di sisi klien rendah dan tidak menunggu cukup lama untuk menerima respons dari server. Dalam hal ini lebih baik untuk meningkatkan batas waktu pada klien. Di gateway aplikasi yang menggunakan sku v1, kode respons HTTP 0 dapat dinaikkan untuk klien yang menutup koneksi sebelum server selesai merespons juga.

Kode respons 5XX (kesalahan server)

Kode respons 500-599 menunjukkan masalah telah terjadi dengan gateway aplikasi atau server backend saat melakukan permintaan.

500 – Kesalahan Server Internal

Azure Application Gateway tidak boleh menunjukkan 500 kode respons. Buka permintaan dukungan jika Anda melihat kode ini, karena masalah ini adalah kesalahan internal untuk layanan. Untuk informasi tentang cara membuka kasus dukungan, lihat Membuat permintaan dukungan Azure.

502 – Gateway Buruk

Kesalahan HTTP 502 dapat memiliki beberapa akar penyebab, misalnya:

  • NSG, UDR, atau DNS kustom memblokir akses ke anggota kumpulan backend.
  • VM backend atau instans set skala komputer virtual tidak merespons pemeriksaan kesehatan default.
  • Konfigurasi pemeriksaan kesehatan kustom tidak valid atau tidak tepat.
  • Kumpulan backend Azure Application Gateway tidak dikonfigurasi atau kosong.
  • Tidak ada komputer virtual atau instans dalam set skala komputer virtual yang sehat.
  • Meminta masalah waktu habis atau konektivitas dengan permintaan pengguna-SKU Gateway V1 aplikasi Azure mengirim kesalahan HTTP 502 jika waktu respons backend melebihi nilai batas waktu yang dikonfigurasi dalam Pengaturan Backend.

Untuk informasi tentang skenario di mana kesalahan 502 terjadi, dan cara memecahkan masalahnya, lihat Memecahkan masalah kesalahan Gateway Buruk.

504 – Batas waktu gateway

Aplikasi Azure Gateway V2 SKU mengirim kesalahan HTTP 504 jika waktu respons backend melebihi nilai batas waktu yang dikonfigurasi di Pengaturan Backend.

IIS

Jika server backend Anda adalah IIS, lihat Batas Default untuk Situs Web untuk mengatur nilai batas waktu. connectionTimeout Lihat atribut untuk detailnya. Pastikan batas waktu koneksi di IIS cocok atau tidak melebihi batas waktu yang ditetapkan dalam pengaturan backend.

nginx

Jika server backend adalah pengontrol ingress nginx atau nginx, dan jika memiliki server upstream, pastikan nilai nginx:proxy_read_timeout kecocokan atau tidak melebihi batas waktu yang diatur dalam pengaturan backend.

Langkah berikutnya

Jika informasi dalam artikel ini tidak membantu menyelesaikan masalah, kirimkan tiket dukungan.