رفع خطای ۵۰۲ و ۵۰۴ در سایت؛ ۵ راهکار فوری وقتی هاست قطع می‌شود

وقتی کاربران یا مشتریان یک وب‌سایت به جای محتوای صفحه با ارورهای سفید و نگران‌کننده «۵۰۲ Bad Gateway» یا «۵۰۴ Gateway Timeout» مواجه می‌شوند، هر ثانیه قطعی مستقیماً به معنای از دست رفتن فروش، بی‌اعتمادی مشتری و افت رتبه در سرچ کنسول گوگل است. خطاهای سری 5xx نشان می‌دهند که وب‌سرور لبه شبکه شما قادر به دریافت پاسخ معتبر یا بموقع از پردازنده‌های پشت صحنه (نظیر PHP-FPM، دیتابیس یا اپلیکیشن سرور) نیست. رفع خطای ۵۰۲ و ۵۰۴ نیازمند درک مهندسی تفاوت ساختاری این دو کد وضعیت، خواندن سریع لاگ‌های زنده سرور و ایزوله‌سازی گلوگاه‌های سخت‌افزاری است. در این راهنمای جامع و فنی از پایگاه دانش تراست‌هاست، ۵ راهکار فوری، ریشه‌ای و عملیاتی را بررسی می‌کنیم تا بتوانید با رفع خطای ۵۰۲ و ۵۰۴ پایداری زیرساخت سایت خود را در سریع‌ترین زمان ممکن بازگردانید.

[Context: Linux Web Server 502/504 Incident Diagnostic]
System Role: Senior DevOps & Linux Infrastructure Engineer
Target: Diagnose and resolve recurring HTTP 502 (Bad Gateway) and HTTP 504 (Gateway Timeout) errors
Stack: Ubuntu 24.04 LTS, Nginx Reverse Proxy, PHP 8.2/8.3-FPM, MariaDB/MySQL, Cloudflare CDN
Diagnostic Inputs:
- Nginx error log: /var/log/nginx/error.log
- PHP-FPM log: /var/log/php8.3-fpm.log
- Kernel OOM: dmesg -T | grep -i oom
- Current worker state: systemctl status php8.3-fpm
Goal: Identify if the root cause is upstream worker exhaustion (max_children), FastCGI timeout, database table lock, or edge proxy timeout, and output the exact configuration patches with zero guesswork.

تفاوت فنی و اساسی خطای ۵۰۲ Bad Gateway و ۵۰۴ Gateway Timeout

برای انتخاب روش صحیح در رفع خطای ۵۰۲ و ۵۰۴، ابتدا باید بدانید پشت هر یک از این کدها چه اتفاقی در لایه شبکه رخ داده است:

• خطای ۵۰۲ Bad Gateway (پاسخ نامعتبر گیت‌وی): زمانی صادر می‌شود که وب‌سرور اصلی (مانند Nginx یا آپاچی) به عنوان یک پروکسی تلاش می‌کند به پردازنده بالادست (Upstream مثل PHP-FPM یا سرویس پایتون/نود) وصل شود، اما سوکت ارتباطی مسدود است، سرویس کرش کرده، پورت پاسخ نمی‌دهد یا بسته‌ای نامعتبر بازگردانده می‌شود. پیام کلاسیک این خطا در لاگ انجین‌ایکس عبارت connect() failed (111: Connection refused) است. در چنین شرایطی، اقدام اول در مسیر رفع خطای ۵۰۲ و ۵۰۴ بررسی سلامت سرویس پردازشی است.
• خطای ۵۰۴ Gateway Timeout (اتمام مهلت گیت‌وی): در این حالت ارتباط وب‌سرور با پردازنده بالادست بدون مشکل برقرار است، اما اسکریپت یا کوئری دیتابیس به قدری طولانی می‌شود که از سقف زمان مجاز (مثلاً ۶۰ ثانیه پیش‌فرض Nginx) فراتر می‌رود. وب‌سرور دیگر منتظر نمی‌ماند، اتصال را قطع کرده و پیام upstream timed out (110: Connection timed out) while reading response header from upstream را در لاگ ثبت می‌کند. بنابراین رفع خطای ۵۰۲ و ۵۰۴ در سناریوی تایم‌اوت نیازمند تنظیم دقیق پارامترهای زمانی وب‌سرور خواهد بود.

به زبان ساده: در خطای ۵۰۲ سرور پردازنده از کار افتاده یا پاسخ نمی‌دهد، اما در خطای ۵۰۴ سرور بیش از حد معطل یک کوئری سنگین یا اسکریپت کند شده است.

راهکار ۱: بررسی کرش PHP-FPM و افزایش تعداد ورکرها (pm.max_children)

