تثبيت خادم Nginx على Debian وضبط الإعدادات الأولية: دليل خطوة بخطوة

Nginx من أكثر خوادم الويب انتشارًا في العالم، ويُستخدم لتقديم المواقع الثابتة، وكوكيل عكسي أمام تطبيقات Node.js وPython وغيرها، ولتوزيع الحمل بين الخوادم. وهو مفتوح المصدر، خفيف على الموارد، وقابل للضبط بملفات نصية واضحة يمكن مراجعتها ونسخها احتياطيًا.

يرشدك هذا الدليل خطوة بخطوة من خادم Debian نظيف إلى موقع يعمل بعنوانه الخاص وشهادة HTTPS، مع الإعدادات الأولية التي تجنّبك مشاكل شائعة: الجدار الناري، هيكل الملفات، الأمان الأساسي، واستكشاف الأخطاء. الأوامر مختبرة على Debian 13 (Trixie)، وتنطبق على الإصدارات الأقدم مع اختلاف رقم إصدار Nginx.

ما الذي سنبنيه في هذا الدليل؟

في نهاية الدليل سيكون لديك:

• خادم Nginx مثبّت ويعمل تلقائيًا عند كل إقلاع
• جدار ناري يسمح بحركة الويب وSSH فقط
• موقع أول مضبوط في ملف مستقل (Server Block) بدل تعديل الإعداد الافتراضي
• إعدادات أمان وأداء أولية معقولة
• شهادة HTTPS من Let's Encrypt تتجدد تلقائيًا
• نموذج جاهز لوضع Nginx أمام تطبيق خلفي

الفكرة العامة التي ستتكرر: عدّل ملفًا، ثم اختبر بأمر nginx -t، ثم أعد تحميل الإعداد. لا تعدّل إعدادًا وتعيد تشغيل الخادم دون اختبار، فخطأ إملائي واحد قد يوقف كل مواقعك.

المتطلبات قبل أن تبدأ

• خادم Debian: جهاز افتراضي (VPS) أو خادم مادي بنظام Debian 13، بذاكرة 1 غيغابايت تكفي لموقع صغير
• مستخدم عادي بصلاحية sudo: لا تعمل بحساب root مباشرة، فهذا يضاعف أثر أي خطأ
• اسم نطاق (اختياري لكنه لازم للـ HTTPS): مع سجل A يشير إلى عنوان IP الخادم، وسجل AAAA إن كان لديك عنوان IPv6
• وصول SSH مفتوح ومجرَّب قبل تفعيل أي جدار ناري، حتى لا تغلق على نفسك الباب

في الأمثلة سنستخدم النطاق example.com كمثال، استبدله بنطاقك أينما ظهر.

الخطوة 1: تثبيت Nginx من مستودع Debian

أبسط طريقة وأنسبها لأغلب الاستخدامات هي الحزمة الموجودة في مستودعات Debian نفسها: تُحدَّث أمنيًا عبر فريق Debian، وتتكامل مع النظام، وتأتي بهيكل ملفات منظم سنشرحه بعد قليل.

# Refresh package lists and apply pending updates first
sudo apt update
sudo apt upgrade -y

# Install Nginx
sudo apt install nginx

# Check the installed version
nginx -v

# Confirm the service is running and enabled at boot
systemctl status nginx --no-pager
systemctl is-enabled nginx

على Debian تبدأ الخدمة وتُفعَّل تلقائيًا بعد التثبيت. إصدار Nginx في Debian 13 هو من سلسلة 1.26 بحسب أدلة منشورة، ويتغير الرقم الدقيق مع التحديثات الأمنية، وكذلك مع إصدار Debian نفسه. اختبر الخادم محليًا:

# Ask the local server for its headers
curl -I http://127.0.0.1

# Illustrative output (version number will differ):
# HTTP/1.1 200 OK
# Server: nginx/1.26.3

# Find your server's IP address to test from another machine
hostname -I

إن ظهر 200 OK فالخادم يعمل. ولتجربته من متصفحك، افتح http://عنوان-الخادم، وإن لم تظهر الصفحة الافتراضية فالسبب غالبًا جدار ناري من مزود الخدمة السحابي (Security Group)، وسنعالج الجدار الداخلي بعد قليل.

