

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

# Hasilkan respons kesalahan khusus
<a name="GeneratingCustomErrorResponses"></a>

Jika objek yang Anda layani tidak CloudFront tersedia karena alasan tertentu, server web Anda biasanya mengembalikan kode status HTTP yang relevan CloudFront untuk menunjukkan ini. Misalnya, jika penampil meminta URL yang tidak valid, server web Anda mengembalikan kode status HTTP 404 (Tidak Ditemukan) ke CloudFront, dan kemudian CloudFront mengembalikan kode status tersebut ke penampil. Alih-alih menggunakan respons kesalahan default ini, Anda dapat membuat respons khusus yang CloudFront kembali ke penampil.

Jika Anda mengonfigurasi CloudFront untuk mengembalikan halaman kesalahan kustom untuk kode status HTTP tetapi halaman kesalahan kustom tidak tersedia, CloudFront mengembalikan ke penampil kode status yang CloudFront diterima dari asal yang berisi halaman kesalahan kustom. Misalnya, asal kustom Anda mengembalikan kode status 500 dan Anda telah mengonfigurasi CloudFront untuk mendapatkan halaman kesalahan kustom untuk kode status 500 dari bucket Amazon S3. Namun, seseorang secara tidak sengaja menghapus halaman kesalahan khusus dari bucket Amazon S3 Anda. CloudFront mengembalikan kode status HTTP 404 (Tidak Ditemukan) ke penampil yang meminta objek.

Saat CloudFront mengembalikan halaman kesalahan kustom ke penampil, Anda membayar CloudFront biaya standar untuk halaman kesalahan kustom, bukan biaya untuk objek yang diminta. Untuk informasi selengkapnya tentang CloudFront tagihan, lihat [ CloudFrontHarga Amazon](https://aws.amazon.com/cloudfront/pricing/).

**Topics**
+ [

# Konfigurasikan perilaku respons kesalahan
](custom-error-pages-procedure.md)
+ [

# Buat halaman kesalahan khusus untuk kode status HTTP tertentu
](creating-custom-error-pages.md)
+ [

# Menyimpan objek dan halaman kesalahan kustom di lokasi yang berbeda
](custom-error-pages-different-locations.md)
+ [

# Ubah kode respons yang dikembalikan oleh CloudFront
](custom-error-pages-response-code.md)
+ [

# Kontrol berapa lama CloudFront kesalahan cache
](custom-error-pages-expiration.md)

# Konfigurasikan perilaku respons kesalahan
<a name="custom-error-pages-procedure"></a>

Anda memiliki beberapa opsi untuk mengelola bagaimana CloudFront merespons ketika ada kesalahan. Untuk mengonfigurasi respons kesalahan kustom, Anda dapat menggunakan CloudFront konsol, CloudFront API, atau CloudFormation. Terlepas dari bagaimana Anda memilih untuk memperbarui konfigurasi, pertimbangkan tip dan rekomendasi berikut ini:
+ Simpan halaman kesalahan kustom Anda di lokasi yang dapat diakses CloudFront. Kami menyarankan agar Anda menyimpannya di bucket Amazon S3, dan bahwa Anda[jangan menyimpannya di tempat yang sama dengan situs web atau konten aplikasi lainnya](custom-error-pages-different-locations.md). Jika Anda menyimpan halaman kesalahan kustom pada asal yang sama dengan situs web atau aplikasi Anda, dan asal mulai mengembalikan kesalahan 5xx, tidak CloudFront bisa mendapatkan halaman kesalahan kustom karena server asal tidak tersedia. Untuk informasi selengkapnya, lihat [Menyimpan objek dan halaman kesalahan kustom di lokasi yang berbeda](custom-error-pages-different-locations.md).
+ Pastikan bahwa CloudFront memiliki izin untuk mendapatkan halaman kesalahan kustom Anda. Jika halaman kesalahan kustom disimpan di Amazon S3, halaman harus dapat diakses publik atau Anda harus mengonfigurasi [kontrol akses CloudFront asal (](private-content-restricting-access-to-s3.md)OAC). Jika halaman kesalahan kustom disimpan dalam asal kustom, halaman harus dapat diakses publik.
+ (Opsional) Konfigurasi asal Anda untuk menambahkan `Cache-Control` atau `Expires` bersama dengan halaman kesalahan kustom, jika Anda ingin. Anda juga dapat menggunakan pengaturan **Error Caching Minimum TTL** untuk mengontrol berapa lama CloudFront cache halaman kesalahan kustom. Untuk informasi selengkapnya, lihat [Kontrol berapa lama CloudFront kesalahan cache](custom-error-pages-expiration.md).

## Konfigurasikan respons kesalahan khusus
<a name="custom-error-pages-console"></a>

Untuk mengonfigurasi respons kesalahan khusus di CloudFront konsol, Anda harus memiliki CloudFront distribusi. Di konsol, pengaturan konfigurasi untuk respons kesalahan kustom hanya tersedia untuk distribusi yang ada. Untuk mempelajari cara membuat distribusi, lihat [Memulai dengan distribusi CloudFront standar](GettingStarted.SimpleDistribution.md).

------
#### [ Console ]

**Untuk mengonfigurasi respons kesalahan kustom (konsol)**

1. Masuk ke Konsol Manajemen AWS dan buka halaman **Distribusi** di CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions).

