WordPress-ə şəkil yükləyəndə HTTP error nə deməkdir?

Bu o deməkdir ki, brauzerdəki yükləyici faylınızı serverə göndərib, geri isə uğurlu cavab kimi oxuya bilmədiyi bir şey alıb. Mesaj səbəbi yox, əlaməti təsvir edir. Çökmüş PHP prosesi, firewall blokası, 403 cavabı və boş cavab — hamısı eyni üç sözü verir.

Eyni şəkil niyə bəzən yüklənir, bəzən yüklənmir?

Sabit olmayan uğursuzluqlar demək olar ki, həmişə konfiqurasiya limitini yox, yaddaşın və ya prosessorun tükənməsini göstərir. Böyük fotonun ölçüsünü dəyişmək bir anlıq yaddaş tələb edir və paylaşılan hostinqdə mövcud həcm server yükündən asılı olaraq dəyişir. post_max_size kimi sərt limit isə hər dəfə eyni şəkildə uğursuz olur.

WordPress-i Imagick-dən GD-yə keçirmək HTTP error xətasını həll edirmi?

Bəzən, özü də yalnız bir konkret budaq üçün. Paylaşılan hostinqlərdə ImageMagick tez-tez siyasət faylı və ya aşağı resurs limitləri ilə məhdudlaşdırılır və GD-nin öhdəsindən gəldiyi yerdə uğursuz olur. Amma GD çox böyük fayllarda daha çox yaddaş yeyir, ona görə keçid yaddaşa bağlı problemləri yaxşılaşdırmaq əvəzinə pisləşdirə bilər.

Hostinqin firewall-unun yükləməni bloklamadığını necə bilim?

Brauzerin şəbəkə alətlərini açın, faylı yükləyin və async-upload.php üçün qayıdan status koduna baxın. HTML gövdəli 403 və ya 406 o deməkdir ki, sorğunu veb tətbiq firewall-u və ya mod_security qaydası rədd edib. 500 və ya boş cavab isə PHP-nin çökdüyünü göstərir.

upload_max_filesize dəyərini artırmaq HTTP error xətasını həll edəcəkmi?

Yalnız fayl həqiqətən limitlərinizi aşırsa, üstəlik adətən post_max_size daha çox əhəmiyyət daşıyır. Bütün sorğu gövdəsi post_max_size dəyərindən böyükdürsə, PHP onu WordPress işə düşməmiş atır və yükləyiciyə heç nə qayıtmır. Birini digəri olmadan artırmaq problemi olduğu yerdə saxlayır.

Fayl adı WordPress HTTP error xətasına səbəb ola bilərmi?

Bəli, baxmayaraq ki bu, ən nadir budaqdır. Diakritik işarələr, apostroflar, ampersandlar və qeyri-latın əlifbaları təhlükəsizlik qaydasını işə sala və ya kodlaşdırması uyğun gəlməyən fayl sistemində yolu poza bilər. Adı sadə kiçik hərflər, rəqəmlər və defislərlə dəyişmək heç nəyə başa gəlmir və bu budağı təxminən on saniyəyə aradan qaldırır.

Şəkil yükləyəndə WordPress "HTTP error": səbəbi həqiqətən tapan qərar ağacı

“HTTP error” səbəb deyil. Bu, media yükləyicisinin etirafıdır: faylınızı serverə göndərib, geri isə uğur kimi oxuya bilmədiyi bir cavab alıb — üstəlik ən azı altı bir-birindən asılı olmayan nasazlıq eyni üç sözü verir. Onların arasında təxmin etmək məhz ona görə insanları bütün günü upload_max_filesize qaldırmağa məcbur edir, halbuki əsl problem firewall qaydasıdır.

Ən qısa yol bir müşahidədir: o, altı səbəbi iki qrupa bölür, sonra hər budaq üçün bir yoxlama qalır.

Əvvəlcə: əsl cavabı oxuyun

Brauzerinizin tərtibatçı alətlərini açın, Network (Şəbəkə) tabına keçin və faylı yenidən yükləyin. async-upload.php sorğusunu izləyin. Geri nə gəlirsə, diaqnozunuz odur.

Gördüyünüz	Nə deməkdir	Keçin
403 və ya 406, HTML gövdə	Firewall və ya mod_security sorğunu rədd edib	A budağı
500, boş cavab və ya yarımçıq gövdə	PHP çöküb və ya prosesin ortasında yaddaşı tükənib	B budağı
413	Sorğu gövdəsi server limitini aşıb	C budağı
200, amma gövdə təmiz JSON deyil	Plagin və ya mövzu cavabdan əvvəl nəsə çap edib	D budağı
Sorğu heç vaxt tamamlanmır / vaxt aşımı	İcra vaxtı limiti, adətən böyük fayllarda	B budağı

Bu bir baxış internetdəki məsləhətlərin çoxunu sizin üçün ələkdən keçirir. Brauzer alətlərinə çata bilmirsinizsə, əvvəlcə wp-config.php faylında jurnalı yandırın:

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

