LimitRequestFieldSize 必须在服务器级或VirtualHost中显式配置，不支持Directory等子块覆盖，因其属server config上下文且在请求解析早期固化为硬限制；遗漏未配VirtualHost或默认主机将导致防护盲区。
LimitRequestFieldSize 在 VirtualHost 中无法被子块覆盖，因为它根本不支持更低层级的作用域。这个指令只在服务器级（主配置、<VirtualHost>）生效，<Directory>、<Location>、<Files> 甚至 .htaccess 都不能重新定义它——不是“会被覆盖”，而是压根不识别。
为什么不会被覆盖？
Apache 明确将 LimitRequestFieldSize 归类为server config 和 virtual host 级指令（见官方文档 Directive Context）。它在请求解析早期就由核心模块读取并固化为连接/请求上下文的硬限制，后续所有目录或路径级配置阶段都已跳过该处理逻辑。
尝试在 <Directory> 中写这行：
LimitRequestFieldSize 4096
</Directory>
结果：Apache 启动时不会报错，但该行完全被忽略——日志无提示，运行时也查不到生效痕迹。
Apache 2.4.62
下载
Apache 2.4.62 官方 tar.gz 源码包是 Linux 及类 Unix 系统构建 Web 服务器的核心基础。通过源码编译安装，开发者能够灵活定制模块、优化性能并精准控制安装路径，满足多样化的业务需求。
真正要防的不是“覆盖”，而是“遗漏”
常见误操作不是子块改了值，而是配置只放在某个 <VirtualHost> 里，却忽略了默认主机或未匹配的端口监听（如只配了 :443 没配 :80）。攻击者可直连 IP 或发 Host 头不匹配的请求，绕过防护。
正确做法是：
- 每个启用的
<VirtualHost>块内都显式声明LimitRequestFieldSize 2048 - 若使用通配符监听（如
<VirtualHost *:80>），确保它作为兜底存在且配置完整 - 避免依赖全局配置段（如
httpd.conf根层级）单独设置——虚拟主机配置会继承服务器级值，但显式写出更可控、更易审计
验证是否真生效
别信“写了就对”。三步确认：
- 语法检查：
apache2ctl -t或httpd -t无报错 - 运行时确认：
apache2ctl -t -D DUMP_RUN_CFG | grep LimitRequestFieldSize，输出必须是你设的数值（如LimitRequestFieldSize 2048） - 实测拦截：用 curl 发一个超长头，例如
curl -H "X-Test: $(printf 'a' {1..3000})" http://yoursite.com/，应返回400 Bad Request，且 error.log 出现request header length exceeds LimitRequestFieldSize