در سناریوهای عملیاتی، اولین قدم در رفع خطای ۵۰۲ و ۵۰۴ بررسی ظرفیت پروسه‌های فرعی PHP-FPM و اطمینان از عدم کشته شدن ناگهانی آن‌ها توسط مکانیزم OOM-Killer لینوکس به دلیل کمبود حافظه رم است.

برای ارزیابی سریع و گام‌به‌گام در مسیر رفع خطای ۵۰۲ و ۵۰۴، دستورات زیر را در ترمینال سرور اجرا فرمایید:

# بررسی وضعیت زنده بودن سرویس PHP-FPM
sudo systemctl status php8.3-fpm

# جستجوی خطای کمبود رم و کشته شدن پروسه‌ها توسط کرنل
dmesg -T | grep -i oom

# بررسی خطاهای پر شدن سقف استخر پردازشی در لاگ اختصاصی
sudo grep -i "max_children reached" /var/log/php8.3-fpm.log

اگر با هشدار server reached pm.max_children setting مواجه شدید، به این معناست که تمام ورکرها اشغال شده‌اند و درخواست‌های جدید در صف تلف می‌شوند تا سرانجام خطا صادر گردد. جهت مدیریت اصولی این پارامترها می‌توانید به مستندات رسمی پیکربندی PHP-FPM در وب‌سایت مرجع PHP مراجعه نمایید.

فرمول مهندسی تنظیم pm.max_children برای رفع خطای ۵۰۲ و ۵۰۴:
برای تعیین تعداد بهینه ورکرها در فایل /etc/php/8.3/fpm/pool.d/www.conf، کل رم آزاد سرور را بر میانگین مصرف هر پروسه PHP (که در سیستم‌های مدیریت محتوا حدود ۶۰ الی ۸۰ مگابایت است) تقسیم کنید. به عنوان مثال، در یک سرور با ۸ گیگابایت رم که ۶ گیگابایت آن به PHP اختصاص داده شده است:

; پیکربندی استاندارد در /etc/php/8.3/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 75
pm.start_servers = 15
pm.min_spare_servers = 10
pm.max_spare_servers = 25
pm.max_requests = 1000

پارامتر pm.max_requests = 1000 در فرآیند رفع خطای ۵۰۲ و ۵۰۴ نقش حیاتی دارد؛ زیرا پس از پردازش ۱۰۰۰ درخواست، پروسه را از نو راه‌اندازی می‌کند تا از نشتی تدریجی حافظه (Memory Leak) جلوگیری شود. پس از ذخیره، سرویس را با sudo systemctl reload php8.3-fpm تازه‌سازی فرمایید.

راهکار ۲: اصلاح تایم‌اوت‌های Nginx و رفع محدودیت FastCGI Timeout

دومین محور کلیدی در رفع خطای ۵۰۲ و ۵۰۴ به تنظیمات وب‌سرور بازمی‌گردد؛ در خطای ۵۰۴، معمولاً اسکریپت‌های پشتیبان‌گیری، درون‌ریزی فایل‌های حجیم ووکامرس یا صدور گزارش‌های مالی طولانی به دلیل اتمام سقف ۶۰ ثانیه‌ای پیش‌فرض Nginx قطع می‌شوند.

برای تسهیل رفع خطای ۵۰۲ و ۵۰۴ در این بخش، باید مقادیر تایم‌اوت را در بلاک location ~ \.php$ فایل تنظیمات Nginx مطابق ماژول ngx_http_fastcgi در اسناد رسمی Nginx افزایش دهید:

# افزایش مهلت پاسخ‌دهی FastCGI به ۳۰۰ ثانیه (۵ دقیقه)
location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    
    fastcgi_connect_timeout 300s;
    fastcgi_send_timeout 300s;
    fastcgi_read_timeout 300s;
    fastcgi_buffer_size 128k;
    fastcgi_buffers 4 256k;
    fastcgi_busy_buffers_size 256k;
}

همچنین در فایل php.ini مقدار max_execution_time را هماهنگ با وب‌سرور روی 300 قرار دهید تا تقارن زمانی حفظ گردد. این تطابق نقشی تعیین‌کننده در تثبیت رفع خطای ۵۰۲ و ۵۰۴ در کارهای سنگین پس‌زمینه ایفا می‌کند. در پایان با دستور sudo nginx -t && sudo systemctl reload nginx کانفیگ را اعتبارسنجی و اعمال کنید.

راهکار ۳: شناسایی کوئری‌های سنگین دیتابیس و قفل‌های جدول

سومین گام موثر جهت رفع خطای ۵۰۲ و ۵۰۴ ردیابی وضعیت پایگاه‌داده است؛ گاهی اوقات ریشه مشکل در کدهای PHP نیست، بلکه دیتابیس به دلیل یک کوئری سنگین بدون ایندکس یا قفل شدن سطرها (Lock Contention) معطل مانده است. در این شرایط، پروسه‌های PHP منتظر پاسخ MySQL می‌مانند تا جایی که تمام ورکرها اشغال شده و سایت کاملاً قفل می‌شود.

