3.1 配置结构与指令作用域

3.1 配置结构与指令作用域

本节摘要：httpd 的"配置"从来不是一份文件，而是一棵树：主入口按 Include 拼装片段，虚拟主机、目录、位置、文件等容器层层嵌套，请求按自己的特征（域名、路径、文件）激活树上的一条分支，各层指令按固定顺序合并成最终工单。本节讲透这棵树的构造、指令的合法位置、合并覆盖规则，以及 .htaccess 的性能账——看懂本节，"配置了不生效"的问题就从玄学变成流程题。

本节的学习收获

阅读完本节，你应当能够：

1. 画出主配置到各片段的 Include 拼装结构；
2. 说出常见指令各自允许的作用域；
3. 解释目录段与位置段的合并顺序与覆盖差异；
4. 决定 .htaccess 的开与关，并说明性能理由；
5. 用既定流程排查"配置不生效"类问题。

配置是一棵树，不是一份清单

第 2 章装好的机器，配置入口只有一个，但入口文件里散布着 Include 指令，把各片段挂进来；片段里又可以再嵌 Include，最终展开成一棵树。Debian 系的展开路径大致是：主配置引入启用的模块片段、启用的站点片段、启用的全局片段；RedHat 系则是主配置引入模块目录与配置目录。无论哪种方言，实际生效的配置 = 这棵树展开后的全集。

想知道自己的树长什么样，两个命令是地图：

# 列出展开后的完整虚拟主机与配置片段顺序
apachectl -t -D DUMP_VHOSTS | head -15
# 语法检查同时显示包含关系（-t 报错时会给出具体片段与行号）
apachectl -t
​

树上有两类节点：全局指令（直接长在主干上，如 Listen、User、ErrorLog）和容器指令。容器家族有五个高频成员，各自按请求的不同特征圈地：

新手最容易混淆的是 Directory 与 Location：前者看磁盘上真实的路径，后者看URL 字符串。多数场景两者会指向同一批文件，但一旦做了重写或代理，URL 与磁盘路径就分家了——比如把某前缀的 URL 代理给后端，这个前缀在磁盘上根本没有对应目录，此时只能用 Location。判断口诀：管"请求去哪"用 Location，管"文件在哪、谁能读"用 Directory。

合并顺序：后写的覆盖先写的，但有精确的"后"

多个容器命中同一个请求时，合并顺序是固定且反直觉的——不是书写顺序，而是：

1. 先主配置与 .htaccess 按目录层级从浅到深（浅层先、深层后，深层覆盖浅层）；
2. Directory 系（按路径从短到长）；
3. .htaccess（跟随所在目录层级插入）；
4. DirectoryMatch、Files、FilesMatch；
5. 最后 Location 与 LocationMatch——Location 是最终解释权。

一个能救命的实际推论：想强制某条规则不被 .htaccess 推翻，写在 Location 里——它在合并顺序的最后，谁也覆盖不了它（除非另一个更长的 Location）。反过来，如果你发现某条 Directory 里的规则"怎么都不生效"，先检查是不是被一个 Location 覆盖了。

同一个作用域内同一条指令重复出现时，多数指令是"后者覆盖前者"；但也有"叠加型"指令（如 Header、SetEnvIf、RewriteCond），重复写会叠加。这种差异没有统一的记忆口诀，靠的是写每条指令前扫一眼文档里的"上下文"说明。好在有工具兜底：apachectl -t 会在明显非法的写法（比如把只允许全局的 Listen 写进虚拟主机）时直接报错并给出文件与行号。

指令的合法位置：五个格子

每条指令的文档页都有"Context"（上下文）属性，取值五种：

• server config：只能写主配置全局区，如 Listen、LoadModule；
• virtual host：可写虚拟主机；
• directory：可写各容器及 .htaccess；
• .htaccess：允许落到用户级目录文件（前提是 AllowOverride 放行该类别）；
• 若指令标了 subset，表示 .htaccess 里只允许部分参数组合。

日常排错里这个属性的价值极高："Invalid command X"多半是模块没加载；"X not allowed here"则是指令写错了格子。两个报错，两种病，别混着治。

.htaccess：便利与代价的合同

.htaccess 允许在内容目录里放配置，浏览器请求路径上的每个目录都会被查一遍。它的存在理由是权限分权：共享主机上，平台管理员不可能替每个租户改主配置，于是让租户在自己家目录里自治。这是 httpd 在托管领域屹立不倒的护城河。

但代价常被低估：请求路径上有 N 层目录，httpd 就要做 N 次磁盘查找（哪怕什么都没找到），而且主配置里与该文件相关的缓存优化会因 AllowOverride 打开而失效。高流量站点上这笔账很可观。

生产决策很清晰：如果你能改主配置，就把规则全部搬进主配置的 Directory 段，然后一把 AllowOverride None 关掉查找：

<Directory "/var/www/example">
    AllowOverride None
    # 把原来 .htaccess 里的规则原样搬进来
    RewriteEngine On
    RewriteRule ^index\.php$ - [L]
</Directory>
​

只有两种情况保留 .htaccess：多租户平台必须分权；或某个遗留应用（典型如内容管理系统的安装器）强制要求写它。即便如此，也用 AllowOverride 限定类别（如只放行 AuthConfig 与 Limit），不要用 All 大开绿灯。

⚠️ 常见坑：改了 .htaccess 立即生效（无需重启），改主配置却要 reload——行为差异让很多人误以为两种配置"机制不同"。其实机制完全一样，.htaccess 只是每次请求都重新合并，代价就是前述的磁盘查找。

"配置不生效"的排查流程

把本节知识收拢成一张排查流程图，这是运维现场最值钱的一页：

图 3-1 配置不生效排查流程

顺手学一个匹配复现技巧——用 curl 伪造 Host 头，验证虚拟主机匹配而不动 DNS：

curl -s -H "Host: shop.example.com" http://127.0.0.1/ -o /dev/null -w "%{http_code}\n"
​

本节要点回顾

• 树形结构：配置 = Include 展开的树，请求按域名与路径激活分支；
• 五大容器：VirtualHost、Directory 系、Location 系、Files 系，按不同特征圈地；
• Directory vs Location：管磁盘用前者，管 URL 用后者，重写/代理场景两者分家；
• 合并铁律：浅到深、Location 最后——想不被覆盖就写 Location；
• htaccess 决策：能进主配置就关 AllowOverride，只有分权与遗留应用值得付磁盘查找的税；
• 两类报错：Invalid command 是模块没装，not allowed here 是格子写错。

💡 一句话记住本节：配置生效三要素——在树上、在正确的格子里、没被覆盖。