Cara Mengatasi WordPress 500 Internal Server Error di VPS Nginx

The Last Digital
Update: ... minutes read

Anda membuka situs WordPress dan yang muncul hanyalah tulisan 500 Internal Server Error — atau, dalam beberapa konfigurasi, halaman putih kosong tanpa penjelasan. Tidak ada keterangan plugin mana yang rusak, tidak ada petunjuk file mana yang bermasalah. Wajar bila rasanya seperti menebak dalam gelap.

Itulah sifat error 500: ia adalah gejala, bukan diagnosis. Angka 500 hanya berarti "terjadi kegagalan di sisi server saat memproses permintaan", tanpa merinci apa yang gagal. Penyebabnya bisa bermacam-macam: fatal error PHP di plugin atau tema, memori PHP habis, PHP-FPM bermasalah, permission file yang salah, versi PHP yang tidak cocok, atau file inti WordPress yang rusak. Semua penyebab itu menampilkan angka yang sama di browser.

Kabar baiknya, penyebab yang sebenarnya hampir selalu tertulis di suatu tempat: log server. Artikel ini mengajari Anda membaca log itu dulu, baru bertindak — supaya Anda memperbaiki penyebab yang benar, bukan mengulang tebakan yang sudah dicoba banyak orang.

Jawaban Singkat: Baca Log Dulu, Baru Bertindak

Urutan yang benar untuk WordPress 500 di VPS Nginx adalah:

  1. Aktifkan WP_DEBUG_LOG di wp-config.php agar WordPress menulis error ke wp-content/debug.log tanpa menampilkannya ke pengunjung.
  2. Baca tiga log: wp-content/debug.log (error WordPress/PHP), /var/log/nginx/error.log (error Nginx), dan log PHP-FPM (error proses PHP).
  3. Ikuti cabang penyebabnya: baris "Fatal error" yang menyebut nama plugin/tema berarti plugin/tema itu; "Allowed memory size exhausted" berarti memori habis; "connect() to unix socket failed" berarti PHP-FPM bermasalah; "Permission denied" berarti permission/ownership salah.
  4. Perbaiki satu hal dalam satu waktu, uji lagi, dan catat apa yang berubah — supaya Anda tahu persis perbaikan mana yang berhasil.
  5. Matikan debug mode setelah masalah selesai, karena membiarkannya aktif di situs live berisiko membocorkan informasi teknis ke pengunjung.

Bila Anda hanya punya waktu untuk satu kalimat dari artikel ini, inilah kalimatnya: jangan menebak penyebab 500 — bacalah lognya.

Bedakan 500 dari 502, 503, 504, dan Error Cloudflare

Angka-angka ini sering tertukar, padahal masing-masing menunjuk lapisan yang berbeda:

KodeArti singkatDi mana masalahnyaApakah panduan ini berlaku?
500Kegagalan umum di server saat memproses permintaanPHP/WordPress di server AndaYa — ini topik artikel ini
502 Bad GatewayNginx tidak mendapat respons valid dari PHP-FPMJalur Nginx→PHP-FPMSebagian — periksa PHP-FPM, tetapi fokusnya berbeda
503 Service UnavailableLayanan sementara tidak tersedia / overloadKapasitas atau mode perawatanTidak langsung — periksa beban dan perawatan
504 Gateway TimeoutUpstream terlalu lama meresponsProses PHP/MySQL yang lambatTidak langsung — ini masalah timeout, bukan fatal error
521/522/524/526 (Cloudflare)Error dari Cloudflare tentang jalur ke originAntara Cloudflare dan originTidak — itu panduan error Cloudflare tersendiri

Petunjuk praktis: bila halaman error menampilkan logo atau Ray ID Cloudflare, masalahnya ada di jalur Cloudflare→origin. Bila halaman error tampil polos dari Nginx atau WordPress Anda sendiri, masalahnya ada di server Anda — dan artikel inilah yang berlaku.

Perbedaan Penting: Nginx Tidak Memakai .htaccess

Ini adalah jebakan paling umum bagi pemilik WordPress yang pindah dari shared hosting Apache ke VPS Nginx. Di Apache, file .htaccess memang berperan dalam routing dan bisa rusak sehingga menyebabkan 500. Di Nginx, file .htaccess tidak dibaca sama sekali — Nginx hanya memakai konfigurasi di /etc/nginx/ dan file situs Anda.

