שגיאה 500, 502, 503 או 504 באתר: מה זה ואיך מתקנים

האתר מציג שגיאה 500, 502, 503 או 504 ואתם לא יודעים מאיפה להתחיל? לפי התקן, כל הקודים שמתחילים ב-5 אומרים שהשרת נכשל בטיפול בבקשה, כלומר הבעיה בצד השרת ולא אצל הגולש. ההבדל בין הקודים מצביע על המקום שבו השרשרת נשברה. שגיאה 500 מגיעה בדרך כלל מהאפליקציה עצמה, 502 ו-504 מגיעות משרת שעומד לפניה ולא קיבל ממנה תשובה תקינה או תשובה בזמן, ו-503 אומרת שהשירות לא זמין כרגע, בגלל עומס או תחזוקה.

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

מה ההבדל בין שגיאה 500, 502, 503 ו-504

ההגדרות שבטבלה לקוחות מ-RFC 9110, התקן שמגדיר את הסמנטיקה של HTTP. העמודות של הסיבה הנפוצה ושל הבדיקה הראשונה הן מניסיון תפעולי, לא מהתקן.

קוד	שם	מה התקן אומר	סיבה נפוצה	מה בודקים קודם
500	Internal Server Error	השרת נתקל במצב לא צפוי שמנע ממנו להשלים את הבקשה	שגיאה בקוד, תוסף שקרס, הגדרה שגויה, הרשאות קבצים	יומן השגיאות של האפליקציה ושל שרת האינטרנט
502	Bad Gateway	שרת שפועל כ-gateway או proxy קיבל תשובה לא תקינה מהשרת שמאחוריו	PHP-FPM או שרת האפליקציה כבוי, קרס או דחה את החיבור	האם השירות שמאחורי ה-proxy רץ, ויומן השגיאות של nginx
503	Service Unavailable	השרת לא יכול לטפל בבקשה כרגע בגלל עומס זמני או תחזוקה מתוכננת	מצב תחזוקה, או עומס שמילא את תהליכי השרת	האם מוגדר מצב תחזוקה, וכמה משאבים פנויים
504	Gateway Timeout	שרת שפועל כ-gateway או proxy לא קיבל תשובה בזמן מהשרת שמאחוריו	שאילתה איטית, קריאה לשירות חיצוני שנתקעה, סקריפט ארוך	זמני ה-timeout, שאילתות איטיות ויומן ה-slowlog

שימו לב לניסוח של 502 ו-504: השרת שמחזיר אותן הוא לא השרת שנכשל. הוא מדווח על מה שקרה לשרת שמאחוריו.

מי אחראי לשגיאה: האפליקציה, שרת האינטרנט או ה-CDN

בקשה לאתר עוברת בדרך כלל כמה תחנות. באתר וורדפרס טיפוסי השרשרת נראית כך: דפדפן, לפעמים CDN או proxy, שרת אינטרנט כמו nginx או Apache, PHP-FPM שמריץ את הקוד, ומסד נתונים.

• שגיאה 500 נוצרת בדרך כלל בתחנה האחרונה שטיפלה בבקשה: הקוד, PHP או הגדרה של שרת האינטרנט, למשל כלל שגוי בקובץ .htaccess.
• שגיאות 502 ו-504 נוצרות בתחנה שמעבירה בקשות הלאה. אם יש CDN לפני האתר, ייתכן שה-CDN הוא שמחזיר אותן כי השרת שלכם לא ענה. בלי CDN, זה בדרך כלל nginx שמדווח על PHP-FPM או על שרת אפליקציה.
• שגיאה 503 יכולה להגיע מכל תחנה. לפעמים היא מכוונת, כמו מצב תחזוקה, ולפעמים היא סימן שהשרת עמוס.

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

סדר אבחון מהיר לשגיאות 5xx

1. האם האתר נפל לכולם

בדקו מרשת אחרת, למשל מהסלולר, או בכלי הבדיקה שקישרנו למעלה. הכלי שולח בקשה מהשרתים שלנו ומחזיר את מצב הזמינות, את קוד התגובה ואת זמן התגובה. אם הקוד שמתקבל מבחוץ הוא 5xx, הבעיה באתר. אם האתר עונה תקין מבחוץ, חפשו בצד שלכם: מטמון הדפדפן, VPN, חומת אש או DNS מקומי.

