All Products
Search
Document Center

Server Load Balancer:Aturan pengalihan untuk pencocokan domain dan path

Last Updated:Jun 25, 2026

Topik ini memberikan contoh konfigurasi aturan pengalihan ALB, mencakup pencocokan nama domain dan path, penulisan ulang (rewrite), serta pengalihan (redirect).

Contoh konfigurasi

Skenario 1: Mengalihkan HTTP ke HTTPS

Alihkan permintaan HTTP ke HTTPS untuk memastikan data dienkripsi selama transmisi. Anda dapat melakukannya dengan menambahkan aturan pengalihan ke listener HTTP (port 80).

Parameter

Deskripsi

Add Condition

Setel Path ke Exact Match and Wildcard dan masukkan /*.

Action

Pilih Redirect.

  • Protocol: Pilih HTTPS.

  • Domain Name: ${host}

  • Port: Masukkan port listener HTTPS yang sudah ada, misalnya 443.

  • Path: ${path}

  • Search: ${query}

  • Status Code: Pilih 301.

Hasil: Saat pengguna mengakses http://www.example.com/page, browser secara otomatis mengalihkan ke https://www.example.com/page.

Konfigurasikan aturan ini pada listener HTTP (port 80). Pastikan juga listener HTTPS (port 443) telah dibuat dan dikaitkan dengan Sertifikat SSL yang valid. Untuk prasyarat lengkap dan prosedurnya, lihat Gunakan ALB untuk mengalihkan permintaan HTTP ke HTTPS.

Skenario 2: Mengarahkan traffic berdasarkan path

Untuk satu domain, Anda dapat meneruskan permintaan dengan path berbeda ke kelompok server yang berbeda. Misalnya, permintaan API dan aset statis dapat diteruskan ke backend terpisah.

Aturan 1: Teruskan permintaan untuk /api/* ke kelompok server API.

Parameter

Deskripsi

Add Condition

Setel Path ke Exact Match and Wildcard dan masukkan /api/*.

Action

Pilih Forward, lalu pilih kelompok server API.

Aturan 2: Teruskan permintaan untuk /static/* ke kelompok server aset statis.

Parameter

Deskripsi

Add Condition

Setel Path ke Exact Match and Wildcard dan masukkan /static/*.

Action

Pilih Forward, lalu pilih kelompok server aset statis.

ALB mengevaluasi aturan pengalihan berdasarkan nomor prioritasnya. Tempatkan aturan path yang lebih spesifik (dengan nomor prioritas lebih rendah) sebelum aturan yang lebih umum agar tidak tertangkap oleh aturan wildcard terlebih dahulu. Misalnya, aturan untuk /api/v2/* harus memiliki nomor prioritas lebih rendah daripada aturan untuk /api/*.

Skenario 3: Meneruskan beberapa domain

Host beberapa domain pada satu instans ALB dan teruskan permintaan untuk setiap domain ke kelompok server backend masing-masing.

Aturan 1: Teruskan permintaan untuk www.example.com ke kelompok server web.

Parameter

Deskripsi

Add Condition

Setel Domain Name ke Exact Match and Wildcard dan masukkan www.example.com.

Action

Pilih Forward, lalu pilih kelompok server web.

Aturan 2: Teruskan permintaan untuk api.example.com ke kelompok server API.

Parameter

Deskripsi

Add Condition

Setel Domain Name ke Exact Match and Wildcard dan masukkan api.example.com.

Action

Pilih Forward, lalu pilih kelompok server API.

Skenario 4: Menghapus awalan path sebelum meneruskan

Hapus awalan tertentu dari path permintaan sebelum meneruskan ke backend, sambil tetap mempertahankan path multi-level setelah awalan tersebut. Misalnya, saat ALB meneruskan permintaan untuk www.example.com/api/aaa/bbb/..., bagian /api perlu dihapus dari path, tetapi path multi-level berikutnya seperti /aaa/bbb/... tetap dipertahankan.

Rewrite mengganti path secara internal dalam ALB; URL di bilah alamat browser klien tidak berubah. Redirect mengembalikan URL baru ke klien, sehingga bilah alamat browser diperbarui ke URL baru tersebut. Gunakan rewrite jika hanya backend yang perlu menerima path tanpa awalan. Gunakan redirect jika klien harus mengetahui perubahan URL tersebut.

Rewrite

Parameter

Deskripsi

Add Condition

Domain Name

Setel ke Exact Match and Wildcard dan masukkan www.example.com.

Path

Setel ke Regular Expression Match | Case Insensitive dan masukkan ^/api/(.*).

Action

Rewrite

  • Domain Name: ${host}

  • Path: /${1}

  • Search: ${query}

Forward

Pilih kelompok server target.

Redirect

Parameter

Deskripsi

Add Condition

Domain Name

Setel ke Exact Match and Wildcard dan masukkan www.example.com.

Path

Setel ke Regular Expression Match | Case Insensitive dan masukkan ^/api/(.*).

Action

Redirect

  • Protocol: ${protocol}

  • Domain Name: ${host}

  • Port: ${port}

  • Path: /${1}

  • Search: ${query}

  • Status Code: Pilih 301.

Hasil: Untuk permintaan ke www.example.com/api/aaa/bbb/..., server backend menerima path /aaa/bbb/....

Skenario 5: Mengalihkan domain telanjang ke www

Alihkan permintaan dari domain telanjang (seperti example.com) ke www.example.com. Hal ini menyatukan titik masuk untuk SEO yang lebih baik dan manajemen yang lebih mudah.

Parameter

Deskripsi

Add Condition

Setel Domain Name ke Exact Match and Wildcard dan masukkan example.com.

Action

Pilih Redirect.

  • Protocol: ${protocol}

  • Domain Name: Masukkan www.example.com.

  • Port: ${port}

  • Path: ${path}

  • Search: ${query}

  • Status Code: Pilih 301.

Hasil: Saat pengguna mengakses example.com, browser secara otomatis mengalihkan ke www.example.com. Protokol dan port tetap tidak berubah.

Jika Anda juga perlu mengalihkan permintaan HTTP ke HTTPS, gabungkan konfigurasi ini dengan Skenario 1.

Skenario 6: Mencocokkan domain wildcard

Gunakan domain wildcard untuk mencocokkan semua subdomain dan meneruskan permintaannya ke kelompok server yang sama.

Parameter

Deskripsi

Add Condition

Setel Domain Name ke Exact Match and Wildcard dan masukkan *.example.com.

Action

Pilih Forward, lalu pilih kelompok server target.

Hasil: Permintaan ke semua subdomain yang cocok, seperti a.example.com, b.example.com, dan tenant1.example.com, diteruskan ke kelompok server yang sama.

Untuk meneruskan subdomain tertentu ke kelompok server berbeda, buat aturan untuk domain eksak tersebut dan berikan nomor prioritas lebih rendah daripada aturan wildcard. ALB mengevaluasi aturan berdasarkan nomor prioritasnya, bukan berdasarkan tingkat kekhususan pencocokan domain.

Skenario 7: Rilis canary berdasarkan Header HTTP

Gunakan Header HTTP untuk menerapkan rilis canary. Permintaan dengan header tertentu diteruskan ke kelompok server versi baru, sedangkan permintaan lainnya diteruskan ke kelompok server versi saat ini.

Aturan 1 (aturan canary, prioritas lebih tinggi): Teruskan permintaan yang berisi header X-Canary: true ke kelompok server versi baru.

Parameter

Deskripsi

Add Condition

Pilih HTTP Header, setel kunci ke X-Canary, dan setel nilai ke true.

Action

Pilih Forward, lalu pilih kelompok server versi baru.

Aturan 2 (aturan default, prioritas lebih rendah): Permintaan tanpa header canary diteruskan ke kelompok server versi saat ini. Hal ini dapat diimplementasikan menggunakan aturan pengalihan default listener.

Hasil: Saat permintaan klien menyertakan header X-Canary: true, trafik diteruskan ke kelompok server versi baru. Permintaan tanpa header ini diteruskan ke kelompok server versi saat ini.

Untuk memastikan trafik canary dicocokkan terlebih dahulu, aturan canary harus memiliki nomor prioritas lebih rendah (menunjukkan prioritas lebih tinggi) daripada aturan default. Untuk informasi tentang metode rilis canary berdasarkan cookie dan bobot kelompok server, lihat Gunakan ALB untuk menerapkan rilis canary.

Pencocokan domain dalam aturan pengalihan

ALB mengevaluasi aturan pengalihan berdasarkan nomor prioritasnya, dari terendah ke tertinggi, dan berhenti pada aturan pertama yang cocok. Aturan tidak diurutkan secara otomatis berdasarkan kekhususan domain. Perilaku ini berbeda dari CLB, yang secara otomatis memprioritaskan aturan berdasarkan kekhususan (misalnya, exact match > narrower wildcard > broader wildcard).

Misalnya, pertimbangkan listener dengan dua aturan berikut:

Nomor prioritas

Kondisi pencocokan

Aturan 1 (Prioritas: 1)

Domain = *.example.com → Teruskan ke kelompok server A

Aturan 2 (Prioritas: 2)

Domain = www.example.com → Teruskan ke kelompok server B

Permintaan ke www.example.com cocok dengan Aturan 1 (aturan wildcard), bukan Aturan 2 (aturan exact match), karena Aturan 1 memiliki nomor prioritas lebih rendah.

Praktik terbaik: Untuk memastikan aturan yang lebih spesifik dievaluasi terlebih dahulu, berikan nomor prioritas lebih rendah daripada aturan yang kurang spesifik. Misalnya, atur aturan untuk www.example.com ke Prioritas 1 dan aturan untuk *.example.com ke Prioritas 2.

Jenis pencocokan

Deskripsi

Exact match and wildcard match

  • Deskripsi pencocokan

    • Exact match: Nama domain yang diminta harus identik dengan yang ditentukan dalam aturan.

    • Wildcard match: Nama domain yang diminta harus sesuai dengan pola wildcard yang ditentukan dalam aturan.

  • Persyaratan

    Nama domain harus terdiri dari 3 hingga 256 karakter dan hanya boleh berisi huruf, angka, serta karakter khusus berikut: .-?=~_+\^*!$&|()[]. Anda dapat menggunakan tanda bintang (*) dan tanda tanya (?) sebagai wildcard.

  • Contoh

    Nama domain yang diminta: www.example.com

    • Exact match: Cocok jika aturan diatur ke www.example.com.

    • Wildcard match: Cocok jika aturan diatur ke *.example.com atau www.example.*.

Regular expression match

  • Deskripsi pencocokan

    Nama domain yang diminta harus sesuai dengan ekspresi reguler yang ditentukan dalam aturan.

  • Persyaratan

    Nama domain harus terdiri dari 3 hingga 256 karakter dan hanya boleh berisi huruf, angka, serta karakter khusus berikut: .-?=~_+\^*!$&|()[].

  • Contoh

    Nama domain yang diminta: www.example.com

    Cocok jika aturan diatur ke ekspresi reguler ^www.example.com$. Pencocokan ini tidak membedakan huruf besar/kecil.

Pencocokan path aturan pengalihan

Aturan pencocokan path ALB berbeda dari Nginx. ALB tidak mendukung prinsip longest prefix match. Misalnya, Nginx menggunakan metode longest prefix match untuk konfigurasi umum seperti location /api. Untuk mencapai efek yang sama di ALB, Anda harus menggunakan wildcard. Anda dapat mengonfigurasi path sebagai /api/* (kombinasi exact match dan wildcard).

Jika listener memiliki aturan untuk /api/* dan /api/v2/*, Anda harus menempatkan aturan /api/v2/* sebelum aturan /api/* dengan memberikan nomor prioritas lebih rendah. Jika tidak, aturan /api/* akan mencocokkan semua permintaan terlebih dahulu.

Jenis pencocokan

Deskripsi

Exact and wildcard match

  • Deskripsi pencocokan

    • Exact match: Path yang diminta harus identik dengan path yang ditentukan dalam aturan.

    • Wildcard match: Path yang diminta harus sesuai dengan pola wildcard yang ditentukan dalam aturan.

  • Persyaratan input

    Path harus diawali dengan garis miring (/), dan hanya boleh berisi huruf, angka, serta karakter khusus berikut: $-_.+/&~@:. Tanda bintang (*) dan tanda tanya (?) berfungsi sebagai wildcard.

  • Contoh

    Path permintaan: /example/text

    • Exact match: Permintaan cocok jika aturan dikonfigurasi dengan path /example/text.

    • Wildcard match: Permintaan cocok jika aturan dikonfigurasi dengan path /example/*.

Regular expression match

  • Deskripsi pencocokan

    Path yang diminta harus sesuai dengan ekspresi reguler yang ditentukan dalam aturan.

  • Persyaratan input

    Ekspresi reguler hanya boleh berisi huruf, angka, serta karakter khusus berikut: .-_/=?~^*$:()[]+|.

  • Contoh

    Path permintaan: /api/v2/Users

    • Case-sensitive: Permintaan cocok jika ekspresi reguler diatur ke ^/api/(.*)/Users$.

    • Case-insensitive: Permintaan cocok jika ekspresi reguler diatur ke ^/api/(.*)/users$.

Konfigurasi path lanjutan untuk rewrite dan redirect

Jika Anda menggunakan ekspresi reguler untuk menentukan path dalam kondisi pengalihan, Anda dapat menggunakan substitusi ekspresi reguler dalam path aksi rewrite atau redirect.

  • Catatan

    • Jumlah grup tangkapan, yang didefinisikan oleh tanda kurung( ), dalam ekspresi reguler kondisi pengalihan harus sesuai dengan jumlah variabel ${n} dalam path rewrite atau redirect aksi pengalihan.

    • Path rewrite atau redirect dalam aksi pengalihan harus menyertakan satu atau lebih dari${1}, ${2}, dan${3}. Jangan mengganti variabel ini dengan karakter lain.

    • Dalam path rewrite atau redirect, gunakan karakter$ hanya untuk mereferensikan variabel berikut: ${host}, ${path}, ${port}, ${protocol}, dan variabel grup tangkapan ekspresi reguler seperti${1}, ${2}, dan${3}. Tidak ada variabel lain yang didukung.

  • Cara kerja

    1. Pencocokan path: Klien mengirim permintaan yang cocok dengan ekspresi reguler dalam aturan pengalihan.

    2. Ekstraksi dan substitusi: Sistem mengekstraksi konten dari tiga grup tangkapan pertama, yang didefinisikan oleh tanda kurung( ), dan menyimpannya ke variabel${1}, ${2}, dan${3}. Variabel ini kemudian digunakan untuk substitusi dalam path rewrite atau redirect aksi pengalihan.

    3. Konstruksi path: Sistem mengganti variabel${1}, ${2}, dan${3} dengan nilai yang ditangkap dan membangun path akhir untuk rewrite atau redirect.

    No.

    Langkah

    Contoh

    1

    Konfigurasikan kondisi pengalihan dan aksi pengalihan untuk aturan pengalihan.

    • Path dalam kondisi pengalihan: /app/(.*)/(.*)/settings

    • Path untuk aksi rewrite atau redirect: /${1}/${2}

    2

    Klien mengirim permintaan yang cocok dengan path tersebut.

    • Path permintaan dari klien: /app/users/profile/settings

    • Path yang cocok dalam kondisi pengalihan: /app/(.*)/(.*)/settings

    3

    Ekstraksi dan substitusi nilai.

    Sistem mengekstraksiusers danprofile dari dua(.*) grup tangkapan dalam path kondisi pengalihan dan menyimpan nilai tersebut ke variabel ${1} dan ${2} untuk aksi pengalihan.

    • ${1} diganti denganusers.

    • ${2} diganti denganprofile.

    4

    Bangun path.

    Path yang diterima server backend: /users/profile

  • Contoh konfigurasi

    Saat menambahkan aturan pengalihan di konsol, rujuk catatan dan deskripsi alur kerja di atas.

    Contoh 1: Actionaksi ke Rewrite dan Forward

    Contoh ini menunjukkan cara menulis ulang path /app/users/profile/settings menjadi /users/profile lalu meneruskan permintaan ke server backend. Ekspresi reguler /app/(.*)/(.*)/settings menggunakan dua grup tangkapan untuk mengekstraksi users dan profile. Path yang ditulis ulang kemudian menggunakan /${1}/${2} untuk membangun path akhir.

    Parameter

    Deskripsi

    Add Condition

    Path

    Pilih Regular Expression Match | Case Insensitive dan masukkan ekspresi reguler /app/(.*)/(.*)/settings.

    Misalnya, jika klien meminta path /app/users/profile/settings, aturan tersebut cocok. Grup tangkapan mengekstraksi users dan profile, yang disimpan ke variabel ${1} dan ${2} masing-masing.

    Action

    Rewrite

    • Domain Name: ${host}

    • Path: /${1}/${2}

    • Search: ${query}

    Search adalah bagian URL yang mengikuti tanda tanya. Misalnya, untuk URL www.example.com/test/test1?x=1, Search adalah x=1.

    Forward

    Pilih kelompok server target dari daftar kelompok server.

    Contoh 2: Mengatur aksi penerusan ke pengalihan

    Contoh berikut mengalihkan path /app/users/profile/settings ke /users/profile. Berbeda dengan Contoh 1, redirect ini mengembalikan kode status 301, dan URL di bilah alamat browser berubah.

    Parameter

    Deskripsi

    Add Condition

    Path

    Pilih Regular Expression Match | Case Insensitive dan masukkan ekspresi reguler /app/(.*)/(.*)/settings.

    Misalnya, jika klien meminta path /app/users/profile/settings, aturan tersebut cocok. Grup tangkapan mengekstraksi users dan profile, yang disimpan ke variabel ${1} dan ${2} masing-masing.

    Action

    Redirect

    • Protocol: ${protocol}

    • Domain Name: ${host}

    • Port: ${port}

    • Path: /${1}/${2}

    • Search: ${query}

    • Status Code: 301

FAQ

Menulis ulang hanya nama domain

Untuk menulis ulang nama domain yang diminta ke domain lain sambil menjaga path dan string kueri tetap tidak berubah, konfigurasikan aturan sebagai berikut:

  • Add Condition: Setel nama domain ke nama domain asli, misalnya old.example.com.

  • Action: Pilih rewrite. Setel nama domain ke nama domain baru (misalnya new.example.com), path ke ${path}, dan kueri ke ${query}. Juga, konfigurasikan Forward untuk menentukan kelompok server.

Menambahkan awalan ke path

Untuk menambahkan awalan ke path (misalnya, menulis ulang /users/list menjadi /v2/users/list), konfigurasikan aturan sebagai berikut:

  • Add Condition: Setel path agar cocok dengan ekspresi reguler ^/(.*).

  • Action: Pilih rewrite dan setel path ke /v2/${1}. Juga, konfigurasikan Forward untuk menentukan kelompok server.

Setelah Anda mengonfigurasi aturan tersebut, ALB menulis ulang permintaan untuk /users/list menjadi /v2/users/list dan meneruskannya ke server backend.

Menghapus awalan path

Lihat Studi kasus 4: Meneruskan permintaan setelah menghapus awalan path dalam topik ini. Studi kasus ini memberikan contoh konfigurasi lengkap untuk menghapus awalan, seperti /api/*, dengan menggunakan pencocokan ekspresi reguler bersama aksi rewrite atau redirect.

Troubleshooting pencocokan dan routing aturan pengalihan

Jika aturan pengalihan Anda tidak mengarahkan permintaan seperti yang diharapkan, gunakan langkah troubleshooting berikut:

  1. Periksa prioritas aturan: ALB mengevaluasi aturan dalam urutan menaik berdasarkan nomor prioritasnya dan berhenti pada kecocokan pertama. Jika aturan yang lebih luas memiliki nomor prioritas lebih rendah (dan dievaluasi terlebih dahulu), aturan yang lebih spesifik dengan nomor prioritas lebih tinggi tidak akan dicocokkan.

  2. Periksa jenis pencocokan: Pastikan Anda menggunakan jenis pencocokan yang benar (exact match, wildcard, atau ekspresi reguler). Misalnya, exact match untuk /api tidak cocok dengan /api/users. Untuk mencocokkan keduanya, Anda harus menggunakan wildcard, seperti /api/*.

  3. Periksa beberapa kondisi: Saat mengonfigurasi beberapa kondisi untuk satu aturan pengalihan, kondisi dengan jenis berbeda digabungkan dengan operator AND, sedangkan beberapa nilai untuk jenis kondisi yang sama digabungkan dengan operator OR. Untuk informasi lebih lanjut, lihat Konfigurasikan aturan pengalihan listener.

  4. Periksa log akses: Gunakan bidang host dan request_uri dalam log akses ALB untuk memverifikasi bahwa detail permintaan yang diterima ALB sesuai dengan harapan Anda.

Rewrite versus redirect

Item

Rewrite

Redirect

Bilah alamat browser

Tidak berubah (transparan bagi pengguna)

Berubah ke URL baru

Cara kerja

ALB menulis ulang path permintaan secara internal lalu meneruskan permintaan ke server backend. Seluruh proses selesai dalam satu permintaan.

ALB mengembalikan kode status 3xx, dan browser memulai permintaan kedua ke URL baru.

Kasus penggunaan

Penyesuaian path internal, seperti menghapus awalan atau menambahkan nomor versi.

Pengalihan HTTP ke HTTPS, pengalihan domain telanjang ke www, dan migrasi URL lama.

Memerlukan "Forward to"

Ya. Aksi rewrite harus dikonfigurasi dengan aksi "Forward to" yang menentukan kelompok server.

Tidak. Aksi redirect berdiri sendiri.

Dokumen terkait

Untuk petunjuk mengonfigurasi aturan pengalihan listener untuk ALB, lihat Konfigurasikan aturan pengalihan listener.