دليل NGINX للمبتدئين: تعلّم إعداد خادم الويب والوكيل العكسي وتحسين الأداء

Updated يونيو 9, 2026 8 min read

Aldawsari

دقائق القراءة: 8

يُعد NGINX واحداً من أشهر خوادم الويب الحديثة، وقد صُمم أساساً لمعالجة أعداد كبيرة من الاتصالات المتزامنة بكفاءة عالية واستهلاك منخفض للموارد. في هذا الدليل العملي، ستتعرّف إلى أساسياته، وطريقة تثبيته، وآلية كتابة ملفاته الإعدادية، وكيفية استخدامه كخادم ويب، ووكيل عكسي، وموازن حمل، مع مجموعة من أفضل ممارسات الأداء.

غلاف دليل NGINX للمبتدئين لتعلّم إعداد خادم الويب والوكيل العكسي

بدأت قصة NGINX عندما واجه المطور الروسي Igor Sysoev مشكلة معروفة باسم C10k، وهي صعوبة الخوادم القديمة في التعامل مع أكثر من عشرة آلاف طلب متزامن. ومن هنا وُلد مشروع يركّز على الأداء العالي، والتعامل غير المتزامن مع الطلبات، والقدرة على خدمة المواقع بكفاءة حتى تحت الضغط.

المشكلة التي يقع فيها كثير من المبتدئين اليوم ليست في صعوبة NGINX بحد ذاته، بل في نسخ ملفات إعداد جاهزة دون فهمها. هذا الأسلوب قد ينجح مؤقتاً، لكنه يسبب مشكلات عند الحاجة إلى التخصيص أو التوسّع أو تحسين الأمان والأداء. لذلك يركّز هذا المقال على الفهم، لا الحفظ.

صورة توضيحية تعبّر عن أن تعلّم NGINX ليس معقداً كما يظن المبتدئون

لماذا يُعد `NGINX` خياراً ممتازاً؟

يشتهر NGINX بكونه خفيفاً وسريعاً، خصوصاً عند تقديم الملفات الثابتة مثل HTML وCSS وJavaScript والصور. كما أنه يعمل بكفاءة عالية كوكيل عكسي Reverse Proxy أمام تطبيقات مثل Node.js وPHP-FPM.

أداء مرتفع مع أعداد كبيرة من الاتصالات.
استهلاك منخفض للذاكرة والموارد.
سهولة بناء بيئات متعددة المواقع Virtual Hosts.
مرونة كبيرة في إعادة التوجيه وإعادة كتابة الروابط.
دعم مدمج لموازنة الحمل، والتخزين المؤقت، والضغط، وSSL وHTTP/2.

المتطلبات قبل البدء

قبل العمل مع NGINX، من الأفضل أن تكون لديك معرفة أساسية بالطرفية في Linux وبعض الأوامر الشائعة مثل ls وcat وps وgrep وfind وnproc وulimit وnano.

كما يُفضّل أن يتوفر لديك أحد الخيارين:

آلة افتراضية محلية باستخدام Vagrant وVirtualBox.
خادم افتراضي خاص VPS لاختبار الإعدادات على بيئة أقرب إلى الإنتاج.

ما الذي ستتعلّمه في هذا الدليل؟

تثبيت NGINX على Ubuntu.
فهم بنية ملفات الإعداد.
إنشاء خادم ويب ثابت من الصفر.
التعامل مع location والمتغيرات وrewrite وtry_files.
استخدام NGINX كوكيل عكسي مع Node.js وPHP.
بناء إعداد بسيط لموازنة الحمل.
تحسين الأداء عبر العمليات العاملة والتخزين المؤقت والضغط.
تفعيل SSL وHTTP/2.

تثبيت `NGINX` على `Ubuntu`

بعد تسجيل الدخول إلى الخادم أو الآلة الافتراضية، ابدأ بتحديث النظام:

sudo apt update && sudo apt upgrade -y