Akibatnya, saran "reset .htaccess" yang banyak beredar untuk Apache tidak berlaku di VPS Nginx. Menghapus atau mengutak-atik .htaccess di server Nginx tidak akan memperbaiki 500, dan hanya membuang waktu diagnosis Anda. Bila Anda menemukan panduan yang menyuruh mereset .htaccess untuk Nginx, abaikan saran itu dan kembali ke log — penyebab 500 di Nginx ada di PHP, konfigurasi Nginx, permission, atau resource, bukan di .htaccess.

Untuk permalink WordPress di Nginx, aturan rewrite yang benar ditulis di blok location / pada konfigurasi situs Nginx, misalnya try_files $uri $uri/ /index.php?$args;. Bila permalink bermasalah setelah migrasi ke Nginx, periksa blok itu — bukan .htaccess.

Tabel Diagnosis: Gejala, Log yang Dibaca, dan Solusi

Gejala / petunjuk di logKemungkinan penyebabLog yang dibacaSolusi yang sesuai
"Fatal error" menyebut file di wp-content/plugins/...Plugin bermasalahwp-content/debug.logNonaktifkan plugin itu (ganti nama foldernya lewat SSH)
"Fatal error" menyebut file di wp-content/themes/...Tema bermasalahwp-content/debug.logBeralih sementara ke tema bawaan WordPress
"Allowed memory size of ... exhausted"Memori PHP habisdebug.log / log PHP-FPMNaikkan memory limit secara bertahap; cari penyebab boros memori bila berulang
"connect() to unix:/run/php/...sock failed" atau "no live upstreams"PHP-FPM mati atau socket salah/var/log/nginx/error.logPeriksa status PHP-FPM dan kecocokan socket di konfigurasi Nginx
"Permission denied" atau "failed to open stream: Permission denied"Permission/ownership file salah/var/log/nginx/error.log, debug.logPerbaiki permission (umumnya 755 direktori, 644 file) dan ownership ke user web server
Fatal error tentang fungsi/deprecated setelah ganti versi PHPVersi PHP tidak cocok dengan plugin/temadebug.logSesuaikan versi PHP atau perbarui plugin/tema yang tidak kompatibel
500 di semua halaman, termasuk file PHP sederhanaKonfigurasi Nginx/PHP-FPM rusak/var/log/nginx/error.logUji konfigurasi dengan nginx -t, periksa blok PHP di konfigurasi situs
500 hanya di wp-admin atau hanya di halaman tertentuPlugin/tema spesifik atau proses berat di halaman itudebug.log pada jam kejadianNonaktifkan plugin terkait halaman itu; periksa proses berat (impor, query berat)

Persiapan dan Backup Sebelum Mengubah Apa Pun

  • Cadangkan situs dan database sebelum mengubah wp-config.php, menonaktifkan plugin, atau mengubah permission. Perubahan permission yang salah bisa membuat 500 semakin meluas.
  • Catat waktu munculnya 500 dan apa yang terakhir diubah — update plugin/tema, ganti versi PHP, migrasi server, atau perubahan konfigurasi Nginx. Perubahan terakhir itu hampir selalu menjadi petunjuk.
  • Pastikan Anda punya akses SSH atau file manager. Bila wp-admin tidak bisa dibuka, sebagian besar perbaikan 500 memang harus dilakukan lewat SSH/SFTP, bukan dari dashboard.

Perintah di bawah ini memakai contoh umum Ubuntu + Nginx + PHP-FPM. Sesuaikan versi PHP (misalnya php8.3-fpm atau php8.2-fpm), jalur log, dan user web server (www-data di Ubuntu/Debian) dengan VPS Anda.

Langkah 1: Aktifkan WP_DEBUG_LOG dengan Aman

Buka file wp-config.php di root WordPress Anda dan tambahkan baris berikut sebelum baris /* That's all, stop editing! Happy blogging. */, sesuai dokumentasi resmi WordPress:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Penjelasan tiap baris, menurut dokumentasi WordPress:

  • WP_DEBUG mengaktifkan mode debug WordPress.
  • WP_DEBUG_LOG menulis semua error, notice, dan warning ke file wp-content/debug.log. Perlu dicatat: konstanta ini tidak berfungsi bila WP_DEBUG tidak true.
  • WP_DEBUG_DISPLAY bernilai false berarti error tidak ditampilkan ke pengunjung — penting untuk situs live, agar detail teknis tidak bocor ke publik.

