Layanan:

Cara Membuat HTTP 503 Maintenance di Nginx aaPanel

Cara Membuat HTTP 503 Maintenance di Nginx aaPanel

HTTP 503 maintenance tepat untuk gangguan sementara ketika situs belum aman melayani halaman normal, termasuk saat update PHP membuat aplikasi gagal tetapi Nginx masih berjalan. Alihkan permintaan ke satu halaman HTML statis, pertahankan status 503 Service Unavailable, kirim Retry-After, dan biarkan robots.txt tetap dapat crawler akses. Respons ini menjelaskan bahwa layanan sedang sementara tidak tersedia. Ia tidak memperbaiki PHP, plugin, atau database yang menjadi sumber masalah.

Jangan mematikan seluruh situs hanya karena ada perubahan kecil. Google menyarankan pemilik situs mempertahankan fungsi yang masih dapat berjalan, sedangkan penutupan penuh menjadi pilihan singkat saat layanan memang harus berhenti. Tutorial ini memakai Nginx pada aaPanel dan akses root melalui SSH. Nama domain, lokasi document root, susunan virtual host, serta perintah service perlu mengikuti server Anda.

Kapan HTTP 503 Maintenance Tepat Dipakai?

Gunakan mode ini saat request dinamis menuju PHP-FPM menghasilkan fatal error, halaman putih, atau respons tidak stabil dan Anda perlu waktu untuk memulihkan aplikasi. Nginx harus tetap sehat karena lapisan inilah yang menyajikan file HTML statis. Bila Nginx, jaringan, DNS, atau mesin VPS ikut mati, konfigurasi 503 di origin tidak akan pernah mencapai pengunjung.

Gangguan pada satu fitur tidak otomatis membutuhkan penutupan seluruh situs. Form yang gagal dapat Anda nonaktifkan sementara sambil mempertahankan halaman informasi yang sehat. Menurut panduan Google Search Central tentang penonaktifan sementara, membatasi fungsi lebih disarankan daripada menutup semua halaman. Mode 503 cocok ketika halaman utama sendiri tidak dapat dipercaya atau perubahan berisiko merusak data dan transaksi.

Sebelum memasang halaman pemeliharaan, bedakan masalah aplikasi dari masalah kapasitas. Panduan diagnosis WordPress di VPS aaPanel membantu memeriksa status service, log, CPU, RAM, dan PHP-FPM. Jika akar masalahnya hanya proses PHP yang salah arah setelah pergantian versi, halaman statis memberi ruang aman untuk memperbaiki pemetaan tanpa menampilkan error kepada pengunjung.

Bedakan 503 dari 404 dan 200 Kosong

Status HTTP membawa makna yang terpisah dari tampilan browser. 404 Not Found menyatakan resource tidak ditemukan, jadi status itu keliru bila URL masih ada dan hanya gagal sementara. 200 OK pada halaman kosong menyatakan request berhasil meski body tidak memberi konten yang semestinya. Crawler dapat menilai respons semacam itu sebagai halaman tipis, halaman sementara, atau soft 404, bergantung pada isi dan sinyal lain.

503 Service Unavailable menyampaikan bahwa server belum dapat melayani request sekarang. Halaman HTML tetap boleh ramah bagi manusia, tetapi kode statusnya harus bertahan sebagai 503. Google juga memperingatkan agar penutupan sementara tidak memakai 403, 404, 410, atau noindex, sebab sinyal tersebut dapat mendorong penghapusan URL dari hasil Search. Untuk konteks perubahan panduan crawl, lihat pembahasan terpisah tentang crawl rate Google dan Retry-After. Artikel tersebut berfokus pada kabar dokumentasi, sedangkan tutorial ini berfokus pada pemasangan dan pemulihan di Nginx.

Header Retry-After memberi perkiraan waktu untuk mencoba lagi. Nilainya dapat berupa jumlah detik atau tanggal HTTP dalam UTC. Nilai tersebut merupakan petunjuk, bukan janji bahwa bot atau browser akan kembali tepat pada saat itu. Dokumentasi crawl rate Google menerima header ini bersama respons 503 atau 429 dan membatasi pemakaian error tersebut untuk gangguan singkat.

