全部产品
Search

搜索本产品

    Server Load Balancer：FAQ tentang ALB

    文档中心

    Server Load Balancer：FAQ tentang ALB

    更新时间：Dec 19, 2025

    Topik ini menyediakan jawaban atas beberapa pertanyaan yang sering diajukan (FAQ) mengenai Application Load Balancer (ALB).

    Apakah Alibaba Cloud menyediakan instans ALB dengan spesifikasi berbeda?

    Tidak, Alibaba Cloud tidak menyediakan spesifikasi berbeda untuk instans ALB. Instans ALB yang ditingkatkan dapat melakukan auto-scale alamat IP virtual (VIP), masing-masing mampu menangani hingga 1 juta QPS. Untuk detail performa ALB, lihat Metrik performa.

    Catatan

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

    Untuk informasi lebih lanjut mengenai performa instans ALB, lihat bagian Metrik performa pada topik "Apa itu ALB?".

    Bagaimana cara meningkatkan bandwidth Internet maksimum instans ALB?

    Jika instans ALB (dideploy di dua zona) tidak dikaitkan dengan instans Bandwidth Internet Bersama apa pun, bandwidth maksimum instans ALB adalah 400 Mbps secara default.

    Jika Anda memerlukan nilai bandwidth maksimum yang lebih besar, Anda dapat membeli instans Bandwidth Internet Bersama dan mengaitkan elastic IP addresses (EIPs) dari instans ALB Anda dengan instans Bandwidth Internet Bersama tersebut.

    Bagaimana cara mengubah konfigurasi pemeriksaan kesehatan suatu listener?

    1. Masuk ke Konsol ALB.

    2. Pada panel navigasi sebelah kiri, pilih ALB > Server Groups.

    3. Pada halaman Server Groups, temukan kelompok server yang ingin Anda kelola dan klik ID-nya.

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

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

      Untuk informasi lebih lanjut, lihat Pemeriksaan kesehatan.

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

    Hal ini karena server backend instans ALB mengalami kelebihan beban. Jika server backend instans ALB Anda mengalami kelebihan beban, permintaan akses mungkin gagal merespons meskipun hasil pemeriksaan kesehatan normal. Untuk informasi lebih lanjut, lihat Pemecahan masalah beban tinggi pada instans Linux.

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

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

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

    Apakah ALB mendukung otentikasi timbal balik?

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

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

    • Pilih atau beli sertifikat CA privat 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 pada daftar drop-down Default CA Certificate. Pada halaman Certificate Application Repository, buat repositori yang Data Source-nya adalah Upload CA certificates. Pada halaman detail repositori, unggah sertifikat root CA self-signed atau sertifikat intermediate CA self-signed.

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

    Persyaratan apa saja 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 mengenali sertifikat yang hanya berisi satu karakter wildcard (*), yang harus berada di sisi paling kiri nama domain. Misalnya, ALB dapat mengenali *.example.com dan *test.example.com, tetapi tidak dapat mengenali test*.example.com.

    • Persyaratan untuk sertifikat wildcard:

      • Tingkat nama domain wildcard: Nama domain wildcard dapat mencocokkan nama domain tertentu yang berada pada tingkat yang sama dengan nama domain wildcard tersebut. Misalnya, *.example.com dapat mencocokkan test.example.com tetapi tidak dapat mencocokkan test.test.example.com, yang berada satu tingkat di bawah nama domain wildcard.

      • Nama domain internasional (IDNA):

        • Jika karakter wildcard adalah satu-satunya karakter wildcard dan berada di sisi paling kiri nama domain wildcard, IDNA dapat mencocokkan nama domain wildcard tersebut. 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 tersebut. Misalnya, xn--fsqu00atest.example.com tidak dapat mencocokkan *test.example.com.

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

    Jenis EIP apa saja yang dapat dikaitkan dengan instans ALB?

    ALB hanya mendukung EIP pay-as-you-go. Tabel berikut menjelaskan jenis EIP yang dapat dikaitkan dengan instans ALB.

    Metode penagihan

    Metode pengukuran Internet

    Jenis jalur

    Proteksi keamanan

    Pay-as-you-go

    Pay-by-data-transfer

    BGP (Multi-ISP)

    Default

    Pay-by-data-transfer

    BGP (Multi-ISP) Pro

    Default

    Pay-by-data-transfer

    BGP (Multi-ISP)

    Anti-DDoS Pro/Premium

    Saat Anda mengaitkan EIP dengan instans ALB, perhatikan batasan berikut:

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

    • EIP yang ingin Anda kaitkan dengan instans ALB tidak boleh dikaitkan dengan paket bandwidth EIP. Anda dapat mengaitkan instans Bandwidth Internet Bersama dengan instans ALB di konsol ALB setelah Anda mengaitkan EIP dengan instans ALB tersebut. Instans Bandwidth Internet Bersama harus menggunakan jenis jalur yang sama dengan EIP. Instans Bandwidth Internet Bersama langganan dan instans Bandwidth Internet Bersama pay-as-you-go didukung. Untuk informasi lebih lanjut tentang cara mengaitkan instans Bandwidth Internet Bersama dengan instans ALB, lihat Ubah bandwidth maksimum.

    • Anda tidak dapat mengaitkan EIP langganan atau EIP pay-as-you-go yang menggunakan metode pengukuran pay-by-bandwidth dengan instans ALB.

    • Jika Anda memilih Purchase EIP atau Automatically assign EIP saat mengalokasikan EIP ke instans ALB, EIP pay-as-you-go yang menggunakan metode pengukuran pay-by-data-transfer akan dibuat. EIP tersebut menggunakan jalur BGP (Multi-ISP) dan dilindungi oleh Anti-DDoS Origin Basic.

    Dapatkah saya mengaitkan EIP dengan instans ALB akses internal?

    Ya, Anda dapat mengaitkan EIP dengan instans ALB akses internal setelah Anda mengubah jenis jaringan instans ALB tersebut menjadi akses Internet.

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

    Setelah Anda mengubah jenis jaringan menjadi akses Internet, instans ALB menggunakan EIP untuk menyediakan layanan melalui Internet. Anda akan dikenai biaya untuk transfer data melalui Internet. Untuk informasi lebih lanjut, lihat Pay-as-you-go.

    Bagaimana cara mengubah EIP instans ALB saya menjadi EIP dengan jenis jalur BGP (Multi-ISP) Pro?

    Anda dapat melakukannya dengan mengubah jenis jaringan instans ALB dalam proses dua langkah:

    1. Ubah jenis jaringan instans ALB dari akses Internet menjadi internal. Tindakan ini akan memutus kaitan EIP saat ini dari instans tersebut.

    2. Ubah kembali jenis jaringan dari internal menjadi akses Internet. Selama konversi ini, Anda akan diminta untuk memilih EIP baru. Pada langkah ini, pilih dua EIP dengan jenis jalur BGP (Multi-ISP) Pro yang telah Anda buat.

    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 pencerminan lalu lintas?

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

    Dapatkah saya mengubah instans ALB dari IPv4 ke dual-stack atau dari dual-stack ke IPv4?

    Tidak, Anda tidak dapat mengubah mode IP instans ALB.

    Jika Anda perlu menggunakan instans ALB IPv4 atau dual-stack, buat instans baru.

    Hal apa saja yang perlu saya perhatikan saat menghapus rekaman DNS?

    Instans ALB yang ditingkatkan mendukung fitur penghapusan dan pemulihan rekaman DNS.

    Catatan

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

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

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

    image

    Bagian berikut 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 diteruskan ke ALB atau CLB. Dalam mode proxy transparan, permintaan melewati dua gerbang. Anda harus mengonfigurasi periode timeout dan sertifikat untuk WAF dan Server Load Balancer (SLB).

    • Mode integrasi layanan WAF 3.0: WAF dideploy dalam mode bypass dan permintaan langsung diteruskan ke ALB. Sebelum permintaan diteruskan ke server backend, ALB mengekstrak dan mengirim konten permintaan ke WAF untuk difilter. Dalam mode integrasi layanan, permintaan hanya melewati satu gerbang. Hal ini menghilangkan kebutuhan untuk menyinkronkan sertifikat dan pengaturan antar gerbang, serta mencegah masalah sinkronisasi.

    Untuk informasi lebih lanjut, lihat Bandingkan WAF 3.0 dan WAF 2.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.

    Tidak didukung.

    ALB

    • Jika Akun Alibaba Cloud Anda memiliki instans WAF 2.0, Anda dapat menghubungkan instans WAF 2.0 tersebut ke ALB dalam mode proxy transparan. Untuk informasi lebih lanjut, lihat bagian Konfigurasikan port pengalihan pot untuk instans ALB pada topik "Konfigurasikan port pengalihan lalu lintas".

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

    Didukung.

    Untuk informasi lebih lanjut tentang wilayah yang didukung dan operasi terkait, lihat Aktifkan proteksi WAF untuk instans ALB.

    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 client difilter oleh WAF sebelum diteruskan ke ALB atau CLB. Permintaan tersebut melewati dua gerbang, dan Anda harus menyinkronkan pengaturan antara WAF dan ALB atau CLB. Jika Anda mengubah periode timeout atau sertifikat, masalah sinkronisasi dapat terjadi akibat latensi.

    Mengapa instans ALB gagal mencapai QPS maksimum yang dikonfigurasi dalam aturan pengalihan listener?

    • Cara kerja: ALB menyediakan layanan load balancing dengan mendistribusikan lalu lintas jaringan secara merata ke kelompok server backend. QPS maksimum yang Anda konfigurasi 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 menunjukkan jumlah server backend dalam kelompok server. Misalnya, Anda mengatur 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 jumlah koneksi persisten kecil digunakan, tidak semua server backend dalam kelompok server dialokasikan koneksi persisten. Akibatnya, instans ALB tidak dapat mencapai QPS maksimum.

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

    Berapa ukuran maksimum permintaan yang dapat diteruskan oleh instans ALB? Dapatkah saya menambah ukuran maksimum yang diizinkan?

    Ukuran maksimum URI atau header HTTP dari permintaan client adalah 32 KB. Anda tidak dapat menambah ukuran maksimum yang diizinkan. Ukuran maksimum default header kustom yang dapat dicatat 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 client melebihi ukuran maksimum, kode status HTTP 400 atau 414 mungkin dikembalikan. Untuk informasi lebih lanjut, lihat Kode status ALB.

    • Jika Anda ingin mentransmisikan data dalam jumlah besar, kami menyarankan agar Anda menggunakan metode POST untuk mentransmisikan data. Badan permintaan POST ke ALB dapat berukuran hingga 50 GB.

    Apakah waktu pemrosesan ALB mencakup waktu yang dihabiskan untuk menerima data client dan mengirim data respons?

    Ya, waktu pemrosesan ALB mencakup waktu yang diperlukan untuk menerima permintaan client secara lengkap dan mengirim respons kembali ke client. Waktu tersebut terdiri dari komponen-komponen berikut:

    • Waktu Penerimaan Permintaan (read_request_time): Ini adalah total waktu yang dihabiskan load balancer untuk membaca permintaan client. Ini merupakan jumlah dari:

      • Waktu Penerimaan Header (read_header_time): Waktu untuk menerima header permintaan HTTP.

      • Waktu Penerimaan Badan (read_body_time): Waktu untuk menerima badan permintaan HTTP.

    • Waktu Transmisi Respons: Ini mencakup waktu yang dihabiskan untuk mengirim data respons kembali ke client.

    Bagaimana instans ALB dapat meneruskan permintaan jika semua server backend dalam kelompok server backend tidak sehat?

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

    Hal apa saja yang perlu saya perhatikan saat menggunakan Ingress ALB?

    Controller Ingress ALB menggunakan objek AlbConfig untuk mengonfigurasi instans ALB. Kami menyarankan agar Anda tidak memodifikasi konfigurasi instans ALB yang dibuat menggunakan controller Ingress ALB secara manual di konsol ALB. Untuk informasi lebih lanjut tentang Ingress ALB, lihat Manajemen Ingress ALB dan Fitur Ingress ALB.

    Jika Anda memodifikasi konfigurasi instans ALB yang dibuat menggunakan controller Ingress ALB secara manual di konsol ALB, konfigurasi yang dimodifikasi secara manual tersebut akan ditimpa oleh objek AlbConfig. Hal ini dapat menyebabkan pengecualian, seperti dinonaktifkannya fitur log akses dan penghapusan aturan routing.

    FAQ tentang fitur CORS ALB

    Mengapa konfigurasi Berbagi sumber daya lintas asal (CORS) tidak berlaku dan browser melemparkan error permintaan preflight?

    Jika parameter Allowed Request Headers dikonfigurasi dengan nama header tertentu alih-alih tanda bintang (*), Anda dapat mengatur Allowed Request Headers ke tanda bintang (*) untuk pengujian. Jika masalah teratasi, periksa apakah atribut header_name dalam Access-Control-Request-Headers termasuk dalam konfigurasi. Jika tidak, ketidakhadiran atribut header_name tersebut merupakan penyebab kegagalan.

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

    ALB mendukung berbagai metode pencocokan untuk aturan pengalihan. Namun, header dan metode permintaan preflight dalam CORS bersifat khusus dan berbeda dari permintaan aktual. Kami menyarankan agar Anda menggunakan nama domain untuk mengonfigurasi aturan pengalihan saat menggunakan CORS. Hal ini memastikan bahwa permintaan preflight dan permintaan aktual tidak mencocokkan aturan pengalihan yang tidak dikonfigurasi dengan aturan CORS.

    Bagaimana header respons Access-Control-Allow-Headers ditangani?

    1. Permintaan preflight

      Saat browser memulai permintaan lintas asal yang memerlukan pemeriksaan preflight, browser terlebih dahulu mengirim permintaan menggunakan metode OPTIONS. Hal ini terjadi jika permintaan aktual bukan permintaan simple (misalnya, menggunakan metode seperti PUT atau DELETE, atau menyertakan header kustom).

      Permintaan preflight OPTIONS ini menyertakan header Access-Control-Request-Method.

      Sebagai respons terhadap permintaan preflight ini, ALB akan mengembalikan header Access-Control-Allow-Headers berdasarkan aturan CORS yang telah Anda konfigurasi di konsol. Nilai header ini akan berupa daftar header permintaan yang diizinkan oleh aturan Anda, dipisahkan koma. Contohnya:

      DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization

    2. Permintaan simple dan permintaan aktual

      Header Access-Control-Allow-Headers hanya dikembalikan untuk permintaan preflight (OPTIONS).

      Untuk permintaan lainnya, seperti permintaan lintas asal simple (yang tidak memerlukan preflight) atau permintaan aktual yang mengikuti preflight yang berhasil, ALB tidak akan menyertakan header Access-Control-Allow-Headers dalam responsnya.