2. כותרות התגובה

כותרות התגובה מראות את קוד הסטטוס המדויק ואיזו תוכנה ענתה. משורת הפקודה:

curl -I --proto-default https example.co.il

הפקודה שולחת בקשת HEAD ומציגה רק את הכותרות. האפשרות --proto-default https אומרת ל-curl להשתמש ב-HTTPS כשהכתובת נכתבה בלי פרוטוקול, ובמקום example.co.il כותבים את הדומיין שלכם. יש אפליקציות שמגיבות ל-HEAD אחרת מאשר לבקשת GET רגילה, ולכן כדאי לבדוק גם כך:

curl -sS -o /dev/null -D - --proto-default https example.co.il

בלי טרמינל אפשר להשתמש בבדיקת כותרות HTTP, שמציגה את כל הכותרות ואת שרשרת ההפניות, עד חמש הפניות. בתוצאה מחפשים את כותרת Server, כותרות שמזהות CDN, ואת Retry-After אם היא קיימת.

3. יומני השגיאות

כאן נמצאת בדרך כלל התשובה. תיעוד Apache מגדיר את יומן השגיאות כמקום הראשון לחפש בו כשיש תקלה. הנתיבים תלויים בהפצה ובהגדרות. ב-Debian וב-Ubuntu הם בדרך כלל אלה:

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/apache2/error.log

בהפצות ממשפחת Red Hat יומן Apache נמצא בדרך כלל ב-/var/log/httpd/error_log. אם הקובץ לא שם, הנתיב מוגדר בהוראה ErrorLog של Apache או error_log של nginx. כדי לראות שגיאות בזמן שהן קורות, מריצים tail -f על היומן ומרעננים את העמוד בדפדפן.

ב-nginx, שורות שמזכירות upstream מצביעות על התחנה שמאחורי nginx. timeout בקריאה מה-upstream מתאים בדרך כלל ל-504, וחיבור שנדחה או נסגר מתאים בדרך כלל ל-502.

4. משאבים: דיסק, זיכרון ומעבד

דיסק מלא ושרת שנגמר לו הזיכרון הם שתי סיבות נפוצות לשגיאות 500 ו-502 שמופיעות "פתאום". הפקודות הבאות רק קוראות מידע:

df -h
df -i
free -m
uptime
journalctl -k --since "1 hour ago" | grep -i "out of memory"

הפקודה df -h מציגה נפח פנוי, ו-df -i מציגה inodes, שיכולים להיגמר גם כשיש נפח פנוי. השורה האחרונה מחפשת ביומן הליבה מקרים שבהם מערכת ההפעלה סגרה תהליך בגלל חוסר בזיכרון. אם השרת חסר זיכרון באופן קבוע, הפתרון הוא בדרך כלל יותר משאבים ולא עוד הגדרות. את חבילות המשאבים אפשר להשוות במחירון שרתי VPS.

5. PHP-FPM וזמני timeout

ברוב אתרי PHP שרצים מאחורי nginx, שגיאות 502 ו-504 קשורות ל-PHP-FPM:

systemctl status nginx
systemctl status 'php*-fpm'

אם PHP-FPM לא רץ, nginx לא יכול להעביר אליו בקשות, והתוצאה היא 502. אם הוא רץ אבל כל התהליכים שלו תפוסים, בקשות חדשות מחכות בתור. ההגדרה pm.max_children קובעת את מספר הבקשות שמטופלות במקביל, וכשהיא מתמלאה, ביומן של PHP-FPM מופיעה אזהרה שמזכירה אותה.

