All Products
Search

This Product

    CDN:Access URL Rewrite

    Document Center

    CDN:Access URL Rewrite

    Last Updated:Jun 25, 2026

    Jika jalur suatu resource di server origin berubah, jalur yang sesuai pada node CDN juga berubah. Saat pengguna meminta URL asli, node CDN menulis ulang URL tersebut dan mengarahkan permintaan ke jalur tujuan. Proses ini mengurangi permintaan origin fetch dan meningkatkan kinerja akses klien.

    Informasi latar belakang

    Kode status HTTP 302 (302 Found) menunjukkan bahwa suatu resource telah dipindahkan sementara. Setelah Anda mengonfigurasi aturan penulisan ulang URL, node CDN menyertakan URL baru dalam header HTTP Location. Saat klien menerima respons 302, klien tersebut meminta URL baru tersebut.

    Secara default, node CDN mengirim kode status 302 setelah aturan penulisan ulang URL dikonfigurasi. Kode status 303 dan 307 juga didukung. Untuk mengubah kode status, Anda dapat mengajukan permintaan dengan atau mengirimkan tiket.

    Kode

    Makna

    Metode penanganan

    Skenario aplikasi khas

    302

    Found

    Metode GET tidak berubah. Metode lain mungkin berubah menjadi metode GET.

    Halaman sementara tidak tersedia karena alasan yang tidak terduga. Dalam kasus ini, mesin pencari tidak memperbarui tautannya.

    303

    See Other

    Metode GET tidak berubah. Metode lain berubah menjadi metode GET. Isi pesan hilang.

    Digunakan untuk pengalihan halaman setelah permintaan PUT atau POST selesai. Ini mencegah operasi dijalankan kembali jika halaman dimuat ulang.

    307

    Temporary Redirect

    Baik metode maupun isi pesan tidak berubah.

    Halaman sementara tidak tersedia karena alasan yang tidak terduga. Dalam kasus ini, mesin pencari tidak memperbarui tautannya. Kode status ini lebih baik daripada kode status 302 ketika situs mendukung tautan atau operasi untuk metode selain GET.
    Penting

    Satu nama domain dapat memiliki hingga 50 aturan penulisan ulang. Jika beberapa aturan dikonfigurasi, aturan tersebut dieksekusi secara berurutan dari atas ke bawah sesuai urutannya dalam daftar penulisan ulang URL di Konsol CDN.

    Access URL Rewrite dan Origin Path Rewrite perbedaan

    Fitur

    Objek yang terpengaruh

    Pengalaman client

    Skenario aplikasi

    Rewrite access URLs

    Mempengaruhi URL yang diakses oleh client. Juga mengubah URL yang digunakan oleh node CDN untuk origin fetch.

    • Jika aturan eksekusi adalah `redirect`, client mengirim permintaan akses baru menggunakan URL yang dialihkan.

    • Jika aturan eksekusi adalah `break`, URL yang dilihat client sama dengan URL akses aktual. Tidak ada perubahan.

    Umumnya digunakan untuk migrasi atau pemetaan URL dari nama domain lama ke yang baru. Juga digunakan untuk menyediakan URL berbeda bagi client mobile dan PC.

    Contoh: Saat client mengakses old.example.com/hello, URL akses ditulis ulang menjadi new.example.com/hello.

    Rewrite Origin Fetch Path

    Mempengaruhi URL yang digunakan oleh node CDN untuk origin fetch. URL yang diakses client tidak berubah.

    URL yang dilihat client sama dengan URL akses aktual. Tidak ada perubahan.

    Umumnya digunakan untuk menyembunyikan struktur URL asli server origin guna melindungi informasinya. Juga digunakan untuk pemetaan URL agar node CDN mengambil konten dari folder server origin yang berbeda.

    Contoh: Saat client mengakses cdn.example.com/hello, URL origin fetch ditulis ulang menjadi origin.example.com/source/hello.

    Access URL Rewrite diagram

    1. Klien mengirim permintaan ke node CDN. URL permintaan adalah old.example.com/hello.

    2. Setelah node CDN menerima permintaan, aturan penulisan ulang URL diterapkan. Node CDN menyertakan URL baru, new.example.com/hello, dalam header Location dari respons 302 yang dikirim ke klien.

    3. Setelah klien menerima respons 302, klien mengirim permintaan ke URL baru tersebut.

    4. Node CDN memeriksa cache-nya. Jika cache berisi konten untuk URL yang ditulis ulang, node tersebut langsung mengembalikan konten ke klien. Jika tidak, node CDN mengirim permintaan ke server origin menggunakan URL yang ditulis ulang, new.example.com/hello.

    5. Server origin menerima permintaan dan mengembalikan konten respons ke node CDN.

    6. Node CDN menyimpan konten respons dalam cache dan mengembalikannya ke klien.

    Origin Path Rewrite diagram

    1. Klien mengirim permintaan ke node CDN. URL permintaan adalah cdn.example.com/files/hello.txt.

    2. Setelah node CDN menerima permintaan, node tersebut memeriksa cache-nya. Jika cache berisi konten untuk URL permintaan, node tersebut langsung mengembalikan konten ke klien. Jika tidak, node CDN menerapkan aturan penulisan ulang URL origin fetch. Node tersebut menulis ulang URL origin fetch menjadi origin.example.com/secret/files/hello.txt dan mengirim permintaan ke server origin.

    3. Setelah server origin menerima permintaan, server tersebut mengembalikan konten respons ke node CDN.

    4. Node CDN menyimpan konten respons dalam cache dan mengembalikannya ke klien.

    Prosedur

    1. Masuk ke CDN console.

    2. Di panel navigasi kiri, klik Domain Names.

    3. Pada halaman Domain Names, temukan nama domain target dan klik Manage di kolom Actions.

    4. Di panel navigasi domain, klik Cache.

    5. Klik tab Access URL Rewrite.

    6. Klik Create dan konfigurasikan parameter untuk menulis ulang URL akses.

      Parameter

      Deskripsi

      Path to Be Rewritten

      Jalur harus diawali dengan /. Jalur tidak boleh mencakup header protokol atau nama domain. Ekspresi reguler PCRE didukung, seperti ^/hello$.

      Bagian setelah # dalam URL merupakan identifier fragmen sisi client. Browser tidak mengirim identifier fragmen ke server. Oleh karena itu, aturan penulisan ulang CDN tidak dapat mencocokkan jalur setelah #. Untuk mengonfigurasi pengalihan untuk URL yang berisi fragmen #, Anda harus membuat aturan penulisan ulang terpisah untuk setiap alamat tujuan yang secara tepat mencocokkan jalur sebelum #.

      Target Path

      • Jika aturan eksekusi diatur ke Break, jalur harus diawali dengan /. Jalur tidak boleh mencakup header protokol atau nama domain.

      • Jika aturan eksekusi diatur ke Redirect, jalur dapat mencakup header protokol dan nama domain. Ekspresi reguler PCRE didukung. Misalnya, Anda dapat menggunakan $1 dan $2 untuk menangkap string dalam tanda kurung dari jalur yang akan ditulis ulang.

      Flag

      • Redirect dan Break didukung secara default.

        • Redirect: Jika URL permintaan cocok dengan aturan, permintaan dialihkan ke URL tujuan dengan kode status 302. Header Location yang dikembalikan node ke client berisi URL tujuan. Parameter dalam URL asli tidak diubah. Setelah aturan ini dieksekusi, sistem melanjutkan pencocokan aturan yang tersisa.

        • Break: Jika URL permintaan cocok dengan aturan, permintaan ditulis ulang ke URL tujuan. Parameter dalam URL asli tidak diubah. Setelah aturan ini dieksekusi, sistem tidak mencocokkan aturan lainnya.

      • Aturan empty, enhance-break, dan enhance_redirect juga didukung. Untuk menggunakan aturan ini, Anda harus mengirimkan tiket agar dikonfigurasi di backend.

        • empty: Jika beberapa aturan dikonfigurasi dan URL permintaan cocok dengan aturan, sistem melanjutkan pencocokan aturan berikutnya setelah aturan saat ini dieksekusi.

        • enhance_break: Mirip dengan break, tetapi menulis ulang seluruh URL, termasuk parameternya.

        • enhance_redirect: Mirip dengan redirect, tetapi menulis ulang seluruh URL, termasuk parameternya.

      Catatan

      Aturan eksekusi yang berbeda menggunakan metode penulisan ulang yang berbeda. Mereka juga berbeda dalam hal apakah URL yang ditulis ulang dapat menggunakan nama domain atau protokol lain:

      • empty, Break, dan enhance_break langsung menulis ulang URL permintaan pengguna. Mereka tidak mendukung penulisan ulang ke nama domain atau protokol lain, seperti dari HTTP ke HTTPS.

      • Redirect dan enhance_redirect menggunakan pengalihan 302 untuk menulis ulang URL. Mereka mendukung penulisan ulang ke nama domain dan protokol lain:

        • Alamat Location 302 dapat diatur ke nama domain yang berbeda, bukan hanya nama domain yang dipercepat saat ini. Misalnya, Anda dapat menulis ulang URL dari domain example.com ke domain aliyundoc.com.

        • Alamat Location 302 mendukung protokol lain. Misalnya, Anda dapat menulis ulang URL dari HTTP ke HTTPS.

      Rule Condition

      Kondisi aturan mengidentifikasi berbagai informasi parameter dalam permintaan pengguna. Hal ini menentukan apakah konfigurasi berlaku untuk permintaan tersebut.

      Penting

      Saat Anda mereferensikan kondisi aturan, kondisi tersebut dicocokkan berdasarkan prioritas kondisi aturan terkait, bukan urutan konfigurasi fitur itu sendiri.

      • Do not use: Tidak menggunakan kondisi aturan.

      • Untuk menambah atau mengedit kondisi aturan, kelola di Rules Engine.

      Nginx Var

      Opsi ini tidak dicentang secara default. Centang opsi ini untuk menggunakan variabel NGINX bawaan dalam URL tujuan. Berikut contoh konfigurasinya:

      • Path to Rewrite: ^/test.jpg$

      • Destination Path: /test.${arg_type}

      • Jika Anda mengaktifkan perhitungan variabel NGINX, nilai `${nginx_var}` dihitung. `${arg_type}` merepresentasikan nilai parameter `type` dalam URL asli.

      Catatan

      Untuk menggunakan parameter ini, Anda harus mengirimkan tiket agar dikonfigurasi di backend.

    7. Klik OK.

      Setelah Anda mengonfigurasi fitur penulisan ulang, Anda dapat Modify atau Delete aturan dari daftar penulisan ulang.

    Contoh konfigurasi

    Contoh 1

    Saat klien meminta http://example.aliyundoc.com/hello, jalur permintaan adalah /hello. Node CDN menyertakan URL baru http://example.aliyundoc.com/index.html dalam header Location dari respons 302 dan mengembalikan respons tersebut ke klien. Klien kemudian mengirim permintaan ke http://example.aliyundoc.com/index.html.

    Untuk aturan ini, Path to Rewrite diatur ke ^/hello$, Destination Path diatur ke /index.html, dan Execution Rule diatur ke redirect.

    Catatan

    Selama pengalihan 302, jika header Location tidak mencakup protokol dan nama domain, klien secara default menggunakan protokol dan nama domain dari permintaan asli.

    Contoh 2

    Saat klien meminta http://example.aliyundoc.com/hello, jalur permintaan /hello cocok dengan ekspresi reguler ^/hello$. Node CDN mengembalikan respons 302 ke klien. Respons tersebut mencakup URL tujuan https://test.aliyundoc.com/index.html dalam header Location. Setelah klien menerima respons tersebut, klien mengirim permintaan ke https://test.aliyundoc.com/index.html.

    Aturan konfigurasi: Atur Path to Rewrite ke ^/hello$, atur Destination Path ke https://test.aliyundoc.com/index.html, dan atur Execution Rule ke redirect.

    Contoh 3

    Saat klien meminta http://www.example.com/cdn/url/http://image.example.com/image/cat.jpg, jalur permintaan berisi /cdn/url/http://, yang cocok dengan ekspresi reguler ^/cdn/url/http://(.*). Node CDN mengembalikan respons 302 ke klien. Respons tersebut mencakup URL tujuan http://image.example.com/image/cat.jpg dalam header Location. Setelah klien menerima respons tersebut, klien mengirim permintaan ke http://image.example.com/image/cat.jpg.

    Untuk aturan konfigurasi, atur Target Path ke http://$1 dan Execution Rule ke redirect.

    Contoh 4

    Saat klien meminta http://example.aliyundoc.com/stories/index.html#/voice/318, bagian #/voice/318 dari URL merupakan identifier fragmen sisi klien. Browser tidak mengirim bagian ini ke server. Jalur permintaan aktual yang diterima node CDN adalah /stories/index.html. Oleh karena itu, saat Anda mengonfigurasi aturan penulisan ulang, atur Path to Rewrite ke ^/stories/index\.html$ untuk mencocokkan jalur sebelum #. Kemudian, atur Destination Path ke URL tujuan dan Execution Rule ke Redirect.

    Untuk mengalihkan beberapa URL sumber yang memiliki fragmen # berbeda ke URL tujuan yang berbeda, Anda harus mengonfigurasi aturan penulisan ulang terpisah untuk setiap jalur sumber. Hal ini karena server tidak dapat membedakan antar-URL berdasarkan konten yang mengikuti simbol #.