تفاوت Nginx و Apache: چارچوب تصمیم

مقایسهٔ Nginx و Apache اغلب به شعار تبدیل می‌شود: «یکی سریع است، دیگری انعطاف‌پذیر». این مقاله به‌جای شعار، تفاوت‌های مستند را از مستندات رسمی هر دو پروژه (خوانده‌شده ۱۹ اکتبر ۲۰۲۶) بیرون می‌کشد: مدل پردازش، نحوهٔ پیکربندی، .htaccess و رفتار reload. عمداً هیچ عدد benchmark نمی‌آوریم، چون نتیجه به سخت‌افزار، پیکربندی و بار شما بستگی دارد و باید روی خودتان اندازه بگیرید. جدول‌ها و چارچوب تصمیم جمع‌بندی نویسنده‌اند. برای زمینه انتخاب معماری وب‌اپ و انتخاب تکنولوژی را ببینید.

مدل پردازش

مستندات nginx می‌گوید یک master process دارد که پیکربندی را می‌خواند و workerها را نگه می‌دارد، و workerها درخواست‌ها را پردازش می‌کنند؛ مدل مبتنی بر رویداد و سازوکارهای وابسته به سیستم‌عامل برای توزیع درخواست بین workerها به کار می‌رود. تعداد workerها ثابت یا متناسب با هستهٔ پردازنده است.

Apache از طراحی ماژولار می‌آید. مستندات می‌گوید MPMها (Multi-Processing Modules) مسئول اتصال به پورت‌ها، پذیرش درخواست و واگذاری به فرزندان‌اند و همیشه دقیقاً یک MPM بارگذاری می‌شود. سایتی که مقیاس‌پذیری زیاد می‌خواهد می‌تواند MPM رشته‌ای مثل worker یا event را بردارد و سایتی که به پایداری یا سازگاری با نرم‌افزار قدیمی نیاز دارد prefork را. در یونیکس، پیش‌فرض بسته به پشتیبانی سیستم از thread و epoll/kqueue انتخاب می‌شود و مستندات می‌گوید عملاً تقریباً همیشه event است. پس عبارت «Apache هر درخواست را با یک پروسه جواب می‌دهد» برای نسخه‌های جدید با MPM event دقیق نیست؛ باید ببینید سرورتان کدام MPM را دارد.

مدل پیکربندی و .htaccess

در Apache مفهومی به نام .htaccess هست: فایل‌های پیکربندی توزیع‌شده در هر دایرکتوری. مستندات می‌گوید مقدار پیش‌فرض AllowOverride برابر None است و این فایل‌ها نادیده گرفته می‌شوند مگر صریحاً فعال شوند. همچنین توصیه می‌کند اگر به پیکربندی اصلی دسترسی دارید، همه چیز را آنجا بگذارید، چون یک‌بار در شروع بارگذاری می‌شود نه در هر درخواست. با فعال‌بودن .htaccess، httpd در هر دایرکتوری دنبال آن می‌گردد و آن را در هر درخواست می‌خواند. مستندات دو دلیل برای ترجیح پیکربندی اصلی می‌دهد: کارایی و امنیت. کاربرد اصلی .htaccess زمانی است که تولیدکنندهٔ محتوا دسترسی root ندارد، مثل میزبانی مدیریت‌شده، پنل‌هایی مثل cPanel و Plesk، و CMSهایی که فایل .htaccess را همراه خود توزیع می‌کنند.

nginx چنین سازوکار هر دایرکتوری ندارد؛ همه چیز در فایل‌های پیکربندی اصلی است (به‌طور پیش‌فرض nginx.conf در مسیرهایی مثل /etc/nginx). این به معنای کنترل مرکزی و بدون هزینهٔ جست‌وجو در هر درخواست است، ولی یعنی هر تغییر نیاز به دسترسی مدیر و reload دارد. اگر برنامهٔ شما (مثلاً یک CMS قدیمی) قوانین بازنویسی را با .htaccess توزیع می‌کند، در nginx باید آن‌ها را به معادل پیکربندی ترجمه کنید؛ کار دستی و باید آزمون شود.

اعمال تغییر و reload

مستندات nginx می‌گوید با nginx -s reload master ابتدا نحو پیکربندی جدید را بررسی می‌کند؛ اگر موفق بود workerهای جدید را می‌سازد و از workerهای قدیمی می‌خواهد خاموش شوند، و اگر ناموفق بود تغییر را برمی‌گرداند و با پیکربندی قبلی ادامه می‌دهد. workerهای قدیمی اتصال جدید نمی‌پذیرند و درخواست‌های جاری را تمام می‌کنند. این رفتار reload بی‌وقفه را ممکن می‌کند. برای Apache، رفتار reload/graceful را در مستندات نسخهٔ خودتان بخوانید؛ ما آن را در این مقاله بررسی نکردیم و ادعایی نمی‌کنیم.

سناریوها

چارچوب تصمیم

