Nginx include 指令通过按域名/业务拆分配置、复用通用模板、变量注入、自动化生成与校验，实现千级vhost可持续管理；需注意加载顺序、上下文限制及绝对路径使用。

Nginx 的 include 指令是管理大量虚拟主机（vhost）配置的核心手段，它能将主配置文件拆分为多个独立、可维护的子文件，避免单个 nginx.conf 膨胀失控。关键不在于“能不能用”，而在于“怎么组织才可持续”——尤其当 vhost 数量达数百甚至上千时。

按域名或业务维度拆分配置文件

不要把所有 server 块堆进一个大文件，而是为每个站点（或一组相关站点）创建单独的配置文件，例如：

• /etc/nginx/sites-available/example.com
• /etc/nginx/sites-available/api.company.internal
• /etc/nginx/sites-available/shop-tenant-0042

再在 http 块中统一 include：

http {
    include /etc/nginx/sites-enabled/*;
}

推荐使用 sites-enabled（软链到 sites-available 中启用的文件），便于快速启停站点而无需删改配置。

统一基础模板 + 变量注入减少重复

千个 vhost 若各自写全量配置，维护成本极高。可通过以下方式收敛共性：

• 提取通用段落：如日志格式、SSL 参数、反向代理头设置，放在 /etc/nginx/common/ssl.conf、/etc/nginx/common/proxy.conf 中，各 vhost 文件内 include 复用
• 利用 Nginx 内置变量（如 $host、$server_name）动态适配路径或证书文件名，例如：
  ssl_certificate /etc/letsencrypt/live/$host/fullchain.pem;
• 对高度同构的租户站点（如 SaaS 多租户），可用 Lua 或 OpenResty 做运行时路由，但需权衡复杂度

自动化生成与校验配置，避免手工失误

手动维护上千个文件不可行。建议构建轻量脚本流程：

• 用 Jinja2、Go template 或简单 shell 脚本，根据 YAML/JSON 清单批量生成 vhost 配置文件
• 每次生成后执行 nginx -t 校验语法，失败则中断部署
• 结合 Git 管理配置源码，配合 CI 检查变更影响范围（例如某次提交新增了 57 个子域，是否触发证书配额告警？）
• 上线前用 nginx -T 导出完整生效配置做 Diff，确认无意外覆盖或遗漏

注意 include 路径与加载顺序的隐含行为

include 不是宏替换，而是按字面路径读取并插入当前上下文。需特别留意：

• 通配符匹配顺序依赖文件系统排序（如字母序），00-default.conf 会先于 zz-last.conf 加载，影响 server_name 匹配优先级
• 被 include 的文件里不能出现顶层指令（如 events、http），只能包含允许出现在该上下文中的块（如 server、location）
• 相对路径以 nginx 启动时的工作目录为基准，生产环境务必用绝对路径，避免因启动方式不同导致加载失败