Dokumentasi WordPress juga menegaskan bahwa WP_DEBUG sebaiknya dipakai di lingkungan pengembangan atau staging, bukan di situs live secara permanen. Karena itu, anggap mode debug ini sebagai alat diagnosis sementara: aktifkan, baca lognya, perbaiki masalahnya, lalu matikan lagi (langkah 8).

Setelah menyimpan, muat ulang halaman yang menampilkan 500 satu kali — tujuannya agar error terbaru tercatat di log. Lalu baca lognya:

tail -n 100 /var/www/namadomainanda.com/wp-content/debug.log

Sesuaikan jalur dengan lokasi WordPress Anda. Baris-baris terbaru di akhir file adalah yang paling relevan.

Langkah 2: Baca Tiga Log dan Pilah Cabangnya

Selain debug.log, baca juga dua log server berikut:

sudo tail -n 100 /var/log/nginx/error.log
sudo systemctl status php8.3-fpm
sudo tail -n 100 /var/log/php8.3-fpm.log

Sesuaikan versi PHP dan jalur log PHP-FPM dengan server Anda — di beberapa instalasi, log PHP-FPM berada di /var/log/php-fpm/ atau di jalur per-pool. Yang penting bukan menghafal jalurnya, melainkan memahami pembagian tugasnya:

  • debug.log: memberi tahu Anda error PHP di level WordPress — nama file plugin/tema dan nomor barisnya.
  • Nginx error.log: memberi tahu Anda kegagalan di level web server — PHP-FPM tidak terjangkau, permission ditolak, atau konfigurasi bermasalah.
  • Log PHP-FPM: memberi tahu Anda kondisi proses PHP — worker habis, proses crash, atau pool gagal start.

Bila ketiga log itu kosong atau tidak menyebut error pada jam kejadian, kemungkinan besar errornya terjadi di tempat lain (misalnya log per situs Nginx yang terpisah) atau mode debug belum aktif dengan benar. Periksa kembali penempatan baris WP_DEBUG di wp-config.php — baris yang diletakkan setelah "That's all, stop editing!" tidak akan berpengaruh.

Langkah 3: Bila Penyebabnya Plugin atau Tema

Ini adalah cabang paling umum. Bila debug.log menunjukkan fatal error di dalam folder plugin atau tema tertentu, nonaktifkan komponen itu lewat SSH dengan mengganti nama foldernya — cara ini bekerja bahkan bila wp-admin tidak bisa dibuka:

mv /var/www/namadomainanda.com/wp-content/plugins/nama-plugin /var/www/namadomainanda.com/wp-content/plugins/nama-plugin.nonaktif

Ganti jalur dan nama plugin dengan yang tertera di log. Setelah itu, muat ulang situs. Bila 500 hilang, Anda sudah menemukan pelakunya. Langkah selanjutnya: periksa apakah ada update plugin yang memperbaiki masalah itu, atau hubungi pengembang plugin dengan menyertakan baris fatal error dari log — laporan yang menyertakan baris log jauh lebih cepat ditindaklanjuti daripada laporan "situs saya 500".

Bila log tidak menyebut plugin tertentu, tetapi 500 muncul tepat setelah update massal, nonaktifkan semua plugin sementara dengan mengganti nama folder plugins menjadi plugins.nonaktif, lalu aktifkan satu per satu dari wp-admin setelah situs kembali. Cara ini memang memakan waktu, tetapi jauh lebih akurat daripada menebak.

Untuk tema, caranya serupa: ganti nama folder tema aktif, dan WordPress akan beralih ke tema bawaan (misalnya Twenty Twenty-Four atau sejenisnya, bila tersedia). Bila situs kembali normal dengan tema bawaan, masalahnya ada di tema Anda — periksa update tema atau konflik dengan versi PHP saat ini.

Langkah 4: Bila Penyebabnya Memori PHP Habis

Pesan khasnya di log adalah Allowed memory size of ... bytes exhausted. Artinya, sebuah proses PHP meminta memori melebihi batas yang diizinkan. Solusi sementaranya adalah menaikkan batas memori WordPress di wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

