HTTP 413 Request Entity Too Large: Główne przyczyny, rozwiązania i przewodnik konfiguracji serwera

Błąd HTTP 413 Request Entity Too Large to kod statusu odpowiedzi po stronie serwera, który występuje, gdy treść przychodzącego żądania — najczęściej przesyłany plik — przekracza maksymalny rozmiar ładunku skonfigurowany na poziomie serwera WWW, odwrotnego proxy lub warstwy aplikacji. Serwer aktywnie odrzuca żądanie przed jego przetworzeniem, zwracając klientowi status 413.

Ten błąd nie jest usterką po stronie klienta. Jest to celowy mechanizm egzekwowania limitów wbudowany w serwery WWW, takie jak Nginx i Apache, konfiguracje środowiska uruchomieniowego PHP oraz oprogramowanie pośredniczące na poziomie aplikacji. Zrozumienie, która warstwa egzekwuje limit — i jak wskazać właściwą dyrektywę konfiguracyjną — to różnica między szybką naprawą a godzinami rozwiązywania problemów.

Dlaczego występują błędy HTTP 413: Analiza warstwa po warstwie

Żądanie przesłania pliku przechodzi przez wiele warstw przetwarzania, zanim dotrze do aplikacji. Każda z tych warstw może niezależnie odrzucić żądanie z odpowiedzią 413. Prawidłowe zdiagnozowanie błędu wymaga ustalenia, która warstwa jest odpowiedzialna.

Warstwa 1: Dyrektywy serwera WWW

Nginx egzekwuje limity rozmiaru przesyłanych plików za pomocą dyrektywy client_max_body_size. Jej domyślna wartość wynosi 1MB, co jest agresywnie niskim limitem dla większości nowoczesnych aplikacji. Dyrektywę tę można ustawić w kontekście bloku http, server lub location, przy czym obowiązuje najbardziej szczegółowy blok.

Apache używa dyrektywy LimitRequestBody, której domyślna wartość w większości dystrybucji wynosi 0 (bez limitu) — jednak dostawcy hostingu rutynowo zastępują ją w swoich globalnych konfiguracjach lub konfiguracjach wirtualnych hostów wartością restrykcyjną. Apache przetwarza również pliki .htaccess, co oznacza, że limit może być egzekwowany na poziomie katalogu bez modyfikowania głównej konfiguracji.

Warstwa 2: Konfiguracja środowiska uruchomieniowego PHP

PHP wprowadza dwie niezależne dyrektywy, które obie muszą być spełnione, aby duże przesyłanie pliku zakończyło się sukcesem:

• upload_max_filesize — maksymalny rozmiar pojedynczego przesyłanego pliku
• post_max_size — maksymalny rozmiar całej treści żądania POST, który musi być równy lub większy niż upload_max_filesize

Częstym błędem konfiguracji jest ustawienie upload_max_filesize = 50M przy pozostawieniu post_max_size na domyślnej wartości 8M. Limit rozmiaru treści POST jest oceniany jako pierwszy, więc przesyłanie pliku kończy się cichym niepowodzeniem, zanim limit rozmiaru pliku zostanie w ogóle sprawdzony.

Istnieje również trzecia dyrektywa, często pomijana: max_input_time, która określa, jak długo PHP będzie czekać na otrzymanie danych wejściowych. Przy wolnych połączeniach i przesyłaniu dużych plików ten limit czasu może wywołać błąd objawiający się jako 413 lub pusta odpowiedź.

Warstwa 3: Odwrotne proxy i load balancery

Jeśli infrastruktura korzysta z odwrotnego proxy — HAProxy, Varnish, Cloudflare lub instancji Nginx działającej jako proxy przed innym serwerem — ta warstwa proxy ma własne limity rozmiaru treści. Na przykład odpowiedź 413 zwrócona przez Cloudflare ma twardy limit 100MB dla planów Free i Pro i żadna konfiguracja po stronie serwera go nie nadpisze. Zawsze sprawdzaj nagłówki odpowiedzi warstwy proxy, aby zidentyfikować źródło błędu 413.

Warstwa 4: Ograniczenia aplikacji i CMS

Systemy zarządzania treścią i frameworki stosują własne ograniczenia przesyłania plików na poziomie serwera i PHP. WordPress odczytuje efektywny limit przesyłania z wartości środowiska uruchomieniowego PHP, ale egzekwuje również własne ograniczenia biblioteki mediów. Niektóre wtyczki WordPress dodają dodatkowe warstwy walidacji. Niestandardowe aplikacje PHP mogą używać logiki walidacji $_FILES, która narzuca bardziej restrykcyjne limity niż te dozwolone przez serwer.

