502 Bad Gateway

שגיאת 502 Bad Gateway היא הדרך של האינטרנט לומר: "אל תאשים אותי — תאשים את השרת שמאחוריי."

כשאתה רואה שגיאת 502, השרת אליו הגעת (ה-gateway) עובד מצוין. הוא קיבל את הבקשה שלך, ניסה להעביר אותה לשרת אחר, וקיבל בחזרה זבל — או שום דבר שניתן להשתמש בו. ה-gateway הוא רק השליח שמביא חדשות רעות על מישהו אחר.

מה בעצם קורה

תשתית רשת מודרנית כמעט לא כוללת שרת בודד. הבקשה שלך עוברת בדרך כלל דרך שכבות:

אתה → מאזן עומסים → שרת אפליקציה → מסד נתונים

שגיאת 502 מתרחשת כאשר אחד מהשרתים האמצעיים האלה (ה-gateway) אינו יכול לקבל תגובה תקינה מהשרת שמאחוריו (ה-upstream). ה-gateway ניסה. הוא נכשל. והוא מספר לך על כך.

HTTP/1.1 502 Bad Gateway

זהו. אין הסבר מפורט — רק הודאה שהשרשרת נשברה איפשהו בהמשכה.

למה שרתי Upstream נכשלים

ה-upstream קרס. שרת האפליקציה היה פועל, קיבל את הבקשה המועברת, ומת באמצע התגובה. ה-gateway קיבל חצי תשובה או איפוס חיבור.

ה-upstream אינו פועל. מישהו פרס קוד שבור, התהליך אזל מהזיכרון, או שהשרת אתחל מחדש. ה-gateway פונה ואין איש בבית.

ה-upstream מחזיר תגובה לא תקינה. השרת הגיב, אבל לא עם HTTP תקין. אולי הוא זרק stack trace ישירות ל-socket. אולי proxy שהוגדר בצורה שגויה החזיר HTML כשציפו ל-JSON. ה-gateway לא מצליח להבין את זה.

החיבור נדחה. שרת ה-upstream קיים אבל לא מאזין על הפורט הצפוי. ה-gateway מנסה להתחבר לפורט 3000, אבל אין שם מאזין.

בעיות רשת. חומות אש, כשלי DNS, או מחיצות רשת מונעים מה-gateway להגיע ל-upstream בכלל.

502 מול שגיאות 5xx אחרות

אלה מתבלבלים כל הזמן. הנה ההבחנה:

500 Internal Server Error: השרת אליו הגעת התקלקל. זו אשמת השרת עצמו.

502 Bad Gateway: השרת אליו הגעת בסדר גמור, אבל השרת מאחוריו התקלקל או הגיב בצורה לא תקינה.

503 Service Unavailable: השרת מסרב לבקשות בכוונה — בדרך כלל כי הוא עמוס מדי או נמצא במצב תחזוקה. זה מכוון, לא כשל.

504 Gateway Timeout: השרת שמאחורי ה-gateway לא הגיב בזמן. שגיאת 502 פירושה שהוא הגיב בצורה לא תקינה; שגיאת 504 פירושה שהוא לא הגיב בכלל.

ההבדל בין 502 ל-504 הוא ההבדל בין מישהו שמדבר שטויות לבין מישהו ששותק לחלוטין.

איתור הבעיה

כשאתה רואה שגיאת 502, ה-gateway בסדר. חפש מאחוריו.

האם ה-upstream פועל?

systemctl status your-app-service
netstat -tulpn | grep :3000

אם השירות מושבת או שהפורט לא מאזין, מצאת את הבעיה.

האם אתה יכול להגיע ל-upstream ישירות?

curl -v http://localhost:3000/health

אם זה עובד אבל ה-gateway מחזיר 502, הבעיה נמצאת בהגדרות ה-gateway — פורט שגוי, שם מארח שגוי, פרוטוקול שגוי.

מה אומרים ה-logs?

לוגים של ה-gateway מספרים לך מה השתבש:

tail -f /var/log/nginx/error.log

הודעות נפוצות:

• upstream prematurely closed connection — ה-upstream קרס באמצע התגובה
• no live upstreams — כל שרתי ה-backend סומנו ככשולים
• upstream sent invalid header — התגובה לא הייתה HTTP תקין

לוגים של האפליקציה מספרים לך למה ה-upstream נכשל:

tail -f /var/log/your-app/app.log

חפש קריסות, שגיאות מחסור בזיכרון, או חריגות שלא טופלו.

האם משהו חוסם את החיבור?

telnet backend-server 3000
nc -zv backend-server 3000