مستودع Debian أم nginx.org؟ كيف تقرر

لـ Nginx مصدران رسميان للحزم على Debian. الأول مستودع Debian كما فعلنا. والثاني المستودع الرسمي لفريق Nginx على nginx.org، ويوفّر فرعين: Stable للإصدارات الأكثر ثباتًا، وMainline لأحدث الميزات. وبحسب فحص منشور في مايو 2026 كان الفرع المستقر عند 1.30.x والرئيسي عند 1.31.0، وهي أرقام تتغير باستمرار فراجع الصفحة الرسمية.

إن احتجت المستودع الرسمي، فهذه هي الخطوات المنشورة في التوثيق الرسمي (للفرع المستقر). لاحظ أن حزمة nginx.org تتعارض مع حزم Nginx الخاصة بـ Debian، فاختر أحد المصدرين ولا تخلط بينهما:

# Prerequisites
sudo apt install curl gnupg2 ca-certificates lsb-release debian-archive-keyring

# Import the official signing key
curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor \
    | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

# Verify the key: compare the fingerprint with the one published on nginx.org
gpg --dry-run --quiet --no-keyring --import --import-options import-show \
    /usr/share/keyrings/nginx-archive-keyring.gpg

# Add the STABLE repository (use /packages/mainline/debian for mainline)
echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] \
https://nginx.org/packages/debian $(lsb_release -cs) nginx" \
    | sudo tee /etc/apt/sources.list.d/nginx.list

# Prefer nginx.org packages over the distribution's
echo -e "Package: *\nPin: origin nginx.org\nPin: release o=nginx\nPin-Priority: 900\n" \
    | sudo tee /etc/apt/preferences.d/99nginx

sudo apt update
sudo apt install nginx

باقي الدليل مبني على حزمة Debian وهيكلها (sites-available وwww-data). إن اخترت nginx.org فضع ملفات مواقعك في /etc/nginx/conf.d/ بامتداد .conf بدل الخطوتين اللتين تخصان sites-enabled.

فهم هيكل ملفات Nginx على Debian

قبل أن تعدّل أي شيء، اعرف أين تقع الملفات. هذا يوفر عليك وقتًا طويلًا حين تبحث عن إعداد لا يعمل:

الفكرة وراء sites-available وsites-enabled بسيطة: تكتب الموقع مرة واحدة في الأول، وتفعّله بإنشاء رابط رمزي في الثاني، وتعطّله بحذف الرابط دون حذف الملف الأصلي. وكل ما يقرؤه Nginx فعليًا هو ما في sites-enabled.

الخطوة 2: إدارة الخدمة بأوامر systemd

Nginx يعمل كخدمة systemd، وستستخدم هذه الأوامر كثيرًا:

# Test the configuration for syntax errors (always do this first)
sudo nginx -t

# Apply a changed configuration WITHOUT dropping connections
sudo systemctl reload nginx

# Full stop/start (drops connections; needed after some changes)
sudo systemctl restart nginx

# Start/stop and boot behaviour
sudo systemctl start nginx
sudo systemctl stop nginx
sudo systemctl enable nginx
sudo systemctl disable nginx

# Print the full effective configuration (all includes merged)
sudo nginx -T

الفرق بين reload وrestart مهم: الأول يقرأ الإعداد الجديد ويبدل العمال تدريجيًا دون قطع الاتصالات الجارية، والثاني يوقف الخدمة ثم يبدؤها. استخدم reload دائمًا في الإنتاج ما لم تكن هناك حاجة فعلية لإعادة التشغيل. والأمر nginx -T مفيد جدًا حين تريد رؤية الإعداد النهائي بعد دمج كل الملفات المضمّنة.

الخطوة 3: فتح المنافذ في الجدار الناري

Debian لا يفعّل جدارًا ناريًا افتراضيًا، فكل المنافذ المفتوحة على الخدمات تكون مكشوفة. سنستخدم UFW لأنه بسيط. قاعدة واحدة لا تتجاوزها: اسمح بـ SSH قبل أن تفعّل الجدار، وإلا ستفقد الوصول للخادم.

sudo apt install ufw

