Nginx 中 301 重定向如何在自动化运维部署脚本中无缝生成重写配置

自动化运维脚本生成Nginx 301重定向配置，需参数化输入、结构化解析（CSV/YAML）、按规则类型生成对应server/location块，统一用return 301、禁用rewrite/if，并内置语法校验与nginx -t验证。

在自动化运维脚本中生成 Nginx 301 重定向配置，核心是把人工写 conf 的逻辑转为可参数化、可校验、可批量执行的代码动作。重点不是“写对一行 return”，而是让脚本能根据输入（如旧域名、新地址、映射规则列表）自动产出合法、安全、可 reload 的 server 块或 location 段，并规避常见陷阱。

用 return 301 替代 rewrite，脚本里直接拼接最稳

所有重定向逻辑统一用 return 301，不调用 rewrite 或 if 判断。脚本只需按规则类型生成对应结构：

1. 单页跳转：生成 location = /old.html { return 301 /new.html?$args; }
2. 目录迁移：生成 location ^~ /old-dir/ { return 301 /new-dir$request_uri; }
3. 整站换域：生成独立 server { listen 80; server_name old.com www.old.com; return 301 https://new.com$request_uri; }

重定向规则从外部文件读取，避免硬编码

脚本不内置跳转逻辑，而是解析结构化输入，比如一个 CSV 或 YAML 映射表：

1. CSV 示例：old_path,new_path,type → /about, /company, page 或 /blog/, /posts/, prefix
2. YAML 示例：domain_redirect: { from: ["old.net", "www.old.net"], to: "https://new.co" }
3. 脚本逐行读取，按 type 分发到不同模板，输出对应 Nginx 片段

生成前做基础语法校验，防无效配置上线

脚本在写入 conf 文件前，应做最小可行性检查：

1. 目标 URL 是否含协议（http:// 或 https://），缺失则补 https://
2. $request_uri 和 $args 是否被正确引用，避免写成 $uri 或漏掉 ?
3. server_name 中的域名是否符合格式（不含下划线、长度合理）
4. 生成后自动执行 nginx -t，失败则退出并打印错误位置

与虚拟主机部署联动，避免孤立配置

重定向配置不应单独存在，需嵌入或关联主站点生命周期：

1. 若为旧站关停场景，脚本同时停用原 server 块，启用跳转 server 块
2. 若为灰度迁移，支持按路径前缀生成带条件判断的 location（但不用 if，改用 map + return）
3. 生成的 conf 文件按约定路径存放（如 /etc/nginx/conf.d/redirects/old-site.conf），便于统一管理与清理