API Gateway:Pertanyaan yang Sering Diajukan

Apakah Cloud-native API Gateway mendukung IPv6?

Ya.

Apakah Cloud-native API Gateway mendukung header permintaan x-forwarded-for?

Ya.

Jika permintaan sudah menyertakan header x-forwarded-for, gateway akan menambahkan alamat IP hop sebelumnya. Jika tidak, gateway akan menambahkan header tersebut beserta alamat IP tersebut.

Menangani error "upstream connect error or disconnect/reset header"

Error ini menunjukkan bahwa security group layanan backend memblokir akses dari instans gateway.

Untuk mengatasinya, buka halaman Overview instans gateway Anda, klik tab Security Group Authorizations, lalu klik Add Security Group Rule untuk menambahkan konfigurasi security group. Gateway meneruskan permintaan langsung ke alamat IP Pod di ACK, sehingga Anda harus membuka port yang digunakan oleh pod dalam aturan security group tersebut.

Menggunakan header untuk mencocokkan nama domain

Tambahkan aturan pencocokan header permintaan saat membuat entri rute.

Atur nama field header menjadi :authority dan nilai header menjadi nama domain tertentu.

Menangani kegagalan permintaan akibat badan permintaan yang besar

Masalah ini terjadi karena buffer koneksi gateway terlalu kecil. Anda dapat menambah ukuran buffer:

• Jika menggunakan HTTP/1.x: Sesuaikan parameter DownstreamConnectionBufferLimits di Konsol.

• Jika menggunakan HTTP/2: Sesuaikan parameter DownstreamConnectionBufferLimits dan InitialStreamWindowSize di Konsol.

Batas penambahan sumber layanan

• Satu instans gateway dapat dikaitkan dengan maksimal tiga kluster ACK.

• Satu instans gateway hanya dapat dikaitkan dengan satu instans Nacos.

Tidak dapat memilih sumber layanan Nacos atau ACK yang sudah ada

Cloud-native API Gateway hanya dapat menambahkan instans Nacos atau kluster ACK yang berada dalam VPC yang sama.

Apakah Cloud-native API Gateway mendukung sertifikat HTTPS kustom?

Cloud-native API Gateway tidak menyimpan sertifikat secara langsung. Sebagai gantinya, gateway mengambil sertifikat dari Certificate Management Service Alibaba Cloud. Unggah sertifikat Anda ke Certificate Management Service, lalu konfigurasikan untuk nama domain di gateway.

Dampak perubahan parameter terhadap traffic yang sedang berjalan

• Perubahan pada XffTrustedNum memerlukan restart gateway agar berlaku.

• Perubahan pada UpstreamIdleTimeout menyebabkan koneksi upstream terputus dan tersambung ulang.

• Perubahan pada DownstreamIdleTime menyebabkan koneksi downstream terputus dan tersambung ulang.

Status pemeriksaan kesehatan layanan backend tidak normal

Status pemeriksaan kesehatan yang tidak normal dapat disebabkan oleh beberapa hal:

• Untuk layanan privat dalam VPC, periksa apakah security group layanan backend mengizinkan gateway mengakses port yang diperlukan. Untuk informasi lebih lanjut, lihat Add a security group rule.

• Untuk layanan yang menghadap publik, periksa apakah VPC memiliki akses Internet. Anda dapat menggunakan fitur SNAT dari Gateway NAT Internet untuk mengakses Internet. Untuk informasi selengkapnya, lihat Gunakan fitur SNAT dari Gateway NAT Internet untuk mengakses Internet.

• Untuk pemeriksaan kesehatan berbasis HTTP, pastikan path permintaan dan domain permintaan dikonfigurasi dengan benar.

• Untuk pemeriksaan kesehatan berbasis HTTP, jika endpoint pemeriksaan kesehatan layanan backend harus diakses melalui HTTPS, atur kebijakan layanan ke mode TLS di Policy Configuration.

• Untuk pemeriksaan kesehatan berbasis HTTP, jika semua konfigurasi di atas sudah benar, kemungkinan masalahnya adalah interval pemeriksaan kesehatan sama dengan waktu koneksi tetap hidup layanan backend. Coba tingkatkan interval pemeriksaan kesehatan.

Menentukan penyebab error permintaan

• Periksa apakah header respons berisi x-envoy-upstream-service-time. Jika ya, gateway telah meneruskan permintaan ke layanan backend. Error kemungkinan berasal dari layanan backend.

