שגיאות 502, 503 ו-504 באתר: מה כל אחת אומרת ואיך מתקנים בקלאודוויז

עודכן לאחרונה: 07.11.2026 · מאת עשהאל דרייר

בקצרה: שגיאה 503 אומרת שהשירות לא זמין כרגע, 502 אומרת שהשרת קיבל תשובה שבורה מהשירות שמאחוריו, ו-504 אומרת שהתשובה לא הגיעה בזמן. בקלאודוויז (Cloudways) ארבע סיבות מכסות כמעט כל מקרה: שרת עמוס, PHP-FPM שהגיע לתקרה, סקריפט שחרג ממגבלת הזמן, או תוסף בעייתי. ב-503 יש עוד שתי סיבות קבועות: וורדפרס שנתקעה במצב תחזוקה, ושטף בקשות לקבצי CSS חסרים של אלמנטור. התיקון המהיר הראשון בשלושתן הוא הפעלה מחדש ב-Manage Services.

⏱ זמן ביצוע: 5–30 דקות · רמת קושי: בינוני · נבדק לאחרונה מול התיעוד הרשמי והשרת שלנו: 07.11.2026

למה מופיעות שגיאות 502, 503 ו-504?

כדי להבין את השגיאה, צריך להכיר את שרשרת השירותים. בשרת של קלאודוויז, Nginx עומד בחזית ומשמש כ"פרוקסי הפוך" (Reverse Proxy): הוא מקבל כל בקשה מהדפדפן ומעביר אותה הלאה. מאחוריו יושבים שירותי קאש כמו Varnish, שרת Apache (בסטאק Hybrid), ו-PHP-FPM, שמריץ בפועל את הקוד של וורדפרס. בסוף השרשרת נמצא מסד הנתונים.

כש-Nginx שולח בקשה הלאה ומקבל תשובה שבורה או לא מקבל תשובה בכלל, הוא מחזיר לגולש 502 או 504. הנקודה החשובה: Nginx עצמו בסדר, והבעיה נמצאת באחד השירותים שמאחוריו או בעומס שמונע מהם לענות. אם האתר מאחורי Cloudflare ואתם רואים שגיאה 521, 522 או 525, קראו את המדריך לשגיאות 5xx של Cloudflare.

קוד	מה קרה	הסיבות הנפוצות בקלאודוויז
502 Bad Gateway	השירות שמאחורי Nginx החזיר תשובה לא תקינה או קרס	PHP-FPM תקוע, עומס CPU או זיכרון, תוסף בעייתי
503 Service Unavailable	השירות לא זמין באופן זמני	שירות שנעצר, PHP-FPM בתקרת התהליכים, וורדפרס במצב תחזוקה, שטף בקשות לקבצים חסרים
504 Gateway Timeout	השירות לא הספיק לענות בזמן	סקריפט ארוך (ייבוא, גיבוי, דוח), שאילתות כבדות למסד הנתונים

ההגדרות הרשמיות של שלושת הקודים נמצאות ב-MDN: 502, 503 ו-504. שגיאת 500, לעומת זאת, אומרת שהקוד רץ ונכשל. אם זה מה שאתם רואים, המדריך לשגיאת 500 מתאים יותר.

לפני שמתחילים

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

איך לתקן 502 Bad Gateway – שלב אחר שלב

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

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

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

1. בפאנל הניהול, פתחו את השרת ובחרו Manage Services.
2. בדקו שכל השירותים במצב פעיל. שירות שמסומן כעצור הוא כמעט בוודאות האשם.
3. לחצו Restart בשורה של PHP-FPM, ואחר כך באותו אופן ב-Apache וב-Nginx.
4. בשורה של Varnish, נקו את הקאש (Purge) כדי שגולשים לא יקבלו גרסה שמורה של עמוד השגיאה.
5. אם יש סימנים לבעיה במסד הנתונים, הפעילו מחדש גם את MariaDB או MySQL.

שימו לב: הפעלה מחדש של Memcached מוחקת את כל הנתונים השמורים בו, והאתר יהיה איטי מעט עד שהקאש ייבנה מחדש. אם השגיאה נעלמה אחרי ההפעלה מחדש וחוזרת אחרי כמה שעות, השירות לא היה הבעיה האמיתית. המשיכו לשלב 2.

שלב 2: בדקו אם השרת עמוס

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

1. פתחו את השרת ובחרו Monitoring.
2. בדקו את הגרפים של CPU, זיכרון ודיסק בשעות שבהן הופיעה השגיאה.
3. בדקו גם את גרף החיבורים למסד הנתונים. עלייה חדה בו בזמן עומס היא סימן מובהק.

מה עושים לפי מה שמצאתם:

מה ראיתם	הסיבה הסבירה	הפתרון
CPU וזיכרון גבוהים לאורך זמן, והתנועה אמיתית	השרת קטן מדי לאתר	הגדלת שרת (Vertical Scaling)
קפיצות CPU חדות בדקות קבועות	משימות Cron כבדות שרצות בתדירות גבוהה מדי	לפזר את המשימות, עם רווח של 15 דקות לפחות ביניהן
הרבה בקשות מכמה כתובות IP בודדות	בוטים או מתקפת DoS	חסימת IP ב-Firewall של השרת, ובדיקת ההגדרות המתקדמות שלו (Enhanced DoS Protection ו-Anti-Bot Protection)
חיבורים רבים למסד הנתונים	יותר מדי גולשים בו-זמנית או שאילתות איטיות	העלאת Max Connections, קאש אובייקטים, ובדיקת תוספים כבדים
MariaDB מופעל מחדש לבד, ו-swap מלא	הזיכרון נגמר, ו-OOM Killer של לינוקס הורג תהליך	המדריך ל-MariaDB שנופל ול-OOM Killer

למגבלת החיבורים של MySQL, ההגדרה Max Connections Limit נמצאת ב-Settings & Packages של השרת, וברירת המחדל שלה היא 150. מי שמכיר לינוקס יכול להתחבר ב-SSH ולהריץ htop כדי לראות בזמן אמת איזה תהליך תופס משאבים. ניתוח מעמיק של עומס תמצאו במדריך לאתר איטי ו-CPU גבוה.

שלב 3: הגדילו את מגבלת זמן הריצה (בעיקר ל-504)

כשסקריפט PHP רץ יותר מהזמן שהוקצב לו, הוא נעצר, וביומן השגיאות מופיע "Maximum Execution Time Exceeded". זה קורה בייבוא מוצרים לחנות, ביצירת דוחות, בגיבוי דרך תוסף או בתוסף שפונה לשירות חיצוני איטי.

1. פתחו את השרת, בחרו Settings & Packages ועברו ללשונית Basic.
2. הגדילו את Execution Limit. ברירת המחדל היא 300 שניות, וההמלצה הרשמית היא להישאר מתחת ל-900.
3. שמרו. אם לאפליקציה יש הגדרת PHP-FPM משלה, פתחו את הגדרות ה-PHP של האפליקציה, חפשו את השורה ;php_admin_value[max_execution_time], הסירו את הנקודה-פסיק שבתחילתה והגדילו את הערך.

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

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

שלב 4: בדקו תוספים וערכת עיצוב

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

1. נטרלו את כל התוספים, מלוח הניהול או ב-SSH עם הפקודה wp plugin deactivate --all בתיקיית public_html.
2. אם האתר חזר, הפעילו את התוספים אחד-אחד ורעננו אחרי כל אחד, עד שהשגיאה חוזרת.
3. אם נטרול התוספים לא עזר, החליפו זמנית לערכת עיצוב ברירת מחדל של וורדפרס.
4. כשמצאתם את האשם, השאירו אותו מנוטרל ודווחו למפתח.

מה זה שגיאה 503 Service Unavailable ואיך מתקנים אותה?

503 אומרת שהשירות לא זמין כרגע, ולא שהוא החזיר תשובה שבורה. לפי MDN, זה מצב זמני מטבעו, למשל תחזוקה או עומס, ואפשר לצרף לו כותרת Retry-After. בפועל, ברוב המקרים שלבים 1 ו-2 למעלה פותרים גם אותה. אלה ארבע הסיבות שכדאי לבדוק במיוחד.

וורדפרס תקועה במצב תחזוקה (.maintenance)

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

1. התחברו ב-SFTP או במנהל הקבצים לתיקיית public_html של האפליקציה.
2. הציגו קבצים מוסתרים, ומחקו את .maintenance.
3. היכנסו ללוח הניהול ובדקו איזה עדכון לא הושלם. הריצו אותו שוב.

אם המסך לבן ולא מופיעה הודעה בכלל, זו כבר תקלה אחרת, שמוסברת במדריך למסך לבן ו-Maintenance Mode תקוע. אגב, באתר שלנו בדקנו ב-7.11.2026 שאין קובץ .maintenance שנשכח.

PHP-FPM הגיע לתקרת התהליכים

PHP-FPM מריץ מספר מוגבל של תהליכים (workers) לכל אפליקציה. כשכולם עסוקים, בקשות חדשות מחכות בתור, ובסוף נגמרות ב-503 או ב-504. זה קורה בעומס אמיתי, אבל גם כשכמה בקשות איטיות תופסות את כל התהליכים.

בפניות שלנו לתמיכה של קלאודוויז ראינו שני צדדים של אותה בעיה. בשרת אחד היו כ-108 תהליכי FPM ל-36 אתרים. בשרת אחר היו כ-112 תהליכים במצב סרק, וקיצוץ שלהם ל-3 שחרר כ-7.5GB זיכרון. בשני המקרים הזיכרון נגמר, ו-MariaDB נפל. איך מאבחנים ומכוונים את זה, פירטנו במדריך ל-MariaDB שנופל ול-OOM Killer. אם האתר איטי ו-OPcache מלא, ראו גם את המדריך ל-OPcache מלא ב-PHP-FPM.

שטף 503 על קבצי CSS של אלמנטור

זה מקרה אמיתי מהשרתים שלנו. אחרי שקבצי ה-CSS שאלמנטור מייצר נמחקו, כל צפייה בעמוד ביקשה קבצים שלא קיימים. הבקשות חזרו כ-404, 500 ו-503, וכל אחת הריצה PHP. אפליקציה אחת צרכה כך כ-69% מזיכרון האפליקציות בשרת, והפילה איתה את MariaDB.

