Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah kode status respons kesalahan di CloudFront
Jika CloudFront meminta objek dari asal Anda, dan asal mengembalikan kode status HTTP 4xx atau 5xx, ada masalah dengan komunikasi antara CloudFront dan asal Anda.
Topik ini juga mencakup langkah-langkah pemecahan masalah untuk kode status ini saat menggunakan Lambda @Edge atau Functions. CloudFront
Topik berikut memberikan penjelasan rinci tentang penyebab potensial di balik respons kesalahan ini dan menawarkan step-by-step panduan tentang cara mendiagnosis dan menyelesaikan masalah yang mendasarinya.
**Topics**
+ [Kode status HTTP 400 (Permintaan Buruk)](http-400-bad-request.md)
+ [Kode status HTTP 401 (Tidak Sah)](http-401-unauthorized.md)
+ [Kode status HTTP 403 (Metode tidak valid)](http-403-invalid-method.md)
+ [Kode status HTTP 403 (Izin Ditolak)](http-403-permission-denied.md)
+ [Kode status HTTP 404 (Tidak Ditemukan)](http-404-not-found.md)
+ [Kode status HTTP 412 (Prasyarat Gagal)](http-412-precondition-failed.md)
+ [Kode status HTTP 500 (Kesalahan Server Internal)](http-500-internal-server-error.md)
+ [Kode status HTTP 502 (Gerbang Buruk)](http-502-bad-gateway.md)
+ [Kode status HTTP 503 (Layanan Tidak Tersedia)](http-503-service-unavailable.md)
+ [Kode status HTTP 504 (Gateway Timeout)](http-504-gateway-timeout.md)
# Kode status HTTP 400 (Permintaan Buruk)
CloudFront mengembalikan 400 permintaan buruk ketika klien mengirim beberapa data yang tidak valid dalam permintaan seperti konten yang hilang atau salah dalam payload atau parameter. Ini juga bisa mewakili kesalahan klien generik.
## Asal Amazon S3 mengembalikan kesalahan 400
Jika Anda menggunakan asal Amazon S3 dengan distribusi Anda, CloudFront distribusi Anda mungkin mengirim respons kesalahan dengan kode status HTTP 400 Permintaan Buruk, dan pesan yang mirip dengan berikut ini:
*Header otorisasi salah bentuk; wilayah '**' salah; mengharapkan '' ***
Contoh:
*Header otorisasi salah bentuk; wilayah 'us-east-1' salah; mengharapkan 'us-west-2'*
Masalah ini dapat terjadi pada skenario berikut:
1. Asal CloudFront distribusi Anda adalah ember Amazon S3.
1. Anda memindahkan ember S3 dari satu AWS Wilayah ke Wilayah lainnya. Artinya, Anda menghapus bucket S3, lalu Anda membuat bucket baru dengan nama bucket yang sama, tetapi di AWS Wilayah yang berbeda dari tempat bucket S3 asli berada.
Untuk memperbaiki kesalahan ini, perbarui CloudFront distribusi Anda sehingga menemukan bucket S3 di AWS Wilayah bucket saat ini.
**Untuk memperbarui CloudFront distribusi Anda**
1. Masuk ke Konsol Manajemen AWS dan buka CloudFront konsol di[https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Pilih distribusi yang menghasilkan kesalahan ini.
1. Pilih **Grup Asal dan Asal**.
1. Temukan asal buket S3 yang Anda pindahkan. Pilih kotak centang di samping asal ini, lalu pilih **Edit**.
1. Pilih **Ya, Edit**. Anda tidak perlu mengubah pengaturan apa pun sebelum memilih **Ya, Edit**.
Saat Anda menyelesaikan langkah-langkah ini, CloudFront pindahkan distribusi Anda. Saat distribusi diterapkan, Anda melihat status **Deploying** di bawah kolom **Terakhir dimodifikasi**. Beberapa saat setelah penerapan selesai, Anda harus berhenti menerima respons `AuthorizationHeaderMalformed` kesalahan.
## Asal Application Load Balancer mengembalikan kesalahan 400
Jika Anda menggunakan asal Application Load Balancer dengan CloudFront distribusi Anda, kemungkinan penyebab kesalahan 400 termasuk yang berikut:
+ Klien mengirim permintaan cacat yang tidak memenuhi spesifikasi HTTP.
+ Header permintaan melebihi 16 KB per baris permintaan, 16 KB per header tunggal, atau 64 KB untuk seluruh header permintaan.
+ Klien menutup koneksi sebelum mengirim badan permintaan lengkap.
# Kode status HTTP 401 (Tidak Sah)
Kode status respons 401 Tidak Sah menunjukkan bahwa permintaan klien belum selesai karena tidak memiliki kredensyal otentikasi yang valid untuk sumber daya yang diminta. Kode status ini dikirim dengan header `WWW-Authenticate` respons HTTP yang berisi informasi tentang bagaimana klien dapat meminta sumber daya lagi setelah meminta pengguna untuk kredensyal otentikasi. Untuk informasi lebih lanjut, lihat [401 Tidak](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401) Sah.
Dalam CloudFront, jika asal Anda mengharapkan `Authorization` header untuk mengautentikasi permintaan, CloudFront perlu meneruskan `Authorization` header ke asal untuk menghindari kesalahan 401 Tidak Sah. Saat CloudFront meneruskan permintaan penampil ke asal Anda, CloudFront hapus beberapa header penampil secara default, termasuk header. `Authorization` Untuk memastikan bahwa asal Anda selalu menerima header `Authorization` di permintaan asal, Anda memiliki opsi berikut:
+ Tambahkan `Authorization` header ke kunci cache dengan menggunakan kebijakan cache. Semua header di kunci cache secara otomatis disertakan dalam permintaan asal. Untuk informasi selengkapnya, lihat [Mengontrol kunci cache dengan kebijakan](controlling-the-cache-key.md).
+ Gunakan kebijakan permintaan asal yang meneruskan semua header penampil ke asal. Anda tidak dapat meneruskan `Authorization` header satu per satu dalam kebijakan permintaan asal, tetapi saat Anda meneruskan semua header penampil, CloudFront sertakan `Authorization` header dalam permintaan penampil. CloudFrontmenyediakan kebijakan permintaan `AllViewer` asal terkelola untuk kasus penggunaan ini. Untuk informasi selengkapnya, lihat [Gunakan kebijakan permintaan asal terkelola](using-managed-origin-request-policies.md).
Untuk informasi selengkapnya, [lihat Bagaimana cara mengonfigurasi CloudFront untuk meneruskan header Otorisasi ke asal?](https://repost.aws/knowledge-center/cloudfront-authorization-header)
# Kode status HTTP 403 (Metode tidak valid)
CloudFront mengembalikan kesalahan 403 (Metode tidak valid) jika Anda mencoba menggunakan metode HTTP yang belum Anda tentukan dalam distribusi. CloudFront Anda dapat menentukan salah satu opsi berikut untuk distribusi Anda:
+ CloudFront hanya ke depan `GET` dan `HEAD` permintaan.
+ CloudFront hanya ke depan`GET`,`HEAD`, dan `OPTIONS` permintaan.
+ CloudFront maju`GET`,,`HEAD`,`OPTIONS`,`PUT`, `PATCH``POST`, dan `DELETE` permintaan. (Jika memilih opsi ini, Anda mungkin perlu membatasi akses ke bucket Amazon S3 atau custom origin agar pengguna tidak dapat melakukan operasi yang tidak Anda inginkan. Misalnya, Anda mungkin tidak ingin pengguna memiliki izin untuk menghapus objek dari asal Anda.
# Kode status HTTP 403 (Izin Ditolak)
Kesalahan HTTP 403 berarti klien tidak berwenang untuk mengakses sumber daya yang diminta. Klien memahami permintaan tersebut, tetapi tidak dapat mengotorisasi akses penampil. Berikut ini adalah penyebab umum ketika CloudFront mengembalikan kode status ini:
**Topics**
+ [CNAME alternatif tidak dikonfigurasi dengan benar](#alternate-cname-incorrectly-configured)
+ [AWS WAF dikonfigurasi pada CloudFront distribusi atau di asal](#aws-waf-configured-on-distribution-origin)
+ [Asal kustom mengembalikan kesalahan 403](#custom-origin-returning-403)
+ [Asal Amazon S3 mengembalikan kesalahan 403](#s3-origin-403-error)
+ [Pembatasan geografis mengembalikan kesalahan 403](#geolocation-403)
+ [URL yang ditandatangani atau konfigurasi cookie yang ditandatangani mengembalikan kesalahan 403](#signed-URLs-cookies-403)
+ [Distribusi bertumpuk menyebabkan kesalahan 403](#stacked-distributions-403)
## CNAME alternatif tidak dikonfigurasi dengan benar
Verifikasi bahwa Anda menentukan CNAME yang benar untuk distribusi kami. Untuk menggunakan CNAME alternatif, bukan CloudFront URL default:
1. Buat catatan CNAME di DNS Anda untuk mengarahkan CNAME ke CloudFront URL distribusi.
1. Tambahkan CNAME dalam konfigurasi CloudFront distribusi Anda.
Jika Anda membuat catatan DNS tetapi tidak menambahkan CNAME dalam konfigurasi CloudFront distribusi Anda, maka permintaan akan mengembalikan kesalahan 403. Untuk informasi selengkapnya tentang mengonfigurasi CNAME kustom, lihat. [Gunakan kustom URLs dengan menambahkan nama domain alternatif (CNAMEs)](CNAMEs.md)
## AWS WAF dikonfigurasi pada CloudFront distribusi atau di asal
Ketika AWS WAF berada di antara klien dan CloudFront, tidak CloudFront dapat membedakan antara kode kesalahan 403 yang dikembalikan oleh asal Anda dan kode kesalahan 403 yang dikembalikan AWS WAF ketika permintaan diblokir.
Untuk menemukan sumber kode status 403, periksa aturan daftar kontrol akses AWS WAF web (ACL) Anda untuk permintaan yang diblokir. Untuk informasi selengkapnya, lihat topik berikut:
+ [AWS WAF daftar kontrol akses web (webACLs)](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)
+ [Menguji dan menyetel perlindungan Anda AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html)
## Asal kustom mengembalikan kesalahan 403
Jika Anda menggunakan custom origin, Anda mungkin melihat error 403 jika Anda memiliki konfigurasi firewall kustom di asal. Untuk memecahkan masalah, buat permintaan langsung ke asal. Jika Anda dapat mereplikasi kesalahan tanpa CloudFront, maka asal menyebabkan kesalahan 403.
Jika asal kustom menyebabkan kesalahan, periksa log asal untuk mengidentifikasi apa yang mungkin menyebabkan kesalahan. Untuk informasi selengkapnya, lihat topik pemecahan masalah berikut:
+ [Bagaimana cara memecahkan masalah kesalahan HTTP 403 dari API Gateway?](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-troubleshoot-403-forbidden/ )
+ [Bagaimana cara mengatasi kesalahan terlarang Application Load Balancer HTTP 403?](https://repost.aws/knowledge-center/alb-http-403-error)
## Asal Amazon S3 mengembalikan kesalahan 403
Anda mungkin melihat kesalahan 403 karena alasan berikut:
+ CloudFront tidak memiliki akses ke bucket Amazon S3. Ini dapat terjadi jika identitas akses asal (OAI) atau kontrol akses asal (OAC) tidak diaktifkan untuk distribusi Anda dan bucket bersifat pribadi.
+ Jalur yang ditentukan dalam URL yang diminta tidak benar.
+ Objek yang diminta tidak ada.
+ Header host diteruskan dengan titik akhir REST API. Untuk informasi selengkapnya, lihat [spesifikasi bucket header HTTP Host](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#VirtualHostingSpecifyBucket) di *Panduan Pengguna Layanan Penyimpanan Sederhana Amazon*.
+ Anda mengkonfigurasi halaman kesalahan kustom. Untuk informasi selengkapnya, lihat [Bagaimana CloudFront proses kesalahan ketika Anda telah mengkonfigurasi halaman kesalahan kustom](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
## Pembatasan geografis mengembalikan kesalahan 403
Jika Anda mengaktifkan pembatasan geografis (juga dikenal sebagai geoblocking) untuk mencegah pengguna di lokasi geografis tertentu mengakses konten yang Anda distribusikan melalui CloudFront distribusi, pengguna yang diblokir akan menerima kesalahan 403.
Untuk informasi selengkapnya, lihat [Batasi distribusi geografis konten Anda](georestrictions.md).
## URL yang ditandatangani atau konfigurasi cookie yang ditandatangani mengembalikan kesalahan 403
Jika Anda mengaktifkan **Batasi akses penampil** untuk konfigurasi perilaku distribusi Anda, permintaan yang tidak menggunakan cookie yang ditandatangani atau ditandatangani URLs menghasilkan kesalahan 403. Untuk informasi selengkapnya, lihat topik berikut:
+ [Sajikan konten pribadi dengan cookie yang ditandatangani URLs dan ditandatangani](PrivateContent.md)
+ [Bagaimana cara memecahkan masalah yang terkait dengan URL yang ditandatangani atau cookie yang ditandatangani? CloudFront](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-troubleshoot-signed-url-cookies/)
## Distribusi bertumpuk menyebabkan kesalahan 403
Jika Anda memiliki dua atau lebih distribusi dalam rantai permintaan ke titik akhir asal, CloudFront mengembalikan kesalahan 403. Kami tidak menyarankan menempatkan satu distribusi di depan yang lain.
# Kode status HTTP 404 (Tidak Ditemukan)
CloudFront mengembalikan kesalahan 404 (Tidak Ditemukan) saat klien mencoba mengakses sumber daya yang tidak ada. Jika Anda menerima kesalahan ini dengan CloudFront distribusi Anda, penyebab umum termasuk yang berikut:
+ Sumber daya tidak ada.
+ URL tidak benar.
+ Asal kustom mengembalikan 404.
+ Halaman kesalahan kustom mengembalikan 404. (Kode kesalahan apa pun dapat diterjemahkan ke 404.) Untuk informasi selengkapnya, lihat [Bagaimana CloudFront proses kesalahan ketika Anda telah mengkonfigurasi halaman kesalahan kustom](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
+ Halaman kesalahan kustom tidak sengaja dihapus, menghasilkan 404 karena permintaan mencari halaman kesalahan kustom yang dihapus. Untuk informasi selengkapnya, lihat [Cara CloudFront memproses kesalahan jika Anda belum mengonfigurasi halaman kesalahan kustom](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages).
+ Jalur asal salah. Jika jalur asal diisi, nilainya ditambahkan ke jalur setiap permintaan dari browser sebelum permintaan diteruskan ke asal. Untuk informasi selengkapnya, lihat [Jalur asal](DownloadDistValuesOrigin.md#DownloadDistValuesOriginPath).
# Kode status HTTP 412 (Prasyarat Gagal)
CloudFront mengembalikan kode kesalahan 412 (Prasyarat Gagal) ketika akses ke sumber daya target telah ditolak. Dalam beberapa kasus, server dikonfigurasi untuk menerima permintaan hanya setelah kondisi tertentu terpenuhi. Jika salah satu kondisi yang ditentukan tidak terpenuhi, maka server tidak mengizinkan klien untuk mengakses sumber daya yang diberikan. Sebagai gantinya, server merespons dengan kode kesalahan 412.
Penyebab umum kesalahan 412 di CloudFront antaranya:
+ Permintaan bersyarat pada metode selain `GET` atau `HEAD` ketika kondisi yang ditentukan oleh `If-None-Match` header `If-Unmodified-Since` atau tidak terpenuhi. Dalam hal ini, permintaan, biasanya unggahan atau modifikasi sumber daya, tidak dapat dibuat.
+ Kondisi di satu atau beberapa bidang permintaan dalam operasi CloudFront [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)API dievaluasi sebagai false.
# Kode status HTTP 500 (Kesalahan Server Internal)
Kode status HTTP 500 (Internal Server Error) menunjukkan bahwa server mengalami kondisi tak terduga yang mencegahnya memenuhi permintaan. Berikut ini adalah beberapa penyebab umum dari 500 kesalahan di Amazon CloudFront.
**Topics**
+ [Server asal mengembalikan kesalahan 500 ke CloudFront](#origin-server-500-error)
## Server asal mengembalikan kesalahan 500 ke CloudFront
Server asal Anda mungkin mengembalikan kesalahan 500 ke CloudFront. Lihat topik pemecahan masalah berikut untuk informasi lebih lanjut:
+ **Jika Amazon S3 mengembalikan kesalahan 500**, lihat [Bagaimana cara memecahkan masalah kesalahan HTTP 500 atau 503 dari](https://repost.aws/knowledge-center/http-5xx-errors-s3) Amazon S3?
+ **Jika API Gateway menampilkan kesalahan 500**, lihat [Bagaimana cara mengatasi kesalahan 5xx untuk API Gateway REST API?](https://repost.aws/knowledge-center/api-gateway-5xx-error) .
+ **Jika Elastic Load Balancing mengembalikan kesalahan 500**, lihat [HTTP 500: Kesalahan server internal](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-500-issues) dalam *Panduan Pengguna untuk Application Load* Balancers.
Jika daftar sebelumnya tidak menyelesaikan kesalahan 500, masalahnya mungkin dengan CloudFront Point of Presence yang mengembalikan kesalahan server internal. Anda dapat menghubungi [Dukungan](https://console.aws.amazon.com/support/home#/)untuk bantuan.
# Kode status HTTP 502 (Gerbang Buruk)
CloudFront mengembalikan kode status HTTP 502 (Bad Gateway) ketika CloudFront tidak dapat melayani objek yang diminta karena tidak dapat terhubung ke server asal.
Jika Anda menggunakan Lambda @Edge, masalahnya mungkin kesalahan validasi Lambda. Jika Anda menerima kesalahan HTTP 502 dengan kode `NonS3OriginDnsError` kesalahan, kemungkinan ada masalah konfigurasi DNS yang CloudFront mencegah tersambung ke asal.
**Topics**
+ [Kegagalan negosiasi SSL/TLS antara CloudFront dan server asal kustom](#ssl-negotitation-failure)
+ [Origin tidak merespons dengan cipher/protokol yang didukung](#origin-not-responding-with-supported-ciphers-protocols)
+ [Sertifikat SSL/TLS pada asal kedaluwarsa, tidak valid, ditandatangani sendiri, atau rantai sertifikat dalam urutan yang salah](#ssl-certificate-expired)
+ [Origin tidak merespons pada port tertentu dalam pengaturan asal](#origin-not-responding-on-specified-ports)
+ [Kesalahan validasi Lambda](#http-502-lambda-validation-error)
+ [CloudFront kesalahan validasi fungsi](#http-502-cloudfront-function-validation-error)
+ [Kesalahan DNS () `NonS3OriginDnsError`](#http-502-dns-error)
+ [Kesalahan asal Application Load Balancer 502](#cloudfront-alb-502-error)
+ [Kesalahan 502 asal API Gateway](#cloudfront-api-gateway-502-error)
## Kegagalan negosiasi SSL/TLS antara CloudFront dan server asal kustom
Jika Anda menggunakan custom origin yang memerlukan HTTPS antara CloudFront dan asal Anda, nama domain yang tidak cocok dapat menyebabkan kesalahan. SSL/TLS Sertifikat asal Anda *harus* menyertakan nama domain yang cocok dengan **Domain Asal** yang Anda tentukan untuk CloudFront distribusi atau `Host` header permintaan asal.
Jika nama domain tidak cocok, SSL/TLS jabat tangan gagal, dan CloudFront mengembalikan kode status HTTP 502 (Bad Gateway) dan menetapkan `X-Cache` header ke. `Error from cloudfront`
Untuk menentukan apakah nama domain dalam sertifikat cocok dengan **Domain Asal** dalam distribusi atau `Host` header, Anda dapat menggunakan pemeriksa SSL online atau OpenSSL. Jika nama domain tidak cocok, Anda memiliki dua opsi:
+ Dapatkan SSL/TLS sertifikat baru yang menyertakan nama domain yang berlaku.
Jika Anda menggunakan AWS Certificate Manager (ACM), lihat [Meminta sertifikat publik](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) di *Panduan AWS Certificate Manager Pengguna* untuk meminta sertifikat baru.
+ Ubah konfigurasi distribusi sehingga CloudFront tidak lagi mencoba menggunakan SSL untuk terhubung dengan asal Anda.
### Pemeriksa SSL online
Untuk menemukan alat uji SSL, cari “pemeriksaan ssl online” di internet. Biasanya, Anda menentukan nama domain Anda, dan alat mengembalikan berbagai informasi tentang SSL/TLS sertifikat Anda. Konfirmasikan bahwa sertifikat berisi nama domain Anda di **Nama Umum** atau **Nama Alternatif Subjek** bidang.
### OpenSSL
Untuk membantu memecahkan masalah kesalahan HTTP 502 CloudFront, Anda dapat menggunakan OpenSSL untuk mencoba membuat koneksi ke server asal Anda. SSL/TLS Jika OpenSSL tidak dapat membuat koneksi, itu dapat menunjukkan masalah dengan konfigurasi SSL/TLS server asal Anda. Jika OpenSSL dapat membuat koneksi, ia mengembalikan informasi tentang sertifikat server asal, termasuk nama umum sertifikat `Subject CN` (bidang) dan nama `Subject Alternative Name` alternatif subjek (bidang).
Gunakan perintah OpenSSL berikut untuk menguji koneksi ke server asal Anda (*origin domain*ganti dengan nama domain server asal Anda, seperti example.com):
`openssl s_client -connect origin domain name:443`
Jika yang berikut ini benar:
+ Server asal Anda mendukung beberapa nama domain dengan beberapa sertifikat SSL/TLS
+ Distribusi Anda dikonfigurasi untuk meneruskan `Host` header ke asal
Kemudian tambahkan `-servername` opsi ke perintah OpenSSL, seperti pada contoh berikut (*CNAME*ganti dengan CNAME yang dikonfigurasi dalam distribusi Anda):
`openssl s_client -connect origin domain name:443 -servername CNAME`
## Origin tidak merespons dengan cipher/protokol yang didukung
CloudFront terhubung ke server asal menggunakan cipher dan protokol. Untuk daftar cipher dan protokol yang CloudFront mendukung, lihat. [Protokol dan cipher yang didukung antara dan asal CloudFront](secure-connections-supported-ciphers-cloudfront-to-origin.md) Jika asal Anda tidak merespons dengan salah satu sandi atau protokol ini di pertukaran SSL/TLS, gagal terhubung. CloudFront [Anda dapat memvalidasi bahwa asal Anda mendukung sandi dan protokol dengan menggunakan alat online seperti SSL Labs.](https://www.ssllabs.com/ssltest) Ketikkan nama domain asal Anda di **Nama host** , lalu pilih **Kirim**. Meninjau **Nama umum** dan **Nama alternatif** bidang dari pengujian untuk melihat apakah sesuai dengan nama domain asal Anda. Setelah uji selesai, temukan **Protokol** dan **Cipher Suites** bagian dalam hasil uji untuk melihat cipher atau protokol mana yang didukung oleh asal Anda. Bandingkan dengan daftar[Protokol dan cipher yang didukung antara dan asal CloudFront](secure-connections-supported-ciphers-cloudfront-to-origin.md).
## Sertifikat SSL/TLS pada asal kedaluwarsa, tidak valid, ditandatangani sendiri, atau rantai sertifikat dalam urutan yang salah
Jika server asal mengembalikan berikut ini, CloudFront menjatuhkan koneksi TCP, mengembalikan kode status HTTP 502 (Bad Gateway), dan menetapkan `X-Cache` header ke: `Error from cloudfront`
+ Sertifikat yang kedaluwarsa
+ Sertifikat tidak valid
+ Sertifikat yang ditandatangani sendiri
+ Rantai sertifikat dalam urutan yang salah
**catatan**
Jika rantai lengkap sertifikat, termasuk sertifikat perantara, tidak ada, lepaskan CloudFront koneksi TCP.
Untuk informasi tentang menginstal SSL/TLS sertifikat di server asal kustom Anda, lihat[Memerlukan HTTPS untuk komunikasi antara CloudFront dan asal kustom Anda](using-https-cloudfront-to-custom-origin.md).
## Origin tidak merespons pada port tertentu dalam pengaturan asal
Ketika Anda membuat asal pada CloudFront distribusi Anda, Anda dapat mengatur port yang CloudFront terhubung ke asal dengan untuk lalu lintas HTTP dan HTTPS. Secara default, ini adalah TCP 80/443. Anda memiliki opsi untuk mengubah port ini. Jika asal Anda menolak lalu lintas pada port ini karena alasan apa pun, atau jika server backend Anda tidak merespons pada port, CloudFront akan gagal terhubung.
Untuk memecahkan masalah ini, periksa firewall apa pun yang berjalan di infrastruktur Anda dan pastikan firewall tersebut tidak menghalangi rentang IP yang didukung. Untuk informasi selengkapnya, lihat [rentang alamat AWS IP](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) di *Panduan Pengguna Amazon VPC*. Selain itu, verifikasi apakah server web Anda berjalan di tempat asalnya.
## Kesalahan validasi Lambda
Jika Anda menggunakan Lambda @Edge, kode status HTTP 502 dapat menunjukkan bahwa respons fungsi Lambda Anda salah dibentuk atau menyertakan konten yang tidak valid. Untuk informasi selengkapnya tentang pemecahan masalah kesalahan Lambda@Edge, lihat [Uji dan debug fungsi Lambda @Edge](lambda-edge-testing-debugging.md).
## CloudFront kesalahan validasi fungsi
Jika Anda menggunakan CloudFront fungsi, kode status HTTP 502 dapat menunjukkan bahwa CloudFront fungsi tersebut mencoba menambahkan, menghapus, atau mengubah header hanya-baca. Kesalahan ini tidak muncul selama pengujian, tetapi akan muncul setelah Anda menerapkan fungsi dan menjalankan permintaan. Untuk mengatasi kesalahan ini, periksa dan perbarui CloudFront fungsi Anda. Untuk informasi selengkapnya, lihat [Perbarui fungsi](update-function.md).
## Kesalahan DNS () `NonS3OriginDnsError`
Kesalahan HTTP 502 dengan kode `NonS3OriginDnsError` kesalahan menunjukkan bahwa ada masalah konfigurasi DNS yang CloudFront mencegah tersambung ke asal. Jika Anda mendapatkan kesalahan ini CloudFront, pastikan konfigurasi DNS asal sudah benar dan berfungsi.
Ketika CloudFront menerima permintaan untuk objek yang kedaluwarsa atau tidak dalam cache, itu membuat permintaan ke asal untuk mendapatkan objek. Untuk membuat permintaan yang berhasil ke asal, CloudFront lakukan resolusi DNS pada domain asal. Jika layanan DNS untuk domain Anda mengalami masalah, tidak CloudFront dapat menyelesaikan nama domain untuk mendapatkan alamat IP, yang menghasilkan kesalahan HTTP 502 ()`NonS3OriginDnsError`. Untuk memperbaiki masalah ini, hubungi penyedia DNS Anda, atau, jika Anda menggunakan Amazon Route 53, lihat [Mengapa saya tidak dapat mengakses situs web saya yang menggunakan layanan DNS Route 53](https://aws.amazon.com/premiumsupport/knowledge-center/route-53-dns-website-unreachable/)?
Untuk mengatasi masalah ini lebih lanjut, pastikan bahwa [server nama otoritatif](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-authoritative-name-server) domain akar atau puncak zona asal Anda (seperti `example.com`) berfungsi dengan benar. Anda dapat menggunakan perintah berikut untuk menemukan server nama untuk asal puncak Anda, dengan alat seperti [dig](https://en.wikipedia.org/wiki/Dig_(command)) atau [nslookup](https://en.wikipedia.org/wiki/Nslookup):
```
dig OriginAPEXDomainName NS +short
```
```
nslookup -query=NS OriginAPEXDomainName
```
Saat Anda memiliki nama server nama Anda, gunakan perintah berikut untuk menanyakan nama domain asal Anda terhadap server tersebut guna memastikan bahwa setiap server menjawabnya dengan jawaban:
```
dig OriginDomainName @NameServer
```
```
nslookup OriginDomainName NameServer
```
**penting**
Pastikan Anda melakukan pemecahan masalah DNS ini menggunakan komputer yang terhubung ke internet publik. CloudFront menyelesaikan domain asal menggunakan DNS publik di internet, jadi penting untuk memecahkan masalah dalam konteks yang sama.
Jika asal Anda adalah subdomain yang otoritas DNSNYA didelegasikan ke server nama yang berbeda dari domain root, pastikan bahwa catatan name server (`NS`) dan start of authority (`SOA`) dikonfigurasi dengan benar untuk subdomain. Anda dapat memeriksa catatan ini menggunakan perintah yang mirip dengan contoh sebelumnya.
Untuk informasi selengkapnya tentang DNS, lihat [konsep Sistem Nama Domain (DNS) dalam dokumentasi](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-domain-name-system-dns) Amazon Route 53.
## Kesalahan asal Application Load Balancer 502
Jika Anda menggunakan Application Load Balancer sebagai asal Anda dan menerima kesalahan 502, lihat [Bagaimana cara mengatasi kesalahan Application Load Balancer HTTP](https://repost.aws/knowledge-center/elb-alb-troubleshoot-502-errors) 502? .
## Kesalahan 502 asal API Gateway
Jika Anda menggunakan API Gateway dan menerima kesalahan 502, lihat [Bagaimana cara mengatasi kesalahan HTTP 502 dari API Gateway REST dengan integrasi proxy APIs Lambda?](https://repost.aws/knowledge-center/malformed-502-api-gateway) .
# Kode status HTTP 503 (Layanan Tidak Tersedia)
Kode status HTTP 503 (Layanan Tidak Tersedia) biasanya menunjukkan masalah kinerja pada server asal. Dalam kasus yang jarang terjadi, ini menunjukkan bahwa CloudFront sementara tidak dapat memenuhi permintaan karena kendala sumber daya di lokasi tepi.
Jika Anda menggunakan Lambda @Edge atau CloudFront Functions, masalahnya mungkin kesalahan eksekusi atau kesalahan Lambda @Edge limit exceeded.
**Topics**
+ [Server asal tidak memiliki kapasitas yang cukup untuk mendukung tingkat permintaan](#http-503-service-unavailable-not-enough-origin-capacity)
+ [CloudFront menyebabkan kesalahan karena kendala sumber daya di lokasi tepi](#http-503-service-unavailable-limited-resources-at-edge-location)
+ [Lambda @Edge atau Kesalahan eksekusi CloudFront Fungsi](#http-503-lambda-execution-error)
+ [Batas Lambda @Edge terlampaui](#http-503-lambda-limit-exceeded-error)
## Server asal tidak memiliki kapasitas yang cukup untuk mendukung tingkat permintaan
Ketika server asal tidak tersedia atau tidak dapat melayani permintaan masuk, ia mengembalikan kode status HTTP 503 (Layanan Tidak Tersedia). CloudFront kemudian menyampaikan kesalahan kembali ke pengguna. Untuk mengatasi masalah ini, coba solusi berikut:
+ **Jika Anda menggunakan Amazon S3 sebagai server asal Anda**:
+ Anda dapat mengirim 3.500 PUT/COPY/POST/DELETE or 5,500 GET/HEAD permintaan per detik per awalan Amazon S3 yang dipartisi. Saat Amazon S3 mengembalikan respons Perlahan 503, ini biasanya menunjukkan tingkat permintaan yang berlebihan terhadap awalan Amazon S3 tertentu.
Karena tingkat permintaan berlaku per awalan dalam bucket S3, objek harus didistribusikan di beberapa awalan. Saat tingkat permintaan pada awalan meningkat secara bertahap, Amazon S3 meningkatkan skala untuk menangani permintaan untuk setiap awalan secara terpisah. Akibatnya, tingkat permintaan keseluruhan yang ditangani bucket adalah kelipatan dari jumlah awalan.
+ Untuk informasi selengkapnya, lihat [Mengoptimalkan kinerja Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) di Panduan Pengguna *Layanan Penyimpanan Sederhana Amazon*.
+ **Jika Anda menggunakan Elastic Load Balancing sebagai server asal Anda**:
+ Pastikan bahwa instance backend Anda dapat merespons pemeriksaan kesehatan.
+ Pastikan bahwa load balancer dan instans backend Anda dapat menangani beban.
Untuk informasi lebih lanjut, lihat:
+ [Bagaimana cara memecahkan masalah 503 kesalahan yang dikembalikan saat menggunakan Classic Load Balancer?](https://repost.aws/knowledge-center/503-error-classic)
+ [Bagaimana cara mengatasi kesalahan 503 (layanan tidak tersedia) dari Application Load Balancer saya?](https://repost.aws/knowledge-center/alb-troubleshoot-503-errors)
+ **Jika Anda menggunakan custom origin**:
+ Periksa log aplikasi untuk memastikan bahwa asal Anda memiliki sumber daya yang cukup, seperti memori, CPU, dan ukuran disk.
+ Jika Anda menggunakan Amazon EC2 sebagai backend, pastikan bahwa jenis instans memiliki sumber daya yang sesuai untuk memenuhi permintaan masuk. Untuk informasi lebih lanjut, lihat [Tipe instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) di *Panduan Pengguna Amazon EC2*.
+ **Jika Anda menggunakan API Gateway**:
+ Kesalahan ini terkait dengan integrasi backend saat API Gateway API tidak dapat menerima respons. Server backend mungkin:
+ Kelebihan beban melebihi kapasitas dan tidak dapat memproses permintaan klien baru.
+ Di bawah pemeliharaan sementara.
+ Untuk mengatasi kesalahan ini, lihat log aplikasi API Gateway Anda untuk menentukan apakah ada masalah dengan kapasitas backend, integrasi, atau yang lainnya.
## CloudFront menyebabkan kesalahan karena kendala sumber daya di lokasi tepi
Anda akan menerima kesalahan ini dalam situasi langka yang tidak CloudFront dapat merutekan permintaan ke lokasi tepi terbaik berikutnya yang tersedia, sehingga tidak dapat memenuhi permintaan. Kesalahan ini umum terjadi saat Anda melakukan pengujian pemuatan pada CloudFront distribusi. Untuk membantu mencegah hal ini, ikuti [Pengujian beban CloudFront](load-testing.md) pedoman untuk menghindari kesalahan 503 (kapasitas terlampaui).
Jika ini terjadi di lingkungan produksi Anda, hubungi [Dukungan](https://console.aws.amazon.com/support/home#/).
## Lambda @Edge atau Kesalahan eksekusi CloudFront Fungsi
Jika Anda menggunakan Lambda @Edge atau CloudFront Functions, kode status HTTP 503 dapat menunjukkan bahwa fungsi Anda mengembalikan kesalahan eksekusi.
Untuk detail selengkapnya tentang cara mengidentifikasi dan mengatasi kesalahan Lambda @Edge, lihat. [Uji dan debug fungsi Lambda @Edge](lambda-edge-testing-debugging.md)
Untuk informasi selengkapnya tentang CloudFront fungsi pengujian, lihat[Fungsi uji](test-function.md).
## Batas Lambda @Edge terlampaui
Jika Anda menggunakan Lambda @Edge, kode status HTTP 503 dapat menunjukkan bahwa Lambda mengembalikan kesalahan. Kesalahan tersebut dapat disebabkan oleh salah satu hal berikut:
+ Jumlah eksekusi fungsi melebihi salah satu kuota yang ditetapkan Lambda untuk membatasi eksekusi dalam (eksekusi bersamaan atau frekuensi Wilayah AWS pemanggilan).
+ Fungsi melampaui kuota waktu habis fungsi Lambda.
Untuk informasi selengkapnya tentang kuota Lambda @Edge, lihat. [Kuotas di Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge) Untuk detail selengkapnya tentang cara mengidentifikasi dan mengatasi kesalahan Lambda @Edge, lihat. [Uji dan debug fungsi Lambda @Edge](lambda-edge-testing-debugging.md) *Anda juga dapat melihat [kuota layanan Lambda di Panduan Pengembang](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html).AWS Lambda *
# Kode status HTTP 504 (Gateway Timeout)
Kode status HTTP 504 (batas waktu gateway) menunjukkan bahwa ketika CloudFront meneruskan permintaan ke asal (karena objek yang diminta tidak berada di cache tepi), salah satu hal berikut terjadi:
+ Asal mengembalikan kode status HTTP 504 ke CloudFront.
+ Asal tidak menanggapi sebelum permintaan kedaluwarsa.
CloudFront akan mengembalikan kode status HTTP 504 jika lalu lintas diblokir ke asal oleh firewall atau grup keamanan, atau jika asal tidak dapat diakses di internet. Periksa masalah tersebut terlebih dahulu. Kemudian, jika akses bukan masalahnya, jelajahi penundaan aplikasi dan batas waktu server untuk membantu Anda mengidentifikasi dan memperbaiki masalah.
**Topics**
+ [Konfigurasikan firewall di server asal Anda untuk memungkinkan CloudFront lalu lintas](#http-504-gateway-timeout-configure-firewall)
+ [Konfigurasikan grup keamanan di server asal Anda untuk mengizinkan CloudFront lalu lintas](#http-504-gateway-timeout-configure-security-groups)
+ [Jadikan server asal kustom Anda dapat diakses di internet](#http-504-gateway-timeout-make-origin-accessible)
+ [Temukan dan perbaiki tanggapan yang tertunda dari aplikasi di server asal Anda](#http-504-gateway-timeout-slow-application)
## Konfigurasikan firewall di server asal Anda untuk memungkinkan CloudFront lalu lintas
Jika firewall di server asal Anda memblokir CloudFront lalu lintas, CloudFront mengembalikan kode status HTTP 504, jadi sebaiknya pastikan itu bukan masalahnya sebelum memeriksa masalah lain.
Metode yang Anda gunakan untuk menentukan apakah masalah dengan firewall Anda bergantung pada sistem yang digunakan server asal Anda:
+ Jika Anda menggunakan IPTable firewall di server Linux, Anda dapat mencari alat dan informasi untuk membantu Anda bekerja dengannya IPTables.
+ Jika Anda menggunakan Windows Firewall di server Windows, lihat [Menambahkan atau Mengedit Aturan Firewall](https://technet.microsoft.com/en-us/library/cc753558(v=ws.11).aspx) di dokumentasi Microsoft.
Saat Anda mengevaluasi konfigurasi firewall di server asal Anda, cari firewall atau aturan keamanan apa pun yang memblokir lalu lintas dari lokasi CloudFront tepi, berdasarkan rentang alamat IP yang dipublikasikan. Untuk informasi selengkapnya, lihat [Lokasi dan rentang alamat IP server CloudFront edge](LocationsOfEdgeServers.md).
Jika rentang alamat CloudFront IP diizinkan untuk terhubung ke server asal Anda, pastikan untuk memperbarui aturan keamanan server Anda untuk memasukkan perubahan. Anda dapat berlangganan topik Amazon SNS dan menerima pemberitahuan saat file rentang alamat IP diperbarui. Setelah menerima notifikasi, Anda dapat menggunakan kode untuk mengambil file, menguraikannya, dan melakukan penyesuaian terhadap lingkungan lokal Anda. Untuk informasi selengkapnya, lihat [Berlangganan Perubahan Alamat IP AWS Publik melalui Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/) di Blog AWS Berita.
## Konfigurasikan grup keamanan di server asal Anda untuk mengizinkan CloudFront lalu lintas
Jika asal Anda menggunakan Elastic Load Balancing, tinjau [grup keamanan ELB](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html) dan pastikan grup keamanan mengizinkan lalu lintas masuk. CloudFront
Anda juga dapat menggunakan AWS Lambda untuk secara otomatis memperbarui grup keamanan Anda untuk memungkinkan lalu lintas masuk dari CloudFront.
## Jadikan server asal kustom Anda dapat diakses di internet
Jika tidak CloudFront dapat mengakses server asal kustom Anda karena tidak tersedia untuk umum di internet, CloudFront mengembalikan kesalahan HTTP 504.
CloudFront lokasi tepi terhubung ke server asal melalui internet. Jika asal kustom Anda ada di jaringan pribadi, tidak CloudFront dapat mencapainya. Karena itu, Anda tidak dapat menggunakan server pribadi, termasuk [Classic Load Balancer internal](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html), sebagai server asal. CloudFront
Untuk memeriksa bahwa lalu lintas internet dapat terhubung ke server asal Anda, jalankan perintah berikut (di mana *OriginDomainName* adalah nama domain untuk server Anda):
Untuk lalu lintas HTTPS:
+ nc -zv *OriginDomainName* 443
+ telnet *OriginDomainName* 443
Untuk lalu lintas HTTP:
+ nc -zv *OriginDomainName* 80
+ telnet *OriginDomainName* 80
## Temukan dan perbaiki tanggapan yang tertunda dari aplikasi di server asal Anda
Waktu habis server sering kali merupakan hasil dari aplikasi yang memerlukan waktu sangat lama untuk merespons, atau nilai habis waktu yang diatur terlalu rendah.
Perbaikan cepat untuk membantu menghindari kesalahan HTTP 504 adalah dengan hanya mengatur CloudFront nilai waktu habis untuk distribusi Anda. Namun, kami menyarankan Anda untuk terlebih dahulu memastikan bahwa Anda mengatasi masalah performa dan latensi dengan aplikasi dan server asal. Kemudian Anda dapat menetapkan nilai batas waktu yang wajar yang membantu mencegah kesalahan HTTP 504 dan memberikan respons yang baik kepada pengguna.
Berikut ikhtisar langkah-langkah yang dapat Anda ambil untuk menemukan masalah kinerja dan memperbaikinya:
1. Ukur latensi (responsifitas) beban tinggi dan tipikal dari aplikasi web Anda.
1. Tambahkan sumber daya tambahan, seperti CPU atau memori, jika diperlukan. Mengambil langkah lain untuk mengatasi masalah, seperti mengatur kueri basis data untuk mengakomodasi skenario muatan tinggi.
1. Jika perlu, sesuaikan nilai batas waktu untuk CloudFront distribusi Anda.
Berikut ini adalah rincian tentang setiap langkah.
### Ukur latensi biasa dan beban tinggi
Untuk menentukan apakah satu atau lebih server aplikasi web backend mengalami latensi tinggi, jalankan perintah curl Linux berikut di setiap server:
```
curl -w "DNS Lookup Time: %{time_namelookup} \nConnect time: %{time_connect} \nTLS Setup: %{time_appconnect} \nRedirect Time: %{time_redirect} \nTime to first byte: %{time_starttransfer} \nTotal time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject
```
**catatan**
Jika Anda menjalankan Windows di server, Anda dapat mencari dan mengunduh curl bagi Windows untuk menjalankan perintah yang serupa.
Saat Anda mengukur dan mengevaluasi latensi aplikasi yang berjalan di server Anda, ingatlah hal berikut:
+ Nilai latensi relatif terhadap setiap aplikasi. Namun, waktu untuk byte pertama dalam milidetik daripada detik atau lebih, masuk akal.
+ Jika Anda mengukur latensi aplikasi di bawah beban normal dan tidak masalah, ketahuilah bahwa pemirsa mungkin masih mengalami batas waktu di bawah beban tinggi. Jika permintaannya tinggi, server dapat memiliki respons tertunda atau tidak merespons sama sekali. Untuk membantu mencegah masalah latensi beban tinggi, periksa sumber daya server Anda seperti CPU, memori, dan pembacaan dan penulisan disk untuk memastikan bahwa server Anda memiliki kapasitas untuk menskalakan beban tinggi.
Anda dapat menjalankan perintah Linux berikut untuk memeriksa memori yang digunakan oleh proses Apache:
`watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"`
+ Pemanfaatan CPU yang tinggi di server dapat secara signifikan mengurangi kinerja aplikasi. Jika Anda menggunakan instans Amazon EC2 untuk server backend Anda, tinjau CloudWatch metrik server untuk memeriksa penggunaan CPU. Untuk informasi selengkapnya, lihat [Panduan CloudWatch Pengguna Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html). Atau jika Anda menggunakan server Anda sendiri, lihat dokumentasi bantuan server untuk petunjuk tentang cara memeriksa pemanfaatan CPU.
+ Periksa masalah potensial lainnya di bawah beban tinggi, seperti kueri basis data yang berjalan lambat ketika ada volume permintaan yang tinggi.
### Tambahkan sumber daya, dan atur server dan basis data
Setelah Anda mengevaluasi responsivitas aplikasi dan server Anda, pastikan Anda memiliki sumber daya yang memadai untuk situasi lalu lintas dan beban tinggi yang biasa terjadi:
+ Jika Anda memiliki server Anda sendiri, pastikan server memiliki CPU, memori, dan ruang disk yang cukup untuk menangani permintaan penampil, berdasarkan evaluasi Anda.
+ Jika Anda menggunakan instans Amazon EC2 sebagai server backend Anda, pastikan bahwa jenis instance memiliki sumber daya yang sesuai untuk memenuhi permintaan masuk. Untuk informasi lebih lanjut, lihat [Tipe instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html) di *Panduan Pengguna Amazon EC2*.
Selain itu, pertimbangkan langkah-langkah penyetelan berikut untuk membantu menghindari timeout:
+ Jika nilai Time to First Byte yang dikembalikan oleh perintah curl tampaknya tinggi, ambil langkah untuk meningkatkan kinerja aplikasi Anda. Meningkatkan responsivitas aplikasi secara bergantian akan membantu mengurangi kesalahan waktu habis.
+ Tune kueri basis data untuk memastikan bahwa mereka dapat menangani volume permintaan yang tinggi tanpa kinerja yang lambat.
+ Persiapkan [ tetap-sif (tetap)](https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01) di server backend Anda. Opsi ini membantu menghindari keterlambatan yang terjadi ketika koneksi harus dibangun kembali untuk permintaan berikutnya atau pengguna.
+ **Jika Anda menggunakan Elastic Load Balancing sebagai asal Anda**, berikut ini adalah kemungkinan penyebab kesalahan 504:
+ Penyeimbang beban gagal membuat koneksi ke target sebelum batas waktu koneksi berakhir (10 detik).
+ Penyeimbang beban membuat koneksi ke target tetapi target tidak merespons sebelum periode batas waktu idle berlalu.
+ Daftar kontrol akses jaringan (ACL) untuk subnet tidak mengizinkan lalu lintas dari target ke node penyeimbang beban pada port sementara (1024-65535).
+ Target mengembalikan header konten-panjang yang lebih besar dari isi entitas. Waktu penyeimbang beban habis menunggu byte yang hilang.
+ Targetnya adalah fungsi Lambda dan Lambda tidak merespons sebelum batas waktu koneksi berakhir.
Untuk informasi selengkapnya tentang mengurangi latensi, lihat [Bagaimana cara mengatasi masalah latensi tinggi pada ELB Classic Load Balancer saya?](https://repost.aws/knowledge-center/elb-latency-troubleshooting)
+ **Jika Anda menggunakan MediaTailor sebagai asal Anda**, berikut ini adalah kemungkinan penyebab kesalahan 504:
+ Jika kerabat URLs salah penanganan, MediaTailor dapat menerima cacat URLs dari para pemain.
+ Jika MediaPackage asal manifes untuk MediaTailor, MediaPackage 404 kesalahan manifes dapat MediaTailor menyebabkan mengembalikan kesalahan 504.
+ Permintaan ke server MediaTailor asal membutuhkan waktu lebih dari 2 detik untuk diselesaikan.
+ **Jika Anda menggunakan Amazon API Gateway sebagai asal Anda**, berikut ini adalah kemungkinan penyebab kesalahan 504:
+ Permintaan integrasi membutuhkan waktu lebih lama daripada parameter batas waktu integrasi maksimum API Gateway REST API Anda. Untuk informasi selengkapnya, [lihat Bagaimana cara memecahkan masalah error batas waktu API HTTP 504 dengan API Gateway](https://repost.aws/knowledge-center/api-gateway-504-errors)?
### Jika diperlukan, sesuaikan nilai CloudFront batas waktu
Jika Anda telah mengevaluasi dan menangani performa aplikasi lambat, kapasitas server asal, dan masalah lain, tetapi penampil masih mengalami kesalahan HTTP 504, maka Anda harus mempertimbangkan mengubah waktu yang ditentukan dalam distribusi Anda untuk timeout respons asal. Untuk informasi selengkapnya, lihat [Batas waktu respons](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).