שגיאת "HTTP error" בהעלאת תמונה ב-WordPress: עץ החלטה שבאמת מאתר את הסיבה

“HTTP error” היא לא סיבה. זו הודאה של מעלה המדיה שהוא שלח את הקובץ לשרת וקיבל בחזרה תשובה שהוא לא הצליח לפרש כהצלחה — ולפחות שישה כשלים שאין ביניהם שום קשר מייצרים בדיוק את אותה הודעה. הניחוש בין השישה הוא הסיבה שאנשים מבזבזים אחר צהריים שלם על העלאת upload_max_filesize באתר שהבעיה האמיתית שלו היא כלל בחומת אש.

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

קודם כול: קראו את התשובה האמיתית

פתחו את כלי הפיתוח של הדפדפן, עברו ללשונית Network, והעלו את הקובץ שוב. חפשו את הבקשה אל async-upload.php. מה שחוזר משם הוא האבחנה שלכם.

מה שאתם רואים	מה זה אומר	לאן ממשיכים
403 או 406, גוף HTML	חומת אש או mod_security דחו את הבקשה	ענף א’
500, או תשובה ריקה, או גוף קטוע	‏PHP קרס או נגמר לו הזיכרון באמצע התהליך	ענף ב’
413	גוף הבקשה חרג ממגבלה בשרת	ענף ג’
200, אבל הגוף אינו JSON נקי	תוסף או ערכת עיצוב הדפיסו פלט לפני התשובה	ענף ד’
הבקשה לא מסתיימת / פג הזמן	מגבלת זמן ריצה, בדרך כלל עם קבצים גדולים	ענף ב’

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

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

שחזרו את ההעלאה, ואז קראו את wp-content/debug.log. שורה של שגיאה פטאלית נוקבת בענף במפורש. אם השורה צפופה, הדביקו אותה אל מפענח יומן השגיאות — הוא ממפה את החתימות הפטאליות הנפוצות למה שבאמת נשבר.

ענף א’ — חומת אש או כלל mod_security

קוד 403 עם עמוד HTML בגוף התשובה פירושו שהבקשה מעולם לא הגיעה ל-WordPress. משהו שיושב לפניו — ‏mod_security, ‏Cloudflare, ‏Wordfence, ‏Sucuri, או מערך הכללים של חברת האחסון עצמה — החליט שבקשת ה-POST נראית זדונית.

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

תהיו כנים עם עצמכם לגבי העצות שתמצאו כאן. קטעי קוד שמציעים לכם לזרוק את זה לתוך .htaccess:

SecFilterEngine Off
SecFilterScanPOST Off

מכוונים ל-mod_security בגרסה 1.x, שכמעט נכחדה. בשרת מודרני ההנחיות האלה או לא עושות כלום או מחזירות שגיאת 500 שמחמירה את מצב האתר. גרסאות מודרניות של mod_security משתמשות ב-SecRuleEngine, ורוב שירותי האחסון המנוהלים חוסמים ממילא דריסה שלו ברמת תיקייה. תשאלו את חברת האחסון; אל תדביקו.

ענף ב’ — מגבלות זיכרון או זמן ריצה של PHP

זה הענף הנפוץ ביותר ובעל הסימן הברור ביותר: הוא לא עקבי. אותו קובץ עולה בניסיון השלישי, או שתמונה של 2MB נכשלת בזמן שקובץ PDF של 6MB עובר חלק. מגבלות תצורה קשיחות נכשלות באותה צורה בכל פעם. כשלי זיכרון לא, כי כמות הזיכרון הפנויה תלויה במה שהשרת עושה באותו רגע.

למה דווקא תמונות: ‏WordPress לא רק שומר את הקובץ, הוא מפרק אותו לפיקסלים גולמיים כדי לייצר כל גודל ביניים — ‏medium_large, כל גודל שנרשם עם add_image_size, ‏woocommerce_thumbnail אם אתם מפעילים חנות, ובנוסף עותק -scaled אם התמונה חורגת מ-big_image_size_threshold. תמונת JPEG של 12 מגה-פיקסל תופסת כמה מגה-בייט על הדיסק ובערך 48MB בזיכרון, עוד לפני מאגר שינוי הגודל. מגבלה של 128MB נעלמת מהר.

העלו אותה בקובץ wp-config.php, מעל שורת ה”stop editing”:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

המחיר האמיתי: ‏WP_MEMORY_LIMIT לא יכול לחרוג ממה ש-PHP עצמו מתיר. אם חברת האחסון מגבילה את memory_limit ל-128M, הקבוע הזה הוא קישוט בלבד. בדקו את הערך האמיתי בכלים ← בריאות האתר ← מידע ← שרת, ולא במה שאתם כתבתם. אם המגבלה של PHP עצמו היא התקרה, רק חברת האחסון יכולה להזיז אותה.

ענף ג’ — מגבלות גודל קובץ ובקשה

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

• upload_max_filesize — התקרה לקובץ בודד.
• post_max_size — התקרה לכל גוף הבקשה.