Nilai 256M adalah contoh umum, bukan angka wajib — sesuaikan dengan kapasitas VPS dan kebutuhan situs Anda, dan naikkan secara bertahap, bukan langsung ke angka besar. Perlu dipahami: menaikkan memory limit menyembunyikan gejala bila penyebab sebenarnya adalah proses yang boros memori (misalnya plugin yang memuat seluruh database ke memori, atau impor yang terlalu besar). Bila 500 karena memori habis terus berulang setelah limit dinaikkan, cari proses penyebabnya di log dan atasi di sana — misalnya dengan menonaktifkan plugin yang boros, memecah impor besar menjadi batch kecil, atau mengoptimalkan query berat.

Perlu juga dicatat: batas di wp-config.php tidak bisa melampaui batas di level server (php.ini dan konfigurasi pool PHP-FPM). Bila menaikkan di wp-config.php tidak berpengaruh, periksa batas di php.ini dan konfigurasi pool PHP-FPM Anda, atau tanyakan ke penyedia hosting berapa batas yang berlaku di level server.

Langkah 5: Bila Penyebabnya PHP-FPM Bermasalah

Periksa dulu apakah PHP-FPM berjalan dan socket-nya cocok dengan konfigurasi Nginx:

sudo systemctl status php8.3-fpm
sudo ss -tlnp | grep php
ls -l /run/php/
grep -r "fastcgi_pass" /etc/nginx/sites-enabled/

Yang harus cocok adalah: alamat socket (atau port) yang tertulis di fastcgi_pass pada konfigurasi Nginx harus sama dengan socket yang didengarkan PHP-FPM. Ketidakcocokan ini sering terjadi setelah upgrade versi PHP — misalnya Nginx masih mengarah ke php8.2-fpm.sock padahal yang terinstal sekarang adalah php8.3-fpm. Perbaiki baris fastcgi_pass ke socket yang benar, uji konfigurasi, lalu reload:

sudo nginx -t && sudo systemctl reload nginx
sudo systemctl restart php8.3-fpm

Bila PHP-FPM sering mati atau kehabisan worker di jam sibuk, periksa konfigurasi pool-nya (biasanya di /etc/php/8.3/fpm/pool.d/www.conf, sesuaikan versinya) — terutama pm.max_children dan mode pm. Menaikkan jumlah worker tanpa menambah memori hanya memindahkan kemacetan: tiap worker mengonsumsi memori, sehingga terlalu banyak worker di VPS kecil justru memicu OOM (kehabisan memori) dan crash berulang. Sesuaikan dengan RAM VPS Anda.

Langkah 6: Bila Penyebabnya Permission atau Ownership Salah

Gejala khasnya di log adalah Permission denied. Penyebab umum: file dipindahkan dari server lain dengan ownership yang berbeda, atau permission diubah secara massal tanpa sengaja. Nilai umum yang dipakai WordPress adalah 755 untuk direktori dan 644 untuk file, dengan ownership milik user web server (di Ubuntu/Debian biasanya www-data).

Perintah perbaikannya, dijalankan dari dalam direktori situs Anda dan hanya untuk direktori situs itu — jangan menjalankannya di root sistem:

cd /var/www/namadomainanda.com
sudo chown -R www-data:www-data .
sudo find . -type d -exec chmod 755 {} \;
sudo find . -type f -exec chmod 644 {} \;

Perhatian: perintah chown -R dan chmod massal adalah perintah yang mengubah banyak file sekaligus. Pastikan Anda berada di direktori situs yang benar sebelum menjalankannya, dan pastikan Anda sudah mencadangkan situs. Ada pengecualian yang perlu diperhatikan: beberapa file (misalnya wp-config.php) kadang sengaja dibuat lebih ketat (misalnya 640 atau 600) demi keamanan — setelah perbaikan massal, periksa kembali file sensitif tersebut dan kembalikan ke permission yang lebih ketat bila sebelumnya memang demikian.

Langkah 7: Bila Penyebabnya Versi PHP atau File Inti Rusak

Versi PHP tidak cocok

Bila 500 muncul tepat setelah Anda mengganti versi PHP, kemungkinan ada plugin atau tema lama yang tidak kompatibel dengan versi baru (atau sebaliknya, plugin baru yang membutuhkan versi PHP lebih tinggi). Periksa versi PHP aktif (php -v) dan bandingkan dengan persyaratan plugin/tema yang disebut di log. Solusinya: perbarui plugin/tema ke versi yang mendukung PHP Anda, atau kembalikan versi PHP ke yang sebelumnya didukung — sambil merencanakan update plugin/tema tersebut, karena bertahan di PHP lama yang sudah tidak didukung keamanannya bukan solusi jangka panjang.