ثم ثبّت NGINX بالأمر التالي:

sudo apt install nginx -y

للتحقق من أن الخدمة تعمل:

sudo systemctl status nginx

إذا لم تكن الخدمة تعمل، يمكنك تشغيلها عبر:

sudo systemctl start nginx

عند زيارة عنوان الخادم في المتصفح، يفترض أن تظهر صفحة الترحيب الافتراضية الخاصة بـ NGINX.

صفحة الترحيب الافتراضية بعد تثبيت NGINX بنجاح على الخادم

أين توجد ملفات إعداد `NGINX`؟

غالباً ما توجد ملفات الإعداد داخل المسار /etc/nginx. الملف الأهم هو nginx.conf، وهو الملف الرئيسي الذي يحمّل بقية الملفات والإعدادات.

cd /etc/nginx
ls -lh

ومن العناصر الشائعة داخل هذا المجلد:

nginx.conf: الملف الرئيسي.
mime.types: أنواع الملفات وامتداداتها.
sites-available: ملفات إعداد المواقع.
sites-enabled: الروابط الرمزية للمواقع المفعّلة.
conf.d: ملفات إعداد إضافية.

فهم البنية الأساسية لملفات الإعداد

تعتمد صياغة NGINX على مفهومين أساسيين:

1) التوجيهات `Directives`

وهي الأوامر التي تكتبها داخل ملف الإعداد، مثل listen وserver_name وroot.

2) السياقات `Contexts`

وهي كتل تحتوي توجيهات أخرى، مثل events وhttp وserver وlocation.

مثال مبسط:

events { }

http {
    server {
        listen 80;
        server_name nginx-handbook.test;
        return 200 "Hello from NGINX\n";
    }
}

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

اختبار الإعدادات وإعادة تحميلها

بعد أي تعديل، يجب أولاً فحص صحة الصياغة:

sudo nginx -t

ثم إعادة تحميل الإعدادات دون إيقاف الخدمة:

sudo nginx -s reload

وهذه خطوة مهمة جداً، لأن NGINX لا يطبّق التعديلات تلقائياً بمجرد حفظ الملف.

إنشاء خادم ويب ثابت `Static Web Server`

إذا أردت تقديم ملفات ثابتة من مجلد معين، يمكنك استخدام التوجيه root:

events { }

http {
    include /etc/nginx/mime.types;

    server {
        listen 80;
        server_name nginx-handbook.test;
        root /srv/nginx-handbook-projects/static-demo;
    }
}

هنا سيبحث NGINX عن الملفات داخل المجلد المحدد، وسيقدّم ملف index.html تلقائياً إذا كان موجوداً.

أهمية ملف `mime.types`

إذا لم تضمّن ملف mime.types، فقد يتعامل NGINX مع بعض الملفات على أنها نص عادي بدلاً من نوعها الصحيح، مثل تقديم ملف CSS بوصفه text/plain. لذلك فإن السطر include /etc/nginx/mime.types; أساسي في معظم المشاريع.

مثال لموقع ثابت يعمل بشكل صحيح بعد ضبط أنواع الملفات في NGINX

آلية المطابقة باستخدام `location`

يُستخدم السياق location لتحديد كيفية التعامل مع مسارات معينة داخل الموقع.

مطابقة بادئة `Prefix Match`

location /agatha {
    return 200 "Miss Marple.\nHercule Poirot.\n";
}

أي مسار يبدأ بـ /agatha سيطابق هذا البلوك.

مطابقة تامة `Exact Match`

location = /agatha {
    return 200 "Exact match\n";
}

هنا لا تتم المطابقة إلا إذا كان المسار مطابقاً تماماً.

مطابقة بالتعابير النمطية `Regex Match`

location ~ /agatha[0-9] {
    return 200 "Regex match\n";
}

ويمكن استخدام ~* لجعل المطابقة غير حساسة لحالة الأحرف.

المتغيرات داخل `NGINX`

