Nginx membaca konfigurasinya saat menyala. Mengubah sebuah berkas tidak berbuat apa-apa sampai Anda menyuruhnya membaca ulang, dan cara Anda menyuruhnya menentukan apakah ada yang menyadarinya.

Selalu uji lebih dulu

nginx -t

Ia mengurai semuanya dan menyebut berkas serta baris dari apa pun yang tak disukainya. Ia tidak mengubah apa pun. Tak pernah ada alasan untuk melewatinya.

Muat ulang, jangan mulai ulang

  • reload - menyalakan pekerja baru dengan konfigurasi baru, membiarkan yang lama menuntaskan pekerjaannya, lalu memensiunkan mereka. Tak ada sambungan yang putus.
  • restart - menghentikan semuanya lalu memulai lagi. Setiap permintaan yang sedang di jalan gagal.
systemctl reload nginx
Memuat ulang dengan konfigurasi rusak TIDAK merusak situsnya: Nginx menolak konfigurasi baru dan tetap menjalankan yang lama. Memulai ulang dengan konfigurasi rusak meninggalkan situs dalam keadaan mati. Itu saja sudah jadi alasan untuk memuat ulang.

Kapan memulai ulang sungguh diperlukan

  • Mengubah pengguna yang menjalankan Nginx.
  • Menambah sebuah modul.
  • Mengubah apa pun di konteks utama yang tak bisa diterapkan pada pekerja yang sedang berjalan.

Jaga agar perubahannya bisa dibalik

cp /etc/nginx/sites-available/mysite{,.bak-$(date +%F)}
# edit, test, reload
# and if it is wrong:
cp /etc/nginx/sites-available/mysite.bak-2026-09-04 /etc/nginx/sites-available/mysite
nginx -t && systemctl reload nginx

Periksa apa yang sungguh termuat

nginx -T | grep -A5 "server_name yourdomain.com"

Huruf T besar mencetak seluruh konfigurasi yang sedang berjalan dengan setiap include terurai, dan itulah satu-satunya cara memastikan berkas yang Anda sunting memang berkas yang dipakai.

Kalau sebuah perubahan tampak tak berbuat apa-apa, cari blok server kedua yang cocok dengan nama yang sama. Yang cocok pertama menang, dan berkas usang di sites-enabled biasanya sebabnya.