全部产品
Search
文档中心

CDN:Menulis ulang URL akses

更新时间:Dec 02, 2025

Jika jalur suatu resource di server origin berubah, resource tersebut tidak lagi dapat diakses melalui jalur aslinya di titik keberadaan (POPs) CDN. Jika klien meminta resource tersebut menggunakan URL asli, CDN dapat menulis ulang URL permintaan dan mengarahkannya ke jalur tujuan. Hal ini mengurangi permintaan origin fetch serta meningkatkan kinerja akses klien.

Latar Belakang

Kode status HTTP 302 (302 Found) menunjukkan bahwa suatu resource telah dipindahkan sementara. Setelah Anda mengonfigurasi fitur penulisan ulang URL akses, POPs CDN akan mengembalikan respons 302 yang menyertakan URL baru dalam header HTTP Location. Setelah menerima respons tersebut, klien akan mengirim permintaan baru ke URL yang ditentukan.

Secara default, POPs CDN mengirim kode status 302 setelah Anda mengonfigurasi aturan penulisan ulang URL akses. Kode status 303 dan 307 juga didukung. Untuk mengubah kode status tersebut, Anda dapat mengajukan tiket.

Status code

Makna

Metode pemrosesan

Kasus penggunaan

302

Found

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

Situs web 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 yang sama dipicu kembali jika halaman dimuat ulang.

307

Temporary Redirect

Metode dan isi pesan tidak berubah.

Situs web sementara tidak tersedia karena alasan yang tidak terduga. Dalam kasus ini, mesin pencari tidak memperbarui tautannya. Kode status ini lebih disukai daripada kode status 302 ketika situs mendukung tautan atau operasi yang menggunakan metode selain GET.

Penting

Anda dapat mengonfigurasi maksimal 50 aturan penulisan ulang untuk satu nama domain. Jika Anda mengonfigurasi beberapa aturan, aturan tersebut dieksekusi sesuai urutan yang tercantum pada halaman Rewrite Access URL di Konsol CDN.

Perbedaan antara penulisan ulang URL akses dan penulisan ulang URL origin

Fitur

Terpengaruh

Pengalaman klien

Kasus penggunaan

Rewrite access URLs

Mempengaruhi URL yang diakses klien. Juga mengubah URL yang digunakan POP untuk origin fetch.

  • Jika flag diatur ke redirect, klien menggunakan URL yang dialihkan untuk mengirim permintaan baru.

  • Jika flag diatur ke break, URL yang dilihat klien tetap sama dengan URL yang diakses dan tidak berubah.

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

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

Rewrite origin URLs

Mempengaruhi URL yang digunakan POP untuk origin fetch. URL yang diakses klien tidak berubah.

URL yang dilihat klien tetap sama dengan URL yang diakses dan tidak berubah.

Umumnya digunakan untuk menyembunyikan struktur URL sebenarnya dari server origin guna melindungi informasi server origin, atau menggunakan pemetaan URL agar POP CDN dapat mengambil konten dari direktori origin yang berbeda.

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

Penulisan ulang URL akses

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

  2. Setelah menerima permintaan, POP menulis ulang URL permintaan menjadi new.example.com/hello berdasarkan aturan penulisan ulang URL akses. POP kemudian menyertakan URL baru tersebut dalam header HTTP Location pada respons 302.

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

  4. POP memeriksa cache-nya. Jika konten untuk URL yang ditulis ulang sudah di-cache, POP mengembalikan konten tersebut ke klien. Jika belum di-cache, POP mengirim permintaan ke server origin dengan URL yang ditulis ulang, yaitu new.example.com/hello.

  5. Server origin menerima permintaan dan mengembalikan respons ke POP.

  6. POP menyimpan respons tersebut dalam cache dan mengembalikannya ke klien.

Penulisan ulang URL origin

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

  2. Setelah menerima permintaan, POP memeriksa cache-nya. Jika konten untuk URL permintaan sudah di-cache, POP mengembalikan konten tersebut ke klien. Jika belum di-cache, POP menulis ulang URL origin menjadi origin.example.com/secret/files/hello.txt berdasarkan aturan penulisan ulang URL origin, lalu mengirim permintaan ke server origin.

  3. Server origin menerima permintaan dan mengembalikan respons ke POP.

  4. POP menyimpan respons tersebut dalam cache dan mengembalikannya ke klien.

