Mengatasi Error 502 Bad Gateway di WordPress: Penyebab, Diagnosis, dan Cara Memperbaikinya untuk Publisher Indonesia

Error 502 Bad Gateway adalah salah satu error WordPress yang paling membingungkan karena pesannya tidak menjelaskan apa yang sebenarnya rusak. Situs Anda tiba-tiba menampilkan halaman putih bertuliskan “502 Bad Gateway”, pengunjung tidak bisa membaca artikel, iklan AdSense tidak tampil, dan — yang paling mengkhawatirkan bagi publisher — Googlebot yang datang di saat yang sama juga menerima error yang sama. Kabar baiknya, 502 hampir selalu bisa dilacak sampai ke lapisan yang menyebabkannya, dan sebagian besar penyebabnya bisa diperbaiki dalam hitungan menit sampai satu jam, tanpa harus memindahkan hosting atau menginstal ulang WordPress. Artikel ini menjelaskan apa arti 502 menurut standar resmi HTTP, bagaimana membedakan 502 dari error 5xx lain, cara mendiagnosisnya lapis demi lapis — dari browser, CDN, sampai server asal — dan langkah perbaikan untuk setiap penyebab yang paling sering dialami publisher WordPress di Indonesia, termasuk situs yang memakai Cloudflare dan hosting bersama.

Poin Kunci

• Error 502 berarti sebuah server yang bertindak sebagai gateway atau proxy menerima jawaban yang tidak valid — atau tidak menerima jawaban sama sekali — dari server di belakangnya, menurut definisi resmi RFC 9110 bagian 15.6.3.
• Pada WordPress, 502 hampir selalu berasal dari lapisan server, bukan dari konten artikel Anda: proses PHP-FPM yang mati, memori PHP yang habis, plugin atau tema yang crash, server yang kelebihan beban, atau CDN yang tidak bisa menghubungi server asal.
• Diagnosis tercepat adalah menentukan lapisan mana yang menghasilkan halaman error: halaman bermerek Cloudflare berarti server asal Anda yang mengembalikan 502, halaman polos berarti Cloudflare sendiri yang bermasalah, dan halaman bernama nginx atau Apache berarti permintaan sampai ke server tanpa melewati CDN.
• Google memperlakukan 502 sama seperti error 5xx lainnya: crawling diperlambat sebanding dengan jumlah URL yang error, konten dari respons error diabaikan, dan URL yang terus-menerus error pada akhirnya bisa dihapus dari indeks — jadi perbaiki dulu, lalu minta validasi di Search Console.
• Jangan menaikkan batas memori secara membabi buta: batas WP_MEMORY_LIMIT di WordPress hanya berlaku bila batas memory_limit PHP di server mengizinkannya, dan menaikkan batas tanpa mencari penyebabnya hanya menunda error berikutnya.
• Setiap perubahan konfigurasi — wp-config.php, .htaccess, atau pengaturan PHP — wajib didahului backup, dan diuji satu perubahan dalam satu waktu agar Anda tahu persis perubahan mana yang memperbaiki atau memperburuk keadaan.

Daftar Isi

1. Apa Itu Error 502 Bad Gateway (dan Bukan Apa)
2. 502 vs 500, 503, 504, dan Kode Error Cloudflare 52x
3. Mengapa 502 Berbahaya bagi Publisher: Pendapatan, SEO, dan Kepercayaan Pembaca
4. Diagnosis Cepat dalam 5 Menit: Menentukan Lapisan yang Rusak
5. Penyebab 1: PHP-FPM Mati, Crash, atau Tidak Merespons
6. Penyebab 2: Memori PHP Habis dan Batas yang Salah Dipahami
7. Penyebab 3: Plugin atau Tema yang Membuat PHP Crash
8. Penyebab 4: Server Kelebihan Beban dan Lonjakan Traffic
9. Penyebab 5: Masalah Cloudflare, CDN, dan DNS
10. Penyebab 6: Database Lambat dan Query yang Tidak Terbatas
11. Penyebab 7: Konfigurasi Server yang Salah: Nginx, Apache, dan Timeout
12. Checklist Pencegahan agar 502 Tidak Terulang
13. FAQ
14. Kesimpulan
15. Sumber resmi yang dirujuk

1. Apa Itu Error 502 Bad Gateway (dan Bukan Apa)

Kode status HTTP 502 Bad Gateway didefinisikan dalam RFC 9110 — spesifikasi resmi protokol HTTP yang diterbitkan oleh IETF — bagian 15.6.3, dengan kalimat yang dikutip secara luas dalam dokumentasi teknis: “The 502 (Bad Gateway) status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.” Dalam bahasa yang lebih sederhana: ada dua server yang terlibat dalam setiap permintaan ke situs Anda, dan server yang berada di depan — yang menerima koneksi pengunjung — tidak mendapatkan jawaban yang bisa dipakai dari server di belakangnya.

Bayangkan sebuah restoran. Pengunjung berbicara dengan pelayan di depan (gateway), dan pelayan itu meneruskan pesanan ke dapur (upstream). Kalau dapur tidak menjawab, menjawab dengan bahasa yang tidak dimengerti pelayan, atau menutup pintu di tengah pesanan, pelayan kembali ke meja dan berkata, “Maaf, pesanan Anda tidak bisa diproses.” Itulah 502. Yang penting dipahami: pelayannya sendiri sehat — ia menerima permintaan Anda dan merespons. Yang gagal adalah percakapan antara pelayan dan dapur.

Pada situs WordPress, rantai ini biasanya terdiri dari beberapa lapisan. Pengunjung terhubung ke CDN seperti Cloudflare, lalu ke web server (nginx atau Apache), lalu ke PHP-FPM — proses yang menjalankan kode WordPress — dan PHP-FPM itu sendiri terhubung ke database MySQL atau MariaDB. Kegagalan di satu titik mana pun dalam rantai ini, ketika lapisan di depannya masih berfungsi, menghasilkan 502. Inilah sebabnya 502 terasa sulit dilacak: pesannya hanya mengatakan “jawaban dari belakang tidak valid”, tanpa mengatakan lapisan mana yang gagal.

Ada tiga hal yang perlu diluruskan sejak awal. Pertama, 502 hampir tidak pernah disebabkan oleh perangkat pengunjung. Browser Anda, koneksi internet Anda, atau cache di laptop Anda bukan penyebabnya — meskipun membersihkan cache kadang membuat halaman yang tadinya error terlihat normal lagi, itu hanya karena errornya memang sudah hilang di server dan browser Anda menyimpan salinan lama. Kedua, 502 bukan berarti situs Anda terhapus atau database Anda hilang. Konten Anda masih ada; yang gagal adalah proses yang menyajikannya. Ketiga, 502 bukan hukuman dari Google dan bukan pula tanda situs Anda diblokir. Ini murni masalah teknis infrastruktur, dan Google memperlakukannya sebagai masalah sementara — selama Anda memperbaikinya dalam waktu yang wajar.

Untuk publisher, penting juga memahami bahwa 502 bisa bersifat menyeluruh atau sebagian. Error menyeluruh berarti seluruh situs — halaman depan, artikel, bahkan wp-admin — menampilkan 502. Ini menandakan masalah di lapisan server yang dipakai semua permintaan. Error sebagian berarti hanya halaman tertentu yang error, misalnya hanya halaman dengan galeri besar, hanya halaman hasil pencarian, atau hanya wp-admin saat mengunggah media. Error sebagian hampir selalu menunjuk ke satu penyebab yang spesifik: halaman itu membutuhkan memori atau waktu proses lebih besar daripada yang diizinkan server. Perbedaan ini adalah petunjuk diagnosis pertama yang paling berharga, jadi catatlah sejak awal: apakah 502 muncul di semua halaman atau hanya di halaman tertentu, dan apakah muncul terus-menerus atau hanya sesekali.