• Periksa apakah field upstream_service_time dalam log akses gateway kosong. Jika field tersebut tidak kosong, gateway telah meneruskan permintaan ke layanan backend. Error kemungkinan berasal dari layanan backend.

Sertifikat HTTPS yang diperbarui tidak berlaku

Masalah ini biasanya terjadi ketika sertifikat HTTPS juga dikonfigurasi pada layanan upstream gateway, seperti CLB, DCDN, WAF, atau Anti-DDoS Proxy. Periksa apakah sertifikat pada layanan upstream juga telah diperbarui. Sebagai praktik terbaik, konfigurasikan sertifikat HTTPS hanya di satu tempat. Jika DCDN atau WAF ditempatkan di upstream, Anda dapat mengonfigurasi HTTPS hanya di DCDN atau WAF dan menggunakan HTTP untuk permintaan back-to-origin ke gateway.

Prioritisasi rute

Pada halaman Route Settings instans gateway, urutan entri rute dalam daftar merepresentasikan prioritas pencocokannya, dari tertinggi ke terendah. Prioritas ditentukan berdasarkan domain dan aturan entri rute. Prioritas pencocokan domain adalah exact domain name > wildcard domain name. Misalnya, test.example.com memiliki prioritas lebih tinggi daripada *.example.com. Untuk domain yang sama, prioritas pencocokan path adalah Exact Match>Prefix Match>Match Regular Expression. Untuk domain dan path yang sama, aturan dengan more matching conditions memiliki prioritas lebih tinggi daripada yang memiliki fewer matching conditions (kondisi pencocokan mencakup parameter Header dan Query).

Kegagalan permintaan HTTPS dengan DCDN

Masalah ini biasanya terjadi karena DCDN tidak menyertakan Server Name Indication (SNI) dalam permintaan back-to-origin ke gateway. Untuk mengatasinya, konfigurasikan SNI back-to-origin di pengaturan DCDN Anda.

Kegagalan permintaan HTTPS dengan WAF

Masalah ini biasanya terjadi karena WAF tidak menyertakan Server Name Indication (SNI) dalam permintaan back-to-origin ke gateway. Jika Anda menggunakan mode akses CNAME di WAF, ubah pengaturan untuk domain yang sesuai. Pada langkah Enter Your Website Information, pilih Enable Origin SNI.

Apakah Cloud-native API Gateway mendukung WebSocket?

Ya, WebSocket didukung dan diaktifkan secara default.

Apakah Cloud-native API Gateway mendukung gRPC?

Ya. gRPC menggunakan protokol HTTP/2 untuk transport. Pastikan EnableHttp2 = true diatur pada halaman Parameter Settings gateway.

Apakah Cloud-native API Gateway mendukung dekompresi GZIP?

Ya. Pastikan EnableGzip = true diatur pada halaman Parameter Settings gateway. Algoritma yang didukung adalah Gzip dan Brotli, dikonfigurasi melalui parameter ZipAlgorithm. Nilai default-nya adalah Gzip.

Mempertahankan kapitalisasi header

Ya. Pastikan PreserveHeaderFormat = true diatur pada halaman Parameter Settings gateway. Parameter ini hanya berlaku untuk HTTP/1.0 dan HTTP/1.1. Spesifikasi protokol HTTP/2 mengharuskan semua header permintaan dan respons menggunakan huruf kecil.

Apakah Cloud-native API Gateway mendukung HTTP/3?

Ya. Pastikan EnableHttp3 = true diatur pada halaman Parameter Settings gateway.

Header dikonversi menjadi huruf kecil

Secara default, gateway mengonversi semua header permintaan dan respons menjadi huruf kecil. Untuk mempertahankan kapitalisasi aslinya, atur PreserveHeaderFormat = true pada halaman Parameter Settings gateway.

Permintaan ke layanan domain DNS gagal

Jika domain DNS yang dikonfigurasi merupakan domain publik, Anda harus mengonfigurasi SNAT di Internet NAT gateway untuk mengaktifkan akses internet. Secara default, instans gateway tidak dapat mengakses internet.

Informasi jejak tidak muncul di Konsol ARMS

Periksa apakah parameter EnableGenerateRequestId diatur ke true dalam konfigurasi gateway. Jika diatur ke false, Anda harus menyertakan header x-request-id yang sesuai dalam permintaan Anda. Jika tidak, gateway tidak dapat melaporkan informasi jejak.

Menerima error 400

Error ini biasanya disebabkan oleh salah satu alasan berikut:

• Klien mengirim permintaan dengan error protokol. Periksa log akses gateway untuk response_flags = DPE.

• Layanan backend mengembalikan error 400. Periksa log akses gateway. Jika field response_flags kosong dan field upstream_host memiliki nilai, ini menunjukkan bahwa layanan backend mengembalikan error 400. Nilai upstream_host adalah alamat IP layanan backend yang menerima permintaan.

Menerima error 401

Error ini biasanya disebabkan oleh salah satu alasan berikut:

• Gateway mengembalikan error, menandakan kredensial akses tidak tersedia. Periksa apakah Anda telah mengaktifkan autentikasi, otorisasi, atau plug-in WebAssembly.

• Layanan backend mengembalikan error 401. Periksa log akses gateway. Jika field response_flags kosong dan field upstream_host memiliki nilai, ini menunjukkan bahwa layanan backend mengembalikan error 401. Nilai upstream_host adalah alamat IP layanan backend yang menerima permintaan.

Menerima error 403

Error ini biasanya disebabkan oleh salah satu alasan berikut:

• Gateway mengembalikan error, menandakan izin akses tidak mencukupi. Periksa apakah Anda telah mengaktifkan blacklist atau daftar putih alamat IP, autentikasi, otorisasi, atau plug-in WebAssembly.

• Layanan backend mengembalikan error 403. Periksa log akses gateway. Jika field response_flags kosong dan field upstream_host memiliki nilai, ini menunjukkan bahwa layanan backend mengembalikan error 403. Nilai upstream_host adalah alamat IP layanan backend yang menerima permintaan.

Menerima error 404

Error ini biasanya disebabkan oleh salah satu alasan berikut:

• Aturan entri rute yang sesuai tidak dikonfigurasi di gateway. Periksa log akses gateway. Jika log berisi response_flags = NR, ini menunjukkan bahwa tidak ada entri rute yang ditemukan.

• Layanan backend mengembalikan error 404. Periksa log akses gateway. Jika field response_flags kosong dan field upstream_host memiliki nilai, ini menunjukkan bahwa layanan backend mengembalikan error 404. Nilai upstream_host adalah alamat IP layanan backend yang menerima permintaan.

Menerima error 405

Jika perlindungan WAF diaktifkan, permintaan mungkin telah memicu aturan perlindungan WAF. Dalam kasus ini, WAF mengembalikan kode status 405.

Menerima error 413

Error ini biasanya disebabkan oleh salah satu alasan berikut:

• Ukuran permintaan melebihi batas buffer koneksi gateway. Tingkatkan nilai parameter DownstreamConnectionBufferLimits pada halaman Parameter Settings.

• Layanan backend mengembalikan error 413. Periksa log akses gateway. Jika field response_flags kosong dan field upstream_host memiliki nilai, ini menunjukkan bahwa layanan backend mengembalikan error 413. Nilai upstream_host adalah alamat IP layanan backend yang menerima permintaan.

Menerima error 429

Aturan pembatasan kecepatan gateway dipicu. Periksa log akses gateway. Jika log berisi response_flags = RL, tinjau aturan pembatasan kecepatan gateway Anda.

Menerima error 502

Error ini biasanya disebabkan oleh salah satu alasan berikut:

• Layanan backend mengembalikan respons dengan error protokol. Periksa log akses gateway. Jika log berisi response_flags = UPE, penyebab paling umum adalah duplikasi field Transfer-Encoding dalam header respons dari layanan backend. Periksa layanan backend Anda.

• Layanan backend mengembalikan error 502. Periksa log akses gateway. Jika field response_flags kosong dan field upstream_host memiliki nilai, ini menunjukkan bahwa layanan backend mengembalikan error 502. Nilai upstream_host adalah alamat IP layanan backend yang menerima permintaan.

Menerima error 503

Error ini dapat disebabkan oleh alasan-alasan berikut:

• Layanan target yang ditentukan dalam aturan entri rute tidak memiliki alamat IP yang sehat. Periksa log akses gateway. Situasi ini ditunjukkan oleh response_flags = UH.

• Layanan backend menutup koneksi saat gateway sedang meneruskan permintaan. Periksa log akses gateway. Situasi ini ditunjukkan oleh response_flags = UC. Hal ini sering terjadi karena idle timeout koneksi layanan backend lebih kecil daripada nilai UpstreamIdleTimeout gateway. Kurangi nilai UpstreamIdleTimeout pada halaman Parameter Settings gateway.

