HTTP504 kode status (Gateway Timeout) - Amazon CloudFront

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

HTTP504 kode status (Gateway Timeout)

Kode status HTTP 504 (batas waktu gateway) menunjukkan bahwa ketika CloudFront meneruskan permintaan ke asal (karena objek yang diminta tidak ada di cache tepi), salah satu hal berikut terjadi:

  • Asal mengembalikan kode status HTTP 504 ke CloudFront.

  • Asal tidak merespons 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.

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 ada baiknya untuk memastikan 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 dengannyaIPTables.

  • Jika Anda menggunakan Windows Firewall di server Windows, lihat Menambahkan atau Mengedit Aturan Firewall 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.

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 SNS topik Amazon 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 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 ELB keamanan 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, 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 HTTPS lalu lintas:

  • nc -zv OriginDomainName 443

  • telnet OriginDomainName 443

Untuk HTTP lalu lintas:

  • 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 menetapkan nilai CloudFront batas waktu yang lebih tinggi 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.

  2. 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.

  3. 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 sepertiCPU, 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"

  • CPUPemanfaatan yang tinggi pada server dapat secara signifikan mengurangi kinerja aplikasi. Jika Anda menggunakan EC2 instans Amazon untuk server backend Anda, tinjau CloudWatch metrik server untuk memeriksa pemanfaatannya. CPU Untuk informasi selengkapnya, lihat Panduan CloudWatch Pengguna Amazon. Atau jika Anda menggunakan server Anda sendiri, lihat dokumentasi bantuan server untuk petunjuk tentang cara memeriksa CPU pemanfaatan.

  • 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 sendiri, pastikan server memiliki cukupCPU, memori, dan ruang disk untuk menangani permintaan penampil, berdasarkan evaluasi Anda.

  • Jika Anda menggunakan EC2 instans Amazon sebagai server backend, pastikan jenis instans memiliki sumber daya yang sesuai untuk memenuhi permintaan yang masuk. Untuk informasi selengkapnya, lihat Jenis instans di Panduan EC2 Pengguna Amazon.

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) 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. Load balancer menghabiskan waktu 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 Classic Load ELB Balancer saya?

  • 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:

Jika diperlukan, sesuaikan nilai CloudFront batas waktu

Jika Anda telah mengevaluasi dan mengatasi kinerja aplikasi yang lambat, kapasitas server asal, dan masalah lainnya, tetapi pemirsa masih mengalami HTTP 504 kesalahan, maka Anda harus mempertimbangkan untuk mengubah waktu yang ditentukan dalam distribusi Anda untuk batas waktu respons asal. Untuk informasi selengkapnya, lihat Batas waktu respons (hanya asal khusus).