2. 502 vs 500, 503, 504, dan Kode Error Cloudflare 52x

Kesalahan paling umum dalam menangani 502 adalah mengobatinya seperti error server lain. Padahal setiap kode 5xx menunjuk ke lapisan yang berbeda, dan perbaikan yang tepat untuk satu kode bisa jadi tidak berpengaruh — atau bahkan memperburuk — kode yang lain. Tabel berikut merangkum perbedaannya berdasarkan definisi RFC 9110 dan dokumentasi resmi Google Search Central serta Cloudflare.

Perbedaan 502 dan 504 adalah yang paling sering membingungkan, tetapi sebenarnya tajam. Pada 502, upstream menjawab dengan sesuatu yang tidak bisa dipakai — koneksi ditolak, koneksi terputus di tengah jawaban, atau jawaban yang rusak. Pada 504, upstream tidak menjawab sama sekali sampai batas waktu (timeout) yang ditetapkan gateway habis. Dalam praktik, 504 biasanya berarti proses PHP masih hidup tetapi terlalu lambat, misalnya query database yang berjalan menit-menit lamanya; 502 biasanya berarti proses PHP sudah mati atau tidak pernah menerima permintaan itu. Namun batas ini tidak mutlak: sebuah proses PHP yang crash di tengah-tengah eksekusi bisa menghasilkan 502 di satu percobaan dan 504 di percobaan lain, tergantung kapan tepatnya crash itu terjadi.

Jika situs Anda memakai Cloudflare, ada satu lapis kode lagi yang perlu dikenali: kode 52x milik Cloudflare. Cloudflare memakai kode 521 untuk origin yang menolak koneksi, 522 untuk koneksi yang timeout sebelum tersambung, 523 untuk origin yang tidak bisa dijangkau sama sekali, 524 untuk timeout saat menunggu jawaban origin, dan 525/526/527 untuk masalah TLS dan Railgun. Kode-kode ini bukan bagian dari standar HTTP; mereka adalah kode diagnostik Cloudflare. Namun penting untuk publisher Indonesia karena banyak situs WordPress di sini memakai Cloudflare gratis. Jika Anda melihat kode 521 atau 522, masalahnya hampir pasti di server asal Anda; jika Anda melihat 502 bermerek Cloudflare, server asal Anda sendiri yang mengembalikan 502 kepada Cloudflare. Perbedaan ini menghemat waktu berjam-jam: Anda tidak perlu mengutak-atik pengaturan Cloudflare bila yang rusak adalah server asal, dan sebaliknya.

Satu hal lagi yang perlu dipahami: Google Search Central mengelompokkan semua kode 5xx — 500, 502, 503, 504 — dalam satu perlakuan yang sama di laporan Page Indexing Search Console, yaitu “Server error (5xx)”. Artinya, dari sisi SEO, 502 tidak lebih ringan atau lebih berat daripada 503. Yang membedakan hanyalah penyebab teknisnya dan cara memperbaikinya. Karena itu, jangan membuang waktu mencari tahu apakah 502 “lebih aman” daripada 503 untuk ranking; fokuslah pada seberapa cepat Anda mengembalikan respons 200 yang stabil.

3. Mengapa 502 Berbahaya bagi Publisher: Pendapatan, SEO, dan Kepercayaan Pembaca

Bagi situs berita atau blog biasa, 502 yang berlangsung beberapa menit mungkin hanya gangguan kecil. Bagi publisher yang hidup dari iklan, 502 adalah kebocoran pendapatan yang terjadi secara diam-diam dan sering baru disadari setelah laporan harian AdSense menunjukkan penurunan. Setiap permintaan halaman yang dijawab 502 adalah satu tayangan iklan yang tidak pernah terjadi: tidak ada page view, tidak ada unit iklan yang dimuat, dan tidak ada peluang klik. Jika 502 terjadi pada jam-jam trafik puncak — misalnya pagi hari saat pembaca membuka berita — kerugiannya berlipat: Anda kehilangan justru tayangan yang paling bernilai. Lebih buruk lagi, 502 yang terjadi sebentar-sebentar (intermittent) sering tidak terlihat oleh pemilik situs yang hanya memeriksa halaman depan sekali sehari, tetapi tercatat rapi di laporan server sebagai ratusan permintaan gagal.

Dari sisi SEO, Google Search Central mendokumentasikan perlakuan terhadap error 5xx dengan jelas. Pertama, Googlebot memperlambat laju crawling secara sementara, dan penurunan laju itu sebanding dengan jumlah URL yang mengembalikan error server — segelintir URL yang error hanya memberi efek kecil, tetapi error di seluruh situs bisa membuat crawling nyaris berhenti. Kedua, konten apa pun yang dikembalikan bersama respons 5xx diabaikan; Google tidak mengindeks halaman error. Ketiga, URL yang sudah terindeks dipertahankan untuk sementara waktu, tetapi jika error terus berlanjut selama berhari-hari atau berminggu-minggu, URL itu pada akhirnya dihapus dari indeks. Keempat, setelah server kembali mengembalikan kode 200 secara konsisten, laju crawling naik kembali secara bertahap — tidak instan. Tidak ada angka resmi mengenai berapa lama “aman”: Google tidak menerbitkan ambang durasi, dan tidak ada jaminan pemulihan otomatis dalam waktu tertentu. Yang bisa Anda pegang adalah prinsipnya: perbaiki secepat mungkin, pastikan respons 200 stabil dan berulang, lalu gunakan URL Inspection di Search Console untuk menguji URL yang terdampak dan klik “Validate fix” pada laporan Page Indexing.

Ada satu detail penting yang sering terlewat: robots.txt Anda harus tetap mengembalikan 200 selama situs bermasalah. Dokumentasi Google menegaskan bahwa jika robots.txt sendiri mengembalikan 503 — atau 5xx lainnya — crawling bisa terhenti di seluruh situs, karena Googlebot tidak bisa membaca aturan crawling Anda. Jika error 502 Anda menyeluruh sampai ke robots.txt, prioritaskan pemulihan itu, atau setidaknya pastikan file statis seperti robots.txt masih bisa disajikan oleh web server tanpa melibatkan PHP.

Dampak ketiga adalah kepercayaan pembaca. Pembaca yang mengklik tautan dari Google atau media sosial lalu menemui halaman “502 Bad Gateway” jarang mencoba lagi di hari yang sama. Mereka kembali ke hasil pencarian dan membuka situs lain. Untuk situs yang mengandalkan trafik organik, setiap kunjungan yang gagal adalah peluang yang hilang dua kali: sekali sebagai page view, dan sekali sebagai sinyal bahwa situs Anda tidak bisa diandalkan. Karena itu, artikel ini menempatkan pencegahan dan monitoring di bagian akhir — bukan sebagai pelengkap, melainkan sebagai bagian dari perbaikan itu sendiri.

Sebagai gambaran praktis, bayangkan situs dengan 10.000 page view per hari yang mengalami 502 selama dua jam di jam sibuk. Jika dua jam itu menyumbang sekitar 15% trafik harian, Anda kehilangan sekitar 1.500 page view — dan iklan yang menyertainya — dalam satu kejadian. Angka ini adalah ilustrasi, bukan rumus resmi, tetapi ia menunjukkan mengapa waktu respons Anda terhadap 502 jauh lebih penting daripada kesempurnaan diagnosisnya. Dalam keadaan darurat, mengembalikan situs ke kondisi berjalan — walau dengan plugin yang dimatikan sementara — selalu lebih baik daripada membiarkan situs mati berjam-jam sambil mencari akar masalah yang sempurna.

