يقرأ Nginx إعداداته عند الإقلاع. وتغييرُ ملفٍّ لا يفعل شيئًا حتى تأمره بإعادة القراءة، وكيف تأمره هو ما يقرّر أيلاحظ أحد أم لا.

اختبر أوّلًا دائمًا

nginx -t

يحلّل كلّ شيء ويسمّي ملفَّ وسطرَ ما لا يعجبه. ولا يغيّر شيئًا. ولا وجه أبدًا لتخطّيه.

أعد التحميل لا التشغيل

  • reload — يبدأ عمّالًا جددًا بالإعداد الجديد، ويدع القدامى يُتمّون ما بأيديهم ثمّ يُحيلهم. ولا يسقط اتّصال.
  • restart — يوقف كلّ شيء ثمّ يبدأ من جديد. وكلّ طلبٍ في الطريق يفشل.
systemctl reload nginx
إعادةُ تحميلٍ بإعدادٍ مكسور لا تكسر الموقع: يرفض Nginx الإعداد الجديد ويظلّ يعمل بالقديم. أمّا إعادةُ تشغيلٍ بإعدادٍ مكسور فتترك الموقع ساقطًا. وهذا وحده سبب إعادة التحميل.

متى تلزم إعادة التشغيل حقًّا

  • تغيير المستخدم الذي يعمل به Nginx.
  • إضافة وحدة.
  • تغيير أيّ شيء في السياق الرئيس لا يمكن تطبيقه على عمّال يعملون.

أبقِ التغيير قابلًا للرجوع

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

افحص ما هو محمَّل فعلًا

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

الحرف T الكبير يطبع الإعداد العامل كلَّه بكلّ تضمينٍ محلولًا، وهو السبيل الوحيد للتيقّن من أنّ الملفّ الذي عدّلته هو المستعمَل.

وإن بدا التغيير بلا أثر فابحث عن كتلة خادم ثانية تطابق الاسم نفسه. فالمطابقة الأولى تفوز، وملفٌّ قديم في sites-enabled هو السبب المعتاد.