Konfiguracja Nginx: Naprawianie błędu 413 na poziomie serwera WWW

W przypadku Nginx naprawa wymaga modyfikacji client_max_body_size w odpowiednim kontekście konfiguracji. Edycja bloku http stosuje limit globalnie; edycja bloku server lub location stosuje go tylko do tego wirtualnego hosta lub punktu końcowego.

# Global setting — applies to all virtual hosts
http {
    client_max_body_size 100M;
}

# Per-virtual-host setting — preferred for multi-tenant environments
server {
    listen 80;
    server_name example.com;
    client_max_body_size 100M;

    # Granular control — apply only to the upload endpoint
    location /wp-admin/async-upload.php {
        client_max_body_size 256M;
    }
}

Po edycji sprawdź poprawność składni konfiguracji przed przeładowaniem:

nginx -t && systemctl reload nginx

Krytyczny przypadek brzegowy: Jeśli Nginx działa jako odwrotne proxy przed PHP-FPM lub innym serwerem aplikacji, należy również sprawdzić dyrektywy proxy_read_timeout i proxy_send_timeout. Duże przesyłanie pliku trwające dłużej niż limit czasu zostanie przerwane w trakcie transferu, generując błąd 413 lub 504 w zależności od zachowania proxy.

Konfiguracja Apache: Naprawianie błędu 413 na poziomie serwera WWW

Dyrektywa LimitRequestBody Apache przyjmuje wartość w bajtach. Dyrektywę można umieścić w httpd.conf, bloku VirtualHost, bloku Directory lub pliku .htaccess.

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

# In .htaccess (if AllowOverride is enabled for the directory)
LimitRequestBody 104857600

Wartość 104857600 odpowiada 100MB (100 × 1024 × 1024). Po zmodyfikowaniu httpd.conf lub pliku wirtualnego hosta uruchom ponownie Apache:

apachectl configtest && systemctl restart apache2

Ważna uwaga: W środowiskach hostingu współdzielonego modyfikacje .htaccess mogą być ignorowane, jeśli dostawca hostingu ustawił AllowOverride None w konfiguracji na poziomie serwera. W takim przypadku tylko dostawca hostingu może zmienić limit. Jest to jeden z głównych technicznych powodów, aby rozważyć przeniesienie się do środowiska VPS Hosting, gdzie masz pełny dostęp root do konfiguracji serwera.

Konfiguracja PHP: Naprawianie błędu 413 na poziomie środowiska uruchomieniowego

Plik php.ini jest autorytatywnym źródłem limitów przesyłania PHP. Właściwy plik do edycji zależy od modelu wykonania PHP (mod_php, PHP-FPM, CLI). Użyj phpinfo() lub php --ini, aby zidentyfikować, który plik php.ini jest faktycznie załadowany.

; Minimum required changes for large file uploads
upload_max_filesize = 128M
post_max_size = 128M
max_input_time = 300
max_execution_time = 300
memory_limit = 256M

Po edycji php.ini uruchom ponownie odpowiednią usługę:

# For PHP-FPM
systemctl restart php8.2-fpm

# For Apache with mod_php
systemctl restart apache2

Alternatywne metody, gdy php.ini jest niedostępny:

Jeśli korzystasz z planu hostingu współdzielonego bez bezpośredniego dostępu do php.ini, możesz nadpisać ustawienia PHP używając:

1. Pliku .user.ini w katalogu głównym witryny (działa z PHP-FPM):

upload_max_filesize = 64M
post_max_size = 64M

1. Dyrektywy .htaccess (działa tylko z mod_php):

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. Kodu PHP w czasie wykonywania (ograniczona skuteczność, niezalecane w środowisku produkcyjnym):

@ini_set('upload_max_filesize', '64M');
@ini_set('post_max_size', '64M');

Należy pamiętać, że ini_set() nie może nadpisać upload_max_filesize ani post_max_size w czasie wykonywania w PHP 7.x i nowszych — te dyrektywy są oceniane przed rozpoczęciem wykonywania skryptu. Metody .user.ini lub .htaccess są znacznie bardziej niezawodne.

Naprawa błędów 413 specyficznych dla WordPress

WordPress wyświetla efektywny limit przesyłania na ekranie Media > Dodaj nowy. Jeśli wyświetlany limit jest niższy niż skonfigurowany w php.ini, problem zazwyczaj polega na tym, że WordPress odczytuje dane z innego procesu PHP lub warstwa pamięci podręcznej serwuje nieaktualne dane konfiguracyjne.

Dodaj poniższy kod do wp-config.php, aby jawnie zdefiniować rozmiar przesyłania:

@ini_set( 'upload_max_size', '128M' );
@ini_set( 'post_max_size', '128M' );
define( 'WP_MEMORY_LIMIT', '256M' );