4. Diagnosis Cepat dalam 5 Menit: Menentukan Lapisan yang Rusak

Sebelum menyentuh konfigurasi apa pun, luangkan lima menit untuk menjawab tiga pertanyaan. Jawabannya akan mengarahkan Anda ke bagian perbaikan yang tepat dan mencegah Anda mengutak-atik lapisan yang sebenarnya sehat.

Pertanyaan pertama: seberapa luas errornya? Buka halaman depan, satu artikel, dan wp-admin. Jika ketiganya menampilkan 502, masalahnya ada di lapisan yang dipakai semua permintaan — proses PHP, web server, atau server asal secara keseluruhan. Jika hanya wp-admin yang error tetapi halaman depan normal, penyebabnya sering kali plugin admin atau proses impor yang berat. Jika hanya satu artikel yang error, curigai konten halaman itu sendiri: galeri besar, embed yang gagal dimuat, atau shortcode dari plugin yang rusak. Jika error muncul sesekali dan hilang sendiri saat di-refresh, curigai beban server atau proses yang crash lalu restart otomatis.

Pertanyaan kedua: siapa yang menampilkan halaman error? Perhatikan tampilan halaman 502 itu sendiri. Halaman bermerek Cloudflare — lengkap dengan logo Cloudflare dan Ray ID di bagian bawah — berarti server asal Anda yang mengembalikan 502 kepada Cloudflare. Halaman polos yang hanya bertuliskan “502 Bad Gateway” dengan tulisan “cloudflare” kecil di bawah berarti Cloudflare sendiri yang menghasilkan error, dan dokumentasi Cloudflare menyebut dua penyebab utamanya: konten gzip yang rusak dari origin, atau origin yang menyajikan gzip tanpa memperbarui header Content-Length. Halaman yang menyebut nginx atau Apache berarti permintaan mencapai server Anda tanpa melewati CDN — entah karena record DNS tidak di-proxy (awan abu-abu di Cloudflare) atau karena Anda sedang mengakses origin secara langsung. Halaman putih polos tanpa merek apa pun biasanya berasal dari web server Anda sendiri atau dari hosting Anda.

Pertanyaan ketiga: kapan error mulai muncul? Cocokkan waktu munculnya error dengan perubahan terakhir yang Anda lakukan. Apakah Anda baru saja mengupdate plugin, tema, atau WordPress core? Apakah hosting Anda baru saja memigrasikan server atau menaikkan versi PHP? Apakah ada lonjakan trafik dari media sosial atau dari Google Discover? Apakah Anda baru memasang plugin keamanan atau firewall baru? Sebagian besar kasus 502 bisa ditelusuri ke satu perubahan dalam 24 jam terakhir. Jika tidak ada perubahan apa pun di sisi Anda, kemungkinan besar penyebabnya ada di sisi hosting — dan langkah tercepat adalah memeriksa halaman status hosting Anda dan menghubungi dukungan mereka.

Setelah tiga pertanyaan itu, lakukan tiga pemeriksaan teknis yang tidak memerlukan akses root. Pertama, periksa status hosting: sebagian besar penyedia hosting Indonesia, termasuk Hostinger, menyediakan halaman status atau pengumuman pemeliharaan di panel mereka. Kedua, periksa Search Console: buka laporan Page Indexing, klik “Server error (5xx)”, dan lihat sejak kapan URL mulai error dan apakah yang terdampak seluruh situs atau hanya sebagian URL. Ketiga, uji URL Anda lewat URL Inspection dengan “Test live URL”: ini mengirim permintaan segar dari Google saat ini juga, bukan hasil crawl terakhir, sehingga Anda tahu apakah error masih terjadi sekarang atau sudah berlalu dan tinggal menunggu laporan Search Console diperbarui.

Jika Anda memiliki akses ke log, bacalah error log PHP dan error log web server untuk rentang waktu saat 502 terjadi. Baris log yang menyebut “upstream prematurely closed connection”, “connect() failed (111: Connection refused)”, atau “recv() failed” adalah tanda klasik bahwa PHP-FPM tidak menjawab. Baris yang menyebut “Allowed memory size exhausted” menunjuk langsung ke masalah memori. Baris yang menyebut “upstream timed out” menunjuk ke proses yang terlalu lambat. Log adalah sumber kebenaran yang paling bisa diandalkan; tebakan tanpa log adalah cara paling lambat menyelesaikan 502.

5. Penyebab 1: PHP-FPM Mati, Crash, atau Tidak Merespons

Penyebab 502 yang paling klasik di WordPress modern adalah PHP-FPM yang tidak berjalan. PHP-FPM (FastCGI Process Manager) adalah proses yang menjalankan kode PHP Anda. Web server — nginx atau Apache — tidak menjalankan PHP sendiri; ia meneruskan permintaan ke PHP-FPM melalui soket atau port tertentu, lalu menunggu jawaban. Jika PHP-FPM mati, crash, atau sedang restart, web server tidak punya siapa pun untuk diajak bicara, dan jawabannya adalah 502.

Mengapa PHP-FPM bisa mati? Penyebab yang paling sering adalah kehabisan memori server. Setiap worker PHP-FPM mengonsumsi RAM, dan jika jumlah worker dikalikan batas memori per proses melebihi RAM yang tersedia, sistem operasi akan mematikan proses — sering kali justru proses PHP-FPM — untuk menyelamatkan server. Penyebab berikutnya adalah crash setelah update PHP: saat versi PHP dinaikkan, misalnya dari 8.1 ke 8.3, jalur soket PHP-FPM bisa berubah, sementara konfigurasi nginx masih menunjuk ke jalur lama. Akibatnya nginx meneruskan permintaan ke soket yang sudah tidak ada. Penyebab lain adalah konfigurasi pool yang salah — misalnya jumlah worker minimum dan maksimum yang tidak konsisten — atau proses yang gagal start karena file konfigurasi mengandung kesalahan sintaks setelah diedit.

Untuk publisher yang memakai shared hosting atau managed WordPress hosting, Anda biasanya tidak bisa me-restart PHP-FPM sendiri. Tetapi Anda tetap bisa memeriksa dan memperbaiki dari sisi yang Anda kendalikan. Pertama, periksa panel hosting Anda: banyak panel menampilkan status layanan PHP dan tombol restart untuk PHP-FPM atau untuk seluruh akun hosting. Kedua, periksa apakah error mulai setelah perubahan versi PHP: di panel hosting, turunkan sementara versi PHP ke versi sebelumnya yang diketahui berfungsi, lalu uji situs Anda. Jika situs kembali normal, masalahnya ada pada kompatibilitas versi PHP baru dengan plugin atau tema Anda — dan solusinya adalah memperbarui plugin/tema itu sebelum mencoba menaikkan versi PHP lagi. Ketiga, periksa penggunaan sumber daya di panel hosting: bila grafik menunjukkan RAM atau CPU menyentuh 100% tepat saat 502 terjadi, penyebabnya adalah kekurangan sumber daya, dan solusinya dibahas di Bagian 8.

