إذا كنت تشغّل WordPress على خادم VPS خاص بك، فإن Apache وNGINX كليهما قادر على تقديم الموقع جيدًا، لكن لكل منهما مفاضلات مختلفة. عادةً ما يكون NGINX الخيار الافتراضي الأفضل مع التزامن العالي وتقديم الملفات الثابتة وHTTP/3 الاختياري. أما Apache فيكون أسهل عندما تعتمد بنية WordPress لديك على .htaccess أو على وحدات خاصة بـ Apache.
تركّز هذه المقارنة بين Apache وNGINX على الفروق التي تهم WordPress: البنية، وطريقة التعامل مع PHP، والتهيئة، وHTTP/3، وما إذا كان تشغيل الاثنين معًا يستحق التعقيد الإضافي. أما LiteSpeed وCaddy فخارج نطاق المقال.
الإجابة المختصرة: على خادم VPS تديره بنفسك لـ WordPress، اختر NGINX افتراضيًا. اختر Apache إذا كان موقعك أو إضافاتك تعتمد بشدة على .htaccess. ولا تشغّل الاثنين معًا إلا عندما تحتاج فعلًا إلى NGINX في المقدمة دون التخلي عن التوافق مع Apache.
ما هو Apache؟
Apache برنامج خادم ويب مفتوح المصدر واسع الانتشار، تطوّره وتصونه المؤسسة الأمريكية غير الربحية Apache Software Foundation (ASF). ويُعرف أيضًا باسم Apache HTTP Server وHTTPD.
صفحة تنزيل Apache تُدرج الإصدار 2.4.68، الصادر في يونيو 2026، بوصفه الإصدار المستقر الحالي.
Apache HTTP Server خادم مفتوح المصدر ذو بنية وحدات، مع دعم ناضج لقواعد .htaccess على مستوى الأدلة، ولعدة وحدات معالجة متعددة (MPM)، وللوكيل العكسي، وإعادة كتابة عناوين URL، وTLS، والوحدات المحمّلة ديناميكيًا. وبالنسبة إلى WordPress، فإن ميزته العملية الأكبر هي توافق التهيئة وليس السرعة الخام.
أهم ميزات Apache في هذه المقارنة هي وحدات MPM من نوع prefork وworker وevent؛ و.htaccess؛ وHTTP/2؛ والوكيل العكسي وموازنة الحمل؛ ودعم FastCGI؛ والوحدات الديناميكية؛ وإعادة كتابة عناوين URL؛ وTLS.
ما هو NGINX؟
NGINX ("engine x") خادم ويب مفتوح المصدر، وهو أيضًا وكيل عكسي، وذاكرة تخزين مؤقت للمحتوى، وموازن حمل، ووكيل TCP/UDP، ووكيل بريد، كتبه في الأصل Igor Sysoev. تستخدم عمليات worker لديه نموذجًا مدفوعًا بالأحداث مصممًا لخدمة عدد كبير من الاتصالات المتزامنة بتكلفة منخفضة لكل اتصال.
صفحة تنزيل NGINX lists the 1.30.x stable branch and the 1.31.x mainline branch.
Apache مقابل NGINX: الفروق الأساسية لـ WordPress
يظهر الفرق بين Apache وNGINX بوضوح في طريقة تعاملهما مع الاتصالات والتهيئة وPHP ودعم البروتوكولات. فسلوك Apache يعتمد بدرجة كبيرة على وحدة MPM التي يشغّلها، بينما يستخدم NGINX عمليات worker مدفوعة بالأحداث.
Apache مقابل NGINX: البنية
يعتمد نموذج معالجة الطلبات في Apache على وحدة MPM التي تشغّلها. فـ prefork قائم على العمليات، بينما يستخدم worker وevent الخيوط. أما NGINX فيستخدم عمليات worker مبنية حول حلقات الأحداث. لذلك فإن المقارنة المألوفة بين "Apache المدفوع بالعمليات وNGINX المدفوع بالأحداث" مبسّطة أكثر من اللازم بالنسبة إلى إعداد Apache 2.4 الحالي.
وحدة event MPM في Apache يمكنها تسليم اتصالات keep-alive الخاملة إلى خيط الاستماع لديها بدل حجز خيط worker لكل اتصال. ولا يزال NGINX عادةً أقل تكلفة لكل اتصال عند أعداد كبيرة جدًا من الاتصالات المتزامنة، لكن الفجوة المعمارية أضيق بكثير مما توحي به المقارنات القديمة من زمن prefork.
Apache مقابل NGINX: الأداء
تظهر ميزة NGINX في الأداء أساسًا مع التزامن العالي وأحمال الملفات الثابتة. إذ تستطيع عمليات worker المدفوعة بالأحداث لديه إبقاء عدد كبير من الاتصالات مفتوحة بتكلفة منخفضة نسبيًا لكل اتصال. أما وحدة event MPM في Apache فتضيّق هذه الفجوة كثيرًا مقارنةً بتهيئات prefork الأقدم.
أما طلبات WordPress الديناميكية فقصة أخرى. إذ يمرّر NGINX عادةً PHP إلى FastCGI، وغالبًا إلى PHP-FPM. ويستطيع Apache أيضًا استخدام PHP-FPM عبر FastCGI، أو تشغيل PHP من خلال وحدة Apache.
بمجرد أن يبدأ PHP في تنفيذ WordPress، قد تصبح شيفرة الإضافات واستعلامات قاعدة البيانات وتخزين الكائنات أو الصفحات مؤقتًا وعدد عمليات worker في PHP أهم من خادم الويب الذي في المقدمة. فإذا كانت إضافة ما تنفّذ عشرات الاستعلامات الثقيلة مع كل طلب، فلن يصلح الانتقال من Apache إلى NGINX المشكلة الأساسية.
Apache مقابل NGINX: دعم HTTP/3 وQUIC
HTTP/3 هو الإصدار الحالي من البروتوكول، وهو يعمل فوق QUIC بدل TCP. وقدرة موقعك على تقديمه أصلًا تعتمد على خادم الويب الموجود في المقدمة، وهذه هي نقطة المقارنة الوحيدة التي لا يتقارب فيها الخادمان.
يوفّر NGINX وحدة HTTP/3 منذ الإصدار 1.25.0. وهي لا تُبنى افتراضيًا، ويحتاج البناء إلى المعامل --with-http_v3_module.
توثيق وحدة HTTP/3 في NGINX لا يزال يصف هذه الوحدة بأنها "experimental, caveat emptor applies".
لا يأتي Apache 2.4 بوحدة أصلية لـ HTTP/3 أو QUIC؛ فدعم البروتوكولات المرفق معه يتوقف عند mod_http2.
النتيجة العملية بالنسبة لصاحب الموقع: تثبيت Apache 2.4 القياسي لا يقدّم HTTP/3. وفي بيئة الإنتاج يبقى الخيار العملي هو إنهاء اتصال HTTP/3 عند وكيل عكسي أو شبكة CDN تدعم HTTP/3 أمام Apache. وإذا كنت تريد هذا البروتوكول، فأحد الخيارات وضع NGINX أمام Apache وترك NGINX ينهي اتصالات العملاء، وهو الترتيب الذي نتناوله لاحقًا.
Apache مقابل NGINX: الأمان
لا يمكن القول إن Apache أو NGINX "أكثر أمانًا" على الإطلاق. فكلاهما مشروع ناضج تجري صيانته أمنيًا بنشاط، وأمان أي نشر إنتاجي يعتمد أكثر على التحديثات الأمنية، والوحدات المفعّلة، وتهيئة TLS، وضوابط الوصول، وحدود المعدل، والتطبيق الذي خلف الخادم.
المقارنة المفيدة تدور حول سطح الهجوم والتهيئة، لا حول فائز مطلق. عطّل الوحدات والنقاط التي لا تحتاج إليها، وأبقِ الخادم محدّثًا أمنيًا، وشدّد بنية WordPress التي خلفه.
Apache مقابل NGINX: التهيئة
ملفات .htaccess على مستوى الأدلة في Apache تعمل متى سمح بها AllowOverride. وهذا مفيد لـ WordPress، لأن قواعد إعادة الكتابة يمكن تغييرها دون تعديل تهيئة الخادم العامة.
لهذه السهولة ثمن. توثيق Apache الرسمي يوصي بوضع القواعد في التهيئة الرئيسية للخادم عندما تملك صلاحية root: فملفات .htaccess تُفحص أثناء الطلبات، وتفعيلها يضيف اعتبارات تتعلق بالأداء والأمان معًا.
لا يوجد في NGINX ما يعادل .htaccess. فتهيئته مركزية، ولذلك لا يستطيع WordPress أن يكتب لك قواعد إعادة كتابة على مستوى الخادم. أما قواعد الروابط الدائمة والتوجيهات الخاصة بالإضافات فيجب أن يضيفها مسؤول النظام إلى تهيئة NGINX ثم يعيد تحميلها.
Apache مقابل NGINX: الوحدات وقابلية التوسيع
يمتلك Apache دعمًا ناضجًا للكائنات المشتركة الديناميكية (DSO): إذ يمكن ترجمة الوحدات على حدة وتحميلها عبر LoadModule. ويدعم NGINX أيضًا الوحدات المحمّلة ديناميكيًا عبر load_module، لكن التوافق الثنائي مع نسخة NGINX المثبتة وتهيئة بنائها يصبح أهم بمجرد استخدامك وحدات طرف ثالث غير قياسية.
لذلك يتفوّق Apache إذا كنت تعتمد على وحدات طرف ثالث غير مألوفة. أما في استضافة WordPress الاعتيادية فعادةً ما يكون هذا الفرق أقل أهمية من .htaccess وطريقة التعامل مع PHP والأدوات التي تستخدمها بالفعل.
Apache مقابل NGINX: دعم المنصات
يعمل Apache على Linux وWindows وmacOS وكثير من الأنظمة الشبيهة بـ Unix. وNGINX متاح أيضًا على المنصات الرئيسية، لكن نسخته الأصلية لـ Windows تعاني قيودًا مهمة. فـ NGINX لا يزال يصف نسخة Windows بأنها تجريبية، ويقول إنه لا ينبغي توقّع أداء عالٍ أو قابلية توسّع، ويشير إلى أن worker واحدًا فقط هو من ينجز العمل فعليًا، ولا يدعم UDP ولا QUIC. ولنشر NGINX في الإنتاج، يبقى نظام تشغيل شبيه بـ Unix هو الخيار العملي.
Apache مقابل NGINX: معالجة الطلبات
يربط Apache عادةً عنوان URL للطلب بمسار في نظام الملفات أسفل DocumentRoot، بينما يستطيع نظام تهيئته أيضًا تطبيق مواقع مبنية على URI وقواعد إعادة كتابة وقواعد وكيل. أما NGINX فيختار أولًا كتلة server ثم كتلة location، اعتمادًا في الأساس على URI الطلب، قبل أن يقرر تقديم ملف أم تمرير الطلب إلى الخادم الخلفي.
يؤثر هذا الفرق في طريقة كتابتك للتهيئة، لكنه بحد ذاته ليس دليلًا على أن NGINX ينقل البيانات أسرع.
مقارنة سريعة بين NGINX وApache
إليك كيف يقف الخادمان في المحاور السابقة، إضافةً إلى دعم البروتوكولات والإصدار الحالي لكل منهما.
| المعيار | Apache | NGINX |
|---|---|---|
| بنية الاتصالات | يعتمد على MPM: prefork أو worker أو event | عمليات worker مدفوعة بالأحداث |
| التزامن العالي والحمل الثابت | منافس عند استخدام event MPM؛ والعبء يتوقف على طبيعة الحمل | تكلفة أقل عادةً لكل اتصال |
| PHP في WordPress | FastCGI مع PHP-FPM، أو وحدة Apache | FastCGI، وغالبًا PHP-FPM |
| .htaccess | نعم، متى سمح AllowOverride بذلك | لا يوجد ما يعادلها |
| الوحدات الديناميكية | دعم ناضج لـ DSO | مدعومة؛ لكن التوافق الثنائي مهم |
| HTTP/3 | لا دعم أصلي ولا مرفق | وحدة تجريبية منذ 1.25.0 |
| Windows | مدعوم | النسخة الأصلية تجريبية ومحدودة |
| الإصدار الحالي | 2.4.68 | Stable 1.30.x; mainline 1.31.x |
استخدام Apache وNGINX معًا
نعم، يمكنك تشغيلهما معًا. يضع التصميم الهجين الشائع NGINX في المقدمة كوكيل عكسي يواجه العملاء، وApache خلفه. يستطيع NGINX إنهاء اتصالات TLS وHTTP/2، كما يستطيع إنهاء HTTP/3 عند بناء وحدته التجريبية الخاصة بـ HTTP/3 وتفعيلها. ويمكنه كذلك تقديم ملفات ثابتة مختارة بنفسه بينما يمرّر طلبات التطبيق إلى Apache.
التحفّظ المهم هنا هو ملكية القواعد. فالطلب الذي يخدمه NGINX مباشرةً لا يصل إلى Apache أبدًا، ولذلك لا تنطبق عليه قواعد .htaccess الخاصة بـ Apache. ويجب أن تتفق التهيئتان على إعادة الكتابة والتخزين المؤقت وتمرير عنوان IP للعميل وسلوك TLS وعلى أي خادم يملك كل مسار.
الثمن أنك صرت تشغّل خادمَي ويب. تهيئتان يجب أن تتوافقا، ودورتا تحديث يجب متابعتهما، وموضع إضافي تبحث فيه عندما يعيد الطلب شيئًا غير متوقع. وعلى موقع صغير واحد، يفوق هذا العبء عادةً الفائدة؛ لكنه يبدأ في الإثمار عندما تريد HTTP/3 أو تقديمًا أسرع للملفات الثابتة دون التخلي عن سلوك .htaccess الذي تعتمد عليه إضافاتك.
هل NGINX أسهل من Apache؟
لا يمكن القول إن أحدهما أسهل في كل الحالات. فـ NGINX أسهل إن كنت تفضّل تهيئة واحدة مركزية ولا تمانع تحرير كتل server. وApache أسهل عندما يتوقع WordPress أو إضافات الطرف الثالث وجود قواعد .htaccess، لأن تلك القواعد تعمل على مستوى الدليل دون تغيير تهيئة الخادم العامة.
على خادم تتحكم فيه، تعود كلمة "أسهل" في الأساس إلى نموذج التهيئة الذي تتوقعه بنيتك التقنية أصلًا.
متى تختار Apache بدل NGINX؟
اختر Apache عندما تعتمد بنية WordPress لديك على .htaccess، أو عندما تتوقع الإضافات أو أدوات لوحة التحكم توجيهات إعادة الكتابة الخاصة بـ Apache، أو عندما تحتاج إلى وحدة Apache بعينها. ومن المعقول أيضًا الإبقاء على Apache في موقع قائم يعمل جيدًا: فتغيير خادم الويب من أجل مكسب نظري في اختبارات الأداء نادرًا ما يستحق ما يصاحبه من اضطراب.
متى تختار NGINX بدل Apache؟
اختر NGINX عندما تتوقع عددًا كبيرًا من الاتصالات المتزامنة، أو تريد طبقة قوية للملفات الثابتة أو للوكيل العكسي، أو تفضّل التهيئة المركزية، أو ترغب في إبقاء خيار تفعيل HTTP/3 مفتوحًا. أما المقابل في WordPress فهو أن قواعد إعادة الكتابة والتوجيهات الخاصة بالإضافات تصبح مهمة مسؤول النظام، لا شيئًا يستطيع WordPress كتابته في .htaccess.
NGINX مقابل Apache: أيهما أنسب لـ WordPress؟
شغّل NGINX. فبالنسبة إلى موقع WordPress على خادم تتحكم فيه، هو الخيار الافتراضي الأفضل: تكلفة اتصال منخفضة عند التزامن العالي، وتقديم فعّال للملفات الثابتة، وHTTP/3 متاح إن أردته.
الاستثناء هو .htaccess، وهو استثناء مهم. فحين يكون .htaccess مفعّلًا يستطيع WordPress كتابة قواعد إعادة الكتابة الخاصة بـ Apache، لكنه لا يستطيع تعديل تهيئة خادم NGINX. وإذا كانت إضافة ما تتوقع توجيهات لإعادة الكتابة أو الأمان أو التخزين المؤقت، فستحتاج إلى تعليماتها الخاصة بـ NGINX أو إلى قاعدة مكافئة داخل كتلة server، ثم إعادة تحميل NGINX. وإن كنت لا تريد هذه المسؤولية التشغيلية، فإن Apache هو الخيار الأسهل مع WordPress. وعلى موقع بحركة زوار عادية، من الأرجح أن يحدّ الأداءَ سلوكُ PHP وقاعدة البيانات والتخزين المؤقت، لا خادم الويب نفسه.
يقوم كل ما سبق على افتراض واحد: أن يكون الخادم ملكك وقابلًا للتغيير. ففي استضافة WordPress المُدارة يقرر مزوّد الخدمة خادم الويب، وتصبح إجابة هذا السؤال ببساطة هي ما يشغّله أصلًا. وهذه المقارنة موجهة إلى من يملك صلاحية root على جهازه الخاص.
أطلق خادم WordPress VPS أسرع بنشر فوري.
احصل على VPS WordPressكيف تعرف إن كنت تشغّل Apache أم NGINX؟
إذا كان هذا خادم VPS الخاص بك، فتحقق من الخدمات العاملة مباشرةً:
systemctl status nginx
systemctl status apache2 # Debian/Ubuntu
systemctl status httpd # RHEL/Fedora-family systemsأما بالنسبة إلى موقع بعيد لا تتحكم فيه، فقد يكون ترويسة الاستجابة HTTP باسم Server دليلًا استرشاديًا، لكنها ليست قاطعة. فقد يعرض وكيل عكسي أو شبكة CDN برنامج الخادم الخاص بها بدل برنامج الخادم الأصلي، كما يمكن إخفاء هذه الترويسة أو تغييرها.
استضافة Apache أو NGINX على خادم VPS
إذا كان الخادم VPS ملكك، فتشغيل أي من الخادمين أمر مباشر. اختر حجم الجهاز بما يناسب بنية WordPress كاملة، لا Apache أو NGINX وحدهما: فعمليات worker في PHP وقاعدة البيانات والتخزين المؤقت وحجم الزيارات والمهام الخلفية تستهلك عادةً موارد أكثر من خادم الويب نفسه.
أيًا كان الخادم الذي تختاره، تبقى التهيئة والتحديثات وTLS والنسخ الاحتياطي والمراقبة مسؤوليتك. وتشغيل الاثنين معًا يضيف تهيئة أخرى ومسار تحديث آخر، لذلك لا تلجأ إلى الإعداد الهجين إلا لسبب محدد.
خادم NGINX VPS من Cloudzy هو خادم Linux VPS تديره بنفسك مع صلاحية root كاملة، ولذلك تبقى تهيئة الخادم بين يديك.
صورة Apache HTTP Server في متجرنا تُثبَّت بالطريقة نفسها بنقرة واحدة، فلا يبدأ تجهيز أي من الخادمين، أو كليهما، بالترجمة من الشيفرة المصدرية.
الأسئلة الشائعة
هل Apache أفضل من NGINX؟
لا أحد منهما أفضل على الإطلاق. فعادةً ما يكون NGINX الخيار الافتراضي الأقوى إن كان يهمّك التزامن العالي أو تقديم الملفات الثابتة أو الوكيل العكسي أو HTTP/3. وعادةً ما يكون Apache أسهل عندما تعتمد بنية WordPress لديك على .htaccess أو على وحدات خاصة بـ Apache.
لماذا NGINX أسرع من Apache؟
يستطيع NGINX معالجة عدد كبير من الاتصالات داخل حلقة الأحداث الخاصة بكل worker، ما يبقي تكلفة الاتصال منخفضة عند التزامن العالي. ووحدة event MPM في Apache تعالج الاتصالات لا تزامنيًا كذلك، ولهذا فالفارق أصغر مما توحي به المقارنات القديمة مع prefork. وفي WordPress قد يكون أثر PHP واستعلامات قاعدة البيانات والتخزين المؤقت أكبر من الفرق بين خادمَي الويب.
هل أستخدم Apache أم NGINX مع WordPress؟
على خادم VPS تديره بنفسك لـ WordPress، يُعد NGINX خيارًا افتراضيًا قويًا إن كنت مرتاحًا لإدارة قواعد كتل server بنفسك. واختر Apache إن كنت تعتمد على .htaccess أو على إضافات تتوقع قواعد إعادة كتابة خاصة بـ Apache وتريدها أن تعمل بأقل قدر من التهيئة اليدوية للخادم.
لماذا يحظى NGINX بهذه الشعبية؟
يجمع NGINX بين معالجة فعّالة للطلبات عند التزامن العالي وبين الوكيل العكسي وموازنة الحمل والتخزين المؤقت ودعم FastCGI وإنهاء اتصالات TLS. وهذا ما يجعله مفيدًا كخادم ويب رئيسي وكوكيل أمامي في آن واحد.
لماذا لا يزال Apache مستخدمًا؟
لا يزال Apache واسع الاستخدام بفضل منظومة وحداته، ودعمه لـ .htaccess، وأدواته الناضجة، ودعمه الواسع للمنصات، وتوافقه مع سير عمل الاستضافة ولوحات التحكم التي بُنيت حوله.
ما الفرق بين Apache وapache2؟
على Debian وUbuntu، يكون apache2 هو اسم الحزمة واسم الخدمة الخاصين بـ Apache HTTP Server. أما أنظمة عائلة RHEL وFedora فتسمّي هذه الخدمة عادةً httpd. وهما ليسا خادمَي ويب مختلفين: كلاهما يشير إلى Apache HTTP Server. والفرع المستقر الحالي من Apache هو 2.4، وآخر إصدار فيه 2.4.68.
هل يدعم Apache بروتوكول HTTP/3؟
ليس بشكل أصلي. فـ Apache HTTP Server 2.4 لا يأتي بوحدة لـ HTTP/3 أو QUIC؛ ودعم البروتوكولات المرفق معه يتوقف عند HTTP/2. وإذا احتجت إلى HTTP/3 في الإنتاج، فيمكنك إنهاؤه عند وكيل عكسي أو شبكة CDN تدعمه أمام Apache.
النقاش
التعليقات
سجّل الدخول للمشاركة في النقاش.