Zwiększanie maksymalnego rozmiaru uploadu pliku w WordPress

Przeciągasz wideo o rozmiarze 60MB do biblioteki media WordPress, czekasz kilka sekund i otrzymujesz jeden z trzech komunikatów błędów: "The uploaded file exceeds the upload_max_filesize directive in php.ini", "413 Request Entity Too Large" lub po prostu "Błąd HTTP" bez dalszego wyjaśnienia. Rozwiązaniem jest prawie zawsze zwiększenie maksymalnego rozmiaru uploadu, ale jak w przypadku większości tematów limitów WordPress, nie ma tylko jednego limitu. Są cztery, żyją w różnych miejscach, a najniższy wygrywa. Ten przewodnik wyjaśnia, który limit powoduje który komunikat błędu i jak zwiększyć każdy z nich w różnych konfiguracjach hostingu.

Który limit jest odpowiedzialny za który błąd?

Cztery osobne ustawienia mogą zablokować upload. Wiedza, który Cię uderzył, oszczędza dużo prób i błędów.

• PHP upload_max_filesize. Twardy sufit na rozmiar pojedynczego przesłanego pliku. Domyślnie na większości hostów to 2M do 64M. Jeśli Twój plik to przekracza, WordPress pokazuje wyraźny komunikat "uploaded file exceeds the upload_max_filesize directive".
• PHP post_max_size. Maksymalny rozmiar całego żądania POST, w tym plik plus wszystkie inne pola formularza. Musi być co najmniej tak duży jak upload_max_filesize; w przeciwnym razie upload zawodzi po cichu, zanim WordPress to nawet zobaczy. Domyślnie zwykle 8M do 64M.
• PHP max_execution_time i max_input_time. Limity czasowe w sekundach. Duży upload przez wolne połączenie może osiągnąć limit czasu, zanim plik skończy przesyłać, nawet jeśli limity rozmiaru są w porządku. Domyślnie zwykle 30 do 60 sekund. Symptom: upload startuje, pasek postępu dochodzi do 80%, następnie zawodzi z "Błąd HTTP".
• Limit ciała żądania webserwera. nginx ma dyrektywę client_max_body_size (domyślnie 1M, boleśnie niska dla uploadów media). Apache rzadko ogranicza to domyślnie, ale reverse proxy, load balancery i CDN-y (zwłaszcza Cloudflare ma limit 100M w planach Free, 200M w Pro, 500M w Business) wszystkie egzekwują własne sufity. Symptom: strona "413 Request Entity Too Large", która w ogóle nie wygląda jak WordPress, ponieważ WordPress nigdy nie otrzymał żądania.

Faktyczny maksymalny rozmiar uploadu to najniższy z czterech. WordPress pokazuje efektywny limit na samej stronie uploadu: otwórz Media, Dodaj nowy w adminie i spójrz na małą linię "Maksymalny rozmiar pliku uploadu" pod obszarem uploadu.

Ile faktycznie potrzebujesz?

Praktyczny model mentalny:

• 32M. Wystarczające dla typowych obrazów, PDF-ów i małych plików audio. Domyślne na konserwatywnych shared hostach.
• 64M. Komfortowe dla większości witryn redakcyjnych. Obsługuje serie fotograficzne z nowoczesnego aparatu, większe PDF-y i krótkie klipy wideo.
• 128M do 256M. Właściwy zakres dla witryn, które regularnie przesyłają wideo, duże pliki PSD, zasoby projektowe lub pliki zip motywu i wtyczek dla samozarządzanej instalacji.
• Powyżej 256M. Szczególnie istotne dla witryn z dużą ilością wideo, feedów podcastów z dużymi plikami audio lub platform kursowych z materiałami lekcyjnymi do pobrania. Warto pomyśleć, czy plik naprawdę musi być na serwerze WordPress, czy usługa taka jak Vimeo, YouTube, Bunny Stream lub dedykowany bucket S3 pasuje lepiej. WordPress nie jest zoptymalizowany do serwowania dużych plików media na dużą skalę.