Prosedur

  1. Login 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 aturan penulisan ulang URL akses.

    image

    Parameter

    Deskripsi

    Path to Be Rewritten

    Jalur harus diawali dengan garis miring (/) dan tidak boleh mengandung protokol atau nama domain. Ekspresi Reguler Kompatibel Perl (PCRE) didukung. Contoh: ^/hello$.

    Target Path

    • Jika Anda mengatur Flag ke Break, jalur harus diawali dengan garis miring (/) dan tidak boleh mengandung protokol atau nama domain.

    • Jika Anda mengatur Flag ke Redirect, jalur dapat mengandung protokol dan nama domain. PCRE didukung. Sebagai contoh, Anda dapat menggunakan $1 dan $2 untuk menangkap string dalam tanda kurung dari jalur yang akan ditulis ulang.

    Flag

    • Secara default, Redirect dan Break didukung.

      • Redirect: Jika URL permintaan cocok dengan aturan, permintaan dialihkan ke URL tujuan dengan kode status 302. Header Location dalam respons yang dikembalikan POP ke klien adalah URL tujuan. Parameter dalam URL asli tidak diubah. Setelah aturan saat ini dieksekusi, permintaan terus dicocokkan dengan aturan yang tersisa.

      • Break: Jika URL permintaan cocok dengan aturan, permintaan ditulis ulang ke URL tujuan. Parameter dalam URL asli tidak diubah. Setelah aturan saat ini dieksekusi, aturan berikutnya dilewati.

    • Flag Empty, enhance-break, dan enhance_redirect juga didukung. Untuk menggunakan flag ini, ajukan tiket agar dikonfigurasi di backend.

      • Empty: Jika Anda mengonfigurasi beberapa aturan dan URL permintaan cocok dengan suatu aturan, permintaan terus dicocokkan dengan aturan berikutnya setelah aturan saat ini dieksekusi.

      • enhance_break: Mirip dengan Break, tetapi memodifikasi seluruh URL, termasuk parameternya.

      • enhance_redirect: Mirip dengan Redirect, tetapi memodifikasi seluruh URL, termasuk parameternya.

    Catatan

    Flag yang berbeda menggunakan metode penulisan ulang yang berbeda. Apakah URL yang ditulis ulang mendukung nama domain dan protokol lain juga berbeda:

    • Empty, Break, dan enhance_break langsung menulis ulang URL permintaan pengguna. Mereka tidak mendukung penulisan ulang ke nama domain atau protokol lain. Misalnya, Anda tidak dapat menggunakan flag ini untuk mengubah protokol 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:

      • Anda dapat mengatur alamat Location 302 ke nama domain yang dipercepat saat ini atau nama domain lain. Ini memungkinkan Anda menulis ulang URL yang menggunakan nama domain example.com menjadi URL baru yang menggunakan nama domain aliyundoc.com.

      • Alamat Location 302 mendukung protokol lain. Ini memungkinkan Anda menulis ulang URL yang menggunakan protokol HTTP menjadi URL baru yang menggunakan protokol HTTPS.

    Rule Condition

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

    • Do not use: Jangan gunakan kondisi aturan.

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

    Enable NGINX variable computing

    Secara default, fitur ini dinonaktifkan. Jika Anda mengaktifkannya, Anda dapat menggunakan variabel bawaan NGINX dalam URL tujuan. Contoh:

    • Path to Rewrite: ^/test.jpg$

    • Destination Path: /test.${arg_type}

    • Setelah opsi ini diaktifkan, nilai ${nginx_var} dihitung. ${arg_type} menentukan nilai parameter type dalam URL asli.

    Catatan

    Untuk mengonfigurasi parameter ini, ajukan tiket agar dikonfigurasi di backend.

  7. Klik OK.

    Setelah aturan penulisan ulang dikonfigurasi, aturan tersebut akan muncul dalam daftar tempat Anda dapat Modify atau Delete aturan tersebut.

Contoh konfigurasi

Contoh 1

Klien meminta http://example.aliyundoc.com/hello. Karena jalur permintaan adalah /hello, POP CDN menulis URL baru http://example.aliyundoc.com/index.html ke header Location dalam respons 302 dan mengirim respons tersebut ke klien. Klien kemudian mengirim permintaan ke http://example.aliyundoc.com/index.html.

正则表达

Catatan

Selama Pengalihan 302, jika header Location tidak berisi protokol dan nama domain, klien secara default menggunakan protokol dan nama domain dari permintaan aslinya.

Contoh 2

Klien meminta http://example.aliyundoc.com/hello. Permintaan tersebut mengandung /hello dan cocok dengan ekspresi reguler ^/hello$. POP CDN mengembalikan kode status 302 ke klien dan menyertakan URL tujuan https://test.aliyundoc.com/index.html dalam header Location. Setelah menerima respons, klien mengirim permintaan baru ke https://test.aliyundoc.com/index.html.

image

Contoh 3

Klien meminta http://www.example.com/cdn/url/http://image.example.com/image/cat.jpg. Permintaan tersebut mengandung /cdn/url/http:// dan cocok dengan ekspresi reguler ^/cdn/url/http://(.*). POP CDN mengembalikan kode status 302 ke klien dan menyertakan URL tujuan http://image.example.com/image/cat.jpg dalam header Location. Setelah menerima respons, klien mengirim permintaan ke http://image.example.com/image/cat.jpg.

image