W instalacjach WordPress Multisite rozmiar przesyłania na poziomie sieci jest kontrolowany oddzielnie w sekcji Network Admin > Settings > Network Settings > Max upload file size. To ustawienie jest niezależne od limitów PHP i musi być skonfigurowane dodatkowo, oprócz zmian na poziomie serwera.

Porównanie: Gdzie naprawić błąd 413 w zależności od środowiska hostingowego

Diagnozowanie, która warstwa zwraca błąd 413

Przed zastosowaniem jakiejkolwiek poprawki potwierdź źródło odpowiedzi 413. Użyj curl z pełnym wyjściem, aby sprawdzić nagłówki odpowiedzi:

curl -v -X POST -F "file=@/path/to/largefile.zip" https://example.com/upload

Sprawdź nagłówek odpowiedzi Server oraz nagłówki X-Powered-By lub CF-RAY. Nagłówek CF-RAY wskazuje, że błąd 413 pochodzi z Cloudflare, a nie z serwera. Odpowiedź od nginx/1.x.x wskazuje na warstwę Nginx. Brak nagłówka Server może wskazywać na load balancer lub WAF przed aplikacją.

Sprawdź również logi błędów serwera bezpośrednio po wywołaniu błędu 413:

# Nginx
tail -f /var/log/nginx/error.log

# Apache
tail -f /var/log/apache2/error.log

# PHP-FPM
tail -f /var/log/php8.2-fpm.log

Gdy konfiguracja serwera nie wystarczy: Kwestie infrastrukturalne

W przypadku aplikacji, które rutynowo obsługują duże transfery plików — platformy wideo, systemy kopii zapasowych, obrazowanie medyczne, duże katalogi produktów e-commerce — na stałe wpisywanie wysokich limitów przesyłania w konfigurację współdzielonego serwera nie jest zrównoważoną architekturą. Rozważ następujące alternatywy:

• Przesyłanie fragmentami (chunked uploads): Podziel duże pliki na mniejsze fragmenty po stronie klienta, używając bibliotek takich jak Resumable.js lub Uppy. Każdy fragment mieści się w limicie serwera, a serwer składa je z powrotem. Całkowicie omija to błąd 413.
• Przesyłanie bezpośrednio do object storage: Wygeneruj wstępnie podpisany URL dla magazynu zgodnego z S3 i pozwól klientowi przesyłać bezpośrednio, całkowicie omijając serwer WWW. Serwer WWW obsługuje tylko transakcję metadanych.
• Dedykowane punkty końcowe przesyłania: Skonfiguruj oddzielny blok location w Nginx z wyższą wartością client_max_body_size specjalnie dla tras przesyłania, zachowując domyślny restrykcyjny limit dla wszystkich pozostałych punktów końcowych.

W przypadku obciążeń obliczeniowych związanych z przetwarzaniem dużych plików — transkodowanie wideo, wnioskowanie uczenia maszynowego na przesłanych danych — środowisko GPU Hosting zapewnia moc obliczeniową do obsługi zarówno przesyłania, jak i późniejszych obliczeń bez wąskich gardeł.

Jeśli aplikacja wymaga środowiska z zarządzanym panelem sterowania i pełnym dostępem do konfiguracji PHP, VPS z cPanel zapewnia dostęp do edytora MultiPHP INI w WHM, umożliwiając nadpisywanie dyrektyw PHP dla poszczególnych domen bez korzystania z wiersza poleceń.

Kwestie bezpieczeństwa przy zwiększaniu limitów przesyłania

Zwiększanie limitów przesyłania bez odpowiedniego wzmocnienia bezpieczeństwa wprowadza realne zagrożenia. Serwer akceptujący żądania POST o rozmiarze 500MB jest realnym celem ataków denial-of-service wyczerpujących operacje I/O dysku, pamięć lub pule połączeń.

Wdróż następujące środki kontroli równolegle z każdym zwiększeniem limitu:

• Ograniczanie częstotliwości żądań na punktach końcowych przesyłania: W Nginx użyj limit_req_zone, aby ograniczyć częstotliwość przesyłania na adres IP.
• Walidacja typów plików: Nigdy nie polegaj na typie MIME dostarczonym przez klienta. Waliduj sygnatury plików (magic bytes) po stronie serwera.
• Uprawnienia katalogu przesyłania: Katalog odbierający przesyłane pliki nie może być dostępny przez sieć ani wykonywalny. Przechowuj przesłane pliki poza katalogiem głównym dokumentów.
• Skanowanie antywirusowe: Zintegruj ClamAV lub podobny skaner z procesem przesyłania dla każdego publicznie dostępnego punktu końcowego przesyłania.
• Tylko uwierzytelnione przesyłanie: Wymagaj uwierzytelnienia przed akceptowaniem dużych ładunków. Nieuwierzytelnione punkty końcowe do przesyłania dużych plików są trywialnie nadużywane.

