راه‌اندازی Varnish Cache برای افزایش سرعت سایت روی سرور مجازی و اختصاصی

وقتی ترافیک یک سایت بالا می‌رود، معمولاً اولین جایی که زیر بار می‌رود بک‌اند است؛ نه شبکه، نه دیسک. هر بار که PHP یا Node.js باید همان صفحه ثابت را از نو رندر کند یا همان کوئری را به دیتابیس بزند، منابع سرور صرف کاری می‌شود که نتیجه‌اش از قبل مشخص است. راه‌اندازی Varnish Cache دقیقاً همین مشکل را حل می‌کند: یک لایه کش بین کاربر و بک‌اند قرار می‌گیرد و پاسخ‌های تکراری را مستقیماً از حافظه تحویل می‌دهد.

این مقاله نصب و پیکربندی Varnish Cache را روی سرور مجازی و اختصاصی لینوکسی مرحله‌به‌مرحله توضیح می‌دهد؛ از نصب پکیج تا تنظیم فایل VCL و تست واقعی عملکرد با varnishlog.

Varnish Cache چیست و چرا سرعت سایت را افزایش می‌دهد؟

Varnish یک HTTP accelerator یا reverse proxy کش است. به‌جای اینکه هر درخواست مستقیماً به Nginx یا Apache برسد، اول به Varnish می‌رسد. اگر پاسخ آن درخواست قبلاً در حافظه RAM ذخیره شده باشد، Varnish بدون تماس با بک‌اند همان پاسخ را برمی‌گرداند.

نتیجه این مدل دو چیز است: زمان پاسخ به چند میلی‌ثانیه کاهش پیدا می‌کند و بار واقعی روی وب‌سرور و دیتابیس کم می‌شود، چون بخش زیادی از درخواست‌ها اصلاً به آن‌ها نمی‌رسد. برای سایت‌های با ترافیک خوانش بالا — وبلاگ، فروشگاه با صفحات محصول پرتکرار، سایت خبری — این تفاوت در عمل قابل اندازه‌گیری است. اگر بخشی از این ترافیک از کاربران جغرافیایی پراکنده می‌آید، CDN هم می‌تواند مکمل Varnish باشد؛ این دو در لایه‌های متفاوتی کار می‌کنند و با هم تداخلی ندارند.

نکته مهم این است که Varnish همه‌چیز را کش نمی‌کند. صفحاتی با کوکی session، فرم‌های پرداخت یا محتوای اختصاصی هر کاربر باید از مسیر کش خارج شوند؛ این دقیقاً همان چیزی است که در فایل VCL تنظیم می‌شود.

پیش‌نیازهای نصب Varnish روی سرور مجازی یا اختصاصی

قبل از نصب، چند نکته باید روشن باشد:

• دسترسی root یا sudo روی سرور مجازی یا اختصاصی لینوکسی (Ubuntu، Debian، CentOS یا AlmaLinux).
• وب‌سرور فعلی (Nginx یا Apache) باید روی پورتی غیر از ۸۰ گوش بدهد، چون پورت ۸۰ را Varnish در اختیار می‌گیرد. معمولاً پورت ۸۰۸۰ برای این کار انتخاب می‌شود.
• اگر سایت روی HTTPS کار می‌کند — مثلاً با گواهی رایگان Let's Encrypt — SSL همچنان باید جلوی Varnish (مثلاً با Nginx یا HAProxy به‌عنوان SSL terminator) یا با افزونه hitch مدیریت شود؛ Varnish به‌تنهایی TLS را ترمینیت نمی‌کند.
• یک بک‌آپ یا snapshot از وضعیت فعلی سرور قبل از تغییر پیکربندی وب‌سرور همیشه ایده خوبی است.

نصب Varnish Cache روی لینوکس

نصب روی Ubuntu و Debian

مخزن پکیج‌های رسمی اوبونتو و دبیان نسخه پایدار Varnish را دارد:

sudo apt update
sudo apt install varnish -y

نصب روی CentOS، RHEL و AlmaLinux

روی توزیع‌های خانواده RHEL، Varnish از طریق مخزن EPEL یا مخزن رسمی خودش نصب می‌شود:

sudo dnf install epel-release -y
sudo dnf install varnish -y

بعد از نصب، وضعیت سرویس را بررسی کنید:

sudo systemctl status varnish

پیکربندی فایل VCL برای Varnish

مغز تنظیمات Varnish در فایل /etc/varnish/default.vcl قرار دارد و با زبان VCL (Varnish Configuration Language) نوشته می‌شود. اولین کاری که باید انجام شود، معرفی آدرس و پورت بک‌اند واقعی (وب‌سرور) است:

vcl 4.1;

backend default {
    .host = "127.0.0.1";
    .port = "8080";
}

sub vcl_recv {
    # کوکی‌ها معمولاً باعث می‌شوند Varnish پاسخ را کش نکند؛
    # برای صفحات عمومی که session ندارند حذفش می‌کنیم
    if (req.http.Cookie && req.url !~ "^/(wp-admin|wp-login|checkout|cart)") {
        unset req.http.Cookie;
    }
}

sub vcl_backend_response {
    set beresp.ttl = 6h;
    set beresp.grace = 1h;
}

sub vcl_deliver {
    if (obj.hits > 0) {
        set resp.http.X-Cache = "HIT";
    } else {
        set resp.http.X-Cache = "MISS";
    }
}

در این تنظیم، backend به پورت ۸۰۸۰ (همان پورتی که وب‌سرور واقعی روی آن گوش می‌دهد) اشاره می‌کند. بخش vcl_recv کوکی را برای مسیرهای عمومی حذف می‌کند تا آن صفحات قابل کش شدن باشند، ولی مسیرهای حساس مثل ورود یا پرداخت را از این قاعده استثنا می‌کند. beresp.ttl مدت زمان نگه‌داری پاسخ در کش را تعیین می‌کند؛ این مقدار باید متناسب با سرعت تغییر محتوای سایت تنظیم شود، نه یک عدد ثابت برای همه پروژه‌ها.

هماهنگ کردن Nginx یا Apache با Varnish

برای اینکه Varnish پورت ۸۰ را بگیرد و درخواست کاربر را اول دریافت کند، باید وب‌سرور را به پورت دیگری منتقل کرد.

در Nginx کافی است در فایل تنظیمات سایت، listen 80; را به listen 8080; تغییر دهید. در Apache، در فایل ports.conf مقدار Listen 80 به Listen 8080 تغییر می‌کند و در VirtualHost مربوطه هم باید پورت به‌روزرسانی شود. اگر هنوز روی تنظیمات پایه Nginx کار می‌کنید، راهنمای بهینه‌سازی وب‌سرور Nginx را هم ببینید.

سپس باید خود Varnish را روی پورت ۸۰ قرار دهید. این کار با یک override روی سرویس systemd انجام می‌شود:

sudo mkdir -p /etc/systemd/system/varnish.service.d
sudo nano /etc/systemd/system/varnish.service.d/customexec.conf

محتوای فایل:

[Service]
ExecStart=
ExecStart=/usr/sbin/varnishd -a :80 -T localhost:6082 -f /etc/varnish/default.vcl -S /etc/varnish/secret -s malloc,256m

بعد از ذخیره، سرویس‌ها را ری‌استارت کنید:

sudo systemctl daemon-reload
sudo systemctl restart varnish
sudo systemctl restart nginx

از این نقطه به بعد، هر درخواست به پورت ۸۰ اول وارد Varnish می‌شود و فقط در صورت نیاز به پورت ۸۰۸۰ (وب‌سرور واقعی) می‌رسد.

تست و رفع‌اشکال با varnishlog و varnishstat

بعد از راه‌اندازی، باید مطمئن شوید Varnish واقعاً کش می‌کند، نه فقط درخواست را رد می‌کند. ساده‌ترین روش بررسی، هدر X-Cache است که در فایل VCL بالا اضافه شد:

curl -I http://your-domain.com/

اگر بار دوم که همان صفحه را درخواست می‌کنید مقدار X-Cache: HIT را ببینید، کش کار می‌کند.

برای بررسی دقیق‌تر در لحظه، از varnishlog استفاده کنید:

sudo varnishlog -g request

