Server

500 Internal Server Error — Penyebab dan Cara Mengatasinya

Diperbarui 2026-08-29Baca ~9 menit

500 Internal Server Error adalah pesan serba guna. Server menjalankan aplikasi Anda, aplikasi itu gagal, dan alih-alih membocorkan detail kepada orang asing, server menampilkan halaman umum. Itu memang disengaja — pesan error adalah risiko keamanan — tetapi konsekuensinya halaman yang Anda lihat sama sekali tidak berisi informasi berguna.

Informasinya tetap ada. Hampir setiap 500 menuliskan alasan spesifik ke sebuah error log, biasanya lengkap dengan nama file dan nomor barisnya. Panduan ini membahas penyebab umum diurutkan dari yang paling sering, menunjukkan letak log itu pada tiap jenis hosting, dan memberi urutan pemeriksaan yang menghindari jebakan klasik yaitu mengubah lima hal sekaligus.

Apa Arti 500 Sebenarnya

Keluarga 5xx berarti kesalahan ada di sisi server, bukan pada permintaan Anda. Di dalam keluarga itu, 500 secara khusus berarti aplikasi berhasil dijangkau dan dijalankan, lalu ada yang salah di dalamnya — exception yang tidak tertangani, fatal error, kesalahan sintaks, atau batas resource yang tercapai di tengah eksekusi.

Ini benar-benar berbeda dari tetangganya. 502 berarti aplikasi tidak pernah memberi jawaban yang bisa dipakai. 503 berarti server memilih tidak melayani. 504 berarti jawabannya terlalu lambat. 500 berarti kodenya berjalan lalu rusak.

💡 Konsekuensi paling bermanfaat: karena aplikasi benar-benar berjalan, hampir pasti ia mencatat sesuatu. Menemukan catatan itu mengubah 500 yang samar menjadi bug spesifik yang bisa diperbaiki.

Error yang Sama dengan Banyak Nama

Sebuah 500 muncul dengan kalimat berbeda tergantung software yang terlibat, sehingga orang mengira masalahnya berbeda-beda. Padahal sama.

  • "500 Internal Server Error" — teks status HTTP yang standar
  • "HTTP Error 500" — biasa ditampilkan IIS dan sebagian browser
  • "Internal Server Error" — halaman bawaan Apache
  • "The server encountered an internal error or misconfiguration" — versi panjang dari Apache
  • "Terjadi kesalahan kritis pada situs ini" — yang ditampilkan WordPress setelah penangan error-nya sendiri menangkap kegagalan
  • "Error 500" dalam respons API — hal yang sama, hanya dikembalikan sebagai JSON alih-alih HTML

Penyebab Umum, dari yang Paling Sering

Urutan di sini penting. Menelusuri daftar ini secara berurutan akan menemukan penyebabnya lebih cepat daripada memilih yang kedengarannya paling menarik.

PenyebabSeberapa seringTanda yang bisa diamati
Fatal error PHP di kode, plugin atau temaSangat seringMuncul persis setelah update atau perubahan kode
Aturan .htaccess yang rusakSangat seringSemua URL rusak sekaligus, termasuk file statis
Batas memori PHP habisSeringHanya halaman berat yang rusak; log menyebut "Allowed memory size exhausted"
Permission file salahSeringMuncul setelah migrasi, restore, atau upload sebagai root
Versi PHP rusak atau tidak kompatibelKadangMenyusul pergantian versi PHP di hosting
Database tidak terjangkau atau batas koneksi penuhKadangMuncul hilang, memburuk saat trafik puncak
Disk penuhKadangSemuanya rusak sekaligus, termasuk proses tulis dan pencatatan log

Urutan Pemeriksaan Tercepat

  • Baca error log lebih dulu. Semua langkah di bawah hanyalah tebakan sampai Anda melakukan ini, dan log biasanya menyebutkan file serta barisnya secara langsung.
  • Tanyakan apa yang berubah. 500 yang muncul persis setelah update plugin, deployment atau pergantian versi PHP sudah memberi tahu Anda tempat mencarinya.
  • Ganti nama .htaccess menjadi .htaccess.bak lalu muat ulang. Kalau situs kembali normal, ada aturan di file itu penyebabnya. Pada WordPress Anda bisa membuat ulang file bersih dengan menyimpan ulang pengaturan permalink.
  • Naikkan batas memori PHP sementara — ke 256M — lalu lihat apakah error hilang. Kalau hilang, perbaikan sebenarnya biasanya ada pada kode yang memakan memori sebanyak itu, bukan pada batas yang dinaikkan permanen.
  • Pada WordPress, aktifkan WP_DEBUG dan WP_DEBUG_LOG di wp-config.php. Layar putih berubah menjadi pesan yang menyebutkan nama plugin.
  • Nonaktifkan semua plugin, pastikan situs kembali normal, lalu aktifkan satu per satu. Melelahkan, tetapi hasilnya pasti dan tetap lebih cepat daripada menebak.
  • Periksa permission: 644 untuk file, 755 untuk direktori. Jangan pernah 777.
  • Periksa sisa ruang disk. Disk penuh menghasilkan kegagalan yang mirip semua penyebab lain dan membuang berjam-jam karena tidak ada yang terpikir memeriksanya.