אם בקשת ה-POST כולה חורגת מ-post_max_size, ‏PHP זורק את הבקשה לפני ש-WordPress מריץ שורת קוד אחת. אין מה להחזיר, ולכן מעלה הקבצים מקבל תשובה שאי אפשר לפרש ואומר “HTTP error”. הערך של post_max_size צריך תמיד להיות גדול בנוחות מ-upload_max_filesize.

הסתייגות שכדאי להכיר: כשקובץ חורג רק מ-upload_max_filesize, מעלה הקבצים בדרך כלל תופס את זה כבר בדפדפן ואומר שהקובץ חורג מגודל ההעלאה המרבי — הודעה הרבה יותר ברורה. לכן “HTTP error” יבש מצביע לרוב על post_max_size או על ענף ב’, ולא על ההגדרה שכולם ממהרים להעלות ראשונה.

איפה משנים אותן תלוי בסביבה שלכם. ב-Apache עם mod_php, קובץ .htaccess עובד:

php_value upload_max_filesize 64M
php_value post_max_size 128M

ב-PHP-FPM, ‏LiteSpeed או NGINX — כלומר ברוב האחסון המודרני — השורות האלה לא עושות כלום, ועלולות להחזיר שגיאת 500. השתמשו בלוח הגדרות ה-PHP של חברת האחסון או בקובץ .user.ini במקום זאת. בנוסף, ‏NGINX אוכף מגבלה משלו בשם client_max_body_size, שרק חברת האחסון יכולה להעלות.

ענף ד’ — ספריית עריכת התמונות (Imagick מול GD)

‏WordPress מעדיף את ImageMagick כשההרחבה של PHP מותקנת, ונופל חזרה ל-GD. בשרתי אחסון משותף, ‏ImageMagick הוא לא פעם הבעיה: קובץ המדיניות שלו מגביל זיכרון, דיסק ושטח לכל פעולה, וכששינוי גודל חוצה אחת מהמגבלות האלה התהליך מת בלי הודעה שימושית. בדרך כלל תראו את זה בתמונות גדולות בזמן שקטנות עובדות — מה שנראה כמו ענף ב’ אבל אינו הוא.

אילצו שימוש ב-GD כדי לבדוק את ההשערה:

add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_GD' );
} );

שימו את זה בקובץ functions.php או ב-mu-plugin קטן, נסו להעלות שוב, ואז הסירו את זה אם שום דבר לא השתנה.

חילופי הדברים הכנים: ‏GD אינו טוב יותר באופן גורף. הוא מחזיק את המפה הביטית הלא-דחוסה במלואה בזיכרון של PHP, ולכן בקבצים גדולים מאוד הוא עלול להיתקל ב-memory_limit דווקא במקום שבו ImageMagick — שעובד חלקית מחוץ להקצאת הזיכרון של PHP — היה מצליח. המעבר עלול להחליף כשל אחד באחר. תתייחסו לזה קודם כל ככלי אבחון, ורק אחר כך כתיקון.

ענף ה’ — הרשאות תיקיית ההעלאות

נדיר באחסון מנוהל, נפוץ מיד אחרי הגירה או העברת שרת ידנית. אם למשתמש שרת הווב אין הרשאת כתיבה ל-wp-content/uploads, או אם תת-תיקיית שנה/חודש שנוצרה זה עתה ירשה בעלות שגויה, הכתיבה נכשלת.

ls -ld wp-content/uploads
ls -ld wp-content/uploads/2026/07

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

ענף ו’ — שם הקובץ

הבדיקה הזולה ביותר ברשימה, אז בצעו אותה מוקדם למרות שהיא הכי פחות סבירה. שנו את שם הקובץ לאותיות קטנות באנגלית, ספרות ומקפים בלבד — בלי ניקוד, גרשים, סימני &, ‏# או תווים שאינם לטיניים — והעלו שוב. תווים מיוחדים מפעילים מדי פעם כלל אבטחה או נשברים במערכת קבצים עם קידוד לא תואם. עשר שניות כדי לשלול.

מה לא לעשות

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

אל תוסיפו שורת handler אקראית ל-.htaccess. קטעי הקוד שמסתובבים ומוסיפים הנחיית SetHandler או AddHandler מניחים תצורת PHP של חברת אחסון מסוימת. בסביבה הלא נכונה הם מפילים את כל האתר עם שגיאת 500.

אל תקבלו “זה עבד בניסיון השני” כתיקון. הצלחה לא עקבית היא החתימה של ענף ב’, והיא תחזור ברגע שהשרת יהיה עמוס או שמישהו יעלה משהו גדול יותר.

עדיין תקועים?

אם התשובה היא 200 נקי עם JSON תקין וההעלאה עדיין נכשלת, השבר מתרחש אחרי שהקובץ נוחת — בדרך כלל תוסף שמחובר לשרשרת עיבוד הקבצים המצורפים וזורק שגיאה פטאלית, או תוסף אופטימיזציה ששולח בקשה משלו לשירות חיצוני שלא מגיב בזמן. הפעילו את WP_DEBUG_LOG, שחזרו את התקלה, והריצו את השגיאה הפטאלית שהתקבלה דרך מפענח יומן השגיאות כדי לראות איזה קובץ ואיזה hook אחראים בפועל.