این دستور درخواست‌های زنده را همراه با جزئیات کامل (هدرها، زمان پاسخ، تصمیم کش) نشان می‌دهد و برای پیدا کردن اینکه چرا یک URL خاص کش نمی‌شود بهترین ابزار است.

برای آمار کلی عملکرد کش، varnishstat کاربردی‌تر است:

sudo varnishstat -1 | grep -E 'cache_hit|cache_miss'

نسبت cache_hit به کل درخواست‌ها نشان می‌دهد چه درصدی از ترافیک واقعاً از کش تحویل داده شده، نه از بک‌اند.

مقایسه Varnish با روش‌های دیگر کش

Varnish تنها راه کش کردن محتوا نیست. انتخاب درست به لایه‌ای بستگی دارد که می‌خواهید کش در آن اتفاق بیفتد.

روش کش	لایه کار	نیاز به تغییر کد اپلیکیشن	مناسب‌ترین کاربرد
Varnish Cache	جلوی وب‌سرور (reverse proxy)	معمولاً خیر	صفحات HTML عمومی با ترافیک خوانش بالا
کش داخلی Nginx (fastcgi_cache)	داخل همان وب‌سرور	معمولاً خیر	سایت‌هایی که از قبل روی Nginx اجرا می‌شوند
Redis / Memcached	سطح اپلیکیشن	بله	کش کردن کوئری‌های دیتابیس یا داده‌های session

Varnish و fastcgi_cache هر دو در لایه HTTP کار می‌کنند و برای کش کردن صفحات کامل مناسب‌اند، با این تفاوت که Varnish یک سرویس مستقل و قابل مقیاس‌دهی جداست، در حالی که fastcgi_cache بخشی از خود Nginx است. Redis و Memcached در لایه کاملاً متفاوتی قرار دارند؛ آن‌ها نتیجه کوئری یا محاسبه را کش می‌کنند، نه کل صفحه HTML، و برای این کار باید در کد اپلیکیشن صدا زده شوند. جزئیات نصب و امن‌سازی این مسیر در راهنمای راه‌اندازی Redis آمده است.

نکات امنیتی و محدودیت‌هایی که باید در نظر بگیرید

Varnish به‌طور پیش‌فرض محتوای حساس را کش نمی‌کند، اما این تضمین فقط تا جایی درست است که VCL را درست نوشته باشید. چند نکته عملی:

• مسیرهای ورود، پنل مدیریت و پرداخت را همیشه از کش استثنا کنید، حتی اگر فکر می‌کنید کوکی آن‌ها را به‌طور خودکار حذف می‌کند.
• اگر سایت چندزبانه یا چند ارزی است، کلید کش باید شامل هدری باشد که زبان یا ارز را تشخیص دهد؛ در غیر این صورت کاربران نسخه اشتباه صفحه را از کش دریافت می‌کنند.
• پس از هر تغییر محتوایی مهم، نیاز به purge یا ban دستی کش دارید؛ varnishadm "ban req.url ~ /mohtava" برای این کار استفاده می‌شود.
• پورت مدیریتی Varnish (۶۰۸۲ در تنظیم بالا) باید فقط روی localhost باز باشد، نه روی اینترنت عمومی.

جمع‌بندی

راه‌اندازی Varnish Cache یکی از راه‌های مؤثر برای کاهش بار بک‌اند و کوتاه کردن زمان پاسخ سایت است، بدون اینکه نیازی به تغییر کد اپلیکیشن باشد. مسیر کار شامل نصب پکیج، انتقال وب‌سرور به پورت جدید، نوشتن VCL متناسب با رفتار واقعی سایت، و تست آن با varnishlog و varnishstat است.

برای اینکه این تنظیمات نتیجه واقعی بدهد، منابع سرور هم باید پایدار باشد؛ کش در حافظه RAM نگه‌داری می‌شود و اگر سرور دچار نوسان منابع یا کمبود RAM باشد، همان مزیت سرعت از بین می‌رود. برای تست و اجرای این سناریو می‌توانید از سرور مجازی ابری آریانت استفاده کنید؛ برای سایت‌های با ترافیک بالا که به منابع اختصاصی و پایدار نیاز دارند، سرور اختصاصی گزینه مناسب‌تری خواهد بود.