Błąd 413 przy uploadzie do WordPressa — który limit blokuje plik

Przy próbie wysłania dużego pliku do WordPressa użytkownik może zobaczyć 413 Content Too Large, komunikat o przekroczeniu maksymalnego rozmiaru uploadu albo po prostu nieudaną operację importu. Te objawy nie muszą pochodzić z tej samej warstwy.

Rozmiar pliku może być akceptowany przez WordPress i PHP, a mimo to żądanie zostanie odrzucone wcześniej przez NGINX, Apache, reverse proxy albo CDN.

Przy problemie z dużym uploadem nie sprawdzaj tylko upload_max_filesize. Najpierw ustal, która warstwa odrzuciła całe żądanie HTTP.

413 oznacza, że żądanie było zbyt duże dla odbiorcy

Kod 413 dotyczy rozmiaru przesyłanej treści żądania. W praktyce przy WordPressie najczęściej chodzi o formularz POST zawierający plik, ale limit może zostać zastosowany jeszcze zanim PHP lub WordPress zaczną przetwarzać upload.

Objaw	Pierwszy trop
Przeglądarka od razu pokazuje 413	NGINX, Apache, reverse proxy albo CDN
WordPress pokazuje własny komunikat o maksymalnym rozmiarze pliku	PHP / limit raportowany przez WordPress
Małe pliki działają, większe zawsze odpadają przy podobnym rozmiarze	Konkretny limit jednej z warstw
Upload działa bez proxy, ale nie przez publiczną domenę	Proxy/CDN albo frontowy serwer WWW
Import ZIP nie działa mimo poprawnego limitu pojedynczego pliku	Sprawdź również całkowity rozmiar POST i sposób przesyłania formularza

Najważniejsze rozróżnienie brzmi więc: czy request dotarł do PHP. Jeśli został odrzucony wcześniej, zmiana ustawień WordPressa nie pomoże.

PHP ma więcej niż jeden limit związany z uploadem

Dwa najważniejsze ustawienia to upload_max_filesize i post_max_size.

upload_max_filesize ogranicza rozmiar pojedynczego przesyłanego pliku;
post_max_size ogranicza rozmiar całych danych POST.

post_max_size powinno pozostawiać zapas ponad upload_max_filesize, ponieważ obejmuje całe żądanie POST, a nie tylko dane samego pliku. Formularz multipart/form-data zawiera również narzut protokołu, dodatkowe pola i potencjalnie więcej niż jeden plik.

Jeżeli post_max_size jest mniejsze od wartości potrzebnej do przesłania całego requestu, samo podniesienie upload_max_filesize nie rozwiąże problemu.

WordPress wylicza maksymalny rozmiar uploadu na podstawie limitów dostępnych w środowisku PHP. Wartość raportowana przez WordPress jest więc użyteczną wskazówką, ale przy post_max_size trzeba pozostawić miejsce również na narzut całego żądania. Nie należy traktować identycznych wartości post_max_size i upload_max_filesize jako gwarancji przesłania pliku dokładnie tej wielkości.

NGINX może odrzucić request zanim uruchomi się WordPress

W NGINX rozmiar body klienta może być ograniczony przez client_max_body_size. Jeżeli żądanie przekroczy skonfigurowaną wartość, NGINX może zwrócić 413 bez przekazywania uploadu dalej do PHP-FPM.

W takim układzie przepływ wygląda mniej więcej tak:

przeglądarka
    ↓
NGINX  ← tutaj request może zostać odrzucony
    ↓
PHP-FPM
    ↓
WordPress

Dlatego sytuacja:

upload_max_filesize = 256M
post_max_size = 300M

nie dowodzi jeszcze, że plik 200 MB przejdzie. Jeśli frontowy NGINX ma niższy limit body, PHP nigdy nie zobaczy requestu.

To samo dotyczy architektury NGINX → Apache → PHP. Każda warstwa może mieć własną konfigurację i rzeczywistym limitem jest ta, która jako pierwsza odrzuci żądanie.

Na Apache również może działać limit rozmiaru requestu

Apache udostępnia dyrektywę LimitRequestBody, która ogranicza rozmiar body żądania HTTP w odpowiednim kontekście konfiguracji.

Oznacza to, że po migracji między serwerami identyczne ustawienia PHP nie gwarantują identycznego maksymalnego uploadu. Nowy hosting może mieć inną konfigurację serwera WWW.

Jeżeli 413 pojawił się dopiero po przeniesieniu witryny, porównaj nie tylko php.ini, ale także warstwę frontową i sposób obsługi PHP.

W hostingu współdzielonym użytkownik często nie ma dostępu do głównej konfiguracji NGINX lub Apache. Wtedy potrzebne są ustawienia udostępnione w panelu albo zgłoszenie do operatora, zamiast prób wpisywania niedozwolonych dyrektyw do przypadkowych plików.

Ustal rzeczywisty limit całej ścieżki uploadu

Przy bardziej rozbudowanej infrastrukturze request może przechodzić przez kilka miejsc, zanim dotrze do WordPressa:

użytkownik
    ↓
CDN / WAF / reverse proxy
    ↓
NGINX / Apache
    ↓
PHP-FPM
    ↓
WordPress

Każda warstwa może mieć własny limit. Podnoszenie jednej wartości bez poznania pozostałych często nie daje żadnego efektu.