# 1) Allow SSH FIRST (change 22 if you use a custom SSH port)
sudo ufw allow 22/tcp

# 2) Allow web traffic
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# 3) Enable and inspect
sudo ufw enable
sudo ufw status verbose

بعد تفعيله افتح اتصال SSH ثانيًا من جهازك للتأكد أنه ما زال يعمل، قبل أن تغلق الاتصال الأول. وإن كان مزود الخادم يوفر جدارًا خارجيًا (Security Group أو Firewall في لوحة التحكم)، فتأكد أنه يسمح بالمنافذ 22 و80 و443 أيضًا، فكلا الجدارين يجب أن يسمحا.

الخطوة 4: إنشاء أول موقع (Server Block)

لا تعدّل ملف الموقع الافتراضي default. أنشئ ملفًا مستقلًا لكل موقع، فيسهل عليك نسخه وتعطيله واستنساخه لاحقًا. ابدأ بمجلد الموقع ومحتواه التجريبي:

# Create the web root for the site
sudo mkdir -p /var/www/example.com/html

# Give your user ownership; others (incl. www-data) can read and enter
sudo chown -R $USER:$USER /var/www/example.com
sudo chmod -R 755 /var/www/example.com

# A plain-text test page
echo "Nginx is working on example.com" > /var/www/example.com/html/index.html

ثم ملف الإعداد نفسه. أنشئه بمحررك المفضل:

sudo nano /etc/nginx/sites-available/example.com

# --- file contents ---
server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;

    root /var/www/example.com/html;
    index index.html;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

شرح الأسطر المهمة:

• listen 80 وlisten [::]:80: الاستماع على المنفذ 80 لعناوين IPv4 وIPv6
• server_name: الأسماء التي يجيب عنها هذا الموقع. يطابق Nginx اسم المضيف في الطلب مع هذه القائمة ليختار الكتلة المناسبة
• root: المجلد الذي تُقدَّم منه الملفات
• try_files $uri $uri/ =404: جرّب الملف المطلوب، ثم المجلد، وإلا أعد خطأ 404 نظيفًا
• سجلات مستقلة لكل موقع تسهّل عليك تتبع مشكلاته بعيدًا عن ضجيج المواقع الأخرى

الآن فعّل الموقع، وعطّل الموقع الافتراضي، واختبر:

# Enable the site with a symlink
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/

# Disable the default site (removes only the symlink, not the original file)
sudo rm /etc/nginx/sites-enabled/default

# Test, then reload
sudo nginx -t
sudo systemctl reload nginx

# Test without waiting for DNS: send the Host header manually
curl -H "Host: example.com" http://127.0.0.1/

الأمر الأخير يرسل الطلب إلى الخادم المحلي مع ترويسة Host تحمل اسم موقعك، فترى صفحتك التجريبية حتى لو لم يصل سجل DNS بعد.

الخطوة 5: الإعدادات الأولية العامة

الإعداد الافتراضي في Debian معقول، لكن هناك بعض القيم التي يحسن ضبطها من البداية. بدل تعديل nginx.conf نفسه، ضعها في ملف مستقل داخل conf.d، فتبقى تعديلاتك منفصلة عن ملف الحزمة ولا تضيع عند تحديثه:

# First, check which of these are already set in the main file
grep -nE "gzip|server_tokens|client_max_body_size" /etc/nginx/nginx.conf

sudo nano /etc/nginx/conf.d/00-basic-tuning.conf

# --- file contents ---
# Hide the Nginx version from headers and error pages
server_tokens off;

# Maximum request body (uploads); the default is only 1m
client_max_body_size 10m;

# Compression for text-based content (gzip itself is usually "on" already)
gzip_vary on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

لماذا فحصنا الملف الرئيسي أولًا؟ لأن Nginx يرفض الإعداد حين تتكرر الأوامر ذات القيمة الواحدة في السياق نفسه، فيظهر خطأ "directive is duplicate". إن ظهر لك هذا الخطأ عند اختبار nginx -t، فاحذف السطر المكرر من أحد الملفين. وفي الإعداد الافتراضي على Debian يكون gzip on مفعّلًا عادة وبعض خيارات الضغط مُعلَّقة، لكن لا تفترض ذلك، تحقق بنفسك.

