Nginx 用 include 抽离老旧站点重定向规则的核心是解耦、可维护与防主配置臃肿，需确保被 include 文件为完整 server 块且置于合法上下文（如 http 块末尾），目录结构推荐 /etc/nginx/conf.d/redirects/ 下按站点分文件，每文件含独立 server 块处理域名级跳转，并须经 nginx -t 验证、DNS 指向确认及 curl 测试。
Nginx 用 include 把老旧站点的重定向规则单独抽出来，核心是解耦 + 可维护 + 避免主配置臃肿。不是简单加一行 include 就完事，得结构清晰、路径正确、上下文匹配。
明确重定向规则该放在哪个上下文里
老旧站点重定向通常是域名级或路径级跳转（比如 `old.com → new.com` 或 `/old-page → /new-page`），这类规则必须写在 `server` 块内。所以你 include 的文件内容本身就得是一个完整的 `server` 块，或者被包含在已有 `server` 块中——不能直接 include 到 `http` 块里再塞 `return 301`，那会报错。常见错误：在 http 块里写 include /etc/nginx/redirects/old-site.conf;，而 old-site.conf 里只有 return 301 ...; —— 缺少 server{...} 包裹，Nginx 启动直接失败。
推荐目录结构与文件组织
把重定向配置按“老站归档”思路管理，例如：-
/etc/nginx/conf.d/redirects/—— 专放所有历史跳转配置 /etc/nginx/conf.d/redirects/old-company.com.conf/etc/nginx/conf.d/redirects/blog-old.conf
每个 .conf 文件就是一个独立的 server 块，只做一件事：监听旧域名、返回 301。例如：
old-company.com.conf 内容：
server {
listen 80;
server_name old-company.com www.old-company.com;
return 301 https://www.php.cn/link/372fd987ae6e6c94ea921ffefe33668f;
}
<p>server {
listen 443 ssl;
server_name old-company.com www.old-company.com;
ssl_certificate /etc/letsencrypt/live/old-company.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/old-company.com/privkey.pem;
return 301 <a href="https://www.php.cn/link/372fd987ae6e6c94ea921ffefe33668f">https://www.php.cn/link/372fd987ae6e6c94ea921ffefe33668f</a>;
}在主配置中正确引入
打开/etc/nginx/nginx.conf 或站点主入口（如 /etc/nginx/conf.d/default.conf），确保 include 语句出现在合法位置：
- 如果要批量加载多个老站配置，加在
http块末尾（前提是每个被 include 的文件都是完整server块）：
http {<br> ... # 其他 http 级配置<br> include /etc/nginx/conf.d/redirects/*.conf;<br>}
- 如果只想让某几个老域名复用现有 HTTPS server 块，也可以把重定向逻辑拆进
location或用map统一处理，再 include 进对应 server 块内 —— 更适合路径级跳转（如/old-api/ → /v2/）。
验证与上线前必做三件事
- 执行
nginx -t检查语法：确保 include 路径存在、文件可读、内容无上下文错位 - 确认旧域名 DNS 已指向当前 Nginx 服务器（否则用户根本走不到这一步）
- 用
curl -I http://old-company.com测试响应头是否含Location: https://new-company.com...和状态码301
不复杂但容易忽略。