Jeden szczegół, który ludzie pomijają: WordPress ma również własny wewnętrzny sufit. Domyślnie nie nakłada limitu rozmiaru poza tym, co PHP zezwala, więc na większości hostów ustawienia PHP są jedyną rzeczą w grze. Filtr upload_size_limit istnieje, jeśli chcesz ustawić sufit specyficzny dla projektu (przydatny w multisite, aby dać różnym rolom różne limity), ale może tylko obniżyć efektywny limit, nigdy podnieść go powyżej PHP.

Opcja 1: Zwiększ limity PHP przez panel hostera

Prawie zawsze właściwy punkt startowy. Większość hostów w 2026 oferuje odpowiednie ustawienia w swoim panelu, a zmiany wchodzą w życie w ciągu sekund.

cPanel (IONOS, Hostinger, wielu resellerów)

Przejdź do MultiPHP INI Editor, wybierz swoją domenę i dostosuj:

• upload_max_filesize do docelowej wartości (np. 128M)
• post_max_size do tej samej lub wyższej (np. 128M)
• max_execution_time do co najmniej 300 sekund dla dużych plików
• max_input_time do tej samej wartości
• memory_limit do 256M lub wyższego (uploady są krótko ładowane do pamięci podczas przetwarzania)

Zapisz. Zmiana jest natychmiast aktywna.

Plesk (All Inkl, DomainFactory, wielu niemieckich hostów)

Otwórz domenę w Plesk, kliknij Ustawienia PHP, przewiń do "Ustawienia wydajności i bezpieczeństwa". Pola są takie same jak dla cPanel. Zapisz, a wartości obowiązują przy następnym żądaniu.

Managed WordPress hosting (Raidboxes, Kinsta, WP Engine, Cloudways, SiteGround)

Te hosty prawie zawsze dostarczają już rozsądne wartości domyślne (zwykle 64M do 128M). Jeśli limit jest nadal zbyt niski dla Twojego przypadku użycia, panel zwykle ma suwak lub pole wprowadzania. Kilka hostów (WP Engine, Pressable) ogranicza absolutne maksimum i wymaga ticketu wsparcia powyżej pewnego rozmiaru, zwykle dlatego, że ich pipeline uploadu wstępnie waliduje pliki przeciwko CDN. Te tickety są odpowiadane w godzinach, nie dniach.

Opcja 2: .user.ini w katalogu głównym WordPress

Jeśli Twój host uruchamia PHP przez FastCGI lub PHP FPM (co jest w zasadzie każdym nowoczesnym hostem), ale nie oferuje panelu ustawień, możesz umieścić plik .user.ini bezpośrednio w katalogu głównym WordPress:

upload_max_filesize = 128M
post_max_size = 128M
max_execution_time = 300
max_input_time = 300
memory_limit = 256M

PHP odbiera .user.ini automatycznie. Jedyną osobliwością jest domyślny czas cache wynoszący pięć minut (kontrolowany przez ustawienie user_ini.cache_ttl), więc zmiany nie zawsze wchodzą w życie przy pierwszym następnym żądaniu.

Zweryfikuj na stronie Stan witryny WordPress: Narzędzia, Stan witryny, Info, Serwer pokazuje aktywne upload_max_filesize i post_max_size. Jeśli wartości po dziesięciu minutach nadal odpowiadają starym domyślnym, host albo wyłącza wsparcie .user.ini, albo PHP działa w trybie, który to ignoruje. Przejdź do Opcji 3.

Opcja 3: php.ini na samozarządzanym serwerze

Na VPS lub serwerze dedykowanym, gdzie zarządzasz PHP bezpośrednio, edytuj aktywny php.ini. Znajdź go za pomocą php --ini w wierszu poleceń. Ścieżka różni się w zależności od dystrybucji i wersji PHP (zwykle /etc/php/8.2/fpm/php.ini na Debianie lub Ubuntu, /etc/php.ini na CentOS lub RHEL).