• Gateway tidak dapat terhubung ke alamat IP layanan backend. Periksa log akses gateway. Situasi ini ditunjukkan oleh response_flags = UF atau response_flags = URX. Hal ini sering terjadi karena security group layanan backend memblokir akses dari gateway. Periksa apakah security group layanan backend telah dikonfigurasi untuk mengizinkan gateway mengakses port tersebut. Untuk informasi lebih lanjut, lihat Add a security group rule.

• Layanan backend tidak ada dalam konfigurasi gateway. Periksa log akses gateway. Situasi ini ditunjukkan oleh response_flags = NC. Hal ini dapat terjadi karena beberapa alasan:

  • Layanan yang sesuai tidak lagi ada.

  • Jika layanan backend memiliki beberapa port, Anda harus memilih port tetap, bukan port dinamis, saat mengonfigurasi layanan target dalam entri rute.

  • Port tetap dipilih untuk layanan backend, tetapi port layanan tersebut telah berubah.

• Layanan backend mengembalikan error 503. Jika field response_flags dalam log kosong dan field upstream_host tidak kosong, ini menunjukkan bahwa layanan backend mengembalikan error 503. Nilai upstream_host adalah alamat IP layanan backend yang menerima permintaan.

response_code bernilai 0 dalam log akses

response_code bernilai 0 menunjukkan bahwa klien tidak menerima respons.

Hal ini biasanya terjadi karena salah satu dari dua alasan berikut:

• Klien menutup koneksi lebih awal, misalnya karena jaringan seluler yang lemah atau respons backend yang lambat. Hal ini ditunjukkan oleh response_flags = "DC" dalam log akses.

• Permintaan HTTPS dikirim tanpa Server Name Indication (SNI), dan tidak ada sertifikat HTTPS yang dikonfigurasi untuk nama domain wildcard. SNI adalah ekstensi TLS yang membawa informasi nama domain. Hal ini ditunjukkan oleh field requested_server_name yang kosong dalam log akses.

Konsumsi traffic publik oleh permintaan yang tidak cocok dengan entri rute

Ya. Semua permintaan yang melewati gateway mengonsumsi traffic publik, termasuk permintaan yang tidak cocok dengan entri rute apa pun. Gateway tetap menggunakan traffic untuk menerima permintaan dan mengirim respons.

Anda dapat memeriksa konsumsi traffic di log akses gateway menggunakan field-field berikut:

• bytes_received: Ukuran badan permintaan, merepresentasikan lalu lintas masuk.

• bytes_sent: Ukuran badan respons, merepresentasikan lalu lintas keluar.

Permintaan yang tidak cocok dengan entri rute diidentifikasi dalam log akses oleh nilai response_code_details sebesar route_not_found dan nilai response_flags sebesar NR.

Menelusuri sumber permintaan yang tidak cocok dengan entri rute

Setelah Anda mengaktifkan fitur pengiriman log untuk gateway, Anda dapat melakukan kueri permintaan yang tidak cocok di Log Service dan menggunakan field log untuk mengidentifikasi alamat IP sumber. Log akses mencatat semua permintaan, termasuk yang gagal. Alamat IP sumber berada di field downstream_remote_address.

Di Log Service, jalankan kueri berikut untuk memfilter permintaan yang tidak cocok:

response_code_details: "route_not_found"

Dalam hasil kueri, periksa field-field berikut untuk mengidentifikasi sumber permintaan:

• downstream_remote_address: Alamat klien yang terhubung ke gateway.

• x-forwarded-for: Field x-forwarded-for dari header permintaan HTTP, yang menunjukkan alamat IP sumber asli permintaan. Jika permintaan melewati proxy, field ini mungkin berisi beberapa alamat IP. Alamat IP terakhir adalah alamat hop sebelumnya sebelum gateway.

Untuk menghitung konsumsi traffic dari permintaan abnormal ini, jalankan kueri berikut di Log Service:

response_code_details: "route_not_found" | SELECT sum(bytes_sent + bytes_received) AS total_bytes

Bagaimana cara menambahkan header Referer klien ke log permintaan Cloud-native API Gateway?

Header Referer tidak dicatat dalam log akses gateway secara default. Untuk menangkapnya, aktifkan fitur pengiriman log dan konfigurasikan aturan pencocokan header kustom di Konsol gateway untuk menyertakan Referer sebagai field header kustom dalam output log.

Untuk informasi lebih lanjut tentang fitur pengiriman log, lihat Enable log delivery for a gateway.