记一次 Nginx 多站点配置踩坑实录路由串台与 SELinux 403 拦截排查一、 故障背景与环境操作系统Rocky Linux 9Web 服务Nginx 1.20.1目标架构配置基于域名的虚拟主机。访问专属域名mytest.com➡️ 返回默认站点/usr/share/nginx/html。访问其他任意域名或直接使用 IP 访问 ➡️ 返回自定义的兜底站点/var/www/default。二、 故障一路由“串台”所有请求均返回默认欢迎页1. 故障现象配置完两个server块并执行systemctl reload nginx重新加载服务后进行测试curl-HHost: mytest.comhttp://127.0.0.1# 预期欢迎页curlhttp://127.0.0.1# 预期自定义兜底页实际结果两条命令均返回了 Nginx 原生的默认欢迎页自定义兜底页未生效。2. 排查思路与过程面对“路由串台”我采用了分层排查与控制变量法应用层验证执行nginx -t提示语法正常。但为了排除热加载reload未完全生效的极端情况我执行了systemctl restart nginx重启服务强制重启问题依旧。检查配置细节仔细核对兜底server块的root指令发现路径被误写为root /var/www/default/html;对比实际物理路径通过ls -ld /var/www/default检查发现实际存在的目录是/var/www/default并不存在html这个子目录。推导结论由于root路径指向了一个不存在的目录Nginx 无法在该块中正确找到index.html。在复杂的虚拟主机匹配和隐式默认规则下请求未能按预期返回自定义页面而是落入了原生的默认欢迎页配置中。3. 解决方案修正root路径去掉多余的/htmlroot /var/www/default;执行nginx -t检查语法并systemctl reload nginx重载配置。再次通过 IP 访问此时 Nginx 成功匹配到了正确的物理目录但页面并未正常显示而是抛出了新的错误403 Forbidden。三、 故障二访问兜底页面报 403 Forbidden1. 故障现象解决路由问题后通过 IP 访问兜底站点curl返回403 Forbidden。2. 排查思路与过程403 错误通常意味着“请求已到达服务器但被拒绝访问”。我按照“文件系统权限 ➡️ 系统安全策略”的顺序进行排查基础文件系统权限排查ls-ld/var/www/default# 目录权限 drwxr-xr-x (正常)ls-l/var/www/default/index.html# 文件权限 -rw-r--r-- (正常)权限配置完全符合 Nginx 运行用户nginx的读取要求排除基础权限问题。系统安全层SELinux排查Rocky 9 默认开启 SELinuxEnforcing 模式它会在基础权限之上进行强制访问控制MAC。临时宽容测试执行setenforce 0后访问立刻恢复正常执行setenforce 1恢复严格模式后再次 403。确诊为 SELinux 拦截。检查安全上下文标签执行ls -Zd /var/www/default输出unconfined_u:object_r:default_t:s0 /var/www/default发现该目录的标签为default_t。而 Nginx 进程httpd_t只被允许读取带有httpd_sys_content_t标签的 Web 目录。由于是我手动新建的目录SELinux 没有自动为其分配正确的 Web 标签。3. 解决方案生产环境最佳实践很多新手会选择直接永久关闭 SELinux但这在生产环境中是严重的安全违规。我采用了semanage工具进行永久且规范的上下文修复安装 SELinux 策略管理工具sudodnfinstallpolicycoreutils-python-utils-y添加目录及其子文件的上下文规则sudosemanage fcontext-a-thttpd_sys_content_t/var/www/default(/.*)?刷新并应用规则sudorestorecon-Rv/var/www/default最终验证确保 SELinux 处于 Enforcing 状态getenforce再次访问页面正常显示。故障二完美解决。四、 复盘与避坑指南1. 排查思维总结路由异常不要只盯着自己写的配置当出现“串台”或未按预期返回时一定要仔细核对root物理路径是否真实存在并排查include引入的“幽灵文件”如conf.d/*.conf确保default_server的全局唯一性。403 异常建立条件反射。在 RHEL/CentOS/Rocky 系系统中只要基础权限rwx没问题却报 403第一嫌疑人永远是 SELinux。2. SELinux 修复规范❌ 错误做法setenforce 0临时或修改/etc/selinux/config为 disabled永久关闭。这会留下巨大的安全隐患。✅ 正确做法使用semanage fcontext定义规则配合restorecon刷新生效。这才是标准姿势。
记一次 Nginx 多站点配置踩坑实录路由串台与 SELinux 403 拦截排查一、 故障背景与环境操作系统Rocky Linux 9Web 服务Nginx 1.20.1目标架构配置基于域名的虚拟主机。访问专属域名mytest.com➡️ 返回默认站点/usr/share/nginx/html。访问其他任意域名或直接使用 IP 访问 ➡️ 返回自定义的兜底站点/var/www/default。二、 故障一路由“串台”所有请求均返回默认欢迎页1. 故障现象配置完两个server块并执行systemctl reload nginx重新加载服务后进行测试curl-HHost: mytest.comhttp://127.0.0.1# 预期欢迎页curlhttp://127.0.0.1# 预期自定义兜底页实际结果两条命令均返回了 Nginx 原生的默认欢迎页自定义兜底页未生效。2. 排查思路与过程面对“路由串台”我采用了分层排查与控制变量法应用层验证执行nginx -t提示语法正常。但为了排除热加载reload未完全生效的极端情况我执行了systemctl restart nginx重启服务强制重启问题依旧。检查配置细节仔细核对兜底server块的root指令发现路径被误写为root /var/www/default/html;对比实际物理路径通过ls -ld /var/www/default检查发现实际存在的目录是/var/www/default并不存在html这个子目录。推导结论由于root路径指向了一个不存在的目录Nginx 无法在该块中正确找到index.html。在复杂的虚拟主机匹配和隐式默认规则下请求未能按预期返回自定义页面而是落入了原生的默认欢迎页配置中。3. 解决方案修正root路径去掉多余的/htmlroot /var/www/default;执行nginx -t检查语法并systemctl reload nginx重载配置。再次通过 IP 访问此时 Nginx 成功匹配到了正确的物理目录但页面并未正常显示而是抛出了新的错误403 Forbidden。三、 故障二访问兜底页面报 403 Forbidden1. 故障现象解决路由问题后通过 IP 访问兜底站点curl返回403 Forbidden。2. 排查思路与过程403 错误通常意味着“请求已到达服务器但被拒绝访问”。我按照“文件系统权限 ➡️ 系统安全策略”的顺序进行排查基础文件系统权限排查ls-ld/var/www/default# 目录权限 drwxr-xr-x (正常)ls-l/var/www/default/index.html# 文件权限 -rw-r--r-- (正常)权限配置完全符合 Nginx 运行用户nginx的读取要求排除基础权限问题。系统安全层SELinux排查Rocky 9 默认开启 SELinuxEnforcing 模式它会在基础权限之上进行强制访问控制MAC。临时宽容测试执行setenforce 0后访问立刻恢复正常执行setenforce 1恢复严格模式后再次 403。确诊为 SELinux 拦截。检查安全上下文标签执行ls -Zd /var/www/default输出unconfined_u:object_r:default_t:s0 /var/www/default发现该目录的标签为default_t。而 Nginx 进程httpd_t只被允许读取带有httpd_sys_content_t标签的 Web 目录。由于是我手动新建的目录SELinux 没有自动为其分配正确的 Web 标签。3. 解决方案生产环境最佳实践很多新手会选择直接永久关闭 SELinux但这在生产环境中是严重的安全违规。我采用了semanage工具进行永久且规范的上下文修复安装 SELinux 策略管理工具sudodnfinstallpolicycoreutils-python-utils-y添加目录及其子文件的上下文规则sudosemanage fcontext-a-thttpd_sys_content_t/var/www/default(/.*)?刷新并应用规则sudorestorecon-Rv/var/www/default最终验证确保 SELinux 处于 Enforcing 状态getenforce再次访问页面正常显示。故障二完美解决。四、 复盘与避坑指南1. 排查思维总结路由异常不要只盯着自己写的配置当出现“串台”或未按预期返回时一定要仔细核对root物理路径是否真实存在并排查include引入的“幽灵文件”如conf.d/*.conf确保default_server的全局唯一性。403 异常建立条件反射。在 RHEL/CentOS/Rocky 系系统中只要基础权限rwx没问题却报 403第一嫌疑人永远是 SELinux。2. SELinux 修复规范❌ 错误做法setenforce 0临时或修改/etc/selinux/config为 disabled永久关闭。这会留下巨大的安全隐患。✅ 正确做法使用semanage fcontext定义规则配合restorecon刷新生效。这才是标准姿势。