File inti WordPress rusak

Bila log menunjuk file inti WordPress (di luar wp-content) atau situs 500 bahkan untuk halaman yang tidak memakai plugin/tema kustom, file inti mungkin rusak akibat update yang gagal atau modifikasi yang tidak sengaja. Cara aman memperbaikinya adalah menginstal ulang file inti lewat WP-CLI tanpa menyentuh konten Anda:

wp core download --force --skip-content --path=/var/www/namadomainanda.com

Perintah ini mengganti file inti tetapi melewatkan direktori konten — tetap cadangkan dulu sebelum menjalankannya. Bila WP-CLI tidak tersedia, unduh paket WordPress resmi dan ganti file inti secara manual, dengan menjaga wp-content dan wp-config.php Anda tetap utuh.

Uji konfigurasi Nginx

Terakhir, bila semua cabang di atas sudah diperiksa, uji konfigurasi Nginx secara keseluruhan:

sudo nginx -t

Hasil yang diharapkan adalah syntax is ok dan test is successful. Bila ada kesalahan sintaks atau referensi file yang tidak ada (misalnya sertifikat SSL yang sudah dipindah), perbaiki baris yang disebut pesan error itu, lalu reload Nginx.

Langkah 8: Verifikasi Hasil dan Matikan Debug Mode

  1. Buka beranda, satu artikel, dan wp-admin — ketiganya harus terbuka tanpa 500.
  2. Ulangi halaman yang sebelumnya 500 (misalnya halaman impor atau editor tertentu), karena 500 yang hanya terjadi di halaman tertentu tidak terdeteksi dari beranda saja.
  3. Periksa debug.log sekali lagi dan pastikan tidak ada lagi fatal error baru pada jam setelah perbaikan.
  4. Matikan debug mode dengan mengembalikan wp-config.php ke:
define( 'WP_DEBUG', false );

Hapus juga baris WP_DEBUG_LOG dan WP_DEBUG_DISPLAY yang Anda tambahkan, atau setidaknya pastikan WP_DEBUG kembali false. Membiarkan debug aktif di situs live berisiko menampilkan detail teknis — termasuk jalur file server Anda — kepada siapa pun yang memicu error.

Terakhir, hapus atau arsipkan debug.log lama yang berisi detail teknis, dan pertimbangkan untuk membatasi akses ke file itu bila Anda menyimpannya untuk arsip.

Troubleshooting Lanjutan

500 hanya di wp-admin, tetapi beranda normal

Curigai plugin yang hanya berjalan di dashboard (misalnya plugin statistik, keamanan, atau page builder yang memuat skrip berat di admin). Nonaktifkan plugin-plugin admin itu satu per satu lewat SSH dan uji wp-admin setiap kali.

500 hanya saat mengimpor atau mengunggah file besar

Kemungkinan besar ini masalah batas, bukan fatal error plugin: memory limit, waktu eksekusi maksimum, atau ukuran upload. Periksa pesan persisnya di log — bila menyebut memori atau timeout, sesuaikan batasnya secara bertahap dan pecah impor besar menjadi bagian-bagian kecil.

500 muncul berulang setelah beberapa jam normal

Pola berulang mengarah ke resource yang habis secara bertahap: memori yang bocor (memory leak) di plugin, worker PHP-FPM yang habis di jam sibuk, atau disk yang penuh oleh log. Periksa free -h, df -h, dan pertumbuhan debug.log serta log Nginx dari waktu ke waktu, bukan hanya sesaat setelah perbaikan.

500 setelah migrasi ke VPS baru

Periksa tiga hal dalam urutan ini: ownership file (apakah masih milik user lama?), versi PHP (apakah sama dengan server lama?), dan konfigurasi Nginx (apakah blok PHP dan fastcgi_pass sudah mengarah ke socket PHP-FPM yang benar?). Migrasi yang hanya menyalin file tanpa menyesuaikan ketiga hal ini adalah penyebab 500 yang sangat umum.