Yükləməni təkrarlayın, sonra wp-content/debug.log faylını oxuyun. Fatal xəta sətri budağı birbaşa adlandırır. Sətir çətin oxunursa, onu xəta jurnalı deşifrəedicisinə yapışdırın — o, geniş yayılmış fatal imzaları əslində nəyin sındığına uyğunlaşdırır.

A budağı — firewall və ya mod_security qaydası

Gövdəsində HTML səhifə olan 403 cavabı o deməkdir ki, sorğu heç WordPress-ə çatmayıb. Onun qarşısındakı nəsə — mod_security, Cloudflare, Wordfence, Sucuri və ya hostinqin öz qayda dəsti — POST sorğusunu zərərli sayıb.

Yoxlama: təhlükəsizlik plaginlərini müvəqqəti deaktiv edin və yenidən yükləyin. Heç nə dəyişmirsə, qayda server səviyyəsindədir və hostinqin uğursuz yükləmənin vaxt möhürü üzrə mod_security audit jurnalına baxması lazımdır. Onlar konkret qayda ID-sini ağ siyahıya sala bilər.

Burada rastlaşacağınız məsləhətlər barədə özünüzlə dürüst olun. .htaccess faylına bunu əlavə etməyi deyən nümunələr:

SecFilterEngine Off
SecFilterScanPOST Off

mod_security 1.x üçün nəzərdə tutulub, o isə praktiki olaraq yoxa çıxıb. Müasir serverdə bu direktivlər ya heç nə etmir, ya da saytı daha da pisləşdirən 500 xətası verir. Müasir mod_security SecRuleEngine işlədir və idarə olunan hostinqlərin çoxu onsuz da onun qovluq səviyyəsində dəyişdirilməsini bloklayır. Yapışdırmayın — hostinqdən soruşun.

B budağı — PHP yaddaş və icra limitləri

Bu, ən çox rast gəlinən budaqdır və əlaməti də ən aydınıdır: sabit deyil. Eyni fayl üçüncü cəhddə yüklənir, yaxud 2MB-lıq foto uğursuz olur, 6MB-lıq PDF isə problemsiz keçir. Sərt konfiqurasiya limitləri hər dəfə eyni şəkildə uğursuz olur. Yaddaş problemləri isə yox, çünki mövcud həcm serverin nə ilə məşğul olmasından asılıdır.

Xüsusən şəkillərdə niyə: WordPress faylı sadəcə saxlamır, onu bütün aralıq ölçüləri yaratmaq üçün xam piksellərə açır — medium_large, add_image_size ilə qeydə alınmış hər ölçü, mağazanız varsa woocommerce_thumbnail, üstəlik şəkil big_image_size_threshold həddini keçirsə bir -scaled surəti. 12 meqapiksellik JPEG diskdə bir neçə MB, yaddaşda isə təxminən 48MB tutur — həm də bu, ölçü dəyişmə buferindən əvvəlki rəqəmdir. 128MB limit sürətlə yox olur.

Onu wp-config.php faylında, “stop editing” sətrindən yuxarıda artırın:

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

Əsl qiyməti belədir: WP_MEMORY_LIMIT PHP-nin özünün icazə verdiyindən yuxarı qalxa bilməz. Hostinqiniz memory_limit dəyərini 128M ilə məhdudlaşdırıbsa, bu sabit sadəcə bəzəkdir. Həqiqi dəyəri yazdığınıza yox, Alətlər → Sayt Sağlamlığı → Məlumat → Server bölməsinə baxaraq yoxlayın. Tavan PHP-nin öz limitidirsə, onu yalnız hostinq qaldıra bilər.

C budağı — fayl ölçüsü və POST limitləri

Real rəqəmləri Alətlər → Sayt Sağlamlığı → Məlumat → Media İdarəetməsi bölməsində yoxlayın. İki parametr vacibdir, insanlar isə həmişə yalnız birini dəyişir:

upload_max_filesize — bir faylın maksimum həcmi.
post_max_size — bütün sorğu gövdəsinin maksimum həcmi.

Bütün POST sorğusu post_max_size dəyərini aşırsa, PHP sorğunu WordPress heç bir kod icra etməmişdən əvvəl atır. Qaytarmağa heç nə qalmır, yükləyici oxuna bilməyən cavab alır və “HTTP error” deyir. post_max_size həmişə upload_max_filesize dəyərindən nəzərəçarpacaq dərəcədə böyük olmalıdır.

Bilməyə dəyən bir incəlik: fayl yalnız upload_max_filesize həddini aşanda yükləyici bunu adətən elə brauzerdə tutur və faylın maksimum yükləmə həcmini aşdığını deyir — daha aydın mesaj. Deməli, quru “HTTP error” mesajı hamının ilk qaldırdığı parametrdən daha çox post_max_size və ya B budağını göstərir.