• server_tokens off: يخفي رقم الإصدار، فلا يعرف من يفحص خادمك أي إصدار تشغّل. وهذا لا يعالج ثغرة، لكنه يقلل المعلومات المكشوفة
• client_max_body_size: الحد الافتراضي 1 ميغابايت يرفض رفع أي صورة كبيرة بخطأ 413. اضبطه بحسب حاجة موقعك لا بأكبر رقم ممكن
• ضغط gzip يقلل حجم النصوص المرسلة، فتحمَّل الصفحات أسرع. لا حاجة لضغط الصور والفيديو لأنها مضغوطة أصلًا

واترك worker_processes auto كما هو، فهو يضبط عدد العمال بعدد أنوية المعالج تلقائيًا، وهو الخيار المناسب في الغالب.

الخطوة 6: أساسيات الأمان

لا يغني هذا القسم عن مراجعة أمنية كاملة، لكنه يغطي ثلاث أمور بسيطة تستحق التفعيل من البداية.

أولًا: كتلة التقاط للطلبات المجهولة

حين يصل طلب باسم مضيف لا يطابق أي موقع لديك (مثل زيارة مباشرة بعنوان IP أو نطاق غريب موجَّه لخادمك)، يقدّم Nginx الموقع الأول افتراضيًا. الأفضل أن تقطع هذه الطلبات:

# /etc/nginx/sites-available/00-catchall
server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;

    # 444 is Nginx-specific: close the connection without a response
    return 444;
}

# Enable it (the original "default" site must already be removed,
# otherwise two default_server blocks will conflict)
sudo ln -s /etc/nginx/sites-available/00-catchall /etc/nginx/sites-enabled/

ثانيًا: ترويسات الأمان في مقطع مشترك

ضع الترويسات الأساسية في مقطع قابل لإعادة الاستخدام:

sudo nano /etc/nginx/snippets/security-headers.conf

# --- file contents ---
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# Then, inside your server block:
include snippets/security-headers.conf;

ولماذا مقطع منفصل بدل كتابتها في كل مكان؟ بسبب سلوك في Nginx يفاجئ كثيرين: توجيهات add_header تُورَّث من المستوى الأعلى فقط إذا لم يكن في المستوى الحالي أي add_header. فإذا أضفت ترويسة داخل location معين، تختفي ترويسات كتلة server عن ذلك الموضع. الحل أن تضمّن المقطع المشترك في كل موضع يضيف ترويساته الخاصة. وعن رأس Content-Security-Policy: لا تنسخه من الإنترنت كما هو، فهو يحتاج ضبطًا حسب موارد موقعك وإلا كسر صفحاتك.

ثالثًا: منع الوصول للملفات المخفية

# Inside the server block: block dotfiles (.git, .env, .htaccess ...)
# but keep /.well-known/ reachable for Let's Encrypt validation
location ~ /\.(?!well-known) {
    deny all;
}

هذه القاعدة تمنع الوصول لملفات مثل .git و.env إن وُضعت بالخطأ داخل مجلد الموقع، وتستثني .well-known الذي يحتاجه التحقق من الشهادة.

الخطوة 7: التخزين المؤقت للملفات الثابتة

الصور وملفات CSS وJavaScript نادرًا ما تتغير، فلا داعي لأن يعيد المتصفح تحميلها كل زيارة. أضف هذه الكتلة داخل server:

location ~* \.(?:css|js|jpg|jpeg|png|gif|webp|svg|ico|woff2)$ {
    expires 30d;
    access_log off;

    # add_header in a location cancels inherited headers, so re-include them
    include snippets/security-headers.conf;
}

الأمر expires 30d يضيف ترويستي Expires وCache-Control تلقائيًا بمدة ثلاثين يومًا. لكن حذار: إن كنت تغيّر ملفاتك دون تغيير أسمائها، فلن يرى الزوار التحديث قبل انتهاء المدة. الأسلم أن تضيف رقم إصدار أو بصمة للاسم عند كل تعديل (مثل app.4f2a9c.js)، وهو ما تفعله أغلب أدوات البناء الحديثة.