Jika Anda mengelola VPS sendiri, pemeriksaan langsung bisa dilakukan lewat SSH. Perintah systemctl status php8.3-fpm (sesuaikan nomor versinya) menunjukkan apakah layanan berjalan. Jika tidak berjalan, systemctl start php8.3-fpm akan menghidupkannya kembali, dan journalctl -u php8.3-fpm -n 50 menampilkan 50 baris log terakhir yang menjelaskan mengapa ia berhenti. Periksa juga konfigurasi pool di /etc/php/8.3/fpm/pool.d/www.conf: pastikan listen menunjuk ke soket atau port yang sama dengan yang dirujuk konfigurasi nginx (fastcgi_pass), dan pastikan nilai pm.max_children masuk akal untuk RAM server Anda. Sebagai patokan praktik, hitung kebutuhan kasar: jika setiap worker memakai rata-rata 50 MB dan server Anda punya 2 GB RAM yang tersedia untuk PHP, jumlah worker maksimum yang aman berada di kisaran 30-an — bukan ratusan. Angka 50 MB per worker ini adalah patokan praktik umum, bukan angka resmi, dan penggunaan nyata sangat bergantung pada plugin yang Anda pakai.

Satu hal yang sering terlupakan: setelah PHP-FPM di-restart, uji bukan hanya halaman depan, tetapi juga wp-admin dan satu artikel dengan banyak gambar. PHP-FPM yang crash karena satu halaman berat akan crash lagi begitu halaman itu dibuka. Jika crash berulang pada halaman yang sama, akar masalahnya bukan di PHP-FPM itu sendiri, melainkan di konten atau plugin yang dipakai halaman itu — lanjutkan ke Bagian 6 dan 7.

6. Penyebab 2: Memori PHP Habis dan Batas yang Salah Dipahami

Ketika sebuah permintaan WordPress membutuhkan memori lebih besar daripada yang diizinkan, PHP menghentikan proses itu dengan fatal error “Allowed memory size exhausted”. Jika proses yang mati itu adalah worker PHP-FPM yang sedang melayani permintaan, web server menerima jawaban yang terputus dan menampilkan 502. Inilah kaitan langsung antara memori dan 502 yang sering tidak disadari: pesan error yang Anda lihat sebagai pengunjung adalah 502, tetapi pesan error yang sebenarnya tercatat di log adalah kehabisan memori.

Kesalahpahaman yang paling umum adalah menganggap WP_MEMORY_LIMIT sebagai satu-satunya batas yang berlaku. Faktanya ada dua batas yang bekerja berlapis. Batas pertama adalah memory_limit milik PHP di level server — inilah batas yang sesungguhnya berlaku untuk setiap proses. Batas kedua adalah konstanta WordPress WP_MEMORY_LIMIT di wp-config.php, yang hanya merupakan permintaan WordPress kepada PHP. WordPress.org mendokumentasikan nilai defaultnya: 40 MB untuk instalasi single-site dan 64 MB untuk multisite, sedangkan WP_MAX_MEMORY_LIMIT — batas yang dipakai untuk tugas admin seperti pemrosesan gambar dan impor — defaultnya 256 MB. Namun poin kuncinya adalah ini: WordPress hanya bisa meminta; PHP hanya akan mengabulkan bila server mengizinkan. Jika server membatasi memory_limit di 128 MB, maka mengatur WP_MEMORY_LIMIT menjadi 512 MB tidak ada pengaruhnya sama sekali. Inilah alasan paling umum mengapa “sudah menaikkan memori tapi tetap error”.

Urutan perbaikan yang benar adalah sebagai berikut. Pertama, cari tahu batas yang benar-benar berlaku: buka Tools → Site Health → Info → Server di wp-admin, dan bandingkan nilai “PHP memory limit” yang dilaporkan WordPress dengan yang ditampilkan panel hosting Anda. Jika keduanya berbeda, nilai yang lebih kecil itulah yang berlaku. Kedua, naikkan batas PHP di level server terlebih dahulu — lewat pengaturan PHP di panel hosting (biasanya di bagian PHP Configuration atau MultiPHP INI Editor), atau lewat file .user.ini atau php.ini di root situs Anda, tergantung jenis hostingnya. Ketiga, barulah atur konstanta WordPress di wp-config.php, tepat di atas baris /* That's all, stop editing! Happy publishing. */:

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

Nilai 256 MB untuk front-end dan 512 MB untuk admin adalah patokan praktik yang umum dipakai untuk situs publisher dengan plugin standar. Situs yang ringan sering cukup dengan 128 MB; situs dengan page builder berat dan banyak plugin mungkin membutuhkan 256 MB. Tetapi perlu diingat: menaikkan batas adalah perbaikan darurat yang sah, bukan perbaikan permanen. Situs WordPress yang berperilaku normal dengan tema standar biasanya merender halaman dengan memori jauh di bawah 128 MB. Jika situs Anda membutuhkan 512 MB hanya untuk menampilkan satu artikel, hampir pasti ada sesuatu yang memakan memori secara tidak wajar — plugin yang menjalankan query tanpa batas, misalnya posts_per_page => -1 pada situs dengan puluhan ribu post, atau plugin yang memuat seluruh pustaka media ke memori.

Karena itu, setelah menaikkan batas dan situs kembali normal, langkah berikutnya adalah mencari penyebabnya. Plugin Query Monitor adalah alat yang paling direkomendasikan untuk ini: ia menampilkan penggunaan memori, jumlah query, dan query paling lambat untuk setiap halaman yang dimuat, sehingga pelakunya biasanya ketahuan dalam satu kali permintaan. Periksa juga error log untuk nama file yang disebut dalam pesan “Allowed memory size exhausted”: pesan itu biasanya menyebut file tempat alokasi terakhir terjadi, bukan file yang bertanggung jawab atas sebagian besar konsumsi memori, tetapi tetap merupakan titik awal yang baik. Dan ingat satu peringatan teknis: jangan menambahkan php_value memory_limit 256M ke .htaccess bila server Anda memakai PHP-FPM atau nginx. Pada PHP-FPM, direktif itu diabaikan sepenuhnya; pada sebagian konfigurasi, ia justru menghasilkan error 500. Gunakan jalur yang benar untuk jenis server Anda: panel hosting, php.ini atau .user.ini, atau konfigurasi pool PHP-FPM.

7. Penyebab 3: Plugin atau Tema yang Membuat PHP Crash

Jika 502 muncul tepat setelah Anda mengupdate, menginstal, atau mengaktifkan plugin atau tema tertentu, pelakunya hampir pasti ada di sana. Plugin yang bermasalah bisa membuat PHP crash dengan berbagai cara: memanggil fungsi yang tidak ada di versi PHP Anda, menjalankan loop tanpa akhir, memuat file yang rusak, atau menghabiskan memori dalam satu permintaan. Yang membuat diagnosis ini rumit adalah crash tersebut terjadi di dalam proses PHP-FPM, sehingga yang terlihat dari luar hanyalah 502 — tanpa pesan error yang informatif bagi pengunjung.

Cara paling aman untuk menguji hipotesis ini adalah menonaktifkan semua plugin sekaligus, lalu mengaktifkannya kembali satu per satu. Jika Anda masih bisa masuk wp-admin, lakukan lewat menu Plugins. Jika wp-admin ikut menampilkan 502 — yang sering terjadi karena plugin yang sama juga dimuat di admin — gunakan cara lewat file manager atau FTP: ubah nama folder /wp-content/plugins/ menjadi /wp-content/plugins-nonaktif/ untuk sementara. WordPress akan menonaktifkan semua plugin secara otomatis karena tidak menemukannya. Uji situs Anda. Jika 502 hilang, Anda sudah memastikan penyebabnya ada di salah satu plugin. Kembalikan nama foldernya, lalu nonaktifkan plugin satu per satu dari wp-admin — atau dengan mengubah nama folder masing-masing plugin — sampai Anda menemukan plugin yang ketika diaktifkan kembali, 502 muncul lagi.