💡 Ubah satu hal saja lalu muat ulang setiap kali. Kalau Anda mengubah beberapa sekaligus lalu situs normal, Anda tidak akan pernah tahu mana yang berpengaruh — dan salah satu perubahan lain mungkin menciptakan lubang keamanan.

Di Mana Letak Error Log

Inilah langkah yang sering dilewati, dan justru inilah yang benar-benar menyelesaikan masalah. Lokasinya tergantung hosting Anda.

LingkunganLokasi log
DirectAdminFile Manager, lalu folder logs milik domain, atau menu "Site Errors"
cPanelMetrics, lalu Errors — atau public_html/error_log
Nginx di VPS/var/log/nginx/error.log
Apache di VPS/var/log/apache2/error.log atau /var/log/httpd/error_log
PHP-FPM/var/log/php-fpm/www-error.log, atau path yang diatur di konfigurasi pool
WordPress dengan debug log aktifwp-content/debug.log
💡 Baca log dari bawah, bukan dari atas. Catatan terbaru ada di akhir, dan baris yang Anda cari adalah yang bertanda waktu ketika error itu Anda picu.

Shared Hosting vs VPS

500 yang sama menjadi pekerjaan yang berbeda tergantung di mana situs itu berada, dan ada baiknya bersikap realistis soal ini.

Di shared hosting Anda bisa membuka error log lewat control panel, mengubah permission file, menyunting .htaccess dan menyesuaikan sebagian setting PHP. Yang tidak bisa Anda lakukan adalah me-restart PHP-FPM, membaca log sistem, memasang extension, atau mengubah batas tingkat server. Kalau penyebabnya ternyata salah satu dari itu, satu-satunya pilihan adalah membuka tiket support.

Di VPS Anda punya semuanya: log lengkap, kendali service, konfigurasi, dan kemampuan mereproduksi kegagalan di bawah beban. Imbalannya, Anda juga bertanggung jawab menjaganya tetap ter-patch dan terkonfigurasi baik. Untuk situs yang menghasilkan uang dan tidak sanggup menganggur menunggu antrean tiket, pertukaran itu biasanya sepadan — selisih antara mendiagnosis 500 dalam sepuluh menit dan menunggu semalaman.

Ingin membaca log sendiri alih-alih menunggu tiket support?

Cloud VPS dengan akses root penuh, error log lengkap dan tanpa batasan shared hosting — mulai ฿150/bulan.

Pertanyaan yang Sering Diajukan

Kenapa halaman kosong sama sekali, bukan menampilkan pesan error?

Karena display_errors dimatikan, dan itu memang pengaturan yang benar untuk situs live — detail error bisa membocorkan path file dan kredensial. Pesannya tetap ada di error log. Aktifkan WP_DEBUG_LOG, atau baca error log server langsung, detailnya ada di sana.

Rusak persis setelah saya update plugin. Sekarang bagaimana?

Kembalikan plugin itu. Kalau area admin ikut rusak, ganti nama folder plugin tersebut di wp-content/plugins lewat FTP atau File Manager — WordPress menonaktifkan apa pun yang tidak ditemukannya dan situs akan kembali. Setelah itu coba update lagi di salinan staging untuk melihat apa yang sebenarnya rusak.

Apakah 500 buruk untuk SEO?

Sebentar, tidak — Google mencoba lagi. Berhari-hari, ya: laju crawl melambat dan halaman bisa keluar dari indeks. Google awalnya memperlakukan 500 sebagai sementara, jadi risikonya sebanding dengan lamanya, bukan dengan kejadiannya.

Apakah menaikkan batas memori PHP bisa jadi solusi permanen?

Bisa, kalau situs memang membutuhkan memori lebih besar daripada yang tersedia. Lebih sering hal itu hanya memindahkan plafon sementara masalah aslinya — query tidak efisien, plugin yang memuat semuanya ke memori — terus membesar. Naikkan untuk memulihkan situs, lalu cari tahu apa yang menghabiskannya.

Bagaimana membedakan 500 dan 502 kalau keduanya menampilkan halaman error kosong?

Periksa kode statusnya, bukan kalimatnya, lewat tab Network di browser atau dengan menjalankan "curl -I" ke URL tersebut. Sepuluh detik itu sepadan: 500 mengarahkan Anda ke kode aplikasi, 502 mengarahkan ke proses backend. Dua penyelidikan yang berbeda.