לראות באתרי אינטרנט 502 Bad Gateway ו 504 שער פסק זמן שגיאות מתרחשות בדרך כלל מכיוון ששרת האינטרנט אינו מקבל את התגובה הנכונה משירות הקצה האחורי. שירות זה יכול להיות PHP-FPM, Apache backend, אפליקציית Node.js, שירות API של פאנל משחקים או אפליקציה אחרת מאחורי ה-proxy.

שגיאות אלו שכיחות במיוחד באירוח, פאנל משחקים, 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. קובץ היומן מציג את הסיבה האמיתית לשגיאה.

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() נכשל: לא ניתן להתחבר לשירות הקצה האחורי.
• תם הזמן הקצוב במעלה הזרם: שירות אחורי מגיב באיחור.
• חיבור סירב: השירות מושבת או שיש העברה ליציאה הלא נכונה.
• הרשאה נדחתה: יש בעיה בהרשאת שקע או קובץ.

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. הגדלת הגדרות הזמן הקצוב

שגיאות 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 של השרת. הגדרת ערך גבוה מדי מגדילה את צריכת ה-RAM.

טעויות נפוצות

• שינוי הגדרות מבלי להסתכל על קובץ היומן
• לא מעדכן את נתיב שקע Nginx למרות שגרסת ה-PHP השתנתה
• אי תיקון השאילתה האיטית בפועל על ידי הגדלת הזמן הקצוב
• הגדלת מגבלות PHP-FPM ללא חישוב זיכרון RAM
• הפעלה מחדש של השירות מבלי לבדוק את תצורת Nginx

שאלות נפוצות

האם שגיאת 502 נגרמת תמיד על ידי Nginx?
לא. Nginx הוא רק זה שמציג את השגיאה. ייתכן שהבעיה האמיתית היא ב-PHP-FPM, ב-Apache backend, ביישום Node.js או בשירות אחר.

האם הגדלת הזמן הקצוב היא הפתרון הסופי לשגיאות 504?
לא תמיד. הגדלת הזמן הקצוב מספקת הקלה זמנית. הפתרון האמיתי הוא למצוא את השאילתה האיטית, העיבוד הכבד או בעיית הביצועים.

האם זה בטוח להפעיל מחדש את PHP-FPM?
זה בדרך כלל בטוח, אבל בקשות פעילות עשויות להיות מושפעות לזמן קצר. במערכות עמוסות יש להעדיף שעות תנועה נמוכות.

המלצות ביצועים

• בדוק את גרסת PHP-FPM ואת נתיב השקע באופן קבוע.
• בדוק יומני שאילתות איטיים בלוח אינטרנט ובשירותי API.
• אם זיכרון RAM אינו מספיק, אל תגדיל את ערך PHP-FPM max_children באופן לא מודע.
• הפחת את העומס האחורי על ידי שימוש במערכת מטמון.
• נהל יומני שגיאות לפני שהם גדלים עם logrotate.

מאמר זה הוכן במיוחד עבור PvPServer.