Siapkan File dan Cadangan Konfigurasi aaPanel

Contoh berikut menganggap document root berada di /www/wwwroot/example.com. Ganti example.com dengan path situs yang tampil pada aaPanel. Dokumentasi aaPanel menempatkan konfigurasi virtual host Nginx di direktori /www/server/panel/vhost/nginx, tetapi nama file dan susunan include dapat berbeda. Buka Website, pilih domain, lalu periksa menu Configuration atau Config untuk melihat file yang benar.

Simpan salinan virtual host sebelum mengubahnya. Periksa konfigurasi efektif dengan nginx -T karena file yang terlihat di panel dapat memuat include tambahan, reverse proxy, aturan cache, atau blok PHP buatan aaPanel. Bila situs memakai gabungan Nginx dan Apache, pastikan edit berlangsung pada lapisan yang menerima koneksi publik, bukan pada backend yang tidak langsung menjawab pengunjung.

cp /www/server/panel/vhost/nginx/example.com.conf \
   /www/server/panel/vhost/nginx/example.com.conf.before-maintenance

/www/server/nginx/sbin/nginx -T > /root/nginx-effective-before-maintenance.txt

Anda memerlukan halaman maintenance.html dan file penanda bernama .maintenance-on. File penanda boleh kosong. Kehadirannya mengaktifkan mode 503 tanpa restart PHP, sedangkan penghapusannya memulihkan alur normal. Pastikan pengguna worker Nginx dapat membaca document root dan file HTML tersebut.

Buat Halaman Maintenance Statis

Halaman harus mandiri dan ringan. Gunakan CSS inline, hindari font eksternal, JavaScript, request API, serta gambar dari CDN. Jika aset eksternal ikut gagal, pengunjung hanya melihat halaman pemeliharaan yang rusak. Jangan menambahkan meta noindex karena status 503 sudah menjelaskan sifat sementara respons.