Cara yang lebih elegan, bila Anda masih bisa mengakses wp-admin, adalah plugin Health Check & Troubleshooting. Plugin resmi dari tim WordPress ini menyediakan mode Troubleshooting yang menonaktifkan semua plugin dan beralih ke tema default hanya untuk sesi Anda sendiri, sementara pengunjung lain tetap melihat situs normal. Ini sangat berguna untuk publisher: Anda bisa mendiagnosis tanpa mematikan situs bagi pembaca dan tanpa kehilangan pendapatan iklan selama diagnosis berlangsung. Setelah mode Troubleshooting aktif, aktifkan plugin satu per satu di sesi Anda dan muat ulang halaman yang bermasalah sampai 502 muncul kembali.

Tema juga bisa menjadi penyebab, meskipun lebih jarang. Tema yang memanggil fungsi dari plugin yang sudah dihapus, tema hasil unduhan dari sumber tidak resmi yang mengandung kode rusak, atau tema yang tidak kompatibel dengan versi PHP terbaru bisa membuat PHP fatal error di setiap halaman yang memakai tema itu. Untuk menguji, beralihlah sementara ke tema default WordPress (misalnya Twenty Twenty-Five) dan lihat apakah 502 hilang. Jika hilang, masalahnya ada di tema Anda. Jangan langsung menghapus tema lama sebelum memastikan: simpan dulu salinannya, periksa apakah ada update dari pembuat tema, dan periksa error log untuk baris yang menyebut file di dalam folder tema.

Ada tiga pola plugin yang paling sering memicu 502 pada situs publisher. Pertama, plugin keamanan dan firewall yang terlalu agresif: plugin ini memindai setiap permintaan sebelum WordPress sempat merespons, dan pada lonjakan trafik, proses pemindaian itu sendiri bisa menghabiskan worker PHP-FPM. Kedua, plugin cache yang salah konfigurasi: cache yang menyimpan halaman dengan cara yang bentrok dengan PHP-FPM, atau cache yang mencoba menulis ke folder yang tidak bisa ditulis, bisa membuat setiap permintaan gagal di tengah jalan. Ketiga, plugin yang melakukan tugas berat secara sinkron — misalnya plugin backup yang berjalan saat pengunjung membuka halaman, plugin yang menarik feed eksternal yang lambat, atau plugin statistik yang menulis ke database pada setiap page view. Untuk pola ketiga ini, solusinya sering kali bukan menghapus plugin, melainkan memindahkan tugas beratnya ke WP-Cron atau ke jadwal di luar jam sibuk.

Setelah pelaku ditemukan, Anda punya tiga pilihan: perbarui plugin itu ke versi terbaru (banyak crash disebabkan bug yang sudah diperbaiki), ganti dengan plugin alternatif yang lebih ringan, atau hubungi pembuat plugin dengan menyertakan baris error log yang relevan. Yang tidak disarankan adalah membiarkan plugin bermasalah tetap aktif sambil menaikkan batas memori dan jumlah worker untuk “menutupi” crash-nya. Itu seperti menambah ember di bawah atap bocor: air tetap masuk, hanya lebih lambat terlihat.

8. Penyebab 4: Server Kelebihan Beban dan Lonjakan Traffic

Tidak semua 502 disebabkan oleh kode yang rusak. Kadang server Anda sehat, kode Anda benar, dan satu-satunya masalah adalah jumlah permintaan yang datang melebihi kemampuan server untuk menjawabnya. Inilah penyebab 502 yang paling mungkin bila error muncul di jam-jam sibuk, hilang sendiri di jam sepi, dan bertepatan dengan artikel yang viral di media sosial, liputan yang masuk Google Discover, atau kampanye yang mendatangkan ribuan pengunjung dalam waktu singkat.

Mekanismenya sederhana. Setiap permintaan ke situs WordPress membutuhkan satu worker PHP-FPM selama sepersekian detik sampai beberapa detik. Server Anda hanya punya sejumlah worker. Selama jumlah permintaan bersamaan masih di bawah jumlah worker, semuanya berjalan lancar. Begitu permintaan bersamaan melampaui jumlah worker, permintaan yang datang berikutnya harus antre. Jika antrean juga penuh, atau jika permintaan menunggu terlalu lama, web server menyerah dan mengembalikan 502. Pada shared hosting, masalah ini diperparah oleh batasan paket: jumlah proses bersamaan (sering disebut entry processes), batas CPU, dan batas I/O dibatasi oleh penyedia hosting, dan melampaui batas itu berarti permintaan ditolak — apa pun yang Anda lakukan di sisi WordPress.

Diagnosisnya bisa dilakukan dari panel hosting. Periksa grafik penggunaan sumber daya pada rentang waktu saat 502 terjadi: apakah CPU menyentuh 100%, apakah RAM penuh, apakah entry processes mencapai batas paket? Jika salah satu grafik menyentuh batasnya tepat pada jam error, Anda sudah menemukan penyebabnya. Periksa juga statistik trafik: apakah ada lonjakan pengunjung dari satu sumber tertentu? Lonjakan dari bot yang agresif — scraper, bot SEO yang tidak dikenal, atau bot AI yang merayapi seluruh arsip Anda — juga bisa menghabiskan worker sama seperti lonjakan pengunjung manusia.

Perbaikan untuk penyebab ini terbagi menjadi tiga lapis. Lapis pertama adalah mengurangi beban per permintaan. Aktifkan page caching agar sebagian besar permintaan dilayani dari file cache statis tanpa melibatkan PHP sama sekali — ini satu-satunya langkah yang paling besar dampaknya, karena permintaan yang tidak menyentuh PHP tidak menghabiskan worker. Pastikan juga gambar dioptimasi dan lazy load aktif, karena halaman yang ringan selesai lebih cepat dan membebaskan worker lebih cepat. Lapis kedua adalah membatasi permintaan yang tidak perlu: blokir bot yang jelas-jelas merugikan lewat robots.txt atau aturan firewall, batasi laju permintaan dari satu IP bila hosting Anda menyediakan fitur itu, dan pastikan wp-cron tidak dipicu oleh setiap kunjungan (ganti dengan cron server yang berjalan terjadwal). Lapis ketiga adalah menaikkan kapasitas: naikkan paket hosting, tambah RAM, atau pindah ke paket dengan entry processes yang lebih besar — tetapi lakukan ini setelah lapis pertama dan kedua, karena menaikkan kapasitas tanpa mengurangi beban hanya menggeser titik jenuhnya ke angka trafik yang sedikit lebih tinggi.

Satu peringatan penting: jangan menaikkan jumlah worker PHP-FPM tanpa menambah RAM. Setiap worker mengonsumsi memori, dan worker yang terlalu banyak pada RAM yang terbatas akan memicu OOM killer — sistem operasi akan mematikan proses secara paksa, dan proses yang dimatikan sering kali adalah PHP-FPM itu sendiri. Hasilnya adalah 502 yang lebih parah daripada sebelumnya. Jika Anda mengelola VPS sendiri, hitung dulu: total RAM yang tersedia untuk PHP dibagi rata-rata memori per worker adalah jumlah worker maksimum yang aman. Jika Anda memakai shared hosting, jumlah worker bukan sesuatu yang Anda kendalikan — yang Anda kendalikan adalah beban per permintaan dan keputusan menaikkan paket.

9. Penyebab 5: Masalah Cloudflare, CDN, dan DNS