Dostosuj te same pięć wartości co w Opcji 1, następnie przeładuj PHP FPM:

sudo systemctl reload php8.2-fpm

(Dostosuj numer wersji do swojej instalacji.) Na Apache z mod_php zrestartuj zamiast tego Apache. Zmiana jest natychmiast aktywna, bez dalszej akcji.

Opcja 4: nginx client_max_body_size

To ten, który łapie wielu ludzi na samozarządzanym nginx. PHP może być skonfigurowany do akceptowania uploadów 1GB, ale jeśli nginx jest nadal ograniczony do 1M (domyślne), upload nigdy nie dociera do PHP. Przeglądarka pokazuje ogólny błąd "413 Request Entity Too Large", często bez żadnej wskazówki, że nginx jest odpowiedzialny.

Dodaj dyrektywę do bloku server swojej witryny, lub globalnie w bloku http nginx.conf:

client_max_body_size 128M;

Przeładuj nginx za pomocą sudo nginx -t && sudo systemctl reload nginx. Wartość musi być równa lub wyższa niż Twoje PHP post_max_size. Nie ma szkody w ustawieniu jej nieco wyższej; faktycznym limitem jest nadal PHP.

Opcja 5: Apache z .htaccess (przestarzałe)

Na starszych konfiguracjach Apache uruchamiających mod_php (rzadkie na nowoczesnym hostingu, częste na przestarzałych serwerach), możesz umieścić dyrektywy PHP bezpośrednio w .htaccess w katalogu głównym WordPress:

php_value upload_max_filesize 128M
php_value post_max_size 128M
php_value max_execution_time 300
php_value max_input_time 300
php_value memory_limit 256M

Jeśli Twój host uruchamia PHP przez FastCGI lub PHP FPM (co jest w zasadzie każdym nowoczesnym hostem), ta dyrektywa rzuca błąd 500 lub jest po cichu ignorowana. Użyj zamiast tego .user.ini z Opcji 2.

Opcja 6: Gdy limit leży na warstwie CDN lub proxy

Jeśli skonfigurowałeś PHP i webserwer do zezwalania na uploady 256M, ale upload nadal zawodzi na, powiedzmy, 100M, wąskie gardło leży gdzieś przed serwerem WordPress. Częste winowajcy:

• Cloudflare ogranicza rozmiar ciała per plan: 100M na Free, 200M na Pro, 500M na Business, 500M na Enterprise (zwiększane na żądanie). Dla większych uploadów ulepsz plan, wyklucz admin WordPress z proxy, ustawiając rekord DNS na "DNS only" dla /wp-admin/ przez Page Rule, lub użyj bezpośredniej subdomeny, która omija Cloudflare dla uploadów.
• Cloudways ma warstwę varnish, która ma domyślnie niski limit rozmiaru ciała. Ich panel zawiera ustawienie pod "Application Settings, Server Configurations".
• Reverse proxy ustawione przed nginx (HAProxy, Traefik) wszystkie mają własne limity rozmiaru ciała, które muszą być zwiększone w odpowiednich plikach konfiguracji.
• Niektóre firewalle i wtyczki bezpieczeństwa na poziomie WAF (Sucuri, Wordfence Premium z cloud WAF) ograniczają domyślnie rozmiary uploadów. Ich panel ustawień ma osobną opcję na to.

Trik diagnostyczny: spróbuj uploadu z wnętrza samego serwera za pomocą curl i lokalnego pliku. Jeśli upload działa lokalnie, ale zawodzi przez publiczny URL, limit leży na warstwie proxy lub CDN, nie w PHP.

Jak zweryfikować, że nowe limity są aktywne

