کش‌کردن امن پاسخ‌های وب با NGINX؛ راهنمای proxy_cache، bypass و purge

NGINX یک reverse proxy و وب‌سرور است که می‌تواند پاسخ‌های عمومی backend را cache کند تا زمان پاسخ و فشار روی برنامه کاهش یابد.

NGINX proxy_cache چیست و چه مسئله‌ای را حل می‌کند؟

در این راهنما، NGINX proxy_cache را از دید عملی بررسی می‌کنیم: NGINX proxy_cache برای پاسخ‌های عمومی، NGINX proxy_cache برای کنترل TTL، NGINX proxy_cache برای طراحی cache key و NGINX proxy_cache برای bypass امن. این تکرار به معنای فعال‌کردن یکسان تنظیمات در همهٔ endpointها نیست؛ هر endpoint باید جداگانه ارزیابی شود تا NGINX proxy_cache فقط جایی فعال باشد که پاسخ واقعاً عمومی است.

پیش از اجرای NGINX proxy_cache، یک endpoint عمومی کوچک را به‌عنوان نمونه انتخاب کنید.

در production، NGINX proxy_cache را مرحله‌ای گسترش دهید و نتیجهٔ هر مرحله را ثبت کنید.

NGINX یک وب‌سرور و reverse proxy است که می‌تواند پاسخ backend را برای درخواست‌های بعدی در cache نگه دارد. در این مقاله، NGINX proxy_cache را برای کم‌کردن زمان پاسخ و فشار روی وردپرس یا برنامهٔ اصلی بررسی می‌کنیم؛ تمرکز روی این است که پاسخ‌های عمومی cache شوند، اما محتوای خصوصی، کاربر واردشده و درخواست‌های دارای اعتبارنامه به اشتباه بین کاربران به اشتراک گذاشته نشوند. مستندات رسمی ماژول proxy در NGINX مرجع اصلی دستورهای این راهنماست و مجلهٔ تکتاز نیز آموزش‌های بیشتری دربارهٔ سرور و زیرساخت دارد.

کش‌کردن در لایهٔ reverse proxy زمانی ارزشمند است که چند کاربر، یک پاسخ عمومی یکسان را درخواست می‌کنند. به‌جای اینکه هر بار PHP، وردپرس یا یک سرویس API دوباره اجرا شود، NGINX می‌تواند پاسخ آماده را مستقیماً برگرداند. بااین‌حال، cache یک کپی از پاسخ را نگه می‌دارد؛ بنابراین اگر شرایط cache به‌درستی تعریف نشود، دادهٔ حساب کاربری، سبد خرید، پنل مدیریت یا صفحه‌ای با مجوز دسترسی ممکن است به درخواست بعدی برسد. «سریع‌تر» بودن بدون مرزبندی دسترسی، بهبود قابل‌قبولی نیست.

طراحی مسیر و ناحیهٔ cache

ابتدا مسیر را روی کاغذ مشخص کنید: client به NGINX وصل می‌شود، NGINX درخواست را به backend می‌فرستد و پاسخ را برای درخواست‌های مجاز ذخیره می‌کند. ناحیهٔ cache در context مربوط به http با proxy_cache_path ساخته می‌شود. این دستور مسیر فایل‌ها، keys_zone، مدت inactive و سقف مصرف دیسک را تعریف می‌کند. اندازهٔ zone فقط متادیتای کلیدها را نگه می‌دارد و جای فایل‌های پاسخ نیست؛ پس باید هم حافظه و هم فضای دیسک را جداگانه برآورد کنید.

نمونهٔ پایهٔ زیر فقط یک الگوست و باید با مسیر دیسک، نام upstream و سیاست نگهداری واقعی شما تطبیق داده شود:

“`nginx proxy_cache_path /var/cache/nginx/site levels=1:2 keys_zone=site_cache:20m inactive=30m max_size=2g;

location / { proxy_pass http://app_backend; proxy_cache site_cache; proxy_cache_key “$scheme$proxy_host$request_uri”; proxy_cache_valid 200 302 10m; proxy_cache_valid 404 1m; add_header X-Cache-Status $upstream_cache_status always; } “`

proxy_cache_key باید نمایندهٔ واقعی پاسخ باشد. در بسیاری از سایت‌های عمومی، scheme، host و URI شروع مناسبی هستند؛ اما اگر پاسخ به زبان، نوع دستگاه یا پارامتر معناداری وابسته است، آن تفاوت باید در کلید یا سیاست bypass دیده شود. اضافه‌کردن همهٔ cookieها به کلید، hit rate را پایین می‌آورد و می‌تواند تعداد بی‌نهایتی از نسخه‌ها بسازد؛ حذف کورکورانهٔ آن‌ها هم خطرناک است.

اعتبار پاسخ و زمان نگهداری

با proxy_cache_valid می‌توان زمان نگهداری پاسخ‌های موفق و خطا را جدا کرد. صفحهٔ عمومی ۲۰۰ ممکن است چند دقیقه cache شود، اما ۴۰۴ معمولاً باید مدت کوتاه‌تری بماند تا بعد از ساخت صفحه، خطای قدیمی مدت زیادی نمایش داده نشود. کدهای redirect و خطا را آگاهانه انتخاب کنید و تصور نکنید هر پاسخ backend برای cache مناسب است.

هدرهای پاسخ نیز مهم‌اند. Set-Cookie، Vary و Cache-Control می‌توانند بر رفتار cache اثر بگذارند. پیش از فعال‌کردن proxy_ignore_headers، دلیل وجود هدر را بفهمید؛ نادیده‌گرفتن آن ممکن است قفل امنیتی برنامه را بی‌اثر کند. اگر backend پاسخ‌های شخصی تولید می‌کند، بهتر است آن endpoint از ابتدا عمومی فرض نشود.