1. برنامهٔ شما چه توزیع می‌کند؟ اگر فایل .htaccess همراه برنامه است، هزینهٔ ترجمه به nginx را حساب کنید.
2. چه کسی پیکربندی را تغییر می‌دهد؟ کاربران بدون root به .htaccess نیاز دارند؛ تیم زیرساخت نه.
3. تجربهٔ تیم: ابزاری که تیم می‌شناسد و می‌تواند عیب‌یابی کند، در بحران ارزشمندتر از تفاوت‌های جزئی است.
4. اندازه‌گیری: با بار نماینده، روی سخت‌افزار خودتان، هر دو را بسنجید. اعداد منابع بیرونی را مبنای تصمیم نکنید.
5. ترکیب: بسیاری از معماری‌ها nginx را جلوی برنامه یا Apache می‌گذارند؛ این یک گزینهٔ معماری است نه الزام، و پیچیدگی عملیاتی دارد.

مهاجرت از یکی به دیگری

اگر از Apache به nginx می‌روید، فهرست قوانین بازنویسی، تنظیمات دسترسی و ماژول‌های فعال را استخراج کنید و هر مورد را به معادل nginx ترجمه و جداگانه آزمون کنید. ابتدا nginx را کنار Apache روی پورت دیگر بالا بیاورید و مقایسهٔ پاسخ‌ها (کد وضعیت، هدرها، ریدایرکت‌ها) را با یک فهرست URL نمونه خودکار کنید. سپس ترافیک را تدریجی منتقل کنید. اگر برنامه به .htaccess متکی است، خروجی نهایی بدون آزمون درخواست‌های واقعی قابل اعتماد نیست. این رویه توصیهٔ عملی نویسنده است و از مستندات رسمی نیامده.

اشتباهات رایج

• تصمیم بر پایهٔ شعار یا benchmark بی‌منبع.
• فرض اینکه Apache همیشه prefork است و بررسی نکردن MPM واقعی.
• فعال‌کردن AllowOverride All برای راحتی و پرداخت هزینهٔ کارایی و امنیت.
• ترجمهٔ ناقص قوانین .htaccess هنگام مهاجرت.
• اعمال پیکربندی بدون بررسی نحو.
• اجرای دو سرور وب بدون دلیل روشن.

مثال ساختگی: دو تیم، دو نتیجه

تیم الف یک سایت وردپرس‌مانند را روی هاست مدیریت‌شده اجرا می‌کند و افزونه‌ها فایل .htaccess می‌نویسند؛ مدیر هاست root ندارد. برای آن‌ها Apache با .htaccess انتخاب طبیعی است و مهاجرت به nginx بی‌دلیل ریسک می‌آورد. تیم ب یک API پایتونی دارد که پشت یک پروکسی با TLS اجرا می‌شود؛ پیکربندی در مخزن است و فقط تیم زیرساخت آن را عوض می‌کند. اینجا نیاز به .htaccess نیست و هر دو وب‌سرور می‌توانند کار کنند؛ انتخاب بر اساس تجربهٔ تیم و نتیجهٔ آزمون بار خودشان انجام می‌شود. دو تیم فرضی‌اند و فقط نشان می‌دهند سؤال درست «کدام برای نیاز من مناسب است» است، نه «کدام بهتر است».

چگونه خودتان اندازه بگیرید

اگر می‌خواهید تصمیم را با عدد بگیرید، آزمایش را خودتان طراحی کنید. بار نماینده بسازید: ترکیبی از درخواست‌های ایستا و پروکسی‌شده به همان برنامه‌ای که واقعاً دارید. هر دو سرور را با پیکربندی بهینهٔ مستندات و روی سخت‌افزار یکسان اجرا کنید، چند بار تکرار کنید و نه فقط میانگین، بلکه توزیع تأخیر و مصرف حافظه را ثبت کنید. تعداد اتصال همزمان، فعال‌بودن keepalive و TLS را ثابت نگه دارید. در گزارش بنویسید نسخه‌ها، پیکربندی و ابزار بار چه بوده تا نتیجه تکرارپذیر باشد. نتیجه فقط برای همان بار و همان محیط معتبر است و نباید آن را به‌عنوان حکم کلی منتشر کرد. اگر تفاوت ناچیز بود، عوامل دیگر مثل تجربهٔ تیم و سهولت عملیات وزن بیشتری پیدا می‌کنند.

چک‌لیست

1. نیاز به .htaccess و دسترسی root مشخص شده است.
2. MPM یا مدل پردازش سرور فعلی شناخته شده است.
3. هر دو گزینه با بار نمایندهٔ شما سنجیده شده‌اند.
4. تجربهٔ تیم و هزینهٔ عیب‌یابی در نظر گرفته شده است.
5. در صورت مهاجرت، فهرست URL نمونه برای مقایسه آماده است.
6. پیکربندی در مخزن و با بازبینی نگه‌داری می‌شود.

منابع و مراجع

• Beginner's Guide (nginx) — nginx documentation، 2026-10-19.
• Multi-Processing Modules (MPMs) — Apache HTTP Server Documentation 2.4، 2026-10-19.
• Apache HTTP Server Tutorial: .htaccess files — Apache HTTP Server Documentation 2.4، 2026-10-19.