nginx rewrite规则需写入可挂载的配置文件（如conf.d/app.conf），通过-v挂载目录后执行nginx -s reload生效；不可硬编码在基础镜像中，且必须置于server/location块内，配合rewrite_log和nginx -t验证确保语法正确。
在容器化环境中，Nginx 的 Rewrite 规则本身不是“挂载”的对象，而是写在配置文件（如 server 块内）中，随配置文件一起被挂载进容器，并在 Nginx 重载后生效。关键在于：规则必须放在正确位置、配置文件要可挂载、重载机制要可靠。
Rewrite 规则必须写在可挂载的配置文件里
不要把 rewrite 指令硬编码进基础镜像的 /etc/nginx/nginx.conf；应将其写入独立的虚拟主机配置文件（如 /etc/nginx/conf.d/app.conf），再通过 Docker volume 挂载该文件或整个 conf.d 目录。
- 推荐结构：宿主机创建
/opt/nginx/conf.d/app.conf，内容含完整的server块和 rewrite 指令 - 启动容器时挂载：
-v /opt/nginx/conf.d:/etc/nginx/conf.d:ro - 避免覆盖主配置：不挂载整个
nginx.conf，除非你完全接管全部配置
挂载后需触发 Nginx 重载才能生效
挂载是实时的（文件一改，容器内立即可见），但 Nginx 进程不会自动读取新配置。必须执行 nginx -s reload 才能加载新 rewrite 规则。
- 开发调试时：手动进入容器执行
docker exec nginx nginx -s reload - 生产环境：配合配置变更监听工具（如
inotifywait）或 CI/CD 流程自动 reload - 注意权限：确保执行 reload 的用户有权限向 Nginx 主进程发送信号（通常为 root 或 nginx 用户）
rewrite 指令位置和上下文不能出错
rewrite 只能在 server、location 或 if 块中使用。容器内若因挂载路径错误导致配置语法异常（如缺少分号、嵌套错误），reload 会失败，Nginx 继续运行旧配置甚至退出。
- 检查语法：挂载前先在宿主机用
nginx -t -c /opt/nginx/conf.d/app.conf验证（需指向完整配置树） - 常见陷阱：rewrite 写在
http块顶层（非法）、正则未转义特殊字符（如点号、斜杠）、flag 误用（如该用last却写了break） - 调试建议：开启
rewrite_log on;并设error_log /var/log/nginx/error.log notice;，便于排查匹配逻辑
动态更新场景下注意变量与路径一致性
如果 rewrite 规则依赖 $host、$args 或自定义变量（如 set $my_path "/new";），要确认这些变量在容器运行时的取值与宿主机测试环境一致——尤其是 Host 头、反向代理头（X-Forwarded-Host）是否透传。
- 例如基于域名跳转的规则：
rewrite ^/(.*)$ https://new.example.com/$1 permanent;，需确保请求实际携带了预期的Host值 - 若 Nginx 前有负载均衡器，可能需要加
proxy_set_header Host $host;保证 $host 可靠 - 所有路径引用（如重定向目标、内部重写路径）都应使用绝对 URI 或相对于 location 的路径，避免因根路径变化失效