Bagi publisher Indonesia, Cloudflare adalah lapisan yang paling sering disalahpahami dalam rantai 502. Banyak pemilik situs mengira semua error bermerek Cloudflare berarti “Cloudflare yang rusak”, padahal dokumentasi resmi Cloudflare sendiri menjelaskan hal sebaliknya: dalam sebagian besar kasus, Cloudflare hanya meneruskan 502 yang sudah dihasilkan oleh server asal Anda. Memahami siapa yang sebenarnya menghasilkan halaman error adalah kunci diagnosis di lapisan ini.

Dokumentasi Cloudflare untuk error 502 dan 504 menyebutkan dua kemungkinan penyebab: error 502/504 dari server asal Anda — yang disebut sebagai penyebab paling umum — dan error 502/504 dari Cloudflare sendiri. Cara membedakannya adalah tampilan halaman error. Jika halaman error bermerek Cloudflare dengan logo dan Ray ID, artinya server asal Anda mengembalikan 502 kepada Cloudflare, dan Cloudflare hanya menampilkannya. Perbaikannya ada di server asal Anda, bukan di pengaturan Cloudflare — lanjutkan ke bagian lain artikel ini. Jika halaman error polos tanpa merek Cloudflare, hanya bertuliskan “502 Bad Gateway” dengan kata “cloudflare” kecil di bawahnya, barulah penyebabnya ada di sisi Cloudflare. Dokumentasi Cloudflare menyebut dua penyebab spesifik untuk kasus ini: origin yang menyajikan konten gzip yang rusak, atau origin yang menyajikan konten gzip tanpa memperbarui header Content-Length. Cara mengujinya sederhana: nonaktifkan kompresi di origin untuk sementara dan lihat apakah error hilang. Jika hilang, perbaiki konfigurasi kompresi di server asal Anda.

Ada beberapa penyebab lain di lapisan CDN yang patut diperiksa. Pertama, DNS yang salah: jika Anda baru memindahkan hosting, record A di Cloudflare mungkin masih menunjuk ke IP server lama yang sudah tidak aktif. Periksa record DNS Anda dan pastikan IP-nya sesuai dengan IP server Anda saat ini. Perlu diingat, DNS yang di-proxy menampilkan IP Cloudflare, bukan IP origin — jadi untuk memeriksa IP origin, lihat pengaturan DNS di dashboard Cloudflare, bukan hasil ping dari luar. Kedua, firewall yang memblokir IP Cloudflare: jika Anda atau hosting Anda memasang aturan firewall yang memblokir rentang IP Cloudflare, Cloudflare tidak bisa menghubungi origin sama sekali. Gejala ini biasanya muncul sebagai error 521 atau 522, bukan 502, tetapi tetap layak diperiksa bila Anda baru mengubah aturan firewall. Ketiga, masalah TLS antara Cloudflare dan origin: bila mode SSL di Cloudflare diset ke Full (Strict) tetapi sertifikat di origin sudah kedaluwarsa atau tidak valid untuk domain Anda, koneksi bisa gagal — gejalanya biasanya error 525 atau 526, tetapi pada beberapa konfigurasi bisa muncul sebagai 502. Periksa masa berlaku sertifikat origin Anda dan pastikan mode SSL sesuai dengan kondisi sertifikat itu.

Keempat, Cloudflare Tunnel: jika Anda memakai Tunnel (cloudflared) untuk menghubungkan server ke Cloudflare, 502 bisa berarti tunnel terhubung ke jaringan Cloudflare tetapi cloudflared tidak bisa mencapai layanan origin yang didefinisikan di aturan ingress. Pesan di log cloudflared biasanya eksplisit: “Unable to reach the origin service. The service may be down or it may not be responding.” Periksa apakah layanan origin benar-benar berjalan dan apakah port di aturan ingress sudah benar. Kelima, gangguan di sisi Cloudflare sendiri: periksa halaman status Cloudflare untuk memastikan tidak ada insiden di data center yang melayani wilayah Anda. Gangguan seperti ini jarang terjadi, biasanya hilang sendiri dalam waktu singkat, dan tidak ada yang bisa Anda perbaiki dari sisi Anda selain menunggu.

Satu pemeriksaan yang sangat berguna tetapi jarang dilakukan adalah mengakses origin secara langsung, melewati Cloudflare. Caranya adalah mengubah sementara record DNS menjadi “DNS only” (awan abu-abu) atau mengakses server lewat subdomain yang menunjuk langsung ke origin. Jika origin diakses langsung menampilkan situs normal tetapi lewat Cloudflare menampilkan 502, masalahnya ada di jalur Cloudflare ke origin. Jika origin diakses langsung juga menampilkan 502, masalahnya ada di origin itu sendiri dan Cloudflare tidak bersalah. Tes sederhana ini bisa menghemat waktu berjam-jam dan mencegah Anda mengubah pengaturan Cloudflare yang sebenarnya tidak bermasalah.

10. Penyebab 6: Database Lambat dan Query yang Tidak Terbatas

WordPress tidak bisa menampilkan satu halaman pun tanpa bertanya ke database. Setiap artikel, setiap menu, setiap widget, dan setiap komentar adalah hasil query ke MySQL atau MariaDB. Ketika database menjadi lambat, PHP-FPM menunggu jawaban yang tidak kunjung datang. Jika penantian itu melewati batas timeout yang ditetapkan web server, hasilnya adalah 502 — atau 504, tergantung kapan tepatnya timeout itu terjadi. Penyebab ini sering terlewat karena pemilik situs memeriksa plugin dan memori, tetapi tidak pernah melihat ke database.

Tanda-tanda masalah database cukup khas. Pertama, 502 muncul pada halaman-halaman tertentu yang berat — halaman arsip dengan ribuan post, halaman pencarian dengan kata kunci umum, atau halaman yang menampilkan banyak post terkait — sementara halaman artikel biasa tetap normal. Kedua, error muncul setelah situs tumbuh besar: jumlah post melewati puluhan ribu, jumlah revisi menumpuk, atau tabel wp_options membengkak karena transient yang tidak pernah dibersihkan. Ketiga, wp-admin terasa lambat bahkan saat situs tidak menampilkan 502, terutama pada halaman daftar post dan media library.

Query yang paling sering menjadi biang masalah adalah query tanpa batas: plugin atau tema yang meminta posts_per_page => -1 berarti meminta semua post sekaligus ke memori. Pada situs kecil dengan 200 post, ini tidak terasa. Pada situs dengan 50.000 post, satu permintaan seperti itu bisa menghabiskan ratusan megabyte memori dan mengunci tabel selama berdetik-detik. Plugin Query Monitor akan menunjukkan query semacam ini dengan jelas, lengkap dengan waktu eksekusinya dan dari mana ia dipanggil. Setelah ketahuan, perbaikannya adalah membatasi query itu — ganti -1 dengan angka yang masuk akal seperti 10 atau 20 dan gunakan pagination — atau ganti plugin yang menulis query tersebut.

Perawatan database berkala juga merupakan bagian dari perbaikan. Bersihkan revisi post lama, hapus transient yang kedaluwarsa, hapus komentar spam yang menumpuk, dan optimalkan tabel secara berkala. WordPress menyediakan alat untuk sebagian tugas ini, dan plugin optimasi database yang tepercaya bisa membantu — tetapi jalankan optimasi di luar jam sibuk, dan selalu backup database terlebih dahulu. Pada situs yang sudah besar, pertimbangkan juga untuk memeriksa apakah database Anda masih berjalan di server yang sama dengan web server dan apakah sumber dayanya masih mencukupi. Database yang berbagi RAM dengan puluhan worker PHP adalah kandidat utama kehabisan memori, dan gejalanya sering muncul sebagai 502 yang datang dan pergi tanpa pola yang jelas.

