Īsi sakot: post_max_size ierobežo visa POST pieprasījuma izmēru, upload_max_filesize atsevišķu failu; noklusējums saskaņā ar PHP rokasgrāmatu ir 8M un 2M. Vērtībām jāatbilst robežām tīmekļa serverī un lietojumprogrammā, citādi augšupielādes izgāžas bez skaidra ziņojuma. Līdz PHP2Shell atjauninājumam php.net iesaka post_max_size = 8M bez augšupielādēm vai 32M ar augšupielādēm, upload_max_filesize zemāk, iestatītu tā, lai lietojumprogrammas to nevarētu pārrakstīt.
Ja pieteikumu veidlapa pēkšņi klusē
Pēc PHP2Shell pārejas pasākumiem daudzi administratori ir samazinājuši post_max_size. Dažas dienas vēlāk personāla nodaļa ziņo, ka pieteikumi vairs nenonāk. Veidlapa vienkārši ielādējas no jauna, kļūdas ziņojuma nav. Iemesls: pieprasījums ar trim PDF pielikumiem bija lielāks par jauno robežu, un PHP veidlapas datus atmeta.
Piemērs rāda pamatproblēmu. Augšupielādes robežas darbojas vairākās vietās vienlaikus, un katra vieta uz pārsniegšanu reaģē citādi. Kas pazīst ķēdi, var iestatīt vērtības tā, lai tās aizsargātu, netraucējot darbību. Kā PHP iekšēji apstrādā augšupielādes, izskaidro Kā PHP apstrādā failu augšupielādes; drošu augšupielādes funkciju programmēšanu apraksta Failu augšupielāžu droša īstenošana PHP.
Augšupielādes robežu ķēde
Pieprasījums šķērso vairākas robežas, pirms lietojumprogramma to redz. Turpmākie dati ir no Nginx, Apache un PHP dokumentācijas:
| Vieta | Iestatījums | Noklusējums saskaņā ar dokumentāciju | Pārsniedzot |
|---|---|---|---|
| Nginx | client_max_body_size |
1m | kļūda 413 pārlūkam |
| Apache no 2.4.54 | LimitRequestBody |
1 GiB (līdz 2.4.53: neierobežots) | kļūdas atbilde apstrādes vietā |
| PHP | post_max_size |
8M | $_POST un $_FILES tukši |
| PHP | upload_max_filesize |
2M | fails tiek noraidīts ar kļūdas kodu |
| PHP | max_file_uploads |
20 | pārējie faili tiek ignorēti |
| PHP | max_input_vars |
1000 | pārējo veidlapas lauku trūkst |
No tā izriet vienkāršs noteikums: upload_max_filesize mazāks par post_max_size, post_max_size mazāks par robežu tīmekļa serverī. PHP rokasgrāmata turklāt iesaka, lai memory_limit parasti būtu lielāks par post_max_size. PHP2Shell pārejas pasākuma ar memory_limit=-1 laikā šo lomu pārņem robeža caur konteineru vai cgroup; vairāk sadaļā memory_limit pareizi iestatīt.
post_max_size pēc PHP2Shell: ko iesaka php.net
Drošības paziņojumā no 2026. gada 21. oktobra php.net serveriem bez atjauninājuma kā vienu no pārejas pasākumiem min zemas pieprasījumu robežas. Tās samazina atsevišķu uzbrukuma ceļu risku, taču nepārprotami nav pilnīga aizsardzība:
- Bez failu augšupielādēm:
post_max_size = 8M. - Ar failu augšupielādēm:
post_max_size = 32M. - Abos gadījumos:
upload_max_filesizeturēt zempost_max_size. - Papildus apsvērt: robežas tīmekļa serverī vai starpniekserverī dekodētajam pieprasījuma izmēram, ievades lauku skaitam, multipart daļu skaitam, galvenes rindu skaitam un ligzdošanas dziļumam. Saskaņā ar php.net šīm robežām jāaptver arī pieprasījumi bez izmantojamas
Content-Lengthnorādes.
Vērtībām jāatrodas tur, kur lietojumprogrammas tās nevar pārrakstīt. Tā kā post_max_size un upload_max_filesize saskaņā ar rokasgrāmatu ir maināmi direktorijas līmenī, .user.ini vai mod_php gadījumā .htaccess tās citādi varētu atkal paaugstināt:
; Vietnes FPM pūls, ar augšupielādēm (pāreja līdz atjauninājumam)
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 24M
php_admin_value[max_file_uploads] = 5
Tīmekļa serverī robežu velciet tikai nedaudz augstāk, lai pārāk lielie pieprasījumi vispār nenonāktu pie PHP:
# Nginx, server vai location blokā
client_max_body_size 32m;
# Apache, VirtualHost: 32 MiB baitos
LimitRequestBody 33554432
Pēc tam pārlādējiet visus PHP worker procesus un tīmekļa serveri. Visu pārejas pasākumu pārskats atrodams sadaļā Tūlītēji pasākumi, ja vēl nevarat ielāpot. Vai un kā augšupielādes pieprasījumus papildus var filtrēt starpniekserverī, aplūko Augšupielādes pieprasījumu filtrēšana malā.
Pēc katras izmaiņas testējiet veidlapas ar lielākajiem leģitīmajiem pieprasījumiem: pieteikumiem ar vairākiem pielikumiem, produktu importiem, attēlu galerijām. Pārāk šaura vērtība paralizē uzņēmējdarbības procesus, un neviens neredz kļūdas ziņojumu.
Pareizās vērtības noteikšana jūsu vietnei
Vispārīgu vērtību vietā ir vērts veikt īsu inventarizāciju. Uzskaitiet visas veidlapas ar augšupielādēm un pierakstiet lielāko leģitīmo failu un lielāko vienlaicīgo failu skaitu. No tā izriet vajadzība: upload_max_filesize sedz lielāko atsevišķo failu, post_max_size visu viena pieprasījuma failu summu plus nelielu rezervi veidlapas laukiem.
Ja vajadzība pārsniedz 32M, tā neatbilst php.net pārejas ieteikumam. Tad tas ir vēl viens iemesls atjauninājumu pieņemt priekšā. Lielas augšupielādes var apstrādāt arī caur savu apakšdomēnu ar savu pūlu, lai pārējā vietne saglabātu šauras robežas.
Pēc atjauninājuma uz 8.5.12, 8.4.27, 8.3.36, 8.2.35 vai apstiprinātu backport varat vērtības atkal pielāgot faktiskajai vajadzībai. Devīgākām nekā vajag tomēr tām nevajadzētu būt: katra robeža, kas pārsniedz vajadzību, palielina uzbrukuma virsmu bez ieguvuma. Ja vietnei augšupielādes nav vajadzīgas vispār, file_uploads = Off ir tīrākais risinājums.
Kļūdu pazīmju pareiza interpretācija
Ja augšupielādes izgāžas, uzvedība atklāj, kura robeža darbojas. Lapa ar kļūdu 413 nāk no tīmekļa servera. Veidlapa, kas bez ziņojuma ielādējas no jauna vai ziņo „nederīgs pieprasījums”, norāda uz tukšiem $_POST datiem, tātad post_max_size. Lietojumprogrammas ziņojums par atsevišķu failu atbilst upload_max_filesize. Un trūkstoši lauki ļoti lielās veidlapās, piemēram, produktu variantiem, liecina par max_input_vars. PHP kļūdu žurnāls, pārsniedzot post_max_size, parasti satur brīdinājumu ar pieprasījuma izmēru.
Lai lietotāji nepaliktu bezpalīdzīgi, lietojumprogrammai šis gadījums jāatpazīst. PHP rokasgrāmata šim nolūkam iesaka vienkāršu ceļu: veidlapa adresē nodod marķieri, piemēram, ?processed=1. Ja marķieris ierodas, bet $_POST un $_FILES ir tukši, pieprasījums bija pārāk liels, un lietojumprogramma var parādīt saprotamu ziņojumu ar pieļaujamo izmēru.
Kā PHP SOS palīdz konkrēti?
- Mēs uzskaitām visus jūsu vietņu augšupielādes ceļus un noskaidrojam faktiski nepieciešamos izmērus.
- Mēs iestatām tīmekļa servera, PHP un pūla robežas saskaņoti un pret pārrakstīšanu bloķētas, ieskaitot php.net pārejas vērtības.
- Mēs pēc pārejas testējam veidlapas, importus un augšupielādes un mērķtiecīgi pielāgojam vērtības.
- Serveru nostiprināšanas ietvaros mēs pēc atjauninājuma vērtības atgriežam pie ilgtermiņa vajadzības.
Biežāk uzdotie jautājumi
Kāda ir atšķirība starp post_max_size un upload_max_filesize?
upload_max_filesize ierobežo vienas augšupielādētas faila izmēru. post_max_size ierobežo visus viena POST pieprasījuma datus, tātad visus failus un veidlapas laukus kopā. Saskaņā ar PHP rokasgrāmatu post_max_size tāpēc jābūt lielākam par upload_max_filesize.
Kas notiek, ja pieprasījums ir lielāks par post_max_size?
Saskaņā ar PHP rokasgrāmatu $_POST un $_FILES tad ir tukši. Lietojumprogramma tātad nesaņem nekādus veidlapas datus un bieži rāda tikai neskaidru kļūdas ziņojumu vai ielādē veidlapu no jauna. Tas šo kļūdu apgrūtina atpazīt.
Kādas vērtības php.net iesaka PHP2Shell dēļ?
Kā pārejas pasākumu līdz atjauninājumam: post_max_size = 8M lietojumprogrammām bez failu augšupielādes, 32M lietojumprogrammām ar augšupielādēm, un upload_max_filesize zemāk. Saskaņā ar php.net tā nav pilnīga aizsardzība; ievainojamības aizver tikai atjauninājums uz labotu PHP versiju.
Vai post_max_size varu mainīt ar ini_set() kodā?
Nē. Saskaņā ar PHP rokasgrāmatu post_max_size ir maināms tikai direktorijas līmenī, piemēram, php.ini, FPM pūlā, .user.ini vai mod_php gadījumā .htaccess. Kas vērtību grib uzspiest, to iestata ar php_admin_value, tad to nevar pārrakstīt arī .user.ini.