خطای 502 Bad Gateway وردپرس؛ سرور PHP را عیب‌یابی کنیم

خطای 502 Bad Gateway یعنی وب‌سروری که به مرورگر پاسخ می‌دهد، از برنامهٔ پشت آن پاسخ قابل‌استفاده نگرفته است. برای وردپرس، این برنامه معمولاً PHP است. 502 با خطای 404 فرق دارد: 404 می‌گوید نشانی پیدا نشده، اما 502 می‌گوید مسیر تا دروازه رسیده و پاسخ سرورِ بعدی خراب، دیر یا قطع شده است. صفحهٔ خطا علت دقیق را نمی‌گوید؛ باید ببینیم خطا برای همهٔ صفحات است یا فقط یک کار خاص.

اول صفحهٔ اصلی، یک نوشته و پیشخوان را در پنجرهٔ خصوصی باز کنید. سپس، اگر می‌توانید، یک فایل متن ساده در پوشهٔ سایت بسازید، مثلاً health-check.txt با محتوای ok. آن را فقط برای چند دقیقه نگه دارید و بعد پاک کنید. اگر فایل ثابت باز می‌شود اما صفحات PHP همگی 502 هستند، مشکل به اجرای PHP یا ارتباط وب‌سرور با PHP نزدیک‌تر است. اگر فقط یک نشانی وردپرس خطا می‌دهد، همان افزونه، قالب یا درخواست خاص را بررسی کنید.

اگر نمی‌توانید فایل آزمایشی بسازید، به پشتیبانی بگویید صفحهٔ اصلی یا فایل تصویری باز می‌شود ولی PHP نه. زمان دقیق، URL و کاری که قبل از خطا انجام دادید را هم بنویسید. همین اطلاعات کمک می‌کند گزارش همان درخواست پیدا شود.

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

برای سایت خودتان از مسیر لازم استفاده کنید؛ این فرمان فقط درخواست می‌فرستد و تغییری در سایت نمی‌دهد. پاسخ ممکن است 502، 503 یا 504 باشد. این کدها به هم شبیه‌اند اما معنی دقیقشان فرق دارد. اگر خطا گاهی می‌آید و گاهی نه، هر بار زمان و نشانی را ثبت کنید؛ یک پاسخ موفق بعدی، رخداد قبلی را بی‌اثر نمی‌کند.

در cPanel بخش Metrics → Errors آخرین خطاهای وب را نشان می‌دهد. بخش MultiPHP Manager هم نسخهٔ PHP هر دامنه را مشخص می‌کند. در DirectAdmin معمولاً گزارش خطا در بخش مدیریت دامنه یا لاگ‌هاست. نام فایل در هر میزبان فرق دارد؛ پوشه‌های پنهان را در File Manager نمایش دهید و برای بازهٔ همان دقیقه دنبال پیام‌های timeout، process exited یا memory exhausted بگردید.

اگر VPS دارید و دسترسی مدیر دارید، نام سرویس PHP-FPM در هر توزیع ممکن است متفاوت باشد. پیش از اجرای فرمان، نام واقعی را با systemctl list-units '*php*fpm*' پیدا کنید. سپس لاگ سرویس همان نسخه را برای زمان خطا بخوانید. دستورهای عمومی مانند systemctl restart php-fpm را از روی حدس اجرا نکنید؛ نام سرویس ممکن است چیز دیگری باشد و راه‌اندازی مجدد می‌تواند همهٔ سایت‌های روی آن را لحظه‌ای قطع کند.

برای مقایسه، یک درخواست ساده و همان صفحهٔ خطادار را جداگانه امتحان کنید. اگر فقط عملیات ساخت تصویر یا ذخیرهٔ سفارش 502 می‌دهد، زمان اجرای آن یا حافظهٔ مصرفی‌اش ممکن است به محدودیت برسد. اگر همهٔ PHPها هم‌زمان خطا دارند، میزبان باید تعداد پردازش‌های آماده و سلامت سرویس PHP را بررسی کند.

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

اگر سایت پس از واردکردن فایل بزرگ یا کار سنگین خطا می‌دهد، یک فایل کوچک‌تر و یک عملیات سبک را برای مقایسه اجرا کنید. بالا بردن همهٔ timeoutها یا محدودیت حافظه مشکل برنامه‌ای را حل نمی‌کند و ممکن است صف پردازش‌ها را طولانی کند. در هاست اشتراکی، مقدارهای PHP-FPM و Nginx دست میزبان است؛ از پشتیبانی بخواهید لاگ دقیق همان درخواست را بررسی کند.

ری‌استارت PHP یا وب‌سرور ممکن است 502 موقت را پاک کند، اما اگر علت باقی باشد خطا برمی‌گردد. قبل از اقدام، لاگ، زمان و URL را ذخیره کنید و اگر کاربر روی صفحهٔ پرداخت است، مطمئن شوید سفارش ثبت نشده تا دوباره دکمه را نزند. مدیر سرور باید تعداد پردازش‌های مشغول، RAM، خطاهای PHP و صف درخواست را ببیند. تنها اگر شواهد نشان می‌دهد یک سرویس گیر کرده و اقدام طبق برنامهٔ نگهداری است، همان سرویس هدفمند راه‌اندازی شود.

وقتی صفحه باز شد، فقط صفحهٔ خانه را نبینید. همان فرم یا فرایندی که خطا می‌داد را با دادهٔ آزمایشی اجرا کنید و نتیجه را یک بار ثبت کنید. اگر 502 برمی‌گردد، خط جدید لاگ را با زمان جدید نگه دارید. مقالهٔ خطای 500 وردپرس بدون تغییر تصادفی دربارهٔ خطایی در خود برنامه است؛ اگر وب‌سرور پاسخ 502 می‌دهد، لاگ دروازه و ارتباط PHP هم باید دیده شود.

به زبان ساده، 502 یعنی دروازه پاسخ قابل‌استفاده از برنامهٔ پشتش نگرفته؛ 504 بیشتر به تمام‌شدن زمان انتظار اشاره دارد و 503 از در دسترس نبودن موقت سرویس خبر می‌دهد. متن و لاگ دقیق مهم‌تر از ظاهر صفحه‌اند. اگر CDN جلوی سایت دارید، ممکن است خودش 502 را ساخته باشد و سرور اصلی همان درخواست را ندیده باشد؛ شناسهٔ خطای CDN را هم نگه دارید و از میزبان بخواهید مبدأ درخواست را پیدا کند.