Satu hal yang perlu diingat: jangan pernah menjalankan perintah perbaikan database secara langsung (misalnya REPAIR TABLE atau menghapus baris secara manual) tanpa backup dan tanpa memahami apa yang Anda hapus. Kerusakan database yang disebabkan oleh perbaikan yang ceroboh jauh lebih sulit dipulihkan daripada 502 itu sendiri. Jika Anda ragu, mintalah bantuan dukungan hosting Anda — memeriksa kesehatan database adalah bagian dari layanan mereka.

11. Penyebab 7: Konfigurasi Server yang Salah: Nginx, Apache, dan Timeout

Kadang tidak ada yang crash, tidak ada yang kehabisan memori, dan server tidak kelebihan beban — tetapi 502 tetap muncul. Dalam kasus seperti ini, penyebabnya sering kali adalah konfigurasi server yang salah, biasanya setelah perubahan yang tampak sepele: menaikkan versi PHP, mengedit file konfigurasi, menginstal sertifikat SSL baru, atau memindahkan situs ke server lain.

Pada nginx, penyebab paling umum adalah arahan fastcgi_pass yang menunjuk ke tempat yang salah. Setelah upgrade PHP, soket PHP-FPM sering berpindah — misalnya dari /run/php/php8.1-fpm.sock ke /run/php/php8.3-fpm.sock — sementara konfigurasi nginx masih menunjuk ke jalur lama. Nginx meneruskan permintaan ke soket yang tidak ada, dan jawabannya adalah 502. Periksa kesesuaian antara fastcgi_pass di konfigurasi nginx dan listen di konfigurasi pool PHP-FPM; keduanya harus menunjuk ke soket atau port yang sama persis. Penyebab nginx lainnya adalah buffer yang terlalu kecil: jika header respons dari PHP terlalu besar — misalnya karena cookie yang sangat besar atau header keamanan yang panjang — nginx tidak bisa menampungnya dan mengembalikan 502. Gejala ini biasanya tercatat di error log nginx sebagai “upstream sent too big header”, dan perbaikannya adalah menaikkan proxy_buffer_size dan fastcgi_buffer_size — dengan catatan, nilai ini adalah pengaturan server yang hanya boleh diubah bila Anda memahami dampaknya, dan pada shared hosting Anda tidak bisa mengubahnya sendiri.

Pada Apache dengan PHP-FPM, masalah yang setara adalah konfigurasi proxy yang salah, misalnya arahan ProxyPassMatch atau SetHandler yang menunjuk ke port atau soket PHP-FPM yang salah setelah perubahan versi PHP. Pada Apache dengan mod_php — yang kini makin jarang dipakai — masalah yang setara biasanya muncul sebagai error 500, bukan 502, karena tidak ada pemisahan antara web server dan proses PHP. Satu kesalahan klasik yang masih sering terjadi di Apache adalah menambahkan php_value ke .htaccess pada server yang memakai PHP-FPM: direktif itu tidak berlaku pada PHP-FPM dan pada sebagian konfigurasi menghasilkan error 500. Jika situs Anda menampilkan error 500 tepat setelah Anda mengedit .htaccess, hapus baris php_value itu terlebih dahulu.

Timeout yang terlalu pendek juga bisa menghasilkan 502. Setiap lapisan dalam rantai — nginx, Apache, PHP-FPM, Cloudflare — punya batas waktu sendiri. Jika PHP-FPM membutuhkan waktu 60 detik untuk menyelesaikan satu permintaan berat tetapi nginx hanya menunggu 30 detik, nginx akan memutus koneksi dan menampilkan 502 atau 504. Menaikkan timeout bisa menjadi perbaikan yang sah untuk tugas yang memang berat, seperti impor besar atau pembuatan sitemap raksasa. Tetapi menaikkan timeout untuk halaman artikel biasa adalah tanda bahwa ada masalah yang lebih dalam: halaman artikel yang sehat seharusnya selesai dalam hitungan detik, bukan puluhan detik. Gunakan kenaikan timeout sebagai penolong sementara sambil mencari penyebab lambatnya, bukan sebagai pengganti perbaikan.

Aturan emas untuk semua perubahan konfigurasi: ubah satu hal dalam satu waktu, catat apa yang Anda ubah, dan uji setelah setiap perubahan. Jika Anda mengubah tiga hal sekaligus dan situs kembali normal, Anda tidak tahu perubahan mana yang memperbaikinya — dan Anda juga tidak tahu perubahan mana yang mungkin menimbulkan masalah baru minggu depan. Simpan salinan file konfigurasi asli sebelum mengeditnya, dan pastikan Anda tahu cara mengembalikannya. Untuk wp-config.php dan .htaccess, salinan itu bisa dibuat dalam hitungan detik lewat file manager, dan kebiasaan kecil ini sudah menyelamatkan banyak situs dari downtime yang lebih panjang daripada 502 itu sendiri.

12. Checklist Pencegahan agar 502 Tidak Terulang

Memperbaiki 502 adalah separuh pekerjaan; separuh lainnya adalah memastikan ia tidak terulang di jam sibuk berikutnya. Checklist berikut disusun berdasarkan penyebab-penyebab di atas, dan bisa dijalankan sebagai rutinitas bulanan. Tandai setiap butir yang sudah Anda lakukan, dan ulangi pemeriksaan ini setiap kali Anda mengupdate plugin, tema, atau versi PHP.

Selain checklist, pasanglah monitoring uptime. Layanan monitoring gratis akan memeriksa situs Anda setiap beberapa menit dan memberi tahu Anda — lewat email atau pesan — begitu situs menampilkan error. Bagi publisher, ini adalah investasi waktu yang paling murah: mengetahui 502 dalam lima menit pertama jauh lebih baik daripada mengetahuinya dari laporan AdSense keesokan harinya. Pasang juga peringatan dari hosting Anda bila tersedia: banyak penyedia hosting menyediakan notifikasi saat penggunaan sumber daya mendekati batas paket.

Terakhir, miliki rencana darurat yang tertulis. Tuliskan di satu tempat: siapa yang dihubungi pertama saat 502 muncul (dukungan hosting atau pengelola server), di mana letak backup terakhir, bagaimana cara menonaktifkan plugin lewat file manager bila wp-admin tidak bisa dibuka, dan bagaimana cara beralih sementara ke tema default. Dalam keadaan darurat, Anda tidak ingin mencari tutorial — Anda ingin mengikuti daftar yang sudah Anda tulis saat kepala masih dingin. Rencana darurat yang tidak pernah dipakai tetap jauh lebih baik daripada rencana yang baru disusun saat situs sedang mati.

FAQ

Apakah error 502 Bad Gateway berbahaya bagi SEO situs saya?

Ya, bila dibiarkan. Google Search Central mengelompokkan 502 ke dalam “Server error (5xx)”: Googlebot memperlambat crawling sebanding dengan jumlah URL yang error, mengabaikan konten dari respons error, dan pada akhirnya bisa menghapus URL yang terus-menerus error dari indeks. Namun Google juga memperlakukan 5xx sebagai masalah sementara: begitu server kembali mengembalikan 200 secara konsisten, crawling naik kembali secara bertahap. Kuncinya adalah kecepatan perbaikan dan kestabilan setelahnya — lalu gunakan URL Inspection dan “Validate fix” di Search Console untuk mempercepat pemulihan.

Apa bedanya 502 dan 504?