bypass و جلوگیری از cache دادهٔ خصوصی

برای درخواست‌های دارای Authorization، cookie ورود، سبد خرید یا پارامترهای صریح عدم‌کش، از proxy_cache_bypass و proxy_no_cache استفاده کنید. اولی مانع خواندن پاسخ از cache می‌شود و دومی مانع ذخیره‌کردن پاسخ فعلی در cache. هر دو را کنار هم بررسی کنید؛ bypass تنها، پاسخ خصوصی را از cache نمی‌خواند اما به‌تنهایی سیاست کامل ذخیره‌سازی نیست.

“`nginx map $http_cookie $skip_cache { default 0; ~*”wordpress_logged_in|comment_author|woocommerce_items_in_cart” 1; }

location / { proxy_pass http://app_backend; proxy_cache site_cache; proxy_cache_bypass $skip_cache $http_authorization $arg_nocache; proxy_no_cache $skip_cache $http_authorization $arg_nocache; proxy_cache_key “$scheme$proxy_host$request_uri”; } “`

نام cookieها باید با برنامهٔ واقعی شما تطبیق داده شود. برای وردپرس، صفحات ورود، مدیریت، checkout، account و endpointهای دارای nonce را در فهرست استثناها بگذارید. همچنین درخواست‌های POST را بدون بررسی دقیق cache نکنید؛ حالت پیش‌فرض ماژول برای cache، GET و HEAD است و همان الگو برای محتوای عمومی امن‌تر است.

تست HIT و MISS بدون حدس

یک هدر وضعیت مانند X-Cache-Status فقط برای محیط کنترل‌شده یا با ملاحظات افشای اطلاعات اضافه کنید. سپس با curl -I یک URL عمومی را چند بار بخوانید: اولین درخواست معمولاً MISS و درخواست بعدی، اگر پاسخ قابل‌کش باشد، HIT خواهد بود. با cookie ورود، هدر Authorization، پارامتر nocache و یک درخواست POST نیز تست کنید و مطمئن شوید پاسخ خصوصی وارد cache نمی‌شود. لاگ NGINX، زمان پاسخ backend و وضعیت واقعی header را کنار هم بررسی کنید؛ فقط کم‌شدن زمان یک درخواست برای نتیجه‌گیری کافی نیست.

purge کنترل‌شده و مقابله با محتوای قدیمی

کش باید راه خروج داشته باشد. ساده‌ترین روش، زمان اعتبار کوتاه و cache key قابل‌پیش‌بینی است؛ برای تغییرات فوری می‌توان purge را به یک endpoint محدود و احراز‌شده سپرد. دستور proxy_cache_purge در مرجع NGINX شرایط حذف را تعریف می‌کند، اما نباید آن را بدون محدودیت روی اینترنت باز کرد. purge را به IP مدیریت، روش درخواست مشخص و یک کلید معتبر محدود کنید و نتیجهٔ ۲۰۴ را در لاگ ثبت کنید.

اگر purge ندارید، انتشار محتوا را با versioning، TTL مناسب و کلید دقیق مدیریت کنید. cache قدیمی برای صفحهٔ عمومی آزاردهنده است؛ برای اطلاعات قیمت، موجودی، دسترسی و محتوای شخصی می‌تواند مشکل عملی یا امنیتی ایجاد کند. پس از هر تغییر تنظیمات، با nginx -t syntax را بررسی و reload کنترل‌شده انجام دهید؛ تغییرات گسترده یا restart بی‌دلیل می‌تواند اختلال ایجاد کند.

چک‌لیست نهایی مدیر سرور

۱. endpointهای عمومی و خصوصی را جدا کنید و فهرست cookie، Authorization و پارامترهای bypass را مستند کنید.

۲. proxy_cache_path، اندازهٔ zone، سقف دیسک و inactive را بر اساس ترافیک واقعی انتخاب کنید.

۳. cache key را با host، URI و تفاوت‌های مؤثر بر پاسخ بسازید؛ cookieهای غیرضروری را کورکورانه به کلید اضافه نکنید.

۴. برای ۲۰۰ و ۴۰۴ TTL جدا تعیین کنید و اثر Cache-Control، Set-Cookie و Vary را بسنجید.

۵. proxy_cache_bypass و proxy_no_cache را برای login، سبد خرید، Authorization و nocache هم‌زمان تست کنید.

۶. HIT، MISS، bypass، پاسخ POST و purge را در staging و سپس در production با سناریوی محدود بررسی کنید.

۷. بعد از تغییر، syntax، لاگ، وضعیت backend و محتوای پاسخ را دوباره بخوانید و فقط بر اساس حدس cache را باز نگذارید.

جمع‌بندی

NGINX proxy_cache می‌تواند با کم‌کردن اجرای تکراری backend، زمان پاسخ و مصرف منابع را پایین بیاورد؛ اما طراحی امن آن به اندازهٔ خود cache مهم است. کلید دقیق، TTL متناسب، bypass برای هویت و cookie، عدم ذخیرهٔ پاسخ‌های خصوصی، تست HIT/MISS و purge محدود، مجموعه‌ای هستند که کش را به یک بهبود پایدار تبدیل می‌کنند. برای سایت‌های وردپرسی و سرویس‌های API، ابتدا endpointهای عمومی را کوچک و قابل‌اندازه‌گیری انتخاب کنید و بعد دامنهٔ cache را مرحله‌به‌مرحله گسترش دهید.