يدعم NGINX متغيرات مدمجة مثل $host و$uri و$args. ويمكن الاستفادة منها في الردود أو التوجيهات:

server {
    listen 80;
    server_name nginx-handbook.test;

    return 200 "Host - $host\nURI - $uri\nArgs - $args\n";
}

كما يمكنك إنشاء متغيرات جديدة باستخدام set:

set $name $arg_name;
return 200 "Name - $name\n";

في هذا المثال، تُقرأ قيمة name من سلسلة الاستعلام Query String.

إعادة التوجيه وإعادة كتابة الروابط

إعادة التوجيه `Redirect`

إذا أردت تحويل المستخدم إلى عنوان آخر بشكل واضح في المتصفح:

location = /about_page {
    return 307 /about.html;
}

سيتم تحديث الرابط الظاهر للمستخدم.

إعادة الكتابة `Rewrite`

أما إذا أردت تغيير المسار داخلياً دون تغيير الرابط الظاهر:

rewrite /about_page /about.html;

تُستخدم هذه التقنية كثيراً في التطبيقات التي تحتاج إلى مسارات نظيفة أو توافق مع أطر العمل.

مثال يوضح عمل إعادة كتابة الروابط في NGINX دون تغيير الرابط الظاهر للمستخدم

استخدام `try_files` بذكاء

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

try_files $uri $uri/ /not_found;

في هذا المثال، يحاول NGINX أولاً الوصول إلى الملف المطلوب، ثم إلى مجلد يحمل الاسم نفسه، ثم ينتقل إلى المسار البديل إذا لم يجد شيئاً.

location /not_found {
    return 404 "الملف المطلوب غير موجود\n";
}

هذا النمط مفيد جداً في مواقع SPA أو المواقع الثابتة التي تعتمد على مسارات متعددة.

السجلات `Logs` في `NGINX`

توجد سجلات الوصول والأخطاء غالباً داخل المسار /var/log/nginx:

ls -lh /var/log/nginx/

وأهم ملفين هما:

access.log: يسجل الطلبات الواردة.
error.log: يسجل الأخطاء والمشكلات.

يمكن تخصيص سجل الوصول لمسار معين أو تعطيله:

location = /admin {
    access_log /var/log/nginx/admin.log;
    return 200 "admin\n";
}

location = /no_logging {
    access_log off;
    return 200 "no log\n";
}

كما يمكن تحديد الحد الأدنى لمستوى الأخطاء في error_log، مثل warn أو error أو emerg.

استخدام `NGINX` كوكيل عكسي `Reverse Proxy`

عند تشغيل تطبيق خلفي مثل Node.js على منفذ داخلي، يمكن لـ NGINX استقبال الطلبات من الإنترنت وتمريرها إلى التطبيق ثم إعادة الاستجابة للعميل.

server {
    listen 80;
    server_name nginx-handbook.test;

    location / {
        proxy_pass http://localhost:3000;
    }
}

هذه البنية مثالية لعزل التطبيق عن الإنترنت المباشر، وتحسين الأمان، وتسهيل إضافة التخزين المؤقت والضغط وSSL.

إعداد `WebSocket`

إذا كان التطبيق يستخدم WebSocket، فأضف التوجيهات التالية:

location / {
    proxy_pass http://localhost:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
}

تشغيل تطبيق `PHP` مع `NGINX`

في بيئات PHP يُستخدم عادة PHP-FPM بدل تمرير الطلبات عبر HTTP المباشر. مثال عملي:

user www-data;

events { }

http {
    include /etc/nginx/mime.types;

    server {
        listen 80;
        server_name nginx-handbook.test;
        root /srv/nginx-handbook-projects/php-demo;
        index index.php;

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

        location ~ \.php$ {
            fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
            fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
            include /etc/nginx/fastcgi_params;
        }
    }
}

هذا الإعداد يجعل NGINX يمرر ملفات PHP إلى PHP-FPM عبر Unix Socket، وهي طريقة شائعة وأكثر أماناً من بعض البدائل.

