limitrequestbody 是协议层资源守门员，用于在请求体进入php前硬拦截大请求；需按 multipart 结构开销设值（如52.3mb），禁用0，仅在等四作用域生效，须同步配置nginx/modsecurity等中间件并验证日志。
LimitRequestBody 不是“防内存溢出”的补丁，而是防止大请求体耗尽 worker 进程缓冲区的第一道硬拦截——它在数据进入 PHP 或应用逻辑前就切断连接，不分配后端内存、不触发解析，本质是协议层资源守门员。
值设多大才既安全又够用
不能照搬文件大小，必须覆盖 multipart 请求的全部结构开销：
- 若 PHP 设 upload_max_filesize = 50M 且 post_max_size = 52M，Apache 建议设 LimitRequestBody 54857600（约 52.3MB），多出的 2–3MB 用于 boundary、字段名、换行符、中文 UTF-8 编码等真实开销
- 纯 JSON/XML API 接口可设 5242880（5MB）或 10485760（10MB），按业务最大 payload 预估，不盲目放大
- 明确禁止上传的路径（如
/login），可设极小值如 1024，只允许轻量参数 - 严禁设为 0——生产环境等于敞开大门，攻击者可发 1GB 垃圾 POST 拖垮所有 worker 进程
必须写对位置，否则形同虚设
该指令只在四个作用域生效，且以最内层为准：
-
块内：推荐用于整站统一管控，例如后台管理域或上传专用子域名 -
块内：最精准，仅限制指定物理路径下的 POST/PUT 请求 -
.htaccess 文件中：需确保上级目录已启用
AllowOverride Limit，否则被忽略 - 主配置顶层（如 httpd.conf）：全局生效但灵活性差，不推荐生产使用
-
不能写在
、 ；XAMPP 用户请确认 httpd-vhosts.conf 已被主配置或 块中 Include加载
绕过 Apache 的常见“隐身拦截”要同步处理
很多 413 错误其实根本没到 Apache，得检查上游和中间件：
-
Nginx 反向代理：必须同步配置
client_max_body_size 50M（放在 http/server/location 块），并确保透传Content-Length和Content-Type -
ModSecurity：默认
SecRequestBodyLimit 1048576（1MB），可能抢先返回 413；查modsec_audit.log确认 -
系统级默认限制：RHEL/CentOS 常在
/etc/httpd/conf.d/welcome.conf中预设LimitRequestBody 1024，必须显式覆盖 -
mod_proxy 缓冲区：若用 Apache 做反向代理，加
ProxyReceiveBufferSize 2097152（2MB），避免缓存截断
验证是否真起效，别信“看起来正常”
改完配置后，必须用真实场景验证：
- 语法检查：
sudo apachectl configtest或sudo httpd -t - 重载服务：
sudo systemctl reload apache2（Debian）或sudo systemctl reload httpd（RHEL） - 构造真实 multipart 请求：
curl -F "file=@test.bin" -F "desc=中文测试" http://example.com/upload.php，而非只测单个大文件 - 查 Apache error_log：成功拦截会记录
request body exceeds LimitRequestBody，而不是 PHP 的$_FILES['file']['error'] === 1