Alternatif Bila Anda Tidak Punya Akses SSH

  • Gunakan file manager di panel hosting untuk mengedit wp-config.php (aktifkan WP_DEBUG_LOG) dan membaca wp-content/debug.log — sebagian besar diagnosis 500 bisa dilakukan dari file manager saja.
  • Nonaktifkan plugin dengan mengganti nama foldernya lewat file manager, sama seperti lewat SSH.
  • Bila panel hosting Anda menyediakan tampilan log server, periksa log Nginx/PHP dari sana dan kirimkan baris error yang relevan ke dukungan hosting — laporan dengan baris log selalu lebih cepat ditindaklanjuti.
  • Jangan mengubah permission secara massal dari panel tanpa cadangan, karena kesalahan di sana sama berbahayanya dengan kesalahan di terminal.

FAQ Seputar WordPress 500 Internal Server Error

Apakah error 500 berarti database saya rusak?

Belum tentu. Error database biasanya menampilkan pesan "Error establishing a database connection", bukan 500 generik. Error 500 lebih sering berasal dari PHP — plugin, tema, memori, atau PHP-FPM. Bila log tidak menyebut database sama sekali, jangan memulai perbaikan dari database.

Kenapa saya harus membaca log, bukan langsung menonaktifkan semua plugin?

Karena menonaktifkan semua plugin tanpa membaca log adalah tebakan — dan tebakan itu bisa benar, tetapi Anda tidak tahu mengapa, sehingga masalah yang sama bisa terulang saat plugin itu diaktifkan lagi. Log memberi tahu Anda plugin mana, baris mana, dan jenis error apa — informasi yang Anda butuhkan untuk perbaikan permanen dan laporan bug yang berguna.

Apakah aman membiarkan WP_DEBUG aktif?

Tidak untuk jangka panjang di situs live. Dokumentasi WordPress sendiri menyarankan WP_DEBUG untuk pengembangan/staging, dan WP_DEBUG_DISPLAY yang true akan menampilkan detail error ke pengunjung. Pakai mode debug sebagai alat diagnosis sementara, lalu matikan setelah selesai.

Apakah menghapus .htaccess akan memperbaiki 500 di Nginx?

Tidak. Nginx tidak membaca .htaccess, sehingga file itu tidak berpengaruh apa pun terhadap error di server Nginx. Bila panduan yang Anda baca menyuruh mereset .htaccess untuk Nginx, panduan itu ditulis untuk Apache dan tidak berlaku di sini.

Apakah menaikkan memory limit selalu memperbaiki 500?

Tidak. Menaikkan limit hanya membantu bila penyebabnya memang memori habis untuk proses yang wajar. Bila penyebabnya plugin yang boros memori atau query yang tidak efisien, menaikkan limit hanya menunda 500 berikutnya. Perbaiki penyebab borosnya, bukan hanya batasnya.

Setelah 500 hilang, apa yang harus saya lakukan agar tidak terulang?

Tiga kebiasaan: uji update plugin/tema di staging dulu bila memungkinkan; catat penyebab 500 yang Anda temukan beserta baris lognya; dan jadwalkan pemeriksaan log berkala — fatal error yang dibiarkan menumpuk di log adalah 500 berikutnya yang menunggu waktu.

Kesimpulan

WordPress 500 Internal Server Error di VPS Nginx bukanlah vonis tanpa penjelasan — ia adalah undangan untuk membaca log. Aktifkan WP_DEBUG_LOG, baca debug.log bersama Nginx error.log dan log PHP-FPM, lalu ikuti cabang penyebabnya: plugin atau tema yang fatal error, memori yang habis, PHP-FPM yang bermasalah, permission yang salah, atau versi PHP yang tidak cocok.

Ingat dua hal yang paling sering salah kaprah: di Nginx, .htaccess tidak berperan, jadi jangan membuang waktu meresetnya; dan menaikkan memory limit bukanlah obat untuk semua 500. Perbaiki penyebab yang tertulis di log, verifikasi dengan membuka beranda, artikel, dan wp-admin, lalu matikan debug mode setelah selesai.

Untuk membedakan kasus ini dari error yang datang dari Cloudflare, baca juga panduan terkait di The Last Digital tentang cara mengatasi Cloudflare Error 526, dan kunjungi beranda The Last Digital untuk panduan troubleshooting WordPress dan VPS lainnya.

Tags:

Related Posts

Memuat…
Cookie Consent