ל-504 יש בדרך כלל קשר לזמנים. ב-nginx, ערך ברירת המחדל של fastcgi_read_timeout ושל proxy_read_timeout הוא 60 שניות. הזמן הזה נמדד בין שתי קריאות רצופות, לא על כל התשובה. אם הסקריפט לא שולח דבר במשך 60 שניות, nginx סוגר את החיבור. לפני שמאריכים את הזמן, בדקו מה איטי: הגדרת request_slowlog_timeout ב-PHP-FPM כותבת backtrace של בקשות איטיות לקובץ slowlog, וזה בדרך כלל מראה את הפונקציה או את השאילתה שנתקעה.

6. מה השתנה לאחרונה

הרבה שגיאות 5xx מתחילות אחרי שינוי: עדכון תוסף, עדכון גרסת PHP, שינוי בקובץ הגדרות, פריסת קוד חדש, או שינוי DNS שהפנה את האתר לשרת אחר. השוו את שעת תחילת השגיאות לשעת השינוי האחרון. אם הן תואמות, החזרה לגרסה הקודמת היא בדרך כלל הדרך המהירה להחזיר את האתר, ואת הבירור עושים אחר כך.

7. תוספים ותבניות

באתרים שמבוססים על מערכת ניהול תוכן, תוסף שקורס הוא חשוד מרכזי לשגיאה 500. הדרך הבטוחה לבדוק היא בסביבת בדיקה, או על ידי השבתה זמנית של התוספים ובדיקה של כל אחד בנפרד.

שגיאה 500 בוורדפרס

מאז גרסה 5.2 יש בוורדפרס מנגנון לטיפול בשגיאות קריטיות. כשקוד PHP קורס, הגולשים רואים את ההודעה "There has been a critical error on this website", והשרת מחזיר קוד 500. במקביל נשלח מייל לכתובת המנהל עם תיאור התקלה וקישור לכניסה ל-Recovery Mode. במצב הזה התוספים או התבנית שגרמו לקריסה מושהים רק עבור מי שנכנס דרך הקישור, כך שאפשר להיכנס לניהול ולהשבית אותם.

אם המייל לא הגיע, מפעילים רישום שגיאות בקובץ wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

עם WP_DEBUG_LOG השגיאות נכתבות לקובץ debug.log, בדרך כלל בתיקייה wp-content. ההגדרה WP_DEBUG_DISPLAY על false מונעת מהן להופיע בעמודים שהגולשים רואים. אחרי התיקון מחזירים את WP_DEBUG ל-false, כי הקובץ עלול לחשוף נתיבים ופרטים טכניים.

אם אין גישה לניהול, אפשר לשנות זמנית את שם התיקייה wp-content/plugins דרך FTP או מנהל הקבצים. וורדפרס לא ימצא את התוספים וישבית את כולם. אם האתר חזר, מחזירים את השם המקורי ומפעילים את התוספים מחדש אחד אחד, עד שהשגיאה חוזרת. באתר שרץ על Apache כדאי לבדוק גם את .htaccess, כי כלל שגוי בו מחזיר 500 עוד לפני שוורדפרס נטען.

לא כל תקלה בוורדפרס היא 5xx. שגיאת הרשאות מחזירה 403, והטיפול בה שונה, כפי שמוסבר במדריך איך מתקנים שגיאת 403 Forbidden. ואם האתר עובד אבל איטי, ולפעמים מגיע ל-504 בשעות עומס, המדריך למה אתר וורדפרס איטי עוזר למצוא את הסיבה.

שגיאה 503, מצב תחזוקה וכותרת Retry-After

לפי RFC 9110, קוד 503 מתאר מצב זמני, עומס או תחזוקה מתוכננת, והשרת רשאי לשלוח איתו את הכותרת Retry-After. הכותרת אומרת כמה זמן השירות צפוי להיות לא זמין, כמספר שניות או כתאריך ושעה מלאים. Retry-After: 120, למשל, מבקש לנסות שוב בעוד שתי דקות.

בוורדפרס, בזמן עדכון נוצר קובץ בשם .maintenance בתיקיית השורש של האתר. כל עוד הקובץ קיים ונוצר לפני פחות מעשר דקות, וורדפרס מחזיר 503 עם Retry-After: 600 ואת ההודעה "Briefly unavailable for scheduled maintenance". אחרי עשר דקות וורדפרס מתעלם מקובץ ישן. אם האתר תקוע במצב תחזוקה אחרי עדכון שנקטע, מסירים את הקובץ .maintenance ובודקים שהעדכון הושלם.

