Błąd 413 w WordPress: jak znaleźć limit i bezpiecznie go zwiększyć

Błąd HTTP 413 oznacza, że serwer lub pośrednicząca brama odrzuciły żądanie z powodu rozmiaru jego treści. WordPress może wyświetlić komunikat podczas przesyłania obrazu, importu kopii, instalacji motywu lub wysyłania pliku przez wtyczkę, ale sam kod 413 nie identyfikuje komponentu, który ustawił limit.

Limit PHP może przerwać przetwarzanie pliku bez wygenerowania statusu HTTP 413. Gdy plik przekracza `upload_max_filesize`, PHP oznacza błąd przesyłania; gdy całe żądanie przekracza `post_max_size`, PHP nie wypełnia `$_POST` ani `$_FILES`. Opis tych skutków znajduje się w dokumentacji dyrektyw PHP oraz dokumentacji PHP dla WordPressa, sprawdzonych w 10.2026.

Serwer WWW może zwrócić właściwy status 413 przed przekazaniem żądania do PHP. Na przykład Nginx stosuje dyrektywę `client_max_body_size`; dokumentacja Nginx wskazuje, że przekroczenie ustawionej wartości powoduje odpowiedź 413. Szczegóły zakresu dyrektywy opisuje dokumentacja Nginx, sprawdzona w 10.2026.

Tabela porządkuje typowe objawy i wskazuje, jaki komponent sprawdzić jako pierwszy. Komunikat jest wskazówką, a nie dowodem źródła problemu, ponieważ hosting lub wtyczka mogą zmienić jego treść.

Status 413 wskazuje na odrzucenie żądania, a błąd PHP uploadu wymaga osobnej diagnozy limitów PHP.

Rozmiar pliku, limit wyświetlany przez WordPress i status odpowiedzi HTTP pozwalają zawęzić źródło problemu. Sprawdź rozmiar pliku we właściwościach systemu, a następnie porównaj go z wartością widoczną w Media > Dodaj nowe. WordPress pokazuje tam maksymalny rozmiar pojedynczego pliku dostępny w danej witrynie.

W panelu WordPressa otwórz Narzędzia > Stan witryny > Informacje > Obsługa mediów i zanotuj maksymalny rozmiar przesyłanego pliku oraz maksymalny rozmiar danych POST. W części Serwer sprawdź dostępne informacje o PHP. WordPress opisuje ekran w dokumentacji Stanu witryny oraz dokumentacji ekranu dodawania mediów, sprawdzonych w 10.2026.

Chrome DevTools pozwala sprawdzić, czy przeglądarka otrzymała status 413. Otwórz DevTools > Network, ponów przesyłanie i wybierz żądanie odpowiadające plikowi; sprawdź status, adres i odpowiedź. Natychmiastowy status 413 przed transferem często wskazuje na limit serwera WWW lub proxy, natomiast długie oczekiwanie może wynikać także z timeoutu albo zerwanego połączenia.

Jeśli WordPress pokazuje błąd aplikacji bez statusu 413, sprawdź log PHP i log wtyczki importującej. Nie publikuj zrzutów z Network zawierających cookies, tokeny sesji ani dane klientów. Inne objawy aplikacji porównaj z przewodnikiem po błędach WordPressa. Jeśli diagnoza wymaga sprawdzenia logów i konfiguracji po stronie serwera, pomoc w naprawie WordPressa obejmuje analizę błędów i przywrócenie prawidłowego działania strony.

Plik musi zmieścić się w każdym limicie obowiązującym na trasie żądania, a limity PHP i serwera WWW działają niezależnie. `upload_max_filesize` ogranicza pojedynczy plik, a `post_max_size` ogranicza całe żądanie POST, w tym plik i pozostałe pola formularza. WordPress wyjaśnia te parametry w dokumentacji konfiguracji PHP, sprawdzonej w 10.2026.

Tabela pokazuje, gdzie szukać najczęstszych ograniczeń i kto zazwyczaj może je zmienić. Dostępne ustawienia zależą od konfiguracji hostingu i uprawnień administratora.

`post_max_size` musi być większy niż rozmiar pliku i uwzględniać pozostałe dane formularza. Gdy status 413 pojawia się przed PHP, sama zmiana parametrów PHP nie podniesie limitu serwera WWW ani proxy.

Limit PHP zmienisz w panelu hostingu, jeśli dostawca udostępnia konfigurację PHP dla właściwej domeny i wersji PHP. Szukaj sekcji o nazwie PHP, Ustawienia PHP, Konfiguracja PHP lub PHP INI, a po zapisaniu sprawdź aktywne wartości ponownie w Narzędzia > Stan witryny > Informacje.

Ustaw `post_max_size` powyżej `upload_max_filesize`, z zapasem na pozostałe pola i narzut kodowania formularza multipart. Oba parametry ustawione na identyczną wartość mogą nie wystarczyć dla pliku równego limitowi. PHP opisuje oba parametry w dokumentacji `php.ini`, sprawdzonej w 10.2026.

Duży plik może przekroczyć limit czasu odbierania danych, nawet jeśli mieści się w limicie rozmiaru. PHP używa do tego `max_input_time`, a WordPress wskazuje, że limity czasu mogą zależeć od konfiguracji serwera lub hostingu w dokumentacji PHP dla WordPressa, sprawdzonej w 10.2026.