<!doctype html>
<html lang="id">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width,initial-scale=1">
  <title>Situs Sedang Dalam Pemeliharaan</title>
  <style>
    body { margin: 0; min-height: 100vh; display: grid; place-items: center; background: #111; color: #eee; font-family: system-ui, sans-serif; }
    main { width: min(42rem, calc(100% - 3rem)); }
    h1 { font-size: clamp(2rem, 7vw, 4rem); line-height: 1.05; }
    p { color: #bbb; font-size: 1.1rem; line-height: 1.7; }
  </style>
</head>
<body>
  <main>
    <h1>Kami sedang melakukan pemeliharaan.</h1>
    <p>Layanan belum tersedia sementara. Silakan coba lagi setelah waktu yang tertera pada respons server.</p>
  </main>
</body>
</html>

Simpan file itu sebagai /www/wwwroot/example.com/maintenance.html. Lalu pastikan robots.txt normal tetap tersedia. Google meminta pemilik situs tidak mengembalikan 503 untuk file tersebut dan tidak menutup seluruh crawl melalui aturan Disallow: /. Bila situs belum mempunyai file fisik, Anda dapat membuat robots minimal yang tetap mengizinkan crawl.

User-agent: *
Disallow:

Pasang Toggle HTTP 503 pada Nginx

Tambahkan blok berikut di dalam server { } untuk domain yang tepat. Jangan menaruhnya di dalam blok PHP-FPM karena halaman maintenance harus tetap bekerja ketika PHP gagal. Directive error_page Nginx melakukan pengalihan internal ke handler pemeliharaan, sedangkan directive return menghentikan pemrosesan dan mengirim status yang Anda tetapkan.

set $maintenance_mode 0;

if (-f /www/wwwroot/example.com/.maintenance-on) {
    set $maintenance_mode 1;
}

if ($uri = /robots.txt) {
    set $maintenance_mode 0;
}

if ($maintenance_mode = 1) {
    return 503;
}

error_page 503 @site_maintenance;

location @site_maintenance {
    root /www/wwwroot/example.com;
    rewrite ^ /maintenance.html break;
    add_header Retry-After 3600 always;
    add_header Cache-Control "no-store, max-age=0" always;
}

Susunan ini memakai operasi set, pemeriksaan file, dan return pada fase rewrite. Named location mencegah request maintenance kembali ke blok aplikasi PHP. Parameter always diperlukan karena Nginx secara default tidak menambahkan header buatan pada semua kode respons. Periksa kembali security header karena add_header pada location dapat mengubah pewarisan header dari level server.

Asumsi simulasi: nilai 3600 berarti satu jam. Pilih estimasi yang masuk akal dari rencana pemulihan Anda. Bila belum dapat memperkirakan waktu selesai, gunakan jeda pendek yang akan Anda perbarui setelah ada diagnosis. Jangan menulis tanggal absolut tanpa zona GMT dan jangan membiarkan jadwal lama tertinggal ketika pemulihan mundur.

Uji Konfigurasi lalu Aktifkan Mode Maintenance

Jangan membuat file penanda sebelum sintaks Nginx lulus. aaPanel menyediakan perintah config test dan reload untuk Nginx yang terpasang melalui panel. Perintah pertama hanya memeriksa konfigurasi, sedangkan reload meminta master process membaca konfigurasi baru dan mempertahankan konfigurasi lama bila penerapan gagal.

/etc/init.d/nginx configtest
/etc/init.d/nginx reload

Setelah reload berhasil, aktifkan maintenance dengan membuat marker. Nginx mengecek keberadaan file pada setiap request, jadi toggle ini tidak membutuhkan reload berikutnya. Buka satu request uji segera setelah aktivasi supaya Anda tidak meninggalkan situs dalam keadaan yang belum terverifikasi.

touch /www/wwwroot/example.com/.maintenance-on

Bila Anda juga perlu mempertahankan challenge sertifikat pada /.well-known/acme-challenge/, tambahkan pengecualian yang sangat sempit dan uji sebelum maintenance. Jangan menyalin pengecualian luas untuk seluruh folder tersembunyi. Pada jendela pemeliharaan satu hingga dua jam, menjadwalkan aktivasi di luar waktu renewal sering lebih sederhana.

Periksa Status, Retry-After, dan Robots dengan curl

Browser dapat menampilkan halaman yang benar sambil menyembunyikan kode status. Gunakan curl pada homepage dan satu URL dalam untuk memastikan keduanya menerima 503. Lalu ambil body agar Anda tahu Nginx benar-benar menyajikan HTML statis, bukan error page milik CDN atau gateway lain.

curl -I https://example.com/
curl -I https://example.com/halaman-dalam/
curl -sS -D /tmp/maintenance-headers.txt \
  https://example.com/halaman-dalam/ \
  -o /tmp/maintenance-body.html

Hasil header perlu memuat status 503 Service Unavailable, Retry-After, dan Cache-Control: no-store, max-age=0. Periksa body secara terpisah dengan membuka file hasil atau mencari judul maintenance. Metode GET lebih meyakinkan daripada hanya HEAD karena sejumlah proxy memperlakukan kedua metode secara berbeda.

grep -iE 'HTTP/|retry-after|cache-control|content-type' \
  /tmp/maintenance-headers.txt

grep -F 'Situs Sedang Dalam Pemeliharaan' \
  /tmp/maintenance-body.html

curl -I https://example.com/robots.txt

robots.txt harus tetap menghasilkan respons normal, idealnya 200, tanpa Retry-After. Coba pula URL yang sebelumnya memakai cache penuh, halaman login, endpoint REST, dan request dengan query string. Pemeriksaan ini menangkap location Nginx yang mungkin lolos dari aturan server utama.

Troubleshooting jika Respons 503 Tidak Sesuai

Bila halaman maintenance tampil tetapi statusnya 200, cari modifier seperti error_page 503 =200 atau aplikasi yang melakukan redirect. Directive Nginx dengan sintaks =response memang dapat mengubah status. Hapus perubahan status tersebut untuk kasus ini, jalankan config test, reload, lalu ulangi pengujian GET dan HEAD.

Respons 404 untuk maintenance.html biasanya berarti nilai root tidak cocok dengan document root atau worker Nginx tidak mempunyai izin baca. Sementara itu, error rewrite or internal redirection cycle menandakan handler maintenance memanggil jalur yang kembali memicu aturan awal. Pertahankan named location dan gunakan break seperti contoh, lalu periksa konfigurasi efektif dengan nginx -T.

Jika Retry-After hilang, pastikan always hadir pada add_header dan tidak ada location lain yang mengambil alih request. Nginx mewariskan header dari level sebelumnya hanya ketika level saat ini tidak mendefinisikan add_header sendiri. Jadi audit semua header yang benar-benar keluar, bukan hanya satu baris konfigurasi.

Reverse proxy dapat mengganti body, status, atau header dari origin. Pada Cloudflare, uji hostname publik dan origin secara terpisah. Dokumentasi Cloudflare menyediakan contoh curl --connect-to untuk melewati proxy. Aturan cache khusus pun dapat menyajikan konten lama saat origin memberi 5xx, jadi periksa CF-Cache-Status, kebijakan stale content, Workers, dan custom error page sebelum menyimpulkan bahwa konfigurasi origin gagal.

Pulihkan Situs setelah Update PHP Selesai

Perbaiki aplikasi saat mode maintenance aktif. Bila perubahan menyangkut kapasitas atau versi runtime, gunakan pengukuran dan verifikasi seperti pada panduan setting PHP aaPanel untuk WordPress di VPS, bukan menyalin limit server lain. Uji PHP-FPM, koneksi database, halaman dinamis, login, form, cron, dan endpoint bisnis yang kritis melalui staging atau akses origin terbatas.

Setelah aplikasi sehat, hapus file penanda. Anda tidak perlu menghapus blok konfigurasi pada saat darurat berakhir. Menyimpannya sebagai mekanisme siap pakai mengurangi perubahan saat insiden berikutnya, selama tim mendokumentasikan lokasi marker dan rutin menguji halaman statisnya.

rm -f /www/wwwroot/example.com/.maintenance-on

curl -I https://example.com/
curl -I https://example.com/robots.txt

Homepage dan URL dalam harus kembali memberi status normal aplikasi, sedangkan header Retry-After harus hilang. Periksa access log serta error log selama beberapa menit. Jika error 5xx kembali naik, aktifkan marker lagi dan lanjutkan diagnosis. Jangan menghapus cadangan konfigurasi sampai perubahan PHP dan trafik produksi stabil.

Google menyebut penutupan penuh sebagai tindakan ekstrem untuk waktu sangat singkat. Dokumentasi crawl rate yang diperbarui 6 Oktober 2026 memberi contoh beberapa jam sampai satu atau dua hari. Bila crawler melihat 503 pada URL yang sama selama beberapa hari, URL tersebut dapat keluar dari indeks. Karena itu, Retry-After tidak membuat maintenance panjang bebas risiko.

Setelah status normal kembali, pantau Crawl Stats, Page Indexing, dan URL Inspection di Search Console. Dokumen yang sama menjelaskan bahwa Google menaikkan kembali crawl rate ketika jumlah error turun, tetapi pemulihan crawling dan tampilan Search tidak mempunyai waktu yang dapat dijamin. Jika perbaikan membutuhkan berminggu-minggu, pertahankan halaman penting yang benar-benar berfungsi dengan 200 atau batasi fitur bermasalah alih-alih membiarkan seluruh hostname mengirim 503.

Konfigurasi ini memberi sinyal sementara yang tepat dan halaman yang tetap berguna saat PHP bermasalah. Batas operasionalnya tetap jelas: Nginx dan jaringan harus hidup, proxy tidak boleh menutupi respons, robots.txt harus lolos, dan tim perlu mematikan marker segera setelah verifikasi aplikasi selesai.

Artikel Terkait

Artikel & Informasi Seputar Bisnis & Website

→
baca semua artikel

Copyright © 2026 CodeF Web Developer. All rights reserved colaborated with Pajuda.com