إعداد خادم ويب على Linux: Nginx وApache

تُعدّ استضافة موقع أو تطبيق ويب على خادم Linux خاص بك من أكثر تمارين إدارة الأنظمة فائدةً في التعلّم، لأنها تجمع بين إدارة الحزم، وخدمات systemd، والشبكات، وشهادات TLS، والأمان. في هذا الدليل سنُعدّ خادم ويب متكاملاً، بدءاً من التثبيت ووصولاً إلى HTTPS مروراً بالـ reverse proxy، مع تغطية الخادمين المهيمنين على السوق: Nginx وApache. تستخدم الأمثلة Ubuntu/Debian، وتُذكر الفروق مع عائلة Red Hat كلما وُجدت.

1. الاختيار بين Nginx وApache

كلا الخادمين ناضج وعالي الأداء، وقادر تماماً على استضافة أي موقع. غير أن بنيتيهما تختلفان، وهناك سياقات تُفضّل أحدهما على الآخر.

المعيار	Nginx	Apache
البنية	قائمة على الأحداث، غير متزامنة	عمليات/خيوط لكل اتصال (MPM event الحديث)
المحتوى الثابت	ممتاز، باستهلاك ذاكرة ضئيل جداً	جيد
الاتصالات المتزامنة الضخمة	نقطة قوة تاريخية	مقبول مع mpm_event
Reverse proxy / موازنة الحمل	مدمج ويُستخدم بكثرة	ممكن (mod_proxy)
ملفات .htaccess	غير مدعومة	مدعومة (إعداد لكل مجلد)
تنفيذ الشيفرة (PHP…)	يُفوَّض دائماً (FastCGI/PHP-FPM)	وحدات مدمجة ممكنة (mod_php)
صياغة الإعداد	كتل موجزة	توجيهات شبيهة بـ XML، أكثر إسهاباً
حالة الاستخدام النموذجية	Reverse proxy، المحتوى الثابت، التطبيقات الحديثة	الاستضافة المشتركة، الأنظمة القديمة، الحاجة إلى .htaccess

في عام 2026 يكون الخيار الافتراضي لمشروع جديد غالباً هو Nginx: reverse proxy مدمج، وإعداد مختصر، واستهلاك مستقر للذاكرة تحت الأحمال العالية. يبقى Apache لا غنى عنه عندما يحتاج مستخدموك إلى تعديل الإعداد لكل مجلد (.htaccess)، أو للتطبيقات القديمة التي تفترض وجوده. سيعتمد بقية الدليل على Nginx مع ذكر المقابلات في Apache عند الخطوات الأساسية.

2. التثبيت

Nginx

# Debian / Ubuntu
sudo apt update
sudo apt install nginx

# RHEL / Rocky / Alma
sudo dnf install nginx
sudo systemctl enable --now nginx

# التحقق من أن الخدمة تعمل
systemctl status nginx
curl -I http://localhost

Apache

# Debian / Ubuntu (الحزمة والخدمة تُسمّيان apache2)
sudo apt install apache2

# RHEL / Rocky / Alma (الحزمة والخدمة تُسمّيان httpd)
sudo dnf install httpd
sudo systemctl enable --now httpd

لا تنسَ فتح الجدار الناري:

# Ubuntu مع ufw
sudo ufw allow "Nginx Full"

# RHEL مع firewalld
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

3. بنية ملفات الإعداد

Nginx

/etc/nginx/
├── nginx.conf              # الإعداد الرئيسي
├── conf.d/                 # ملفات .conf تُضمَّن تلقائياً
├── sites-available/        # مضيفاتك الافتراضية vhosts (Debian/Ubuntu)
├── sites-enabled/          # روابط رمزية إلى المضيفات الافتراضية المفعّلة
└── snippets/               # مقاطع قابلة لإعادة الاستخدام (SSL، إلخ)

على Debian/Ubuntu نكتب كل موقع في sites-available/ ثم نفعّله عبر رابط رمزي في sites-enabled/. أما على RHEL فهذا العرف غير موجود: ضع ملفاتك مباشرةً في conf.d/.

# تفعيل موقع (Debian/Ubuntu)
sudo ln -s /etc/nginx/sites-available/monsite.conf /etc/nginx/sites-enabled/