התיקון היה לבנות את הקבצים מחדש. בגרסאות הנוכחיות של אלמנטור זה הכפתור Clear Files & Data בכלים (Tools), לפי מרכז העזרה של Elementor. אחר כך מנקים את הקאש של Varnish ושל Cloudflare. ולקח שלמדנו בדרך הקשה: אל תמחקו ידנית קבצים או תיקיות בתוך elementor/css. קוד שמחק תיקייה כזו שבר אתר של לקוח שלנו, ושחזור מגיבוי בן שבוע לא עזר. עוד על אלמנטור מהיר בשרת, במדריך לאתר אלמנטור מהיר.

חלון תחזוקה של השרת

בדקו ב-Settings & Packages מתי מוגדר חלון התחזוקה השבועי. אם השגיאה הופיעה בדיוק אז ונעלמה, זה הסבר סביר.

האם שגיאת 503 פוגעת בקידום בגוגל?

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

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

איך מונעים את זה בפעם הבאה?

• הפעילו התראות ניטור על השרת, כדי לדעת על עומס CPU או זיכרון לפני שהגולשים רואים שגיאה.
• לפני מבצע או קמפיין, הגדילו את השרת זמנית. החיוב לפי שעה, כך שיומיים בשרת גדול עולים מעט.
• הפעילו קאש בכל השכבות: Varnish, קאש אובייקטים ותוסף קאש. כל בקשה שנענית מהקאש לא מגיעה ל-PHP.
• עקבו אחרי שגיאות 404 חוזרות על קבצי CSS ו-JS. הן נראות תמימות, אבל כל אחת מריצה PHP.
• שקלו את Cloudways Copilot, שמנטר את השרת, מזהה תקלות ומציע תיקון.

טעויות נפוצות ואיך לפתור אותן

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

חוסמים IP ב-.htaccess באפליקציה ב-Lightning Stack: בסטאק Lightning (Nginx בלבד) הקובץ לא נקרא. חסמו כתובות ב-Firewall של השרת, וכללים אחרים הגדירו ב-Web Rules.

מגדילים Execution Limit ל-3,600 שניות: בקשות תקועות יחזיקו תהליכי PHP פתוחים ויחסמו גולשים אחרים, וכך עלולות לגרום ל-502 או 503 נוסף. הישארו מתחת ל-900 שניות.

מוחקים ידנית את תיקיית ה-CSS של אלמנטור: משתמשים בכלי של אלמנטור עצמו, לא ב-SFTP.

השגיאה רק דרך Cloudflare: אם הדומיין עובר דרך Cloudflare ועמוד השגיאה ממותג Cloudflare, בדקו קודם שהשרת עצמו עונה, ושה-DNS מפנה לכתובת ה-IP הנכונה. בעיות במסד הנתונים מקבלות הודעה אחרת לגמרי, שמוסברת במדריך ל-Error Establishing a Database Connection.

אם שום שלב לא עזר, פתחו פנייה לתמיכה של קלאודוויז וצרפו את שעת התקלה, צילום של גרפי הניטור ומה ניסיתם. התמיכה זמינה 24/7.

מקורות

• Cloudways Knowledge Base: How to fix 502 bad gateway error
• Cloudways Knowledge Base: What can I do in the manage services section on Cloudways
• Cloudways Knowledge Base: How to manage your server settings
• MDN Web Docs: 502, 503, 504
• How HTTP status codes and network errors affect Google Search – Google Search Central
• Clear Files & Data – Elementor Help Center

הנתונים שלנו: הערך של max_execution_time וקיום הקובץ .maintenance נבדקו בקריאה בלבד בשרת של האתר, 7.11.2026. מספרי התהליכים, הזיכרון ומקרה אלמנטור לקוחים מפניות שלנו לתמיכה של קלאודוויז בספטמבר ובאוקטובר 2026, בשרתים עם עשרות אתרי וורדפרס.

שאלות נפוצות

מדריכים קשורים

• איך לתקן שגיאת 500 Internal Server Error
• MariaDB נופל ו-OOM Killer: איך מאבחנים
• OPcache מלא בוורדפרס ו-PHP-FPM
• שגיאות 5xx של Cloudflare: 520 עד 526
• הגדלת שרת ו-RAM בקלאודוויז
• מסך לבן בוורדפרס ו-Maintenance Mode תקוע
• אתר איטי או CPU גבוה: איך מאתרים את הסיבה
• Error Establishing a Database Connection
• Mixed Content ו-Too Many Redirects בוורדפרס
• אחסון אתרים בקלאודוויז: למה שרת מנוהל
• כל המדריכים בתחום: מדריכי פתרון תקלות

מקור רשמי: How to Fix 502 Bad Gateway Error, ובנוסף What Can I Do in the Manage Services Section on Cloudways ו-How to Manage Your Server Settings (Cloudways Knowledge Base). המדריך נכתב ונבדק על ידי עשהאל דרייר · עודכן: 07.11.2026

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