nginx master进程启动时继承shell环境变量，worker进程默认继承master的环境变量；reload不更新环境变量，必须重启master才能生效。
Nginx 的 Master 进程本身不直接处理请求，但它负责启动、监控和管理 Worker 进程。环境变量的继承与传递，是理解 Nginx 启动行为和配置生效范围的关键点之一。
Master 进程如何获取环境变量
Master 进程在启动时（即执行 nginx 命令时）会完整继承当前 shell 的环境变量。这包括通过 export 设置的变量、系统级环境配置（如 /etc/environment）、以及 systemd 或 init 脚本中显式设置的变量（取决于启动方式）。
注意：Nginx 自身不会主动读取或解析 `.bashrc`、`.profile` 等用户 shell 配置文件 —— 它只继承调用它的进程实际拥有的环境快照。
Worker 进程是否继承 Master 的环境变量
是的，但有前提：默认情况下，Worker 进程由 Master 通过 fork() + exec() 启动，会完整继承 Master 当前的环境变量表（即 POSIX 的 environ）。这意味着：
- 在 Master 启动前已设置的环境变量（如
PATH、LD_LIBRARY_PATH、自定义变量）通常能透传到 Worker； - 若 Master 启动后、Worker 启动前，通过
setenv()或类似方式动态修改了自身环境，这部分变更也会被 fork 后的 Worker 继承； - 但 Nginx 配置文件（如
nginx.conf）中 不支持 直接设置或覆盖环境变量（例如没有env MY_VAR=xxx这样的原生指令，除非使用商业版或 OpenResty 的set_by_lua等扩展）。
常见陷阱与可控手段
实践中容易误判环境变量是否生效，尤其在容器化或 systemd 环境中：
-
systemd 启动时需显式声明：若用 systemd 管理 Nginx，必须在 service 文件中用
Environment=或EnvironmentFile=提前注入变量，否则即使宿主机 shell 里 export 了，systemd 子进程也不会继承； -
Docker 中要避免仅靠
ENV指令：Dockerfile 的ENV只影响构建和docker run时的初始环境；若 entrypoint 覆盖了启动命令（如用sh -c "nginx"），可能丢失父层环境，建议用 exec 形式（exec nginx）确保干净继承； -
Worker 内无法修改全局环境：单个 Worker 中调用
putenv()或类似操作，只影响自身进程空间，不会反向同步给 Master 或其它 Worker； -
调试建议：可在 Worker 进程中通过 Lua（OpenResty）或小模块打印
os.getenv("XXX")，或用cat /proc/<pid>/environ | tr '\0' '\n'</pid>查看某 Worker 实际看到的环境。
特殊场景：reload 时的环境变量行为
执行 nginx -s reload 时，Master 进程不会重启，而是发送信号让其重新加载配置并优雅启动新 Worker。此时：
- 新 Worker 仍从当前 Master 进程的环境继承变量，而 Master 的环境自最初启动起就未变化；
- 即使你在 reload 前修改了 shell 环境变量，也不会影响正在运行的 Master，因此新 Worker 也不会拿到这些“新”变量；
- 要更新环境变量，必须彻底 stop 再 start（即重启 Master 进程），而非 reload。
掌握这个继承链（启动 Shell → Master → Worker），就能准确预判变量在哪一层生效、为什么某些配置看似“不生效”，也能避开容器和 systemd 下常见的环境隔离误区。
