راه حل خطای 502 Bad Gateway و 504 Gateway Timeout در سرور لینوکس
راهنمای گام به گام برای حل مشکلات Nginx، Apache، PHP-FPM و زمانبندی سرویس.
در وب سایت ها دیده می شود دروازه بد 502 و 504 Gateway Timeout خطاها معمولاً به این دلیل رخ می دهند که سرور وب پاسخ صحیح را از سرویس پشتیبان دریافت نمی کند. این سرویس می تواند PHP-FPM، باطن آپاچی، برنامه Node.js، سرویس API پنل بازی یا برنامه دیگری در پشت پراکسی باشد.
این خطاها به ویژه در میزبانی، پنل بازی، WHMCS، Pterodactyl، پنل مدیریت سفارشی و سیستم های لانچر مبتنی بر وب رایج است.
1. تفاوت بین خطای 502 و 504
- دروازه بد 502: وب سرور نمی تواند به سرویس پشتیبان متصل شود یا یک پاسخ مخدوش دریافت می کند.
- مهلت زمانی دروازه 504: به نظر می رسد که سرویس باطن در حال پاسخگویی است، اما پاسخ به موقع بازگردانده نمی شود.
بنابراین 502 بیشتر یک خرابی اتصال/سرویس است و 504 یک مشکل کندی یا مهلت زمانی است.
2. بررسی وضعیت خدمات
ابتدا بررسی کنید که آیا وب سرور و سرویس های PHP در حال اجرا هستند یا خیر.
systemctl status nginx systemctl status apache2 systemctl status php-fpm
در سیستمهای CentOS، AlmaLinux یا Rocky Linux، سرویس PHP-FPM ممکن است نامگذاری شود:
systemctl status php-fpm systemctl status httpd
اگر سرویس متوقف شد، آن را مجددا راه اندازی کنید:
systemctl restart nginx systemctl restart php-fpm
3. بررسی فایل های گزارش
ادامه با حدس زدن برای خطاهای 502 و 504 صحیح نیست. فایل log علت واقعی خطا را نشان می دهد.
tail -n 100 /var/log/nginx/error.log tail -n 100 /var/log/apache2/error.log
در سیستم های مبتنی بر CentOS:
tail -n 100 /var/log/httpd/error_log
عبارات زیر را می توان در گزارش ها مشاهده کرد:
- connect() ناموفق بود: اتصال به سرویس پشتیبان امکان پذیر نیست.
- زمان بالادست تمام شد: سرویس Backend دیر پاسخ می دهد.
- اتصال رد شد: سرویس قطع است یا به پورت اشتباهی ارسال می شود.
- اجازه رد شد: مشکل سوکت یا مجوز فایل وجود دارد.
4. سوکت PHP-FPM یا کنترل پورت
Nginx از طریق سوکت یا پورت به PHP-FPM متصل می شود. مسیر PHP-FPM در فایل پیکربندی Nginx و مقدار واقعی گوش دادن PHP-FPM باید یکسان باشد.
grep -R "fastcgi_pass" /etc/nginx/sites-enabled/ grep -R "listen =" /etc/php/*/fpm/pool.d/www.conf
به عنوان مثال اگر Nginx استفاده می کند:
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
همان سوکت باید در سمت PHP-FPM گوش داده شود:
listen = /run/php/php8.2-fpm.sock
5. افزایش تنظیمات Timeout
خطاهای 504 ممکن است در پنلهای پردازشی بزرگ، بازارهای بازی، APIها یا اسکریپتهای PHP با کندی اجرا دریافت شوند. مقادیر تایم اوت Nginx را می توان افزایش داد.
nano /etc/nginx/nginx.conf
مقادیر زیر را می توان به بلوک http یا بلوک سرور مربوطه اضافه کرد:
proxy_connect_timeout 300; proxy_send_timeout 300; proxy_read_timeout 300; fastcgi_read_timeout 300;
تنظیمات را تست کنید و Nginx را مجددا راه اندازی کنید:
nginx -t systemctl restart nginx
6. بررسی محدودیت های فرآیند PHP-FPM
وقتی ترافیک افزایش می یابد، محدودیت های تراکنش PHP-FPM ممکن است ناکافی باشد. در این حالت درخواست ها در صف قرار می گیرند و مهلت زمانی رخ می دهد.
nano /etc/php/8.2/fpm/pool.d/www.conf
تنظیمات نمونه:
pm = dynamic pm.max_children = 30 pm.start_servers = 5 pm.min_spare_servers = 5 pm.max_spare_servers = 10
این مقادیر باید با توجه به میزان RAM سرور تنظیم شوند. تنظیم مقدار بسیار بالا مصرف رم را افزایش می دهد.
اشتباهات رایج
- تغییر تنظیمات بدون نگاه کردن به فایل گزارش
- عدم به روز رسانی مسیر سوکت Nginx حتی با وجود تغییر نسخه PHP
- رفع نشدن پرس و جو کند واقعی با افزایش زمان
- افزایش محدودیت های PHP-FPM بدون محاسبه RAM
- راه اندازی مجدد سرویس بدون آزمایش پیکربندی Nginx
سوالات متداول
آیا خطای 502 همیشه توسط Nginx ایجاد می شود؟
نه. Nginx فقط یکی است که خطا را نشان می دهد. مشکل واقعی ممکن است در PHP-FPM، باطن آپاچی، برنامه Node.js یا سرویس دیگری باشد.
آیا افزایش مدت زمان راه حل قطعی برای خطاهای 504 است؟
نه همیشه. افزایش تایم اوت باعث تسکین موقت می شود. راه حل واقعی یافتن پرس و جو کند، پردازش سنگین یا مشکل عملکرد است.
آیا راه اندازی مجدد PHP-FPM ایمن است؟
به طور کلی ایمن است، اما درخواست های فعال ممکن است برای مدت کوتاهی تحت تأثیر قرار گیرند. در سیستم های شلوغ، ساعات کم ترافیک باید ترجیح داده شود.
توصیه های عملکرد
- نسخه PHP-FPM و مسیر سوکت را به طور منظم بررسی کنید.
- گزارشهای کند درخواست را در پنل وب و سرویسهای API بررسی کنید.
- اگر RAM کافی نیست، مقدار max_children PHP-FPM را ناخودآگاه افزایش ندهید.
- با استفاده از یک سیستم کش، بار پشتیبان را کاهش دهید.
- گزارش های خطا را قبل از رشد با logrotate مدیریت کنید.
این مقاله به طور ویژه برای PvPServer تهیه شده است.