موازنة الحمل `Load Balancing`

إذا كان لديك أكثر من خادم خلفي للتطبيق نفسه، يمكنك تجميعها داخل كتلة upstream:

events { }

http {
    upstream backend_servers {
        server localhost:3001;
        server localhost:3002;
        server localhost:3003;
    }

    server {
        listen 80;
        server_name nginx-handbook.test;

        location / {
            proxy_pass http://backend_servers;
        }
    }
}

بهذه الطريقة يوزّع NGINX الطلبات بين الخوادم الخلفية، ما يحسن الاستقرار وقابلية التوسع.

تحسين أداء `NGINX`

ضبط `worker_processes` و`worker_connections`

تعتمد كفاءة NGINX بشكل كبير على عدد العمليات العاملة والاتصالات المتاحة لكل عملية.

worker_processes auto;

events {
    worker_connections 1024;
}

القيمة auto تجعل NGINX يضبط عدد العمليات بناءً على عدد أنوية المعالج، وهو خيار عملي في أغلب الحالات.

يمكن معرفة عدد الأنوية عبر:

nproc

ومعرفة الحد الأقصى للملفات المفتوحة عبر:

ulimit -n

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

من أفضل الممارسات تعيين ترويسات تخزين مؤقت للصور والملفات الثابتة:

location ~* \.(css|js|jpg)$ {
    access_log off;
    add_header Cache-Control public;
    add_header Pragma public;
    add_header Vary Accept-Encoding;
    expires 1M;
}

هذا يقلل عدد الطلبات المتكررة ويخفف الضغط على الخادم ويحسن سرعة التصفح.

ضغط الاستجابات باستخدام `GZIP`

gzip on;
gzip_comp_level 3;
gzip_types text/css text/javascript application/json;

يساعد الضغط على تقليل حجم الملفات النصية بشكل ملحوظ، خصوصاً ملفات التنسيق والبرمجيات النصية وواجهات JSON.

عند اختبار الاستجابة المضغوطة:

curl -I -H "Accept-Encoding: gzip" http://nginx-handbook.test/mini.min.css

إذا ظهر الرأس Content-Encoding: gzip فهذا يعني أن الضغط يعمل بشكل صحيح.

تنظيم إعدادات المواقع بطريقة احترافية

في الأنظمة المبنية على Debian وUbuntu، يُفضّل عدم تعديل الملف الرئيسي nginx.conf لكل موقع، بل استخدام:

/etc/nginx/sites-available لحفظ ملفات المواقع.
/etc/nginx/sites-enabled لتفعيلها بروابط رمزية.

مثال على ملف موقع داخل sites-available:

server {
    listen 80;
    server_name nginx-handbook.test;
    root /srv/nginx-handbook-projects/static-demo;
}

ثم تفعيله عبر:

sudo ln -s /etc/nginx/sites-available/nginx-handbook /etc/nginx/sites-enabled/nginx-handbook

هذه الآلية تسهّل إدارة أكثر من موقع، وتقلل الفوضى داخل الملف الرئيسي.

تفعيل `SSL` باستخدام `Certbot`

لتمكين HTTPS، تحتاج إلى شهادة SSL صالحة. واحدة من أسهل الطرق هي استخدام Let's Encrypt مع أداة Certbot.

snap install --classic certbot
certbot --nginx

بعد تنفيذ الأداة واتباع الخطوات، سيُضاف إعداد الشهادة تلقائياً إلى ملف الموقع، مع إعادة توجيه طلبات HTTP إلى HTTPS.

موقع يعمل عبر HTTPS بعد تثبيت شهادة SSL باستخدام Certbot مع NGINX

وللتحقق من التجديد التلقائي:

certbot renew --dry-run

تفعيل `HTTP/2`

بعد تثبيت شهادة SSL، يمكنك تفعيل HTTP/2 بسهولة عبر تعديل أسطر الاستماع:

listen 443 ssl http2;
listen [::]:443 ssl http2 ipv6only=on;

ثم اختبر الإعداد وأعد تحميله:

nginx -t
nginx -s reload

يمكن التأكد من عمل البروتوكول عبر:

curl -I -L https://your-domain.com

إذا ظهرت الاستجابة بصيغة HTTP/2 200 فهذا يعني أن التفعيل تم بنجاح.

ميزة `Server Push` في `HTTP/2`

من ميزات HTTP/2 القدرة على إرسال بعض الموارد المرتبطة بالصفحة تلقائياً قبل أن يطلبها المتصفح صراحةً.

location = /index.html {
    http2_push /mini.min.css;
    http2_push /the-nginx-handbook.jpg;
}

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

رسم توضيحي لآلية Server Push في HTTP/2 عند استخدام NGINX

أخطاء شائعة يجب تجنبها

نسخ ملفات إعداد جاهزة دون فهم كل توجيه.
تعديل الإعدادات دون تنفيذ nginx -t قبل إعادة التحميل.
نسيان تضمين mime.types في الخوادم التي تقدّم ملفات ثابتة.
الخلط بين redirect وrewrite.
إهمال مراجعة error.log عند ظهور خطأ 500 أو فشل التحميل.
تشغيل تطبيقات خلفية مباشرة على الإنترنت دون وكيل عكسي.

أفضل ممارسات سريعة للاعتماد الإنتاجي

استخدم ملفات منفصلة لكل موقع داخل sites-available.
اختبر الإعدادات دائماً قبل إعادة التحميل.
فعّل HTTPS بشكل افتراضي لكل موقع عام.
أضف التخزين المؤقت والضغط للملفات الثابتة.
راقب السجلات باستمرار، خاصة بعد التعديلات.
لا تعتمد على إعداد واحد لكل التطبيقات؛ اضبط NGINX بحسب نوع التطبيق والموارد المتاحة.

مرجع مشروع الأمثلة

يمكن العثور على مشاريع الأمثلة المستخدمة في الشرح داخل المستودع التالي:

https://github.com/fhsinchy/nginx-handbook-projects

الخلاصة التقنية

NGINX ليس مجرد خادم ويب سريع، بل منصة متكاملة لإدارة حركة المرور وتقديم المحتوى وتشغيل التطبيقات بكفاءة عالية. القيمة الحقيقية لا تكمن في حفظ التوجيهات، بل في فهم منطقها: كيف تُطابق الطلبات، وكيف تُمرّر إلى الخلفية، وكيف تُحسَّن الاستجابات من ناحية الأداء والأمان. إذا أتقنت الأساسيات مثل server وlocation وproxy_pass وtry_files، فستمتلك قاعدة قوية تمكّنك من بناء إعدادات احترافية قابلة للتوسع والصيانة.

لماذا يُعد NGINX خياراً ممتازاً؟

المتطلبات قبل البدء

ما الذي ستتعلّمه في هذا الدليل؟

تثبيت NGINX على Ubuntu

أين توجد ملفات إعداد NGINX؟

فهم البنية الأساسية لملفات الإعداد

1) التوجيهات Directives

2) السياقات Contexts

اختبار الإعدادات وإعادة تحميلها

إنشاء خادم ويب ثابت Static Web Server

أهمية ملف mime.types

آلية المطابقة باستخدام location

مطابقة بادئة Prefix Match

مطابقة تامة Exact Match

مطابقة بالتعابير النمطية Regex Match

المتغيرات داخل NGINX

إعادة التوجيه وإعادة كتابة الروابط

إعادة التوجيه Redirect

إعادة الكتابة Rewrite

استخدام try_files بذكاء

السجلات Logs في NGINX

استخدام NGINX كوكيل عكسي Reverse Proxy

إعداد WebSocket

تشغيل تطبيق PHP مع NGINX

موازنة الحمل Load Balancing

تحسين أداء NGINX

ضبط worker_processes وworker_connections