Onları harada dəyişəcəyiniz sisteminizdən asılıdır. mod_php ilə işləyən Apache-də .htaccess işləyir:

php_value upload_max_filesize 64M
php_value post_max_size 128M

PHP-FPM, LiteSpeed və ya NGINX üzərində — müasir hostinqlərin böyük hissəsi belədir — bu sətirlər heç nə etmir və 500 xətası verə bilər. Əvəzində hostinqin PHP parametrləri panelindən və ya .user.ini faylından istifadə edin. NGINX həm də özünün client_max_body_size limitini tətbiq edir və onu yalnız hostinq qaldıra bilər.

D budağı — şəkil emalı kitabxanası (Imagick və GD)

PHP genişlənməsi mövcud olanda WordPress ImageMagick-ə üstünlük verir, olmayanda GD-yə keçir. Paylaşılan hostinqlərdə problem tez-tez məhz ImageMagick olur: onun siyasət konfiqurasiya faylı hər əməliyyat üçün yaddaşı, diski və sahəni məhdudlaşdırır və ölçü dəyişmə bu limitlərdən birinə dəyəndə proses faydalı mesaj vermədən ölür. Bunu adətən böyük şəkillərdə görürsünüz, kiçiklər isə işləyir — bu, B budağına oxşayır, amma o deyil.

Fərziyyəni yoxlamaq üçün GD-ni məcbur edin:

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

Bunu functions.php faylına və ya kiçik bir mu-plagin daxilinə qoyun, yükləməni təkrarlayın, heç nə dəyişmirsə silin.

Dürüst güzəşt: GD birmənalı olaraq daha yaxşı deyil. O, tam sıxılmamış bitmap-i PHP-nin yaddaşında saxlayır, ona görə çox böyük fayllarda memory_limit həddinə dəyə bilər — halbuki qismən PHP-nin ayırdığı yaddaşdan kənarda işləyən ImageMagick bunun öhdəsindən gələ bilərdi. Keçid bir problemi digəri ilə əvəz edə bilər. Ona əvvəlcə diaqnostika, sonra həll kimi yanaşın.

E budağı — uploads qovluğunun icazələri

İdarə olunan hostinqdə nadirdir, miqrasiyadan və ya əl ilə server köçürməsindən dərhal sonra isə çox rast gəlinir. wp-content/uploads qovluğuna veb server istifadəçisi yaza bilmirsə, yaxud yeni yaradılmış il/ay alt qovluğu səhv sahib alıbsa, yazma əməliyyatı uğursuz olur.

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

Qovluqlar adətən 755 olmalı və PHP-nin işlədiyi istifadəçiyə məxsus olmalıdır. Forumda belə yazılıb deyə 777 qoymayın — bu, əlaməti qovluğu serverdəki hər hesab üçün yazıla bilən etməklə “düzəldir”, paylaşılan hostinqdə isə bu, real təhlükəsizlik boşluğudur.

F budağı — fayl adı

Siyahıdakı ən ucuz yoxlamadır, ona görə ehtimalı ən aşağı olsa da erkən edin. Faylın adını sadə kiçik hərflər, rəqəmlər və defislərlə dəyişin — diakritik işarə, apostrof, ampersand, # və ya qeyri-latın simvolu olmadan — və yenidən yükləyin. Xüsusi simvollar bəzən təhlükəsizlik qaydasını işə salır, yaxud kodlaşdırması uyğun gəlməyən fayl sistemində sınır. Aradan qaldırmaq üçün on saniyə bəs edir.

Nə etməməli

Bütün plaginləri deaktiv etməklə başlamayın. Bu, işi pozur və yalnız A ilə D budaqlarını yoxlayır. Şəbəkə cavabı sizə beş saniyəyə daha çoxunu deyir.

.htaccess faylına təsadüfi handler sətri əlavə etməyin. Dövriyyədə olan və SetHandler və ya AddHandler direktivi əlavə edən nümunələr konkret hostinqin PHP quruluşunu nəzərdə tutur. Yanlış sistemdə onlar bütün saytı 500 xətası ilə yıxır.

“Təkrar cəhddə işlədi” cavabını həll kimi qəbul etməyin. Sabit olmayan uğur B budağının imzasıdır və server yüklənən kimi, yaxud kimsə daha böyük fayl yükləyən kimi geri qayıdacaq.

Hələ də ilişib qalmısınız?

Cavab təmiz 200 və düzgün JSON-dursa, yükləmə isə yenə də alınmırsa, sınıq nöqtə fayl serverə düşəndən sonradır — adətən qoşma emalı zəncirinə qoşulmuş plagin fatal xəta verir, yaxud optimallaşdırıcı plagin xarici xidmətə öz sorğusunu göndərir və vaxt aşımına düşür. WP_DEBUG_LOG yandırın, problemi təkrarlayın və alınan fatal xətanı xəta jurnalı deşifrəedicisindən keçirin ki, əslində hansı faylın və hansı qarmağın məsuliyyət daşıdığını görəsiniz.