LimitExcept指令仅能在Directory、Location、Files或.htaccess上下文中使用；正确配置需用配合Require all denied，并注意OPTIONS等方法需显式放行。
LimitExcept 指令只能在目录上下文中使用
直接写在 VirtualHost 或服务器全局配置里会报错：Invalid command 'LimitExcept', perhaps misspelled or defined by a module not included in the server configuration。这不是模块没加载，而是作用域错了——LimitExcept 只允许出现在 .htaccess 中。
实操建议：
- 优先用
.htaccess性能更好、更可控 - 若必须用
.htaccess，确保父目录的AllowOverride启用了Limit（不是默认的All或None） - Apache 2.4+ 默认不启用
mod_access_compat，但LimitExcept属于mod_authz_core，无需额外加载模块
只允许 GET 和 HEAD，禁止其他所有方法
这是最常见需求，比如静态资源目录或只读 API 端点。注意：不显式列出的方法默认被拒绝，但 LimitExcept 的逻辑是「除了列出的，其余全拒」，所以写法要反着来。
正确配置示例：
<directory><limitexcept get head>
Require all denied
</limitexcept></directory>
关键点：
-
Require all denied是 Apache 2.4 的写法；2.2 用Deny from all，但混用会导致语法错误 - 别漏掉
HEAD—— 浏览器预检、CDN 缓存探针常用它，禁掉可能引发 405 或缓存失效 -
OPTIONS不在允许列表里，会被拦截，而 CORS 预检依赖它；如需支持跨域，得显式加上OPTIONS
配合 Require 指令做条件放行
单纯靠 LimitExcept 只能控制方法类型，没法区分用户角色或来源 IP。真要实现「管理员可用 POST，普通用户只能 GET」，必须嵌套 Require。
例如限制 POST 仅限内网调用：
<directory><limitexcept get head><requireall>
Require ip 192.168.0.0/16
Require valid-user
</requireall></limitexcept></directory>
注意陷阱：
-
LimitExcept块内不能直接写Require ip，必须包在 - 如果同时配置了外部
Require（比如整个目录设了Require valid-user），会和LimitExcept内的规则叠加，容易过度拦截 -
TRACE方法默认被 Apache 关闭（TraceEnable off），即使没在LimitExcept中禁止，也无法启用
调试 405 Method Not Allowed 错误时重点查三点
返回 405 不代表配置失败，而是请求方法被明确拒绝。排查顺序很关键：
- 先确认请求方法是否在
LimitExcept的「白名单」里（大小写敏感，get≠GET） - 检查是否触发了更高优先级的配置，比如外层
Limit或LimitExcept覆盖了当前目录 - 用
curl -v -X PATCH http://host/path实测，别依赖浏览器——浏览器自动降级为 GET，掩盖问题
真正容易被忽略的是：Apache 对 WebDAV 相关方法（PROPFIND、PROPPATCH 等）有独立模块处理，LimitExcept 控制不了它们，得靠 LoadModule dav_module 开关或