Gdy panel nie udostępnia ustawień, wyślij hostingowi nazwę domeny, wersję PHP, rozmiar pliku, czas przerwania i status HTTP. Poproś o sprawdzenie aktywnych wartości PHP oraz limitu żądania na serwerze WWW i proxy. Nie dopisuj dyrektyw do `.htaccess`, dopóki hosting nie potwierdzi, że działa na Apache i pozwala zmieniać te ustawienia.

Limit uploadu nie jest tym samym co `memory_limit`. Jeśli po przesłaniu pojawia się błąd pamięci, sprawdź poradnik o PHP memory limit w WordPressie.

Limit serwera WWW albo proxy sprawdź, gdy przeglądarka otrzymuje status 413, a limity PHP wystarczają dla testowanego pliku. Administrator Nginx powinien sprawdzić `client_max_body_size` w aktywnym kontekście `http`, `server` lub `location`; właściwy blok musi obsługiwać domenę i ścieżkę, na której występuje błąd. Dyrektywa oraz zachowanie po przekroczeniu limitu są opisane w dokumentacji Nginx, sprawdzonej w 10.2026.

Administrator Apache powinien zweryfikować `LimitRequestBody` w konfiguracji serwera, wirtualnego hosta, katalogu lub `.htaccess`, zgodnie z uprawnieniami hostingu. Dyrektywa ogranicza treść całego żądania, a nie tylko plik. Jej składnię i zakres opisuje dokumentacja Apache 2.4, sprawdzona w 10.2026.

Reverse proxy, CDN lub WAF może odrzucić żądanie przed serwerem źródłowym. Administrator powinien porównać logi obu usług z tego samego czasu; brak żądania w logu serwera źródłowego wskazuje, że problem może występować na wcześniejszym etapie. Zmianę wykonuje administrator, który zna aktywną konfigurację i może zweryfikować ją po przeładowaniu usługi.

Zalecamy dobrać limit do rzeczywistego procesu i zasobów serwera, zamiast ustawiać wartość nieograniczoną. Duże żądania zużywają transfer, miejsce tymczasowe i zasoby procesu PHP.

Pojedynczy duży plik można dostarczyć przez SFTP, importer etapami albo narzędzie hostingu, jeśli nie ma potrzeby zwiększania limitu publicznych formularzy. Metodę dobierz do celu: plik do biblioteki mediów wymaga innej obsługi niż archiwum przeznaczone do odtworzenia kopii.

Tabela porównuje metody dla pojedynczego pliku. Możliwości importu etapami zależą od używanej wtyczki, a SFTP wymaga dostępu do serwera.

SFTP kopiuje plik na serwer, ale WordPress może wymagać dodatkowego importu lub indeksowania, aby pokazać go w bibliotece mediów. Nie umieszczaj archiwum w przypadkowym katalogu publicznym ani nie ustawiaj zapisu dla wszystkich użytkowników. Kopię odtwarzaj narzędziem lub procedurą, która ją utworzyła.

Poprawka działa, gdy testowe pliki mieszczące się w zatwierdzonych limitach przechodzą poprawnie, a logi nie pokazują nowych błędów. Wykonaj test plikiem poniżej poprzedniego limitu i plikiem powyżej niego, ale nadal mieszczącym się w zatwierdzonych limitach PHP, serwera i proxy.

Sprawdź wynik w miejscu docelowym: bibliotece mediów, importerze albo narzędziu odtwarzania kopii. Porównaj status HTTP i czas żądania w Network z logami PHP i serwera WWW. Jeśli po zmianie status 413 ustąpi, ale pojawi się timeout albo błąd pamięci, zdiagnozuj nowy komunikat jako osobny problem.

Zapisz zmienione parametry, poprzednie i nowe wartości, zakres konfiguracji oraz wynik testów. Przy dużym serwisie wykonuj próbę poza okresem największego ruchu i obserwuj wolne miejsce na dysku. Jeśli nie masz dostępu do konfiguracji i logów, naprawa WordPressa obejmuje diagnozę błędu 413 oraz konfiguracji przesyłania plików.

Błąd HTTP 413 naprawisz przez zwiększenie limitu tego komponentu, który faktycznie odrzucił żądanie, albo przez użycie metody przesłania pliku niewymagającej zmiany limitu publicznego formularza. Najpierw potwierdź status w Network, a następnie sprawdź właściwy limit serwera WWW, proxy lub hostingu; jeśli PHP zgłasza błąd uploadu, zweryfikuj `upload_max_filesize` i `post_max_size` osobno.

Z naszych wdrożeń wynika, że sam limit widoczny w Mediach nie rozstrzyga, czy żądanie zatrzymał wcześniejszy komponent. Zalecamy zachować status odpowiedzi i czas wystąpienia błędu, bo te dane pomagają administratorowi powiązać żądanie z logami.

• Błąd 414 WordPress: jak znaleźć przyczynę i naprawić zbyt długi adres
• WordPress nie może zapisać pliku na dysku: jak znaleźć przyczynę
• Błąd 403 w WordPress: jak znaleźć blokadę i odzyskać dostęp
• Błąd 503 w WordPressie: jak znaleźć przyczynę i przywrócić stronę
• Maksymalny czas wykonywania skryptu przekroczony w WordPress: diagnoza i naprawa