Apache 的 conf.d 目录通常用来存放独立的配置片段，虚拟主机配置也经常写在这里。文件放进目录并重启服务后却不生效，原因一般不在 Apache 本身，而在于加载链路、匹配顺序或端口监听这几个环节没有被核实。先从主配置是否真正包含 conf.d 目录开始排查，再结合虚拟主机列表输出和日志定位，可以避免反复重启却找不到问题。
一、先确认 conf.d 目录是否真的被主配置包含
很多人会默认只要把文件放进 conf.d 目录，Apache 就会自动读取。实际上这取决于主配置文件 httpd.conf 中是否显式加入了 Include 指令。多数发行版会默认包含 Include conf.d/*.conf，但部分精简安装或自定义编译版本可能没有这一行。没有 Include 时，conf.d 里的文件会被完全忽略，即使配置内容正确也不会生效。
可以打开主配置文件检查。常见的路径有 /etc/httpd/conf/httpd.conf、/etc/apache2/apache2.conf 或 /usr/local/apache2/conf/httpd.conf。如果使用的是 IncludeOptional，即使 conf.d 目录不存在也不会报错，但 Include 在目录缺失时会直接导致启动失败。这个差异会影响你排查时看到的错误信息。
还需要注意文件后缀名。Include 通常只匹配 .conf 文件，如果你把配置写成了 .txt 或者没有后缀名，Apache 不会加载。文件权限也不可忽略，运行 Apache 的用户必须至少拥有读取配置文件的权限，否则加载阶段可能直接跳过或者报错。
# 在 httpd.conf 中确认存在以下包含语句 Include conf.d/*.conf # 或者使用可选包含，目录不存在时不会报错 IncludeOptional conf.d/*.conf
二、用 httpd -S 查看虚拟主机加载顺序与默认站点
当配置确实被加载，但请求仍然进入错误的虚拟主机时，最有效的排查工具是 apachectl -S 或 httpd -S。它会列出当前 Apache 解析到的所有虚拟主机、监听端口、ServerName，以及哪个主机是默认主机。这个命令不需要重启服务，适合在修改配置后快速核对结果。
在输出中，标记为 default server 的那个虚拟主机，就是当请求没有匹配到任何 ServerName 或 ServerAlias 时会被使用的配置。很多人以为域名解析对了就会进入对应虚拟主机，其实如果 ServerName 写得与请求的 Host 头不完全一致，又没有配置 ServerAlias，请求就会落到默认主机上。
默认主机的选择通常与配置文件的加载顺序有关。Apache 会按字母顺序读取 conf.d 目录下的文件，先读到的虚拟主机更容易成为默认主机。因此文件名不要随意命名，例如 00-default.conf、10-example.conf 这样的命名方式可以主动控制加载顺序，避免因文件顺序导致默认站点不符合预期。
VirtualHost configuration:
*:80 is a NameVirtualHost
default server www.ipipp.com (/etc/httpd/conf.d/10-example.conf:1)
port 80 namevhost www.ipipp.com (/etc/httpd/conf.d/10-example.conf:1)
port 80 namevhost api.ipipp.com (/etc/httpd/conf.d/20-api.conf:1)
从上面输出可以看出，www.ipipp.com 是默认主机，如果 api.ipipp.com 的请求没有被正确匹配，也会进入 www.ipipp.com。要解决这个问题，需要检查 20-api.conf 中的 <VirtualHost> 块里 ServerName 是否写成了 api.ipipp.com，并且是否配置了 ServerAlias。很多配置不生效的问题，实际上都是 ServerName 和请求域名没有精确对应导致的。
三、常见配置不生效原因及修复思路
端口未监听是另一个高频原因。虚拟主机块中使用的端口必须已经在主配置中通过 Listen 指令打开。比如 <VirtualHost *:8080> 如果没有对应的 Listen 8080，Apache 完全不会在 8080 端口上接收请求。此时即使虚拟主机配置正确，访问时也只会得到连接被拒绝，而不是进入某个站点。
重复定义虚拟主机也会导致行为混乱。如果两个文件里都写了 <VirtualHost *:80> 且 ServerName 相同，Apache 可能会合并部分指令，或者后加载的配置覆盖前面的某些参数。更隐蔽的是 DocumentRoot 指向同一个目录，但日志和重写规则不同，导致表面看配置没生效，实际是请求根本没有进入你以为的那个虚拟主机。
为了确定请求到底进入了哪个虚拟主机，可以在每个虚拟主机块中配置独立的日志文件。这样访问一次目标 URL，再查看对应日志是否新增记录，就能判断匹配是否正确。日志配置如下：
<VirtualHost *:80>
ServerName api.ipipp.com
DocumentRoot /var/www/api
ErrorLog /var/log/httpd/api-error.log
CustomLog /var/log/httpd/api-access.log combined
</VirtualHost>
如果日志没有新增，说明请求没有进入该虚拟主机；如果日志出现了，但页面内容不对，则需要检查 DocumentRoot 路径、目录索引文件，以及是否存在 .htaccess 覆盖了配置。在开启 AllowOverride 的目录下，.htaccess 中的重写规则或错误页面可能会覆盖虚拟主机级别的设置，这也是代码调整后仍然看不到效果的一个常见原因。
权限问题也不能忽视。即使配置正确，如果 DocumentRoot 目录不可读，或者 SELinux 策略阻止了 httpd 访问，Apache 仍然会返回 403。此时可以查看 /var/log/httpd/error_log 中的具体报错，通常能看到 Permission denied 或 SELinux 相关提示。根据错误日志内容再决定是调整目录权限，还是修改 SELinux 上下文。
四、修改后如何验证与维护注意事项
每次修改配置后，不要直接重启服务。先执行 apachectl configtest 检查语法，再执行 apachectl -S 查看虚拟主机列表。这两个命令可以在不中断服务的情况下发现大部分配置问题，尤其是多文件配置时，语法检查能够准确指出出错文件和行号。
reload 和 restart 也有区别。reload 会重新读取配置，但不会中断现有连接，适合大多数场景。不过有些模块或监听端口的变更需要 restart 才能生效。如果修改了 Listen 端口，或者遇到非常诡异的缓存行为，直接 restart 会更可靠，也能排除因为优雅重启未完全释放旧配置导致的现象。
维护阶段建议给 conf.d 下的文件使用统一的命名规则，例如用数字前缀控制加载顺序，用站点域名或用途作为文件名。同时避免同一个虚拟主机既在 conf.d 目录配置，又在 sites-enabled 目录软链接启用，否则排查时很容易漏掉另一份配置。把每个站点独立成文件，并配置独立日志，是减少混乱、快速定位问题最实用的方法。
Apache虚拟主机conf.dhttpd.conf修改时间：2026-10-05 18:23:55