# تعطيل موقع: احذف الرابط، وليس الملف المصدر أبداً
sudo rm /etc/nginx/sites-enabled/monsite.conf

Apache

/etc/apache2/                     # Debian/Ubuntu (RHEL : /etc/httpd/)
├── apache2.conf                  # الإعداد الرئيسي
├── sites-available/              # المضيفات الافتراضية المتاحة
├── sites-enabled/                # المضيفات الافتراضية المفعّلة
├── mods-available/               # الوحدات المتاحة
└── mods-enabled/                 # الوحدات المفعّلة

يوفّر Apache أوامر مخصصة للتفعيل:

sudo a2ensite monsite.conf        # تفعيل مضيف افتراضي
sudo a2dissite monsite.conf       # تعطيله
sudo a2enmod rewrite ssl headers  # تفعيل وحدات

4. المضيفات الافتراضية (Virtual Hosts وServer Blocks)

يمكن للخادم الواحد استضافة عدة مواقع، تتميّز بأسماء نطاقاتها. يتحدث Nginx عن «server blocks»، ويتحدث Apache عن «virtual hosts».

Server block كامل في Nginx

# /etc/nginx/sites-available/monsite.conf
server {
    listen 80;
    listen [::]:80;

    server_name monsite.example.com;

    root /var/www/monsite;
    index index.html index.htm;

    # سجلات مخصصة للموقع
    access_log /var/log/nginx/monsite.access.log;
    error_log  /var/log/nginx/monsite.error.log;

    location / {
        # تقديم الملف، وإلا المجلد، وإلا الخطأ 404
        try_files $uri $uri/ =404;
    }

    # منع الوصول إلى الملفات المخفية (.git، .env...)
    location ~ /\. {
        deny all;
    }
}

# إنشاء جذر الموقع وصفحة اختبار
sudo mkdir -p /var/www/monsite
echo "<h1>Bienvenue sur monsite</h1>" | sudo tee /var/www/monsite/index.html
sudo chown -R www-data:www-data /var/www/monsite

# التفعيل وإعادة التحميل
sudo ln -s /etc/nginx/sites-available/monsite.conf /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

المضيف الافتراضي المكافئ في Apache

# /etc/apache2/sites-available/monsite.conf
<VirtualHost *:80>
    ServerName monsite.example.com
    DocumentRoot /var/www/monsite

    ErrorLog ${APACHE_LOG_DIR}/monsite.error.log
    CustomLog ${APACHE_LOG_DIR}/monsite.access.log combined

    <Directory /var/www/monsite>
        Options -Indexes
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

sudo a2ensite monsite.conf
sudo apachectl configtest && sudo systemctl reload apache2

5. HTTPS مع Let’s Encrypt

لم يعد الموقع بدون HTTPS مقبولاً: فالمتصفحات ومحركات البحث تعاقب HTTP. يوفّر Let’s Encrypt شهادات مجانية، ويتولى certbot كل شيء، من تحدّي التحقق إلى التجديد.

# تثبيت certbot مع إضافة Nginx
sudo apt install certbot python3-certbot-nginx
# (Apache : python3-certbot-apache ; RHEL : عبر EPEL)

# الحصول على الشهادة وتعديل الإعداد تلقائياً
sudo certbot --nginx -d monsite.example.com

# التحقق من التجديد التلقائي (مؤقّت systemd)
systemctl list-timers | grep certbot
sudo certbot renew --dry-run

المتطلبات: يجب أن يشير النطاق إلى عنوان IP العام للخادم (سجل DNS من نوع A/AAAA)، ويجب أن يكون المنفذ 80 متاحاً للوصول من أجل تحدّي HTTP-01. يضيف certbot إعادة التوجيه من HTTP إلى HTTPS ويضبط الشهادات في server block الخاص بك:

# مقطع يضيفه certbot في server block
listen 443 ssl;
ssl_certificate     /etc/letsencrypt/live/monsite.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/monsite.example.com/privkey.pem;
include /etc/letsencrypt/options-ssl-nginx.conf;

شهادات Let’s Encrypt صالحة لمدة 90 يوماً، ويجددها مؤقّت systemd الذي تثبّته الحزمة تلقائياً عند اقتراب موعد انتهائها. يكفي أن تتحقق من --dry-run مرة واحدة بعد التثبيت.

