PvP Server Kiralama & Oyun Sunucuları
0 Giriş Yap Kayıt Ol

راه حل خطای 502 Bad Gateway و 504 Gateway Timeout در سرور لینوکس

Yazdır

راه حل خطای 502 Bad Gateway و 504 Gateway Timeout در سرور لینوکس

راهنمای گام به گام برای حل مشکلات Nginx، Apache، PHP-FPM و زمان‌بندی سرویس.

در وب سایت ها دیده می شود دروازه بد 502 و 504 Gateway Timeout خطاها معمولاً به این دلیل رخ می دهند که سرور وب پاسخ صحیح را از سرویس پشتیبان دریافت نمی کند. این سرویس می تواند PHP-FPM، باطن آپاچی، برنامه Node.js، سرویس API پنل بازی یا برنامه دیگری در پشت پراکسی باشد.

این خطاها به ویژه در میزبانی، پنل بازی، WHMCS، Pterodactyl، پنل مدیریت سفارشی و سیستم های لانچر مبتنی بر وب رایج است.

توضیح ساده: Nginx مانند خدمتکار در است. اگر پی اچ پی یا اپلیکیشن داخل جواب ندهد، خطای 502 یا 504 را به کاربر نشان می دهد.

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
مهم: اگر نسخه PHP تغییر کرده باشد، Nginx ممکن است همچنان به دنبال مسیر سوکت قدیمی PHP-FPM باشد. این یکی از رایج ترین دلایل خطاهای 502 است.

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 تهیه شده است.

Bu cevap yeterince yardımcı oldu mu?

Oyla

overlay spinner