1. Otwórz Narzędzia, Stan witryny, Info w adminie WordPress.
2. Rozwiń sekcję Serwer. Znajdź upload_max_filesize, post_max_size, max_execution_time i memory_limit. Powinny wszystkie odzwierciedlać nowe wartości.
3. Dla szybszej kontroli otwórz Media, Dodaj nowy. Linia "Maksymalny rozmiar pliku uploadu" na dole obszaru uploadu powinna pokazywać nowy efektywny limit.
4. Spróbuj faktycznego uploadu, który spowodował problem. Jeśli nadal zawodzi, zanotuj dokładnie, jaki komunikat błędu otrzymujesz; to wskazuje, który z czterech limitów jest nadal zbyt niski.

Co zrobić, gdy plik jest naprawdę zbyt duży dla uploadu HTTP

Powyżej 500M do 1GB uploady przeglądarki przestają być praktyczne niezależnie od ustawień serwera. Połączenie TCP staje się niestabilne, pośrednie proxy timeoutują, a pojedyncza usterka sieci oznacza rozpoczęcie od nowa. Dwie rozsądniejsze alternatywy:

• Upload przez SFTP i import przez WordPress. Umieść plik bezpośrednio w wp-content/uploads/ROK/MIESIAC/ przez SFTP, następnie użyj wtyczki takiej jak Add From Server lub Media Sync, aby zarejestrować go w bibliotece media. WordPress generuje metadane i miniatury tak, jakbyś przesłał normalnie.
• Zewnętrzne usługi media. Szczególnie dla wideo, Vimeo, Bunny Stream, Cloudflare Stream i YouTube obsługują hosting i adaptive streaming znacznie lepiej niż core WordPress. Większość nowoczesnych motywów i pagebuilderów osadza je natywnie, w tym automatycznie generowane miniatury. Ta sama logika dla audio (Soundcloud, Spotify for podcasters) i dużych pobrań plików (S3 z CloudFront lub Bunny CDN z przodu).

Hosting surowego wideo 5GB na shared WordPress hostingu i serwowanie go bezpośrednio jest technicznie możliwe, ale rzadko jest właściwym wyborem. Koszty pasma, brak adaptive bitrate i obciążenie jednego workera PHP na równoczesnego widza wszystkie wskazują w kierunku dedykowanego hostingu media.

Częste błędy, których należy unikać

• Zwiększanie upload_max_filesize bez zwiększania post_max_size obok. Upload zawodzi po cichu, ponieważ całe żądanie POST przekracza niższy z dwóch. Zawsze zmieniaj je razem.
• Ustawianie absurdalnie wysokich wartości "na wszelki wypadek". Limit uploadu 4G na serwerze z łącznie 4GB RAM to wektor denial-of-service. PHP ładuje części uploadu do pamięci podczas przetwarzania. Wybierz wartość, która odzwierciedla to, co faktycznie przesyłasz, plus margines.
• Zapomnienie o max_execution_time. Upload 500MB na połączeniu 10 Mbit/s zajmuje około siedmiu minut. Jeśli max_execution_time jest domyślne 30 sekund, żądanie jest przerywane w połowie uploadu niezależnie od limitów rozmiaru.
• Edycja niewłaściwego php.ini. Częsty błąd na systemach z zainstalowanymi wieloma wersjami PHP (np. obecne zarówno 7.4, jak i 8.2, ale tylko jedno aktywne). Komenda php --ini w wierszu poleceń może wskazywać na inny php.ini niż ten, którego PHP FPM używa dla webserwera. Stan witryny jest autorytatywnym źródłem.

Dla większości przypadków dwie minuty w panelu hostera ze zwiększeniem pięciu wartości do rozsądnych domyślnych rozwiązuje problem na stałe. Komunikaty błędów wokół limitów rozmiaru uploadu są niestety sformułowane tak, że brzmią jak niejasne problemy techniczne, ale faktyczna naprawa jest mechaniczna i dobrze udokumentowana. Po dostrojeniu limitów do faktycznego obciążenia pracą, to jeden z tematów WordPress, który nie musi już pojawiać się.