אם אלה נכשלים, בדוק חומות אש והגדרות רשת.

מניעת שגיאות 502

הפעל מספר upstreams

שרת backend יחיד הוא נקודת כשל יחידה:

upstream backend {
    server backend1.example.com:3000;
    server backend2.example.com:3000;
    server backend3.example.com:3000;
}

אם אחד נכשל, ה-gateway מנתב לאחר.

הגדר בדיקות תקינות

אל תשלח תעבורה לשרתים מתים:

upstream backend {
    server backend1.example.com:3000 max_fails=3 fail_timeout=30s;
    server backend2.example.com:3000 max_fails=3 fail_timeout=30s;
}

אחרי 3 כשלים, השרת מסומן כמושבת למשך 30 שניות.

הפעל מעבר אוטומטי לגיבוי

location /api {
    proxy_pass http://backend;
    proxy_next_upstream error timeout http_502;
    proxy_next_upstream_tries 2;
}

אם ה-upstream הראשון מחזיר 502, נסה את הבא אוטומטית.

הגדר פסקי זמן סבירים

proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;

קצר מדי ותקבל שגיאות 502 מזויפות במהלך תגובות איטיות. ארוך מדי והמשתמשים ימתינו לנצח.

טיפול בשגיאות 502 כלקוח

שגיאות 502 הן לעיתים קרובות חולפות — שרת שמאתחל, תקלת רשת קצרה. נסה שוב עם השהייה מעריכית:

async function fetchWithRetry(url, maxRetries = 3) {
    for (let attempt = 0; attempt < maxRetries; attempt++) {
        const response = await fetch(url);
        
        if (response.status === 502 && attempt < maxRetries - 1) {
            const waitTime = Math.pow(2, attempt) * 1000;
            await new Promise(resolve => setTimeout(resolve, waitTime));
            continue;
        }
        
        return response;
    }
}

המתן שנייה, אחר כך שתיים, אחר כך ארבע. לעיתים קרובות הבעיה נפתרת מעצמה.

הנקודה העיקרית

שגיאת 502 Bad Gateway אינה אשמת ה-gateway. ה-gateway עובד כראוי — הוא מספר לך שמשהו מאחוריו אינו. כשאתה רואה שגיאת 502, הסתכל מעבר לשליח כדי למצוא את הבעיה האמיתית: שרת אפליקציה שקרס, מחיצת רשת, או backend שמחזיר משהו שאינו HTTP תקין.

ה-gateway רק עושה את עבודתו: מדווח נאמנה שהשרת שמאחוריו נכשל.

שאלות נפוצות על 502 Bad Gateway

למה אני רואה שגיאות 502 רק לפעמים?

אם יש לך מספר שרתי backend ורק אחד מהם נכשל, תראה שגיאות 502 מדי פעם — רק כשמאזן העומסים מנתב לשרת השבור. בדוק את תקינות כל ה-upstreams שלך, לא רק אחד.

האם כדאי לרענן את הדף כשאני רואה 502?

כן. שגיאות 502 הן לעיתים קרובות חולפות — שרת שמאתחל, בעיית רשת רגעית. המתנה של כמה שניות ורענון עובדת לעיתים קרובות. אם הבעיה נמשכת, היא חמורה יותר.

איך 502 שונה מאתר שהוא "למטה"?

כשאתר מושבת לחלוטין, בדרך כלל לא ניתן להתחבר אליו כלל — הדפדפן שלך מסתובב לנצח או מציג "connection refused". שגיאת 502 פירושה שהצלחת להתחבר למשהו (ה-gateway), אבל השרתים שמאחוריו אינם פועלים. הדלת הקדמית פתוחה; הבניין שמאחוריה עולה באש.

האם 502 יכולה להיגרם על ידי הדפדפן שלי או חיבור האינטרנט?

לעיתים נדירות. שגיאת 502 נוצרת על ידי שרת, לא הדפדפן שלך. אם אתה רואה שגיאות 502, הבעיה כמעט בוודאי נמצאת בצד השרת. עם זאת, proxy שהוגדר בצורה שגויה ברשת שלך יכול תיאורטית ליצור אחת.

למה CDNs מציגים שגיאות 502 לאתרים שאני יודע שפועלים?

ה-CDN יכול להגיע לאינטרנט, אבל אינו יכול להגיע לשרת המקור הספציפי של אותו אתר. האתר עשוי לעבוד עבור אנשים שמתחברים ישירות, אבל הנתיב של ה-CDN למקור שבור — לעיתים קרובות בגלל כללי חומת אש, בעיות DNS, או ששרת המקור חוסם את כתובות ה-IP של ה-CDN.