1. Pada daftar distribusi, pilih distribusi yang akan diperbarui.

1. Pilih tab **Halaman Kesalahan**, lalu pilih **Membuat Respons Kesalahan Kustom**.

1. Masukkan nilai yang berlaku. Untuk informasi selengkapnya, lihat [Halaman kesalahan kustom dan caching kesalahan](DownloadDistValuesErrorPages.md).

1. Setelah memasukkan nilai yang diinginkan, pilih **Buat**.

------
#### [ CloudFront API or CloudFormation ]

Untuk mengonfigurasi respons kesalahan kustom dengan CloudFront API atau CloudFormation, gunakan `CustomErrorResponse` tipe dalam distribusi. Untuk informasi selengkapnya, lihat berikut ini:
+ [AWS::CloudFront::Distribution CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html) di *Panduan Pengguna AWS CloudFormation *
+ [CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html)di *Referensi CloudFront API Amazon*

------

# Buat halaman kesalahan khusus untuk kode status HTTP tertentu
<a name="creating-custom-error-pages"></a>

Jika Anda lebih suka menampilkan pesan kesalahan kustom daripada pesan default—misalnya, halaman yang menggunakan format yang sama dengan situs web lainnya—Anda dapat CloudFront mengembalikan objek ke penampil (seperti file HTML) yang berisi pesan kesalahan kustom Anda.

Untuk menentukan file yang ingin Anda kembalikan dan kesalahan yang harus dikembalikan file, Anda memperbarui CloudFront distribusi Anda untuk menentukan nilai-nilai tersebut. Untuk informasi selengkapnya, lihat [Konfigurasikan perilaku respons kesalahan](custom-error-pages-procedure.md).

Misalnya, berikut ini adalah pesan kesalahan kustom:

![\[Screenshot dari contoh halaman AWS 404 kustom.\]](http://docs.aws.amazon.com/id_id/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png)


Anda dapat menentukan objek yang berbeda untuk setiap kode status HTTP yang didukung, atau Anda dapat menggunakan objek yang sama untuk semua kode status yang didukung. Anda dapat memilih untuk menentukan halaman kesalahan kustom untuk beberapa kode status dan tidak untuk yang lainnya.

Objek yang Anda layani CloudFront bisa tidak tersedia karena berbagai alasan. Hal ini dibagi ke dalam dua kategori luas:
+ *Kesalahan klien* menunjukkan masalah dengan permintaan. Misalnya, objek dengan nama yang ditentukan tidak tersedia, atau pengguna tidak memiliki izin yang diperlukan untuk mendapatkan objek di bucket Amazon S3. Ketika kesalahan klien terjadi, asal mengembalikan kode status HTTP dalam rentang 4xx ke CloudFront.
+ *Kesalahan server* menunjukkan masalah dengan server asal. Misalnya, server HTTP sibuk atau tidak tersedia. Ketika kesalahan server terjadi, server asal Anda mengembalikan kode status HTTP dalam rentang 5xx ke CloudFront, atau CloudFront tidak mendapatkan respons dari server asal Anda untuk jangka waktu tertentu dan mengasumsikan kode status 504 (Gateway Timeout).

Kode status HTTP yang CloudFront dapat mengembalikan halaman kesalahan kustom meliputi yang berikut:
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
**Catatan**  
Jika CloudFront mendeteksi bahwa permintaan mungkin tidak aman, CloudFront mengembalikan kesalahan 400 (Permintaan Buruk) alih-alih halaman kesalahan khusus.
Anda dapat membuat halaman kesalahan kustom untuk kode status HTTP 416 (Rentang yang Diminta Tidak Memuaskan), dan Anda dapat mengubah kode status HTTP yang CloudFront kembali ke pemirsa saat asal Anda mengembalikan kode status 416 ke. CloudFront Untuk informasi selengkapnya, lihat [Ubah kode respons yang dikembalikan oleh CloudFront](custom-error-pages-response-code.md). Namun, CloudFront tidak menyimpan kode status 416 respons, jadi meskipun Anda menentukan nilai untuk **Error Caching Minimum TTL** untuk kode status 416, CloudFront tidak menggunakannya.
Dalam beberapa kasus, CloudFront tidak mengembalikan halaman kesalahan khusus untuk kode status HTTP 503 bahkan jika Anda mengonfigurasi CloudFront untuk melakukannya. Jika kode CloudFront kesalahan `Capacity Exceeded` atau`Limit Exceeded`, CloudFront mengembalikan kode status 503 ke penampil tanpa menggunakan halaman kesalahan kustom Anda.
Jika Anda membuat halaman kesalahan kustom, CloudFront akan kembali `Connection: close` atau `Connection: keep-alive` untuk kode respons berikut:  
CloudFront pengembalian `Connection: close` untuk kode status: 400, 405, 414, 416, 500, 501
CloudFront pengembalian `Connection: keep-alive` untuk kode status: 403, 404, 502, 503, 504

Untuk penjelasan rinci tentang cara CloudFront menangani respons kesalahan dari asal Anda, lihat[Bagaimana CloudFront memproses kode status HTTP 4xx dan 5xx dari asal Anda](HTTPStatusCodes.md).

# Menyimpan objek dan halaman kesalahan kustom di lokasi yang berbeda
<a name="custom-error-pages-different-locations"></a>

Jika Anda ingin menyimpan objek Anda dan halaman kesalahan kustom Anda di lokasi yang berbeda, distribusi Anda harus menyertakan perilaku cache yang menyatakan hal berikut benar:
+ Nilai dari **Pola Jalan** sesuai dengan jalur ke pesan kesalahan khusus Anda. Misalnya, Anda menyimpan halaman kesalahan kustom untuk 4xx kesalahan dalam bucket Amazon S3 di direktori bernama `/4xx-errors`. Distribusi Anda harus menyertakan perilaku cache yang pola jalurnya merutekan permintaan untuk halaman kesalahan kustom Anda ke lokasi tersebut, misalnya, `/4xx-errors/*`.
+ Nilai dari **Asal** menentukan nilai dari **ID Asal** untuk asal yang berisi halaman kesalahan kustom Anda.

Untuk informasi selengkapnya, lihat [Pengaturan perilaku cache](DownloadDistValuesCacheBehavior.md).

# Ubah kode respons yang dikembalikan oleh CloudFront
<a name="custom-error-pages-response-code"></a>

Anda dapat mengonfigurasi CloudFront untuk mengembalikan kode status HTTP yang berbeda ke penampil daripada yang CloudFront diterima dari asal. Misalnya, jika asal Anda mengembalikan kode status 500CloudFront, Anda mungkin CloudFront ingin mengembalikan halaman kesalahan kustom dan kode status 200 (OK) ke penampil. Ada berbagai alasan mengapa Anda mungkin ingin CloudFront mengembalikan kode status ke penampil yang berbeda dari yang asal Anda kembalikanCloudFront:
+ Beberapa perangkat internet (beberapa firewall dan proksi korporat, misalnya) menangkap kode status HTTP 4xx dan 5xx dan mencegah respons kembali ke penampil. Dalam skenario ini, jika Anda mengganti `200`, respon tidak dicegat.
+ Jika Anda tidak peduli tentang membedakan antara kesalahan klien atau kesalahan server yang berbeda, Anda dapat menentukan `400` atau `500` sebagai nilai yang CloudFront mengembalikan semua kode status 4xx atau 5xx.
+ Anda mungkin ingin mengembalikan kode status `200` (OK) dan situs web statis sehingga pelanggan Anda tidak tahu bahwa situbgs web Anda sedang tidak aktif.

Jika Anda mengaktifkan [log CloudFront standar](AccessLogs.md) dan Anda mengonfigurasi CloudFront untuk mengubah kode status HTTP dalam respons, nilai `sc-status` kolom di log berisi kode status yang Anda tentukan. Namun, nilai kolom `x-edge-result-type` tidak terpengaruh. Ini berisi jenis hasil respons dari asal. Misalnya, Anda mengonfigurasi CloudFront untuk mengembalikan kode status `200` ke penampil saat asal kembali `404` (Tidak Ditemukan) ke CloudFront. Ketika asal merespon permintaan dengan kode status `404`, nilai dalam kolom `sc-status` di log menjadi `200`, tetapi nilai dalam kolom `x-edge-result-type` menjadi `Error`.

Anda dapat mengonfigurasi CloudFront untuk mengembalikan salah satu kode status HTTP berikut bersama dengan halaman kesalahan kustom:
+ 200
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504

# Kontrol berapa lama CloudFront kesalahan cache
<a name="custom-error-pages-expiration"></a>

CloudFront cache respons kesalahan untuk durasi default 10 detik. CloudFront kemudian mengirimkan permintaan berikutnya untuk objek ke asal Anda untuk melihat apakah masalah yang menyebabkan kesalahan telah diselesaikan dan objek yang diminta tersedia.

Anda dapat menentukan durasi error caching — **Error Caching Minimum TTL — untuk setiap kode status** 4xx dan 5xx yang di-cache. CloudFront (Untuk informasi selengkapnya, lihat [Kode status HTTP 4xx dan 5xx yang di-cache CloudFront](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors).) Saat Anda menentukan durasi, perhatikan hal berikut:
+ Jika Anda menentukan durasi caching kesalahan singkat, CloudFront teruskan lebih banyak permintaan ke asal Anda daripada jika Anda menentukan durasi yang lebih lama. Untuk 5xx kesalahan, ini dapat memperparah masalah yang awalnya menyebabkan asal Anda mengembalikan kesalahan.
+ Saat asal Anda mengembalikan kesalahan untuk suatu objek, CloudFront merespons permintaan objek baik dengan respons kesalahan atau dengan halaman kesalahan kustom Anda hingga durasi caching kesalahan berlalu. Jika Anda menentukan durasi caching kesalahan yang lama, CloudFront mungkin terus menanggapi permintaan dengan respons kesalahan atau halaman kesalahan kustom Anda untuk waktu yang lama setelah objek tersedia kembali.

**catatan**  
Anda dapat membuat halaman kesalahan kustom untuk kode status HTTP 416 (Rentang yang Diminta Tidak Memuaskan), dan Anda dapat mengubah kode status HTTP yang CloudFront kembali ke pemirsa saat asal Anda mengembalikan kode status 416 ke. CloudFront (Untuk informasi selengkapnya, lihat [Ubah kode respons yang dikembalikan oleh CloudFront](custom-error-pages-response-code.md).) Namun, CloudFront tidak menyimpan kode status 416 respons, jadi meskipun Anda menentukan nilai untuk **Error Caching Minimum TTL** untuk kode status 416, CloudFront tidak menggunakannya.

Jika Anda ingin mengontrol berapa lama kesalahan CloudFront cache untuk objek individual, Anda dapat mengonfigurasi server asal Anda untuk menambahkan header yang berlaku ke respons kesalahan untuk objek tersebut.

Jika asal menambahkan `Cache-Control: max-age` atau `Cache-Control: s-maxage` direktif, atau `Expires` header, CloudFront cache respons kesalahan untuk nilai yang lebih besar di header atau **Error Caching** Minimum TTL.

**catatan**  
`Cache-Control: s-maxage`Nilai `Cache-Control: max-age` dan tidak boleh lebih besar dari nilai **TTL Maksimum** yang ditetapkan untuk perilaku cache yang halaman kesalahan diambil.

Jika asal menambahkan`Cache-Control: no-store`,`Cache-Control: no-cache`, atau `Cache-Control: private` direktif untuk kode kesalahan 404, 410, 414, atau 501, CloudFront tidak men-cache respons kesalahan. **Untuk semua kode kesalahan lainnya, CloudFront abaikan `private` arahan`no-store`,`no-cache`, dan cache respons kesalahan untuk nilai Error Caching Minimum TTL.**

**Jika asal menambahkan `Cache-Control` arahan lain atau tidak menambahkan header, CloudFront cache respons kesalahan untuk nilai Error Caching Minimum TTL.**

Jika waktu kedaluwarsa untuk kode status 4xx atau 5xx untuk objek lebih lama dari yang Anda inginkan, dan objek tersedia lagi, Anda dapat membatalkan kode galat cache dengan menggunakan URL objek yang diminta. Jika asal Anda mengembalikan respons kesalahan untuk beberapa objek, Anda perlu menggugurkan setiap objek secara terpisah. Untuk informasi lebih lanjut tentang objek yang tidak valid, lihat [Membatalkan file untuk menghapus konten](Invalidation.md).

Jika Anda mengaktifkan caching untuk asal bucket S3, dan Anda mengonfigurasi kesalahan caching TTL minimum 0 detik dalam CloudFront distribusi Anda, Anda masih akan melihat kesalahan caching TTL minimum 1 detik untuk kesalahan asal S3. CloudFront melakukan ini untuk melindungi asal Anda dari serangan DDo S. Ini tidak berlaku untuk jenis asal lainnya.