אבחון מסך לבן של מוות (WSOD) ב-1C-Bitrix
עדכנת את האתר שלך—וראית דף ריק. אין שגיאות, אין HTML. רק מסך לבן. השרת מחזיר 200 או 500, אבל הגוף ריק. זהו WSOD (מסך לבן של מוות). ב-Bitrix, הבעיה מתרחשת לעתים קרובות יותר ממה שהיית רוצה: חציצת פלט מסתירה שגיאות PHP קטלניות. למהנדסים שלנו, עם 8 שנות ניסיון ב-Bitrix, יש פתרונות למאות מקרים כאלה. נראה לך גישה שיטתית לאבחון ואיך לא לבזבז זמן.
מדוע מתרחש המסך הלבן?
מפרש ה-PHP מפסיק את הביצוע על שגיאה קטלנית (E_ERROR, E_PARSE, E_COMPILE_ERROR). אם display_errors כבוי (כפי שצריך להיות בסביבת ייצור), אין פלט. ואם log_errors כבוי או שנתיב היומן שגוי, אין גם רישום ביומן. התוצאה: תגובה ריקה.
Bitrix מחמיר את הבעיה עם חציצת פלט. הליבה משתמשת ב-ob_start() בשלב מוקדם של האתחול עבור פונקציות דחויות וקאש מרוכב. אם מתרחשת שגיאה בתוך חציץ שמעולם לא נשפך, הלקוח מקבל כלום—אפילו לא HTML חלקי. זו הסיבה העיקרית לכך ששיטות סטנדרטיות כמו error_reporting ב-.htaccess לא עוזרות.
כיצד לאבחן WSOD: שיטה שלב-אחר-שלב
1. בדוק את יומן השגיאות של PHP. זו הפעולה הראשונה והחשובה ביותר. קבע את הנתיב:
-
php -i | grep error_log— עבור CLI -
phpinfo()— עבור web (צור קובץ זמני) - תצורת בריכת php-fpm:
/etc/php-fpm.d/www.conf→php_admin_value[error_log]
אם היומן ריק, ודא ש-log_errors = On מופעל ושנתיב הקובץ ניתן לכתיבה על ידי משתמש php-fpm (בדרך כלל www-data או nginx).
2. הפעל זמנית פלט שגיאות. הוסף זאת לתחילת index.php, לפני כל includes:
ini_set('display_errors', 1); ini_set('display_startup_errors', 1); error_reporting(E_ALL); אם מופיעה שגיאה כעת, יש לך את האבחון. הודעות אופייניות:
-
ini_set('display_errors', 1); ini_set('display_startup_errors', 1); error_reporting(E_ALL);— קובץ PHP שבור -
Parse error: syntax error— נזק לליבה -
Fatal error: Class 'CBitrixComponent' not found— מחסור בזיכרון
אם המסך עדיין לבן, השגיאה מתרחשת לפני שהקוד שלך רץ (בשלב טעינת הרחבות PHP) או שהתהליך נהרג על ידי OOM-killer.
3. בדוק יומני מערכת.
dmesg | grep -i "oom\|kill\|segfault" journalctl -u php-fpm --since "1 hour ago" Segfault בתהליך PHP הוא באג בהרחבה (לעתים קרובות Fatal error: Allowed memory size exhausted, dmesg | grep -i "oom\|kill\|segfault" journalctl -u php-fpm --since "1 hour ago" , ionCube מיושן). OOM פירושו זיכרון RAM לא מספיק.
4. בדיקת ליבה מינימלית. צור קובץ Zend Guard:
<?php echo "Step 1: PHP works\n"; require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php'; echo "Step 2: Kernel loaded\n"; תוצאות:
- ריק — PHP לא יכול אפילו לבצע echo. הבעיה ברמת השרת או תצורת PHP.
- "שלב 1" — ליבת Bitrix לא נטענת. הבעיה ב-
opcache,/test_kernel.php, או בחיבור למסד הנתונים. - "שלב 1" ו-"שלב 2" — הליבה נטענת, הבעיה בדף/רכיב ספציפי.
גורמים עיקריים ל-WSOD ב-Bitrix
שגיאה ב-init.php. קובץ זה רץ על כל בקשה. שגיאה קטלנית בו מבטיחה WSOD על כל האתר. בדיקה מהירה: שנה את שם הקובץ. תיקון מהיר: מצא את שורת השגיאה באמצעות <?php echo "Step 1: PHP works\n"; require_once $_SERVER['DOCUMENT_ROOT'] . '/bitrix/modules/main/include/prolog_before.php'; echo "Step 2: Kernel loaded\n"; (בדיקת תחביר).
Opcache פגום. Zend OPcache מאחסן קוד ביניים מהודר. אם המטמון פגום (קריסה במהלך כתיבה, שינוי גרסת PHP ללא איפוס), PHP טוען קוד ביניים שבור וקורס בשקט. פתרון: הפעל מחדש את php-fpm (dbconn.php) כדי לנקות את opcache. לאמינות: .settings.php ו-php -l /bitrix/php_interface/init.php. שיטת האבחון שלנו מהירה פי 3 מהגישה הסטנדרטית.
חוסר תאימות לגרסת PHP. שדרוג PHP מ-7.4 ל-8.0 שובר אתרים המשתמשים בפונקציות שהוסרו: systemctl restart php-fpm, opcache.validate_timestamps = 1, opcache.revalidate_freq = 2. Bitrix עשוי להיטען, אבל מודול צד שלישי מפעיל שגיאה קטלנית. בדוק תאימות מראש באמצעות each() עבור כל קבצי הפרויקט.
לולאת הפניה עם גוף ריק. מודול create_function() מפנה על סמך כללים ב-mysql_*. אם כלל יוצר לולאה (A → B → A), nginx/Apache עלול לבטל את הבקשה, ולהחזיר תגובה ריקה. בדוק כותרות באמצעות php -l וספור הפניות.
שחיתות בקובצי הליבה. עדכונים לא מלאים, עריכה ידנית של קבצי ליבה, וירוסים—כל אלה יכולים להוביל לטעינה חלקית. כלי לבדיקת תקינות: main → "בדוק קבצי ליבה". אם האתר לא נטען כלל, שחזר את הליבה מגיבוי או הורד גרסה חדשה מ-1c-bitrix.ru והחלף את b_urlrewrite ו-curl -v -L URL.
טבלת זמני אבחון
| גורם | זמן אבחון | זמן תיקון |
|---|---|---|
| שגיאה ב-init.php | 15-30 דקות | 30-60 דקות |
| memory_limit מוצה | 30 דקות | 5 דקות (תצורה) |
| Opcache פגום | 10 דקות | 5 דקות (הפעלה מחדש) |
| חוסר תאימות לגרסת PHP | 1-2 שעות | 2-8 שעות (חזרה לגרסה קודמת או התאמה) |
| שחיתות בליבה | 1-3 שעות | 2-4 שעות (שחזור) |
| Segfault בהרחבת PHP | 2-4 שעות | 1-8 שעות (החלפה/עדכון הרחבה) |
תסמינים נפוצים וגורמים
| תסמין | גורם אפשרי |
|---|---|
| דף ריק בכל כתובות ה-URL | init.php, opcache, שחיתות בליבה |
| דף ריק רק בכתובות URL מסוימות | שגיאה ברכיב, תבנית |
| הדף נטען לאט, ואז מסך לבן | מחסור בזיכרון (memory_limit) |
| מסך לבן לאחר שדרוג PHP | חוסר תאימות לגרסת PHP |
מה כוללת העבודה שלנו?
כאשר אתה מזמין מאיתנו אבחון WSOD מקיף, אנחנו:
- מנתחים יומני PHP, יומני שרת web, ויומני מערכת.
- בודקים תצורת opcache והגדרות זיכרון.
- בודקים את ליבת Bitrix וקבצים
/bitrix/admin/site_checker.php,1c-bitrix.ru. - משחזרים קבצי ליבה פגומים או מעדכנים מודולים.
- מספקים דוח עם גורמים שזוהו והמלצות.
- מציעים אחריות ל-30 יום מפני הישנות בעיות דומות.
רשימת בדיקה: 5 שלבים לאבחון עצמי
1. בדוק יומן שגיאות PHP (`/var/log/php-fpm/`). 2. הפעל זמנית `display_errors` ב-`index.php`. 3. בדוק יומני מערכת באמצעות `dmesg` ו-`journalctl`. 4. צור קובץ בדיקה `test_kernel.php`. 5. שנה את שם `init.php` ובדוק את האתר.למה לסמוך עלינו באבחון?
אנחנו צוות עם 8 שנות ניסיון ב-Bitrix. השלמנו למעלה מ-1,500 פרויקטים בהקמה ושחזור אתרים. אנו משתמשים בגישה שיטתית: לא רק "הפעל שגיאות" אלא מצא את שורש הבעיה. אם אתה מתמודד עם WSOD, נבחן את הפרויקט שלך בחינם. פשוט צור קשר—נייתן לך לוחות זמנים ועלות. החיסכון הממוצע ללקוח לאחר האבחון שלנו הוא 25,000 רובל.
מקור: תיעוד טיפול בשגיאות PHP