الخطوة 8: Nginx كوكيل عكسي لتطبيقك

استخدام شائع جدًا: تشغّل تطبيقك (Node.js أو Python أو غيرهما) على منفذ محلي مثل 3000، ويقف Nginx أمامه ليستقبل الطلبات العامة ويمرّرها له، ويتولى HTTPS والضغط والتخزين المؤقت:

location / {
    proxy_pass http://127.0.0.1:3000;

    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
}

# If your app uses WebSockets, add these inside the same location:
# proxy_http_version 1.1;
# proxy_set_header Upgrade $http_upgrade;
# proxy_set_header Connection "upgrade";

ترويسات X-Forwarded-* تُعلم تطبيقك بعنوان العميل الحقيقي وبروتوكول الاتصال الأصلي، وبدونها سيرى تطبيقك كل الطلبات قادمة من 127.0.0.1. تأكد أن تطبيقك يستمع على 127.0.0.1 فقط لا على كل الواجهات، فلا يكون متاحًا من الخارج متجاوزًا Nginx. وإن ظهر لك خطأ 502 عند الاختبار فالمعنى أن Nginx لم يستطع الوصول لتطبيقك، فتحقق أنه يعمل على المنفذ المحدد.

الخطوة 9: تفعيل HTTPS مع Let's Encrypt

الشهادات المجانية من Let's Encrypt تُصدر وتُجدَّد تلقائيًا بأداة Certbot. قبل أن تبدأ تأكد من ثلاثة أمور: النطاق يشير فعلًا لعنوان خادمك، والمنفذ 80 مفتوح، وserver_name في ملف موقعك يحمل اسم النطاق الصحيح.

# Install Certbot and its Nginx plugin from the Debian repositories
sudo apt install certbot python3-certbot-nginx

# Request and install a certificate (it edits your server block for you)
sudo certbot --nginx -d example.com -d www.example.com

# Test the automatic renewal process without issuing anything
sudo certbot renew --dry-run

# Renewal normally runs from a systemd timer
systemctl list-timers | grep -i certbot

سيسألك Certbot عن بريدك لإشعارات الانتهاء، ثم عن إعادة توجيه HTTP إلى HTTPS، واختيارها مناسب لأغلب المواقع. بعد النجاح، افتح ملف موقعك وراجع ما أضافه Certbot: كتلة جديدة تستمع على المنفذ 443 مع مسارات الشهادة. وتذكر أن لـ Let's Encrypt حدود طلبات لكل نطاق، فجرّب بخيار --dry-run أو --staging قبل التكرار في الإنتاج.

ولا تتسرع في تفعيل ترويسة HSTS (التي تُلزم المتصفح بـ HTTPS مدة طويلة) قبل أن تتأكد أن موقعك كله يعمل جيدًا على HTTPS، لأن التراجع عنها صعب إذا خزّنها المتصفحون. وللإعدادات المتقدمة لبروتوكولات التشفير يوفر موقع Mozilla مولدًا لإعدادات SSL موثوقة.

السجلات واستكشاف الأخطاء

حين لا يعمل شيء، ابدأ دائمًا بالسجلات واختبار الإعداد:

# Syntax check (tells you the file and line of the problem)
sudo nginx -t

# Follow the error log live while you reproduce the problem
sudo tail -f /var/log/nginx/error.log

# Last lines from the service itself
sudo journalctl -u nginx --no-pager -n 50

# Who is listening on ports 80 and 443?
sudo ss -tlnp | grep -E ':80|:443'

# Check permissions on every directory in the path to your file
namei -l /var/www/example.com/html/index.html

ملف الصلاحيات (403) أكثر الأخطاء التي تحيّر المبتدئين: يحتاج المستخدم الذي يشغّل العمال (www-data) صلاحية الدخول (x) على كل مجلد في المسار حتى الملف، لا على الملف وحده. وأمر namei -l يعرض لك صلاحيات كل حلقة في المسار فتكتشف المجلد المانع بسرعة.

الصيانة والتحديثات الأمنية

خادم الويب مكشوف للإنترنت، فتحديثاته الأمنية ليست اختيارية. وتساعدك Debian على أتمتتها للتحديثات الأمنية تحديدًا:

# Manual update routine
sudo apt update && sudo apt upgrade

# Automatic security updates
sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

# Back up your configuration before major changes
sudo tar -czf ~/nginx-config-backup-$(date +%F).tar.gz /etc/nginx

سجلات Nginx تُدوَّر تلقائيًا بأداة logrotate بإعداد جاهز في /etc/logrotate.d/nginx، فلا تمتلئ مساحة القرص بالسجلات القديمة في الأحوال العادية. ومع ذلك راقب مساحة القرص دوريًا، خصوصًا على المواقع كثيرة الزيارات. واحتفظ بملفات الإعداد في نظام تحكم بالإصدارات مثل Git إن كنت تدير عدة خوادم، فهذا يعطيك سجلًا لكل تغيير وإمكانية التراجع.

قائمة تحقق نهائية

• الخدمة تعمل ومفعّلة عند الإقلاع: systemctl status nginx
• الجدار الناري يسمح بـ 22 و80 و443 فقط، وتم اختبار SSH بعد تفعيله
• موقعك في ملف مستقل داخل sites-available ومفعّل برابط رمزي
• الموقع الافتراضي القديم معطّل
• nginx -t يعرض "syntax is ok" و"test is successful"
• شهادة HTTPS صالحة، واختبار certbot renew --dry-run ينجح
• ترويسات الأمان تظهر في الاستجابة: curl -I https://example.com
• نسخة احتياطية من /etc/nginx محفوظة خارج الخادم
• التحديثات الأمنية التلقائية مفعّلة

جدول مرجعي للأوامر

المصادر والتوثيق الرسمي

• الموقع الرسمي لـ Nginx: nginx.org
• دليل المبتدئين الرسمي: nginx.org/en/docs/beginners_guide
• حزم لينكس الرسمية (مستودعات Debian وغيرها): nginx.org/en/linux_packages
• كيفية مطابقة الطلبات لأسماء الخوادم (server_name): nginx.org/en/docs/http/server_names
• توثيق الوحدة الأساسية ngx_http_core_module: nginx.org/en/docs/http/ngx_http_core_module
• دليل التثبيت في توثيق NGINX: docs.nginx.com: Installing NGINX Open Source
• Certbot: certbot.eff.org
• مولد إعدادات SSL من Mozilla: ssl-config.mozilla.org
• دليل تثبيت Nginx على Debian 13 (Linuxize): linuxize.com

أسئلة شائعة

أيهما أفضل: حزمة Debian أم مستودع nginx.org؟
لأغلب المواقع، حزمة Debian كافية وأقل عناءً. اختر nginx.org إن احتجت ميزة موجودة في إصدار أحدث، وتذكر أن هيكل الملفات يختلف (conf.d بدل sites-enabled) وأن الحزمتين تتعارضان.

ما الفرق بين reload وrestart؟
reload يطبق الإعداد الجديد دون قطع الاتصالات الجارية، وrestart يوقف الخدمة ثم يبدؤها فتنقطع الاتصالات. استخدم الأول ما لم تضطر للثاني.

لماذا أرى الصفحة الافتراضية رغم أني أنشأت موقعي؟
غالبًا لأنك لم تفعّل موقعك برابط في sites-enabled، أو لم تعطّل الموقع الافتراضي، أو نسيت reload بعد التغيير. راجع sudo nginx -T لترى ما يقرؤه Nginx فعلًا.

هل أستطيع تشغيل Nginx وApache معًا؟
نعم بشرط ألا يستمعا على المنفذ نفسه. يمكن أن يعمل Apache على منفذ داخلي مثل 8080 ويقف Nginx أمامه كوكيل عكسي، لكن إن لم يكن لديك سبب لذلك فالأبسط اختيار واحد منهما.

كيف أتراجع إن أفسدت الإعداد؟
إن كان الخطأ في ملف موقع، عطّله بحذف رابطه من sites-enabled ثم reload. وإن احتفظت بنسخة من /etc/nginx فاستعدها. ولهذا السبب بالضبط نختبر بـ nginx -t قبل كل تطبيق، فالخادم يستمر بالعمل بالإعداد القديم حتى ينجح الاختبار.