رفع خطای 502 با تشخیص جایی شروع می‌شود که ارتباط با سرویس پشت وب‌سرور مشکل پیدا کرده است. پیام Bad Gateway معمولاً به نقش دروازه یا پراکسی اشاره دارد: یک لایه، پاسخ قابل قبول از سرویس بالادست دریافت نکرده است. این پیام به‌تنهایی نام افزونه معیوب یا میزان RAM لازم را مشخص نمی‌کند.
در سایت وردپرسی، مسیر درخواست می‌تواند از CDN به وب‌سرور و سپس PHP-FPM و پایگاه داده برسد. اگر هر مرحله را جدا بررسی کنید، تغییر لازم محدودتر و نتیجه قابل پیگیری‌تر خواهد بود. این راهنما برای مدیر سایت و مدیر سرور نوشته شده و فرض نمی‌کند همه سرویس‌ها از یک معماری استفاده می‌کنند.
خطای 502 Bad Gateway چه معنایی دارد؟
طبق تعریف رسمی 502 در MDN، سروری که نقش دروازه یا پراکسی دارد، پاسخ نامعتبر از سرویس بالادست دریافت کرده است. منظور از بالادست، مرحله بعدی در همان زنجیره درخواست است؛ ممکن است وب‌سرور مبدأ، یک برنامه یا سرویس دیگری باشد. بنابراین صفحه‌ای با نام CDN لزوماً به معنی خرابی خود CDN نیست.
در 503، سرویس موقتاً آماده پاسخ‌گویی نیست؛ 504 معمولاً به پایان انتظار دروازه برای پاسخ مربوط می‌شود. نوع پیاده‌سازی و شرایط ارتباط می‌تواند کد نهایی را تغییر دهد، پس تشخیص را فقط از روی عدد انجام ندهید. اگر پیام شما 503 است، راهنمای رفع خطای 503 در وردپرس مسیر مناسب‌تری ارائه می‌کند.
پیش از هر تغییر، یک نمونه قابل تکرار ثبت کنید
نشانی دقیق، زمان همراه منطقه زمانی، نوع عملیات و متن خطا را یادداشت کنید. آیا صفحه اصلی خراب است یا فقط پرداخت، آپلود و ورود؟ آیا فایل تصویری موجود باز می‌شود؟ با یک مرورگر خصوصی و در صورت امکان اتصال دیگری مقایسه کنید. این آزمون‌ها کمک می‌کنند دامنه اختلال را بفهمید، ولی کش می‌تواند بخشی از مشکل را پنهان کند.
برای یک درخواست عمومی و بدون داده حساس، نمونه زیر هدرها را نمایش و بدنه را کنار می‌گذارد. دامنه نمونه را با سایت خود جایگزین کنید:
curl -sS -D - -o /dev/null https://example.com/هدرها، شناسه درخواست و زمان رخداد را برای مقایسه با لاگ نگه دارید. این فرمان وضعیت همان درخواست را نشان می‌دهد؛ نتیجه آن اثبات نمی‌کند تمام صفحات سالم‌اند. مسیر پرداخت یا عملیاتی که داده ثبت می‌کند باید با روش آزمایشی مناسب خودش بررسی شود و نباید با تکرار درخواست واقعی، سفارش تکراری بسازید.
جدول سرنخ‌های رایج در خطای 502
| سرنخ | احتمال قابل بررسی | گام بعد |
|---|---|---|
| خطا پس از تغییر نسخه PHP | مسیر سوکت یا سرویس فعال تغییر کرده | مقایسه تنظیم وب‌سرور با تنظیم Pool |
| connection refused در لاگ | سرویس در مقصد موردنظر گوش نمی‌دهد یا اتصال رد می‌شود | بررسی وضعیت سرویس و مقصد اتصال |
| permission denied برای سوکت | مجوز یا مالکیت مسیر با دسترسی وب‌سرور سازگار نیست | بررسی دسترسی لازم بدون باز کردن عمومی مجوزها |
| upstream prematurely closed connection | پردازش برنامه یا ارتباط پیش از تکمیل پاسخ بسته شده | تطبیق لاگ PHP و منابع با همان زمان |
| خطا فقط پشت پراکسی | ارتباط پراکسی تا مبدأ یا پاسخ مبدأ | آزمون کنترل‌شده مبدأ با حفظ نام دامنه |
عبارت‌های جدول سرنخ هستند و علت قطعی را تعیین نمی‌کنند. برای مثال، بسته شدن زودهنگام ارتباط می‌تواند از توقف پردازش، خطای برنامه یا یک عامل دیگر ناشی شود. به تغییر اخیر، تکرارپذیری و گزارش همان ثانیه توجه کنید؛ یک هشدار قدیمی نامرتبط را علت اختلال امروز معرفی نکنید.
۱. مشخص کنید کدام لایه خطا را تولید می‌کند
متن صفحه، هدر پاسخ و شناسه درخواست برای پیدا کردن لایه پاسخ‌دهنده مفیدند. سپس گزارش CDN یا پراکسی را با لاگ مبدأ تطبیق دهید. اگر درخواست اصلاً به وب‌سرور نرسیده، جست‌وجوی خطای افزونه در وردپرس نقطه شروع مناسبی نیست. اگر رسیده و ارتباط PHP شکست خورده، باید همان بخش بررسی شود.
برای آزمون مبدأ، نام میزبان و HTTPS باید درست باقی بمانند؛ باز کردن IP ممکن است سایت دیگری یا خطای گواهی نشان دهد. راهنمای تست سایت با نام واقعی دامنه پیش از تغییر DNS روش مرتبط را توضیح می‌دهد. دور زدن کنترل دسترسی مبدأ یا تغییر عمومی DNS صرفاً برای عیب‌یابی، گام اول لازم نیست؛ از مدیر میزبان بخواهید آزمون محدود انجام دهد.
۲. تنظیم اتصال Nginx و PHP-FPM را مقایسه کنید
در معماری متداول Nginx و PHP-FPM، وب‌سرور درخواست PHP را با FastCGI به یک سوکت Unix یا نشانی TCP می‌فرستد. مقصد تنظیم‌شده در fastcgi_pass باید با محل listen سرویس مربوط هماهنگ باشد. مسیر نمونه‌ای که از مقاله دیگر برداشته‌اید، الزاماً با نسخه PHP، Pool یا کنترل‌پنل شما یکسان نیست.
برای مثال فرضی، نسخه PHP عوض شده ولی تنظیم وب‌سرور هنوز به سوکت نسخه قبلی اشاره می‌کند. افزایش timeout این ناهماهنگی را حل نمی‌کند. ابتدا سرویس مورد انتظار و نشانی واقعی آن را مشخص کنید. جزئیات مقصد اتصال در مستندات رسمی ماژول FastCGI در Nginx و تنظیم listen در راهنمای پیکربندی PHP-FPM آمده است.
برای مشکل permission، مالک و گروه سوکت و دسترسی مسیر والد را بررسی کنید. استفاده از مجوز 777 برای رفع سریع خطا، راهکار متناسبی نیست؛ دسترسی باید فقط برای فرآیند لازم فراهم شود. در سرور دارای کنترل‌پنل، فایل تولیدشده ممکن است بازنویسی شود، پس تغییر باید از روش پشتیبانی‌شده همان پنل انجام گیرد.
۳. وضعیت سرویس و لاگ PHP را کنار هم ببینید
نام سرویس PHP-FPM در توزیع‌ها و نسخه‌ها متفاوت است. قبل از اجرای فرمان مدیریت سرویس، نام واقعی را از تنظیمات میزبان بگیرید. بررسی کنید سرویس متوقف شده، با خطا بالا نمی‌آید یا هنگام عملیات مشخص از کار می‌افتد. گزارش وب‌سرور را با لاگ PHP و رخدادهای حافظه در همان بازه مقایسه کنید.
در سرور مبتنی بر systemd، گزارش Nginx ممکن است با فرمان زیر قابل بررسی باشد؛ مسیر لاگ و شیوه ثبت آن در هر نصب می‌تواند متفاوت باشد:
journalctl -u nginx --since "30 minutes ago" --no-pagerبرای نمونه، اگر خطا پس از فعال شدن پردازش تصویر یا درون‌ریزی بزرگ تکرار می‌شود، همان عملیات را در محیط آزمایشی با پایش منابع بازتولید کنید. restart ممکن است موقتاً دسترسی را برگرداند، ولی بدون ثبت علت، شواهد را از دست می‌دهید و احتمال تکرار باقی می‌ماند. در هاست اشتراکی این بررسی معمولاً باید توسط میزبان انجام شود.
۴. ظرفیت پردازش را با مصرف واقعی تطبیق دهید
محدودیت تعداد پردازش‌های PHP و مصرف حافظه هرکدام بر ظرفیت هم‌زمان اثر می‌گذارد. افزایش عدد پردازش‌ها بدون محاسبه RAM ممکن است فشار بیشتری ایجاد کند. از طرف دیگر، طولانی شدن درخواست‌ها می‌تواند صف را نگه دارد، حتی اگر تعداد بازدید روزانه زیاد نباشد. زمان اجرای عملیات، تعداد درخواست هم‌زمان و وضعیت دیتابیس را با هم بررسی کنید.
برای وردپرس، افزونه یا کد سفارشی ممکن است عامل درخواست طولانی یا توقف پردازش باشد. شواهد لاگ را دنبال کنید و آزمون غیرفعال‌سازی را ابتدا در محیط آزمایشی وردپرس انجام دهید. پاک کردن همه افزونه‌ها یا تعویض هم‌زمان قالب و PHP، تشخیص عامل اصلی را دشوار می‌کند.
۵. تغییر را آزمایش و نتیجه را کنترل کنید
قبل از تغییر، فایل تنظیم و مقدار قبلی را ثبت کنید. برای نصب استاندارد Nginx، nginx -t آزمون صحت پیکربندی است؛ در محیط کنترل‌پنل از مسیر توصیه‌شده همان ابزار استفاده کنید. موفق شدن این آزمون به معنی سالم بودن ارتباط با PHP یا عملکرد برنامه نیست؛ بعد از اعمال کنترل‌شده تغییر باید مسیر واقعی کاربر هم آزموده شود.
صفحه اصلی، ورود، صفحه بدون کش و عملیاتی که خطا داشت را بررسی کنید. لاگ جدید را ببینید و مطمئن شوید خطا فقط از یک لایه به لایه دیگر منتقل نشده است. اگر پاسخ خطا کش شده، وضعیت کش همان لایه را پس از رفع علت کنترل کنید. خاموش کردن کامل کش می‌تواند بار بیشتری به برنامه برساند، بنابراین اثرش را بسنجید.
پرسش‌های رایج درباره رفع خطای 502
آیا افزایش timeout همیشه کمک می‌کند؟
خیر؛ خطای مقصد سوکت، توقف سرویس و مجوز دسترسی با افزایش انتظار برطرف نمی‌شوند. حتی در درخواست طولانی نیز باید زمان اجرای مورد انتظار و ظرفیت سرویس بررسی شود.
آیا 502 حتماً از وردپرس است؟
خیر؛ CDN، پراکسی، وب‌سرور و سرویس برنامه در زنجیره قرار دارند. ابتدا لایه خطادار را مشخص کنید. نام یک نرم‌افزار روی صفحه خطا، دلیل کافی برای مقصر دانستن آن نیست.
برای پشتیبانی چه اطلاعاتی ارسال کنیم؟
دامنه، نشانی نمونه، زمان، متن خطا، شناسه درخواست و آخرین تغییر را بفرستید. اطلاعات محرمانه و داده کاربران را از لاگ حذف کنید. نتیجه آزمون‌هایی که انجام داده‌اید، رفت‌وبرگشت بررسی را کمتر می‌کند.
رفع مشکل را به یک تغییر قابل توضیح وصل کنید
رفع خطای 502 زمانی قابل اتکاست که بدانید کدام ارتباط مشکل داشت، چه تغییری انجام شد و با کدام آزمون سلامت سرویس تأیید شد. برای بررسی لاگ، پیکربندی و ظرفیت، از خدمات مدیریت سرور و سایت آفاق هاست کمک بگیرید و مسیر پیگیری اختلال را از قبل مشخص کنید.
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
پرسش‌ها و دیدگاه‌های شما
سؤال یا تجربه مرتبط با این مطلب دارید؟ با ما و خوانندگان مجله آفاق هاست در میان بگذارید.