Dobrym testem jest sprawdzenie kilku plików o kontrolowanym rozmiarze. Jeżeli 40 MB działa, 45 MB działa, a 50 MB i wszystko większe konsekwentnie odpada, masz znacznie lepszy punkt wyjścia niż ogólne „duże pliki się nie wysyłają”.

Nie oznacza to, że trzeba testować produkcję setkami uploadów. Kilka wartości wokół obserwowanej granicy zwykle wystarczy do wskazania warstwy, której konfigurację należy sprawdzić.

Nie zapomnij o CDN lub WAF

Jeżeli publiczny ruch przechodzi przez zewnętrzną usługę, jej limity mogą różnić się od limitów originu. Wtedy bezpośrednia konfiguracja PHP może być poprawna, a żądanie nadal nie przejdzie pełnej ścieżki od użytkownika.

Nie należy jednak automatycznie omijać CDN lub WAF na produkcji. Najpierw sprawdź dokumentację planu, logi i dostępne narzędzia diagnostyczne operatora.

Nie każdy problem z dużym plikiem jest błędem 413

Jeżeli upload przechodzi warstwę HTTP, awaria może nastąpić później.

Przykładowo:

PHP może przekroczyć czas wykonania,
proces może zabraknąć pamięci podczas rozpakowywania pliku,
import może wygenerować 500, 502 lub 504,
plugin może mieć własny limit,
może zabraknąć wolnego miejsca lub quota dyskowego,
plik może zostać odrzucony z powodu typu lub walidacji, a nie rozmiaru.

Dlatego najpierw zapisz dokładny kod HTTP i komunikat. Jeśli request kończy się dopiero po długim oczekiwaniu, diagnoza timeoutu z poradnika o 504 Gateway Timeout będzie bardziej odpowiednia niż dalsze zwiększanie limitu uploadu.

Podnoszenie limitów bez potrzeby nie jest dobrym celem samym w sobie

Jeżeli serwis rzeczywiście musi przyjmować pliki 500 MB, konfiguracja powinna to świadomie obsługiwać na całej ścieżce. Nie wynika z tego jednak, że każdej stronie WordPress trzeba od razu ustawić bardzo wysokie wartości.

Większy dopuszczalny request oznacza, że infrastruktura musi być przygotowana na obsługę takiego transferu i późniejsze przetwarzanie danych.

Przy jednorazowej migracji dużej biblioteki lub imporcie danych czasem lepszym rozwiązaniem jest mechanizm CLI, SFTP albo narzędzie importujące plik już znajdujący się na serwerze, zamiast przepychania bardzo dużego pliku przez formularz HTTP.

To zależy od aplikacji i dostępnych narzędzi. Ważne, aby nie podnosić limitów w ciemno tylko dlatego, że użytkownik zobaczył słowo „upload”.

Bezpieczna procedura diagnozy błędu 413

Zapisz dokładny kod HTTP i rozmiar problematycznego pliku.
Sprawdź, czy odpowiedź 413 pochodzi z frontowego serwera, proxy lub CDN.
Odczytaj upload_max_filesize i post_max_size.
Sprawdź, czy post_max_size ma zapas ponad upload_max_filesize.
Sprawdź maksymalny upload raportowany przez WordPressa.
Na NGINX sprawdź client_max_body_size.
Na Apache uwzględnij LimitRequestBody.
Jeżeli przed originem działa CDN/WAF, sprawdź jego limit dla request body/uploadu.
Ustal najniższy limit w całej ścieżce zamiast zmieniać wartości losowo.
Po zmianie wykonaj kontrolowany test plikiem o znanym rozmiarze.
Jeżeli request przechodzi, ale import nadal się wykłada, przenieś diagnozę do czasu wykonania, pamięci, aplikacji lub miejsca na dysku.

Jeżeli podejrzewasz ogólne limity konta, możesz dodatkowo użyć Diagnostyki zasobów hostingu.

Najważniejsze wnioski

413 oznacza, że body żądania jest większe niż odbiorca chce lub może obsłużyć;
request może zostać odrzucony zanim dotrze do PHP i WordPressa;
upload_max_filesize dotyczy pojedynczego pliku, a post_max_size całego POST;
post_max_size powinno pozostawiać zapas ponad upload_max_filesize;
wartość raportowana przez WordPress nie uwzględnia gwarancji zmieszczenia pliku dokładnie tej samej wielkości w całym multipart POST;
NGINX może mieć własny client_max_body_size;
Apache może ograniczać body przez LimitRequestBody;
CDN, WAF lub reverse proxy może wprowadzać kolejny limit;
rzeczywisty maksymalny upload wyznacza najniższy skuteczny limit na całej ścieżce;
jeżeli upload przejdzie, dalszy błąd może już dotyczyć czasu, pamięci, aplikacji albo przestrzeni dyskowej;
duże jednorazowe migracje nie zawsze powinny odbywać się przez formularz HTTP.

Źródła

RFC 9110 — 413 Content Too Large — znaczenie kodu 413.
PHP Manual — upload_max_filesize — limit rozmiaru pojedynczego uploadu.
PHP Manual — post_max_size — maksymalny rozmiar całych danych POST i relacja do upload_max_filesize.
WordPress Developer Resources — wp_max_upload_size() — wyliczanie maksymalnego rozmiaru uploadu w WordPressie.
NGINX — client_max_body_size — limit body żądania i odpowiedź 413.
Apache HTTP Server — LimitRequestBody — limit rozmiaru body żądania.