全部产品
Search

搜索本产品

    Server Load Balancer：FAQ tentang ALB

    文档中心

    Server Load Balancer：FAQ tentang ALB

    更新时间：Jul 06, 2025

    Topik ini menjawab beberapa pertanyaan umum (FAQ) terkait Application Load Balancer (ALB).

    Apakah Alibaba Cloud menyediakan instance ALB dengan spesifikasi berbeda?

    Tidak, Alibaba Cloud tidak menyediakan spesifikasi berbeda untuk instance ALB. Instance ALB yang ditingkatkan dapat secara otomatis menskalakan alamat IP virtual (VIP), masing-masing mampu menangani hingga 1 juta QPS. Untuk detail performa ALB, lihat Metrik Performa.

    Catatan

    Instance ALB yang belum ditingkatkan membedakan antara mode IP statis dan dinamis. Dalam mode IP statis, VIP yang digunakan oleh instance ALB tetap. Dalam mode IP dinamis, lebih banyak VIP dapat digunakan seiring meningkatnya beban, masing-masing instance mampu mencapai 1 juta QPS.

    Untuk informasi lebih lanjut tentang performa instance ALB, lihat bagian Metrik Performa dari topik "Apa itu ALB?".

    Bagaimana cara meningkatkan bandwidth Internet maksimum dari sebuah instance ALB?

    Jika instance ALB ditempatkan di dua zona dan tidak diasosiasikan dengan instance Bandwidth Internet Bersama, bandwidth Internet maksimum default dari instance ALB adalah 400 Mbit/s.

    Jika Anda membutuhkan lebih banyak bandwidth, Anda dapat membeli instance Bandwidth Internet Bersama dan mengasosiasikan elastic IP addresses (EIPs) dari instance ALB Anda dengan instance Bandwidth Internet Bersama.

    Bagaimana cara memodifikasi konfigurasi pemeriksaan kesehatan dari sebuah listener?

    1. Masuk ke konsol ALB.

    2. Di panel navigasi sisi kiri, pilih ALB > Server Groups.

    3. Di halaman Server Groups, cari grup server yang ingin dikelola, lalu klik ID-nya.

    4. Di tab Details, klik Modify Health Check di bagian Pemeriksaan Kesehatan.

    5. Di kotak dialog Modify Health Check, klik Modify di sebelah kanan Health Check Settings dan modifikasi pengaturannya. Klik Save.

      Untuk informasi lebih lanjut, lihat Pemeriksaan Kesehatan.

    Mengapa kode status 502 dikembalikan ketika tidak ada pengecualian yang terdeteksi selama pemeriksaan kesehatan?

    Ini karena server backend dari instance ALB kelebihan beban. Jika server backend dari instance ALB Anda kelebihan beban, permintaan akses mungkin gagal mendapatkan respons meskipun hasil pemeriksaan kesehatan normal. Untuk informasi lebih lanjut, lihat Memecahkan masalah dan menyelesaikan masalah beban tinggi pada instance Linux.

    Dapatkah saya menggunakan rencana transfer data untuk mengimbangi biaya transfer data Internet untuk ALB?

    • Jika instance ALB Anda menggunakan EIP untuk menyediakan layanan melalui Internet, Anda dapat menggunakan rencana transfer data untuk mengimbangi biaya bandwidth publik.

    • Jika instance ALB Anda menggunakan Anycast EIP untuk menyediakan layanan melalui Internet, Anda tidak dapat menggunakan rencana transfer data untuk mengimbangi biaya transfer data Internet.

    Apakah ALB mendukung autentikasi timbal balik?

    Instance ALB dasar tidak mendukung autentikasi timbal balik. Anda dapat mengaktifkan autentikasi timbal balik untuk listener HTTPS dari instance ALB standar atau yang diaktifkan Web Application Firewall (WAF). Anda harus mengubah edisi instance ALB dasar Anda menjadi standar atau diaktifkan WAF sebelum Anda dapat mengonfigurasi autentikasi timbal balik.

    Sertifikat otoritas sertifikat (CA) yang digunakan untuk autentikasi timbal balik dapat ditandatangani oleh Alibaba Cloud atau pihak ketiga.

    • Pilih atau beli sertifikat CA pribadi yang ditandatangani oleh Alibaba Cloud.

    • Pilih atau tambahkan ke ALB sertifikat CA yang ditandatangani oleh pihak ketiga. Saat mengonfigurasi sertifikat, klik Upload Self-signed CA Certificate di daftar drop-down Default CA Certificate. Di halaman Certificate Application Repository, buat repositori yang Data Source-nya adalah Upload CA certificates. Di halaman detail repositori, unggah sertifikat root CA tanda tangan sendiri atau sertifikat intermediate CA tanda tangan sendiri.

    Untuk mengonfigurasi autentikasi timbal balik, pilih sertifikat dari Layanan Manajemen Sertifikat Alibaba Cloud atau beli sertifikat CA. Untuk informasi lebih lanjut, lihat Beli dan aktifkan CA pribadi.

    Apa saja persyaratan yang harus dipenuhi oleh sertifikat listener wildcard?

    Saat Anda mengonfigurasi sertifikat wildcard untuk listener HTTPS, perhatikan batasan berikut:

    • Saat Anda memilih sertifikat wildcard, ALB dapat mengidentifikasi sertifikat yang hanya berisi satu karakter wildcard (*), yang harus berada di sisi paling kiri nama domain. Misalnya, ALB dapat mengidentifikasi *.example.com dan *test.example.com, tetapi tidak dapat mengidentifikasi test*.example.com.

    • Persyaratan untuk sertifikat wildcard:

      • Tingkat domain wildcard: Domain wildcard dapat mencocokkan nama domain tertentu yang memiliki tingkat yang sama dengan domain wildcard tersebut. Misalnya, *.example.com dapat mencocokkan test.example.com tetapi tidak dapat mencocokkan test.test.example.com, yang satu tingkat lebih rendah dari domain wildcard.

      • Nama domain internasional (IDNAs):

        • Jika karakter wildcard adalah satu-satunya karakter wildcard dan berada di sisi paling kiri nama domain wildcard, IDNA dapat mencocokkan nama domain wildcard. Misalnya, xn--fsqu00a.example.com dapat mencocokkan *.example.com.

        • Jika karakter wildcard tidak berada di sisi paling kiri nama domain wildcard, IDNA tidak dapat mencocokkan nama domain wildcard. Misalnya, xn--fsqu00atest.example.com tidak dapat mencocokkan *test.example.com.

      • Ruang lingkup pencocokan: Karakter wildcard (*) dapat mencocokkan digit, huruf, dan tanda hubung (-). Misalnya, *.example.com dapat mencocokkan test.example.com tetapi tidak dapat mencocokkan test_test.example.com.

    Jenis elastic IP addresses (EIPs) apa yang dapat diasosiasikan dengan instance ALB?

    ALB hanya mendukung EIP bayar sesuai penggunaan. Tabel berikut menjelaskan jenis EIP yang dapat diasosiasikan dengan instance ALB.

    Metode Penagihan

    Metode Pengukuran Internet

    Jenis Jalur

    Perlindungan Keamanan

    Bayar sesuai penggunaan

    Bayar berdasarkan transfer data

    BGP (Multi-ISP)

    Default

    Bayar berdasarkan transfer data

    BGP (Multi-ISP) Pro

    Default

    Bayar berdasarkan transfer data

    BGP (Multi-ISP)

    Anti-DDoS Pro/Premium

    Saat Anda mengasosiasikan EIP dengan instance ALB, perhatikan batasan berikut:

    • EIP yang dialokasikan ke zona berbeda dari instance ALB yang sama harus memiliki jenis yang sama.

    • EIP yang ingin Anda asosiasikan dengan instance ALB tidak dapat diasosiasikan dengan paket bandwidth EIP. Anda dapat mengasosiasikan instance Bandwidth Internet Bersama dengan instance ALB di konsol ALB setelah Anda mengasosiasikan EIP dengan instance ALB. Instance Bandwidth Internet Bersama harus menggunakan jenis jalur yang sama dengan EIP. Instance Bandwidth Internet Bersama berlangganan dan bayar sesuai penggunaan didukung. Untuk informasi lebih lanjut tentang cara mengasosiasikan instance Bandwidth Internet Bersama dengan instance ALB, lihat Modifikasi bandwidth maksimum.

    • Anda tidak dapat mengasosiasikan EIP berlangganan atau EIP bayar sesuai penggunaan yang menggunakan metode pengukuran bayar berdasarkan bandwidth dengan instance ALB.

    • Jika Anda memilih Purchase EIP atau Automatically assign EIP saat Anda menetapkan EIP ke instance ALB, EIP bayar sesuai penggunaan yang menggunakan metode pengukuran bayar berdasarkan transfer data dibuat. EIP menggunakan jalur BGP (Multi-ISP) dan dilindungi oleh Anti-DDoS Origin Basic.

    Dapatkah saya mengasosiasikan EIP dengan instance ALB akses internal?

    Ya, Anda dapat mengasosiasikan EIP dengan instance ALB akses internal setelah Anda mengubah tipe jaringan instance ALB menjadi akses Internet.

    Untuk mengaitkan EIP dengan instance ALB akses internal, ubah tipe jaringan dari instance tersebut. Anda dapat mengubah instance ALB akses internal menjadi instance ALB akses Internet. Untuk informasi lebih lanjut, lihat Ubah tipe jaringan dari instance ALB.

    Setelah Anda mengubah tipe jaringan menjadi akses Internet, instance ALB menggunakan EIP untuk menyediakan layanan melalui Internet. Anda akan dikenakan biaya untuk transfer data melalui Internet. Untuk informasi lebih lanjut, lihat Bayar sesuai penggunaan.

    Dapatkah saya mengunggah sertifikat di konsol ALB?

    Tidak, Anda tidak dapat mengunggah sertifikat di konsol ALB.

    ALB menggunakan sertifikat dari Layanan Manajemen Sertifikat Alibaba Cloud. Anda harus mengunggah sertifikat Anda di konsol Layanan Manajemen Sertifikat, bukan di konsol ALB. Untuk informasi lebih lanjut, lihat Unggah sertifikat SSL.

    Apakah ALB mendukung pemantulan lalu lintas?

    Ya, ALB mendukung pemantulan lalu lintas. Untuk informasi lebih lanjut, lihat Cerminkan lalu lintas produksi ke lingkungan staging.

    Dapatkah saya beralih instance ALB dari IPv4 ke dual-stack atau dari dual-stack ke IPv4?

    Tidak, Anda tidak dapat beralih mode IP dari instance ALB.

    Jika Anda membutuhkan instance ALB IPv4 atau dual-stack, buatlah satu.

    Apa yang perlu saya perhatikan saat menghapus catatan DNS?

    Instance ALB yang ditingkatkan mendukung fitur penghapusan dan pemulihan catatan DNS.

    Catatan

    Sebelum peningkatan, instance ALB dalam mode IP statis mendukung fitur ini, sedangkan instance ALB dalam mode IP dinamis tidak.

    Setelah Anda menghapus catatan DNS untuk suatu zona, pemeriksaan pada VIP yang digunakan di zona tersebut berhenti. Sementara itu, EIP atau VIP yang digunakan di zona tersebut, termasuk alamat IPv4 dan IPv6, dihapus. Menghapus hanya alamat IPv4 atau IPv6 saja tidak didukung.

    Apa perbedaan antara mode proxy transparan WAF 2.0 dan mode integrasi layanan WAF 3.0?

    Berikut ini menjelaskan perbedaan antara mode proxy transparan WAF 2.0 dan mode integrasi layanan WAF 3.0:

    • Mode proxy transparan WAF 2.0: Permintaan difilter oleh WAF sebelum permintaan diteruskan ke ALB atau CLB. Dalam mode proxy transparan, permintaan melewati dua gateway. Anda harus mengonfigurasi periode timeout dan sertifikat untuk WAF dan Server Load Balancer (SLB).

    • Mode integrasi layanan WAF 3.0: WAF ditempatkan dalam mode bypass dan permintaan langsung diteruskan ke ALB. Sebelum permintaan diteruskan ke server backend, ALB mengekstrak dan mengirimkan isi permintaan ke WAF untuk penyaringan. Dalam mode integrasi layanan, permintaan melewati satu gateway. Ini menghilangkan kebutuhan untuk menyinkronkan sertifikat dan pengaturan antar gateway, serta mencegah masalah sinkronisasi.

    Untuk informasi lebih lanjut, lihat Bandingkan WAF 3.0 dan WAF 2.0.

    Bagaimana cara mengintegrasikan WAF dengan ALB?

    ALB terintegrasi dengan WAF 3.0. Jika Anda ingin instance ALB Anda dilindungi oleh WAF, belilah instance ALB yang diaktifkan WAF. Saat Anda membeli instance ALB yang diaktifkan WAF, perhatikan informasi berikut:

    • Jika akun Alibaba Cloud Anda tidak memiliki instance WAF 2.0 atau belum mengaktifkan WAF: Anda dapat mengaktifkan WAF 3.0 untuk instance ALB yang menghadap Internet dan akses internal dengan membeli instance ALB yang telah diaktifkan WAF. Dengan cara ini, ALB terhubung dengan WAF pada tingkat layanan. Untuk informasi lebih lanjut, lihat Aktifkan dan kelola instance ALB yang diaktifkan WAF.

      Wilayah yang mendukung instance ALB dengan WAF aktif (Wilayah di mana ALB terintegrasi dengan WAF 3.0)

      Area

      Wilayah

      Cina

      Cina (Chengdu), Cina (Qingdao), Cina (Beijing), Cina (Guangzhou), Cina (Hangzhou), Cina (Ulanqab), Cina (Shanghai), Cina (Shenzhen), Cina (Zhangjiakou), dan Cina (Hong Kong)

      Asia Pasifik

      Filipina (Manila), Indonesia (Jakarta), Jepang (Tokyo), Malaysia (Kuala Lumpur), Singapura, dan Thailand (Bangkok)

      Eropa dan Amerika

      Jerman (Frankfurt), AS (Silicon Valley), dan AS (Virginia)

      Timur Tengah

      SAU (Riyadh - Wilayah Mitra)

    • Jika akun Alibaba Cloud Anda sudah memiliki instance WAF 2.0: Anda dapat mengaktifkan WAF 2.0 untuk instance ALB Internet-facing dasar dan instance ALB Internet-facing standar dalam mode proxy transparan. Instance ALB yang menghadap internal tidak mendukung WAF 2.0.

      Hanya instance ALB di wilayah berikut yang dapat dihubungkan dengan WAF 2.0 dalam mode proxy transparan: Cina (Hangzhou), Cina (Shanghai), Cina (Shenzhen), Cina (Chengdu), Cina (Beijing), dan Cina (Zhangjiakou).

      Catatan

      Jika Anda ingin mengaktifkan WAF 3.0 untuk instance ALB Anda, lepaskan instance WAF 2.0 terlebih dahulu atau migrasikan ke WAF 3.0.

      • Setelah Anda melepaskan instance WAF 2.0, kesalahan layanan mungkin muncul karena header X-Forwarded-Proto dinonaktifkan secara default untuk ALB. Anda harus mengaktifkan header X-Forwarded-Proto untuk listener instance ALB untuk mencegah kesalahan. Untuk informasi lebih lanjut, lihat Kelola listener.

      • Untuk informasi lebih lanjut tentang cara melepaskan instance WAF 2.0, lihat Hentikan layanan WAF.

      • Untuk informasi lebih lanjut tentang cara bermigrasi ke WAF 3.0, lihat Migrasikan instance WAF 2.0 ke WAF 3.0.

    Apakah CLB dan ALB mendukung WAF 2.0 dan WAF 3.0?

    Layanan

    WAF 2.0 (mode proxy transparan)

    WAF 3.0 (mode integrasi layanan)

    CLB

    Didukung.

    Untuk informasi lebih lanjut tentang cara menghubungkan WAF 2.0 ke CLB dalam mode proxy transparan, lihat topik berikut:

    Tidak didukung.

    ALB

    • Jika akun Alibaba Cloud Anda memiliki instance WAF 2.0, Anda dapat menghubungkan instance WAF 2.0 ke ALB dalam mode proxy transparan. Untuk informasi lebih lanjut, lihat bagian Konfigurasikan port pengalihan untuk instance ALB dari "Konfigurasikan port pengalihan lalu lintas".

    • Jika akun Alibaba Cloud Anda tidak memiliki instance WAF 2.0 atau belum mengaktifkan WAF, Anda hanya dapat menghubungkan WAF 3.0 ke ALB. Dalam hal ini, Anda harus membeli instance ALB yang diaktifkan WAF.

    Didukung.

    Untuk informasi lebih lanjut tentang wilayah yang didukung dan operasi terkait, lihat Aktivasi dan kelola instance ALB yang diaktifkan WAF.

    Mengapa periode timeout dan sertifikat tidak disinkronkan setelah saya mengintegrasikan WAF 2.0 dengan ALB atau CLB?

    Setelah Anda mengintegrasikan WAF 2.0 dengan ALB atau CLB, permintaan klien difilter oleh WAF sebelum diteruskan ke ALB atau CLB. Permintaan melewati dua gateway, dan Anda harus menyinkronkan pengaturan antara WAF dan ALB atau CLB. Jika Anda mengubah periode timeout atau sertifikat, masalah sinkronisasi mungkin terjadi karena latensi.

    Jika sertifikat tidak diperbarui atau perubahan periode timeout tidak berlaku, bergabunglah dengan grup DingTalk 21715946 untuk konsultasi.

    Mengapa instance ALB gagal mencapai QPS maksimum yang dikonfigurasikan dalam aturan pengalihan listener?

    • Cara kerja: ALB menyediakan layanan load balancing dengan mendistribusikan lalu lintas jaringan secara merata di seluruh grup server backend. QPS maksimum yang Anda konfigurasikan dalam aturan pengalihan didistribusikan secara merata ke setiap server backend.

      QPS maksimum setiap server backend dihitung menggunakan rumus berikut: QPS Maksimum setiap server backend = Total QPS/(N-1). N menentukan jumlah server backend dalam grup server. Misalnya, Anda menetapkan QPS maksimum menjadi 1.000 dalam aturan pengalihan. Jika jumlah server backend adalah 8, QPS maksimum setiap server backend dihitung menggunakan rumus berikut: 1000/(8-1) = 142.

    • Penyebab: Dalam skenario di mana sejumlah kecil koneksi persisten digunakan, tidak semua server backend dalam grup server dialokasikan koneksi persisten. Akibatnya, instance ALB tidak dapat mencapai QPS maksimum.

    • Saran: Untuk mencegah gangguan layanan, kami sarankan Anda menetapkan QPS maksimum dalam aturan pengalihan ke nilai yang sesuai berdasarkan kebutuhan bisnis Anda. Untuk informasi lebih lanjut tentang cara menetapkan QPS maksimum dalam aturan pengalihan, lihat bagian Buat aturan pengalihan dari topik "Kelola aturan pengalihan untuk listener".

    Berapa ukuran maksimum permintaan yang dapat diteruskan oleh instance ALB? Dapatkah saya menaikkan ukuran maksimum yang diizinkan?

    Ukuran maksimum URI atau header HTTP dari permintaan klien adalah 32 KB. Anda tidak dapat menaikkan ukuran maksimum yang diizinkan. Ukuran maksimum default header kustom yang dapat direkam dalam log akses adalah 1 KB, yang dapat ditingkatkan hingga 4 KB. Untuk meminta peningkatan, hubungi manajer akun Anda.

    • Jika ukuran URI atau header HTTP dari permintaan klien melebihi ukuran maksimum, kode status HTTP 400 atau 414 mungkin dikembalikan. Untuk informasi lebih lanjut, lihat Kode status ALB.

    • Jika Anda ingin mentransmisikan sejumlah besar data, kami sarankan Anda menggunakan metode POST untuk mentransmisikan data. Body permintaan POST ke ALB dapat mencapai ukuran hingga 50 GB.

    Bagaimana instance ALB meneruskan permintaan jika semua server backend di backend server yang sama tidak sehat?

    ALB mendistribusikan permintaan berdasarkan algoritma penjadwalan untuk mempertahankan ketersediaan layanan. Untuk mengatasi masalah ini, Anda dapat memeriksa log untuk menentukan apakah server backend mengalami kesalahan, atau memeriksa konfigurasi pemeriksaan kesehatan. Untuk informasi lebih lanjut, lihat Pemecahan masalah pemeriksaan kesehatan ALB.

    Mengapa kode status HTTP 500, 502, 503, dan 504 dikembalikan?

    500 (Internal Server Error)

    Kesalahan internal terjadi pada server backend. Permintaan tidak dapat diproses oleh server backend.

    Penyebab potensial:

    • Server backend mengembalikan kode status HTTP 500, dan ALB meneruskan kode status backend ke klien. Periksa mengapa server backend mengembalikan kode status HTTP 500.

    • Server backend menutup koneksi sebelum mengirim respons. Kami sarankan Anda menangkap paket di server backend untuk menentukan penyebab dan memperbaiki masalah.

    502 (Bad Gateway)

    Listener HTTP atau HTTPS dari ALB gagal mengirim permintaan ke server backend atau tidak ada respons yang dikembalikan dari server backend. Akibatnya, kode status HTTP 502 dikembalikan ke klien.

    Penyebab potensial:

    • Server backend mengembalikan kode status HTTP 502, dan ALB meneruskan kode status backend ke klien. Periksa mengapa server backend mengembalikan kode status HTTP 502.

    • Server backend ALB mengembalikan kode status HTTP lainnya (seperti 504 dan 444), tetapi ALB mengembalikan kode status HTTP 502. Kami sarankan Anda memeriksa bidang upstream_status dan status di log akses atau menangkap paket untuk memeriksa apakah server backend memiliki kesalahan.

    • Komunikasi antara ALB dan server backend melalui TCP mengandung kesalahan. Periksa apakah server backend sehat, apakah port layanan didengarkan oleh listener, atau apakah handshake TCP berhasil.

    • Antrian backlog server backend penuh, yang menyebabkan paket dijatuhkan. Kami sarankan Anda menggunakan netstat untuk memeriksa apakah statistik jaringan server backend menunjukkan jumlah paket yang dijatuhkan. Misalnya, Anda dapat menjalankan perintah netstat -s | grep -i listen.

    • Panjang paket yang dikirim oleh klien melebihi unit transmisi maksimum (MTU) server backend. Dalam hal ini, pemeriksaan kesehatan berhasil, atau paket yang lebih pendek dikirim seperti yang diharapkan. Namun, paket yang lebih panjang tidak dikirim seperti yang diharapkan. Kami sarankan Anda menangkap paket di server backend untuk menganalisis apakah panjang paket memenuhi persyaratan.

    • Paket yang dikembalikan oleh server backend dalamformat yang tidak valid atau berisi header HTTP yang tidak valid. Kami sarankan Anda menangkap paket di server backend untuk memeriksa apakah format respons HTTP tidak valid.

    • Server backend dari ALB belum menyelesaikan pemrosesan permintaan. Periksa data log server backend. Selain itu, periksa penggunaan CPU dan memori.

    503 (Service Temporarily Unavailable)

    Layanan tidak tersedia. Hal ini karena lalu lintas melebihi batas atau server backend tidak tersedia.

    Penyebab potensial:

    • Server backend mengembalikan kode status HTTP 503, dan ALB meneruskan kode status backend ke klien. Periksa mengapa server backend mengembalikan kode status HTTP 503.

    • Lalu lintas jaringan dari klien memicu pembatasan laju ALB. Anda dapat menggunakan salah satu metode berikut untuk memperbaiki masalah:

      • Lihat jumlah permintaan per detik di konsol CloudMonitor. Untuk informasi lebih lanjut, lihat Metrik pemantauan ALB dan Lihat informasi pemantauan instance ALB.

      • CloudMonitor menampilkan data pemantauan pada level menit. Anda dapat melihat jumlah permintaan per detik menggunakan log akses. Lihat bidang upstream_status dari log akses. Jika kontennya adalah "-", permintaan tidak dikirim ke server backend.

      • Periksa apakah header respons berisi bidang ALB-QPS-Limited:Limited. Jika ya, itu menunjukkan bahwa permintaan telah memicu pembatasan laju ALB.

    • Klien mengakses alamat IP instance ALB daripada menggunakan nama domain ketika klien mengakses ALB, atau tidak memperbarui hasil resolusi DNS ketika klien menggunakan nama domain untuk mengakses ALB. Akibatnya, permintaan tidak dapat didistribusikan di antara beberapa alamat IP ALB dan kode kesalahan HTTP 503 dikembalikan. Kami sarankan klien mengakses nama domain ALB daripada alamat IP. Selain itu, pastikan klien menggunakan alamat IP berbeda yang dikembalikan oleh DNS untuk mengakses ALB.

    • Tidak ada server backend yang diasosiasikan dengan listener ALB atau bobot server backend diatur ke 0.

    504 (Gateway Time-out)

    Respons server backend habis waktu.

    Penyebab potensial:

    • Jika kode status 504 dikembalikan oleh server backend, periksa apakah server backend kelebihan beban.

    • Koneksi dari ALB ke server backend habis waktu. Periode timeout diatur ke 5 detik secara default. Anda dapat memeriksa apakah bidang upstream_connect_time di log akses diatur ke 5 detik atau sekitar 5 detik. Kami sarankan Anda menangkap paket untuk menentukan penyebab timeout respons.

    • Beban kerja di server backend berat dan waktu yang diperlukan untuk mengembalikan respons lebih lama daripada periode timeout yang ditentukan. Misalnya, periode timeout permintaan diatur ke 60 detik. Jika waktu respons adalah 60,001 detik, ALB mengembalikan kode status HTTP 504. Anda dapat melihat latensi jaringan selama periode terjadinya masalah di konsol CloudMonitor atau di log akses. Untuk melihat latensi jaringan, periksa bidang upstream_rt di CloudMonitor, atau bidang upstream_response_time di log akses.

    Apa yang perlu saya perhatikan saat menggunakan Ingress ALB?

    Kontroler Ingress ALB menggunakan objek AlbConfig untuk mengonfigurasi instance ALB. Kami sarankan agar Anda tidak memodifikasi konfigurasi instance ALB yang dibuat menggunakan kontroler Ingress ALB di konsol ALB. Untuk informasi lebih lanjut tentang Ingress ALB, lihat Manajemen Ingress ALB dan Fitur Ingress ALB.

    Jika Anda memodifikasi konfigurasi instance ALB yang dibuat menggunakan kontroler Ingress ALB di konsol ALB, konfigurasi yang dimodifikasi secara manual akan ditimpa oleh objek AlbConfig. Ini dapat menyebabkan pengecualian, seperti fitur log akses dinonaktifkan dan aturan routing dihapus.

    FAQ tentang fitur CORS ALB

    Mengapa konfigurasi untuk berbagi sumber daya lintas domain (CORS) tidak berlaku dan browser melempar kesalahan permintaan preflight?

    Jika nama header tertentu alih-alih asterisk (*) ditentukan untuk parameter Header Permintaan yang Diizinkan, Anda dapat mengatur Header Permintaan yang Diizinkan ke asterisk (*) untuk pengujian. Jika masalah teratasi, periksa apakah atribut header_name dalam Access-Control-Request-Headers termasuk dalam konfigurasi. Jika tidak, ketiadaan atribut header_name adalah penyebab kegagalan.

    Mengapa permintaan preflight dan permintaan aktual menggunakan aturan pengalihan yang berbeda?

    ALB mendukung beberapa metode pencocokan untuk aturan pengalihan. Namun, header dan metode permintaan preflight dalam CORS bersifat khusus dan berbeda dari permintaan aktual. Kami sarankan Anda menggunakan nama domain untuk mengonfigurasi aturan pengalihan saat menggunakan CORS. Ini memastikan bahwa permintaan preflight dan permintaan aktual tidak cocok dengan aturan pengalihan yang tidak dikonfigurasikan dengan aturan CORS.