LimitExcept 实现HTTP方法白名单反向控制,必须嵌套在Directory/Location/Files/.htaccess中并配合Require指令生效;仅允许GET和HEAD时需显式包含HEAD以防CDN或预检失败;支持嵌套RequireAll/RequireAny实现细粒度权限控制。

用 LimitExcept 控制 HTTP 方法,核心不是“放行哪些”,而是“除了列出的,其余一律拒绝”——它本质是白名单逻辑的反向表达,必须搭配 Require 才生效,且只能出现在目录级上下文中。
必须放在正确的配置位置
LimitExcept 不能写在 VirtualHost 或全局服务器块里,否则会报错:Invalid command 'LimitExcept'。它只被允许在以下四种作用域中使用:
-
块内(推荐,性能好、易维护) -
块内(适合按 URL 路径控制) -
或块内(针对特定文件名) -
.htaccess文件中(需父目录开启AllowOverride Limit,不建议生产环境滥用)
只允许 GET 和 HEAD 的标准写法
这是静态资源或只读接口最常用的安全配置。注意:HEAD 必须显式列出,否则浏览器预检、CDN 缓存探测可能失败,返回 405。
Apache 2.4+ 正确示例:
Require all denied
关键点:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 不要漏掉
Require all denied,光有LimitExcept不起作用 - 别混用 Apache 2.2 语法(如
Deny from all),会导致解析失败 - OPTIONS 方法默认不在允许列表里,跨域请求会因预检失败而中断;如需支持 CORS,必须加进
LimitExcept列表
结合 Require 实现条件化放行
单纯限制方法不够细粒度。LimitExcept 块内可嵌套 或 ,实现“某方法仅限某类用户/某段 IP 使用”。
例如:只允许内网 IP 调用 POST,其他方法全拒:
Require ip 10.0.0.0/8
Require valid-user
注意:
-
Require不能直接写在LimitExcept下,必须包在或中 - 若该目录外层已设
Require valid-user,会与内部规则叠加,可能导致合法 POST 请求也被拦住,需统一梳理权限层级
避开常见陷阱和隐性影响
有些行为看似无关,实则和 LimitExcept 交互紧密:
-
TRACE方法默认被禁用(TraceEnable off),即使没出现在LimitExcept中也无法启用 -
OPTIONS被拒时,前端发不出跨域请求,错误表现为 405 Method Not Allowed,但根源常被误判为 CORS 配置问题 - 调试 405 错误时,优先确认三点:请求方法是否在
LimitExcept允许列表中、Require规则是否匹配、是否存在外层Require或认证模块干扰 - WebDAV 等扩展功能依赖 PUT、DELETE、PROPFIND 等方法,启用前务必在对应路径中显式放开,否则服务不可用