برای پیشبرد سریع رفع خطای ۵۰۲ و ۵۰۴ در لایه پایگاه‌داده، وارد شل MariaDB/MySQL شده و پردازش‌ها را رصد نمایید:

-- مشاهده کوئری‌های در حال اجرا و شناسایی پردازش‌های قفل‌شده
SHOW FULL PROCESSLIST;

-- در صورت مشاهده کوئری با مدت زمان Time بالا (مثلاً > 120 ثانیه)، آن را متوقف کنید:
KILL [ID_پردازش];

فعال‌سازی ایندکس‌های مناسب، تنظیم دقیق استخر بافر مطابق با راهنمای بهینه‌سازی InnoDB در MySQL و استفاده از کش در حافظه، بار دیتابیس را تا ۹۰٪ کاهش داده و تضمین‌کننده موفقیت در رفع خطای ۵۰۲ و ۵۰۴ در زمان‌های اوج بار خواهد بود.

راهکار ۴: عیب‌یابی CDN و کلودفلر؛ تفکیک خطای لبه از سرور اصلی

برای رفع خطای ۵۰۲ و ۵۰۴ در سایت‌هایی که پشت شبکه کلودفلر (Cloudflare) یا آروان‌کلود قرار دارند، ظاهر صفحه ارور کلیدی‌ترین سرنخ است:

• اگر خطای ۵۰۲ یا ۵۰۴ دارای لوگوی Cloudflare باشد، نشان می‌دهد که CDN سالم است اما سرور مبدا شما در دیتاسنتر یا پاسخ نداده یا اتصال را رد کرده است. در این وضعیت برای رفع خطای ۵۰۲ و ۵۰۴ باید مستقیماً سراغ سرویس‌های هاست بروید.
• اگر صفحه ارور خاکستری بدون برند کلودفلر باشد، قطعی از خود شبکه لبه، ناهماهنگی گواهینامه SSL یا تنظیمات محلی DNS است.

جهت تسریع عیب‌یابی و رفع خطای ۵۰۲ و ۵۰۴، با دستور زیر لایه پروکسی را دور بزنید و مستقیماً سرور اصلی را تست کنید:

# دور زدن CDN و تست مستقیم سرور مبدا با آی‌پی واقعی سرور
curl -Iv --resolve yourdomain.com:443:185.x.x.x https://yourdomain.com/

اگر در خروجی این دستور کد HTTP/2 200 OK را دریافت کردید، مشکل از WAF یا فایروال محلی است که آی‌پی‌های CDN را مسدود کرده است. آی‌پی‌های رسمی کلودفلر را در فایروال UFW سرور مجاز (Allow) کنید تا گامی اساسی در رفع خطای ۵۰۲ و ۵۰۴ برداشته شود.

راهکار ۵: عبور از محدودیت‌های اشتراکی و مهاجرت به سرور ابری اختصاصی

اساسی‌ترین اقدام زیرساختی برای رفع خطای ۵۰۲ و ۵۰۴ به صورت ریشه‌ای، رهایی از هاست‌های اشتراکی است؛ زیرا در این سرویس‌ها، منابع سخت‌افزاری نظیر هسته‌های پردازنده، رم و پهنای باند دیسک میان صدها سایت مختلف تقسیم می‌شوند و اوج مصرف یک سایت همسایه می‌تواند کسب‌وکار شما را با قطعی مواجه کند.

همچنین در هاست‌های اشتراکی امکان دسترسی ریشه (Root)، تغییر مقادیر pm.max_children، بهینه‌سازی سوکت‌های سیستم‌عامل و افزایش تایم‌اوت‌ها وجود ندارد و شما نمی‌توانید برنامه جامعی برای رفع خطای ۵۰۲ و ۵۰۴ پیاده‌سازی فرمایید.

با مهاجرت به سرور مجازی ابری NVMe تراست‌هاست، پردازنده‌های فرکانس بالا، حافظه رم ۱۰۰٪ ایزوله و درایوهای ذخیره‌سازی سازمانی PCIe Gen4 در اختیار شما قرار می‌گیرند. این معماری اختصاصی بالاترین اطمینان را برای رفع خطای ۵۰۲ و ۵۰۴ به ارمغان آورده و خیال شما را از پایداری سایت در جشنواره‌های پرفروش راحت می‌کند.

جدول راهنمای تشخیص سریع علت خطای ۵۰۲ و ۵۰۴ بر اساس لاگ سرور

جدول زیر نقشه راه سریع مهندسان برای رفع خطای ۵۰۲ و ۵۰۴ بر اساس شایع‌ترین پیام‌های ثبت‌شده در لاگ‌ها، علل و اقدامات را خلاصه می‌کند:

سوالات متداول پیرامون رفع خطای ۵۰۲ و ۵۰۴