6. Reverse Proxy نحو تطبيق

حالة شائعة جداً: يستمع تطبيقك (Node.js أو Python أو Go…) على منفذ محلي، ويتولى Nginx نشره على المنفذ 443 مع إدارة TLS والضغط والسجلات.

# /etc/nginx/sites-available/app.conf
# تجميع الخوادم الخلفية (يتيح موازنة الحمل لاحقاً)
upstream mon_app {
    server 127.0.0.1:3000;
    keepalive 32;
}

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate     /etc/letsencrypt/live/app.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/app.example.com/privkey.pem;

    location / {
        proxy_pass http://mon_app;

        # تمرير معلومات العميل إلى التطبيق
        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;

        # دعم WebSockets
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # مهل زمنية معقولة
        proxy_connect_timeout 5s;
        proxy_read_timeout    60s;
    }
}

ترويسات X-Forwarded-* أساسية: فبدونها يرى تطبيقك أن جميع الطلبات قادمة من 127.0.0.1 ويظن أنه يعمل عبر HTTP. وعلى عائلة Red Hat، انتبه أيضاً إلى قيمة SELinux المنطقية (boolean) التي تسمح لـ Nginx بفتح اتصالات صادرة:

sudo setsebool -P httpd_can_network_connect on

7. ترويسات الأمان

تحمي بعض ترويسات HTTP زوّارك من clickjacking وMIME sniffing والرجوع القسري إلى HTTP. ضعها في server block (أو في snippet تضمّنه جميع مواقعك):

# /etc/nginx/snippets/security-headers.conf
# HSTS : يفرض HTTPS لمدة سنتين (لا تفعّله إلا بعد استقرار HTTPS)
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;

# يمنع تضمين الموقع في iframe تابع لطرف ثالث (clickjacking)
add_header X-Frame-Options "SAMEORIGIN" always;

# يمنع المتصفح من تخمين أنواع MIME
add_header X-Content-Type-Options "nosniff" always;

# يحدّ من معلومات المصدر المرسلة إلى المواقع الخارجية
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

# في كل server block يعمل عبر HTTPS
include snippets/security-headers.conf;

أضف Content-Security-Policy مناسبة لموقعك عندما تعرف بدقة مصادر السكربتات والأنماط فيه: فهي الترويسة الأكثر فعالية، لكن الضبط الصارم أكثر من اللازم يُعطّل الموقع. اختبر إعدادك على securityheaders.com، واختبر جزء TLS على ssllabs.com.

أخفِ أيضاً إصدار الخادم، فهو معلومة لا فائدة من تقديمها للماسحات الضوئية (scanners):

# داخل http {} في /etc/nginx/nginx.conf
server_tokens off;

8. السجلات والتدوير

قراءة السجلات

# متابعة الحركة في الوقت الفعلي
sudo tail -f /var/log/nginx/access.log

# متابعة الأخطاء
sudo tail -f /var/log/nginx/error.log

# أكثر 10 عناوين IP نشاطاً
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head

# عدّ رموز الاستجابة
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn

التدوير باستخدام logrotate

تثبّت حزمتا Nginx وApache إعداد logrotate مسبقاً؛ تحقق منه وكيّف مدة الاحتفاظ بحسب احتياجاتك:

# /etc/logrotate.d/nginx (توفره الحزمة، مقطع)
/var/log/nginx/*.log {
    daily              # تدوير يومي
    rotate 14          # الاحتفاظ بـ 14 أرشيفاً
    compress           # ضغط الأرشيفات
    delaycompress      # باستثناء الأحدث
    notifempty
    sharedscripts
    postrotate
        invoke-rc.d nginx rotate >/dev/null 2>&1
    endscript
}

# الاختبار دون انتظار الليل
sudo logrotate -d /etc/logrotate.d/nginx

إذا أنشأت سجلات لكل موقع كما في أمثلتنا، فإن النمط *.log يغطيها تلقائياً.

9. الاختبار وإعادة التحميل دون انقطاع

عادة يجب ترسيخها نهائياً: لا تُعد تشغيل خادم ويب أبداً دون التحقق من الإعداد، وفضّل دائماً إعادة التحميل على إعادة التشغيل.

# 1. التحقق من الصياغة وتماسك الإعداد
sudo nginx -t
# Apache : sudo apachectl configtest

# 2. إعادة التحميل: تُنهي عمليات workers طلباتها الجارية،
#    وتبدأ عمليات workers جديدة بالإعداد الجديد.
#    لا ينقطع أي اتصال.
sudo systemctl reload nginx

# في سطر واحد، إعادة التحميل مشروطة بنجاح الاختبار
sudo nginx -t && sudo systemctl reload nginx

يقطع systemctl restart الاتصالات الجارية بشكل مفاجئ؛ فاحتفظ به للحالات التي لا تكفي فيها إعادة التحميل (تغيير منافذ الاستماع، تحديث الملف التنفيذي).

10. التحسينات الأساسية

ضغط gzip

# داخل http {} في /etc/nginx/nginx.conf
gzip on;
gzip_comp_level 5;              # توازن جيد بين المعالج والحجم
gzip_min_length 256;            # لا فائدة دون 256 بايت
gzip_types text/plain text/css application/json application/javascript
           application/xml image/svg+xml;
# صور JPEG/PNG/WebP مضغوطة أصلاً: لا تدرجها

التخزين المؤقت للملفات الثابتة

اطلب من المتصفحات الاحتفاظ طويلاً بالموارد التي لا تتغير:

# في server block
location ~* \.(css|js|jpg|jpeg|png|webp|svg|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, immutable";
    access_log off;             # يخفف أيضاً حجم السجلات
}

تفترض هذه الاستراتيجية أن ملفاتك تتغير أسماؤها مع كل إصدار (تجزئة hash في الاسم، وهو ما تفعله جميع أدوات التجميع bundlers الحديثة). وإلا فقلّل المدة.

عمليات workers

# في /etc/nginx/nginx.conf
worker_processes auto;          # عملية worker لكل نواة معالج: الضبط الصحيح

events {
    worker_connections 1024;    # اتصالات متزامنة لكل worker
}

القيمة auto هي الافتراضية في الحزم الحديثة وتناسب الغالبية العظمى من الحالات. لا تزد worker_connections إلا إذا أظهرت سجلاتك بلوغ الحد، وفكّر حينها في حد واصفات الملفات (worker_rlimit_nofile).

أفضل الممارسات

• ملف إعداد واحد لكل موقع، يُفعَّل برابط رمزي؛ ولا تعدّل الملفات التي توفرها الحزمة.
• تحقق باستخدام nginx -t أو apachectl configtest قبل كل إعادة تحميل، ويفضّل ذلك في سطر الأوامر نفسه.
• فضّل reload على restart: بلا أي انقطاع لزوّارك.
• HTTPS في كل مكان، مع إعادة توجيه HTTP إلى HTTPS، وتنفيذ certbot renew --dry-run بعد التثبيت للتحقق من التجديد التلقائي.
• أضف ترويسات الأمان في snippet مشترك واختبر النتيجة على securityheaders.com.
• سجلات مخصصة لكل موقع، وتدوير مُتحقَّق منه، ومراقبة منتظمة لـ error.log.
• خلف reverse proxy، مرّر دائماً Host وX-Forwarded-For وX-Forwarded-Proto إلى التطبيق.
• انسخ احتياطياً /etc/nginx (أو /etc/apache2) و/etc/letsencrypt: فإعداد خادم الويب يُعاد بناؤه في دقائق عندما يكون خاضعاً للتحكم في الإصدارات.

الخلاصة

أصبح لديك الآن خادم ويب متكامل: مواقع متعددة عبر المضيفات الافتراضية، وHTTPS تلقائي مع Let’s Encrypt، وreverse proxy نحو تطبيقاتك، وترويسات أمان، وسجلات تحت السيطرة، وتحسينات أساسية. Nginx وApache برمجيتان على درجة لافتة من الموثوقية: فإذا أُعدّتا جيداً عملتا سنوات دون تدخل. أما الخطوات التالية في مسارك فهي: موازنة الحمل بين عدة خوادم خلفية، والتخزين المؤقت باستخدام proxy_cache، وتحديد المعدل (limit_req) للتصدي لإساءة الاستخدام، وأتمتة هذا الإعداد كله باستخدام Ansible أو Terraform لإعادة بناء خادمك بأمر واحد.