כשאתם מורידים את האתר לתחזוקה קצרה ומתוכננת, החזירו 503 עם Retry-After, ולא עמוד תחזוקה שמחזיר קוד 200. כך גם גוגל יודע שמדובר במצב זמני.

מה קורה בגוגל כשהאתר מחזיר שגיאות 5xx

לפי התיעוד של Google Search Central, שגיאות 5xx וגם 429 גורמות לסורקים של גוגל להאט את קצב הסריקה של האתר. ההאטה יחסית למספר הכתובות שמחזירות שגיאה. כתובות שכבר נמצאות באינדקס נשמרות בהתחלה, אבל כתובות שמחזירות שגיאת שרת באופן מתמשך מוסרות בסוף מהאינדקס. כשהאתר חוזר להחזיר 2xx, גוגל מעלה את קצב הסריקה בהדרגה.

למקרה של סגירה מתוכננת, גוגל ממליץ להחזיר 503 עם Retry-After לתקופה קצרה של יום או יומיים, ולא יותר מכמה ימים. לסגירה ארוכה יותר הוא ממליץ על עמוד בית שמחזיר 200 עם הסבר לגולשים. יש גם אזהרה מפורשת: לא להחזיר 503 לקובץ robots.txt, כי זה חוסם את כל הסריקה.

התיעוד לא נותן מספר ימים שאחריו כתובת יוצאת מהאינדקס. ככל שהשגיאות נמשכות יותר זמן ומופיעות ביותר עמודים, הסיכון גדל. דוח נתוני הסריקה ב-Search Console מראה אם גוגל נתקל בשגיאות שרת באתר שלכם.

שאלות נפוצות

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

לא בהכרח. שגיאה 500 מגיעה בדרך כלל מהקוד, מתוסף או מהגדרה של האתר. חברת האחסון אחראית כשהסיבה בתשתית, למשל דיסק מלא בשרת משותף או שירות שקרס בצד שלה. יומן השגיאות יראה לכם איפה הבעיה.

מה ההבדל בין 502 ל-504?

בשתיהן שרת ביניים מדווח על השרת שמאחוריו. ב-502 הוא קיבל תשובה לא תקינה, או שהחיבור נדחה. ב-504 הוא לא קיבל תשובה בזמן. 502 מצביעה בדרך כלל על שירות כבוי או קורס, ו-504 על משהו איטי.

השגיאה מופיעה רק לפעמים. מה זה אומר?

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

כמה זמן אפשר להשאיר את האתר במצב תחזוקה?

לפי ההנחיות של גוגל, 503 מתאים לתקופה קצרה של יום או יומיים. אם הסגירה ארוכה יותר, עדיף עמוד הסבר שמחזיר 200.

האם להאריך את זמני ה-timeout כדי להיפטר מ-504?

רק אחרי שמבינים מה איטי. הארכת timeout מסתירה בקשה איטית, והגולש עדיין מחכה. קודם בדקו ב-slowlog ובשאילתות של מסד הנתונים, ושנו את הזמן רק לפעולות שבאמת ארוכות, כמו ייבוא נתונים.

מתי כדאי לעבור לשרת מנוהל

אם שגיאות 5xx חוזרות ואין אצלכם מי שיודע לקרוא יומני שרת ולטפל בתקלה באמצע הלילה, שווה לבדוק שרת VPS מנוהל. ב-VPS המנוהל של אמפייר אייאל הצוות שלנו אחראי על שכבת השרת: עדכוני מערכת ההפעלה, הקשחת אבטחה וחומות אש, ניטור, גיבויים לפי מדיניות שמסכמים איתכם וטיפול בתקלות. השרתים רצים על דיסקי NVMe Enterprise בחוות שרתים בישראל, עם הגנת DDoS מובנית, והסכם השירות מתחייב לזמינות חודשית של 99.9%. בתקלה קריטית המענה הראשון הוא עד שעה, והתמיכה אנושית ובעברית.

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