Keduanya melibatkan gateway yang gagal mendapatkan jawaban dari upstream, tetapi dengan cara berbeda. Pada 502, upstream menjawab dengan sesuatu yang tidak valid — koneksi ditolak, terputus di tengah jalan, atau jawaban yang rusak. Pada 504, upstream tidak menjawab sama sekali sampai batas waktu habis. Dalam praktik, 502 lebih sering menunjuk ke proses yang sudah mati atau crash, sedangkan 504 lebih sering menunjuk ke proses yang masih hidup tetapi terlalu lambat, misalnya query database yang berjalan sangat lama.

Mengapa 502 saya hanya muncul di jam tertentu?

Pola seperti ini hampir selalu menunjuk ke beban server. Di jam sibuk, jumlah permintaan bersamaan melampaui jumlah worker PHP-FPM atau batas entry processes paket hosting Anda, sehingga permintaan yang tidak kebagian worker dijawab 502. Periksa grafik CPU, RAM, dan entry processes di panel hosting pada jam error, aktifkan page caching agar sebagian besar permintaan tidak menyentuh PHP, dan pertimbangkan menaikkan paket hosting bila grafik menunjukkan batas paket yang tercapai secara rutin.

Saya sudah menaikkan WP_MEMORY_LIMIT tetapi 502 tetap muncul. Mengapa?

Karena WP_MEMORY_LIMIT hanya permintaan WordPress kepada PHP, dan batas yang benar-benar berlaku adalah memory_limit PHP di level server. Jika server membatasi memori di 128 MB, mengatur WP_MEMORY_LIMIT ke 512 MB tidak ada pengaruhnya. Periksa nilai yang benar-benar berlaku lewat Tools → Site Health → Info → Server, naikkan batas PHP di panel hosting terlebih dahulu, dan barulah atur konstanta WordPress. Dan bila situs Anda butuh memori sangat besar hanya untuk menampilkan artikel biasa, carilah plugin atau query yang memakan memori secara tidak wajar — menaikkan batas tanpa mencari penyebabnya hanya menunda error berikutnya.

Apakah Cloudflare menyebabkan error 502 di situs saya?

Jarang. Dalam sebagian besar kasus, halaman 502 bermerek Cloudflare berarti server asal Anda sendiri yang mengembalikan 502 kepada Cloudflare. Cloudflare sendiri hanya menjadi penyebab bila halaman errornya polos tanpa merek — yang menurut dokumentasi Cloudflare disebabkan konten gzip yang rusak dari origin atau header Content-Length yang tidak diperbarui. Ujilah dengan mengakses origin secara langsung: bila origin juga error, masalahnya ada di server Anda, bukan di Cloudflare.

Kapan saya harus menghubungi dukungan hosting, dan apa yang saya sampaikan?

Hubungi dukungan hosting bila: 502 terjadi di seluruh situs dan Anda tidak baru saja mengubah apa pun; grafik sumber daya menunjukkan batas paket tercapai; Anda mencurigai PHP-FPM mati tetapi tidak bisa me-restart-nya sendiri; atau Anda sudah mencoba semua langkah di artikel ini tanpa hasil. Sampaikan empat hal: sejak kapan error muncul, apakah menyeluruh atau hanya halaman tertentu, pesan persis di halaman error, dan baris error log yang relevan bila Anda punya. Informasi ini membuat tim dukungan bisa langsung memeriksa lapisan yang tepat, bukan menebak dari awal.

Kesimpulan

Error 502 Bad Gateway terlihat menakutkan karena pesannya tidak menjelaskan apa-apa, tetapi sebenarnya ia adalah salah satu error WordPress yang paling sistematis untuk dilacak. Definisi resminya — gateway yang menerima jawaban tidak valid dari server di belakangnya — sudah memberi tahu Anda cara berpikirnya: jangan bertanya “apa yang rusak di situs saya”, bertanyalah “lapisan mana dalam rantai ini yang gagal menjawab”. Jawab tiga pertanyaan diagnosis dalam lima menit — seberapa luas errornya, siapa yang menampilkan halaman error, dan kapan ia mulai muncul — lalu periksa log sebelum mengubah apa pun. Dalam sebagian besar kasus, penyebabnya adalah salah satu dari tujuh yang dibahas di artikel ini: PHP-FPM yang mati, memori PHP yang habis, plugin atau tema yang crash, server yang kelebihan beban, masalah Cloudflare atau DNS, database yang lambat, atau konfigurasi server yang salah. Perbaiki satu lapis dalam satu waktu, catat perubahan Anda, dan uji setelah setiap perubahan.

Yang tidak kalah penting adalah apa yang terjadi setelah situs kembali normal. Periksa Search Console untuk memastikan Googlebot kembali menerima 200, gunakan “Validate fix” pada laporan “Server error (5xx)”, pantau grafik sumber daya hosting Anda selama beberapa hari ke depan, dan jalankan checklist pencegahan bulanan agar penyebab yang sama tidak terulang di jam sibuk berikutnya. Situs publisher yang sehat bukanlah situs yang tidak pernah error — melainkan situs yang pemiliknya tahu persis lapisan mana yang harus diperiksa ketika error itu muncul, dan bisa mengembalikan layanannya sebelum pembaca sempat pergi ke situs lain.

Sumber resmi yang dirujuk

1. IETF — RFC 9110, HTTP Semantics, Bagian 15.6.3 (502 Bad Gateway): definisi resmi bahwa server, saat bertindak sebagai gateway atau proxy, menerima respons yang tidak valid dari server inbound yang diaksesnya. https://www.rfc-editor.org/rfc/rfc9110#section-15.6.3
2. Cloudflare Docs — Error 502 or 504: dua kemungkinan penyebab (error dari origin, paling umum; atau error dari Cloudflare sendiri), cara membedakan halaman bermerek dan halaman polos, penyebab gzip/Content-Length, dan error pada Cloudflare Tunnel. https://developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-5xx-errors/error-502-504/
3. Google Search Central — HTTP status codes, network and DNS errors: perlakuan 5xx — crawling diperlambat sebanding dengan jumlah URL yang error, konten respons error diabaikan, URL yang persisten error dapat dihapus dari indeks, serta pemulihan bertahap setelah respons 2xx kembali. https://developers.google.com/search/docs/crawling-indexing/http-network-errors
4. Google Search Console — Page Indexing report (“Server error (5xx)”), URL Inspection dan “Validate fix”: alur pemeriksaan URL terdampak dan permintaan validasi perbaikan. https://support.google.com/webmasters/answer/7440203
5. WordPress.org Developer Resources — Editing wp-config.php (WP_MEMORY_LIMIT dan WP_MAX_MEMORY_LIMIT): nilai default 40 MB (single-site) / 64 MB (multisite) dan 256 MB untuk admin, serta catatan bahwa keberhasilan permintaan memori bergantung pada server. https://developer.wordpress.org/advanced-administration/wordpress/wp-config/
6. WordPress.org — Health Check & Troubleshooting (plugin resmi): mode Troubleshooting menonaktifkan plugin dan beralih ke tema default hanya untuk sesi pengguna sendiri. https://wordpress.org/plugins/health-check/
7. WordPress.org Support — Changing File Permissions dan dokumentasi terkait pengelolaan plugin: dasar pengelolaan plugin, instalasi, dan pencopotan yang aman. https://wordpress.org/documentation/article/changing-file-permissions/
8. MDN Web Docs — 502 Bad Gateway: penjelasan bahwa gateway atau proxy menghubungi upstream dan menerima respons yang tidak valid. https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/502