W środowiskach produkcyjnych obsługujących wrażliwe przesyłane dane, połączenie infrastruktury hostingowej z prawidłowo skonfigurowanymi certyfikatami SSL zapewnia szyfrowanie transferów plików podczas przesyłania, zapobiegając przechwyceniu przesyłanych treści.

Macierz decyzji technicznych: Wybór właściwej poprawki

Praktyczna lista kontrolna rozwiązywania błędu HTTP 413

• Zidentyfikuj warstwę zwracającą błąd 413 za pomocą curl -v i logów błędów serwera przed wprowadzeniem jakichkolwiek zmian
• W Nginx ustaw client_max_body_size w najbardziej szczegółowym odpowiednim bloku (location preferowany przed server przed http)
• Upewnij się, że post_max_size jest zawsze większy lub równy upload_max_filesize w php.ini
• Zwiększ max_input_time i max_execution_time dla dużych plików na wolnych połączeniach
• Sprawdź, czy nadpisania .htaccess są dozwolone (AllowOverride All lub AllowOverride Options) przed poleganiem na nich
• Sprawdź wszystkie warstwy proxy niezależnie — CDN, load balancer i serwer aplikacji egzekwują limity oddzielnie
• Po każdej zmianie konfiguracji przeładuj (nie tylko uruchom ponownie) odpowiednią usługę i wyczyść pamięć podręczną opcode lub stron
• W przypadku WordPress Multisite skonfiguruj limit przesyłania na poziomie sieci dodatkowo, oprócz dyrektyw PHP
• Wdróż ograniczanie częstotliwości żądań i walidację typów plików przed zwiększeniem limitów na publicznych punktach końcowych przesyłania
• Jeśli hosting współdzielony uniemożliwia dostęp do konfiguracji, przenieś się do środowiska VPS Hosting lub serwerów dedykowanych dla pełnej kontroli

Często zadawane pytania

Jaki jest domyślny limit przesyłania w Nginx powodujący błąd 413?

Nginx domyślnie ustawia client_max_body_size na 1MB. Każda treść żądania przekraczająca 1MB zwróci błąd 413, chyba że ta dyrektywa zostanie jawnie zwiększona w konfiguracji Nginx.

Czy mogę naprawić błąd 413 bez dostępu root do serwera?

Na hostingu współdzielonym możesz próbować naprawić błąd za pomocą .htaccess (tylko Apache, jeśli AllowOverride na to pozwala) lub pliku .user.ini (tylko PHP-FPM). Jednak jeśli dostawca hostingu ustawił restrykcyjne globalne limity, te metody będą nieskuteczne i będziesz musiał skontaktować się z pomocą techniczną lub przejść na plan VPS.

Dlaczego przesyłanie pliku kończy się niepowodzeniem nawet po zwiększeniu upload_max_filesize w php.ini?

Najczęstszą przyczyną jest to, że post_max_size pozostaje na niższej domyślnej wartości. PHP ocenia limit rozmiaru treści POST przed limitem rozmiaru pojedynczego pliku, więc przesyłanie jest odrzucane, zanim upload_max_filesize zostanie w ogóle sprawdzony. Zawsze zwiększaj obie dyrektywy jednocześnie.

Czy Cloudflare powoduje błędy 413?

Tak. Cloudflare egzekwuje własne limity rozmiaru treści żądania: 100MB dla planów Free i Pro, 200MB dla Business i 500MB dla Enterprise. Jeśli żądanie przekracza te limity, Cloudflare zwraca błąd 413, zanim żądanie dotrze do serwera źródłowego. Żadna zmiana konfiguracji po stronie serwera tego nie rozwiąże — musisz albo uaktualnić plan Cloudflare, użyć bezpośredniego przesyłania z pominięciem (wstępnie podpisane URL) lub wdrożyć przesyłanie fragmentami.

Jak trwale naprawić błąd 413 w WordPress na serwerze cPanel?

Użyj edytora MultiPHP INI w WHM, aby zwiększyć upload_max_filesize i post_max_size dla konkretnej wersji PHP i domeny. Następnie sprawdź, czy zmiana jest widoczna w WordPress w sekcji Media > Dodaj nowy. W przypadku WordPress Multisite dodatkowo zaktualizuj maksymalny rozmiar przesyłania w Network Admin > Settings. Żadne zmiany .htaccess ani wp-config.php nie są wymagane przy bezpośrednim korzystaniu z edytora INI w WHM.