sbin 存放 Nginx 主程序 nginx，是启动、重载、停止服务的核心二进制文件；conf 存放所有配置文件，默认主配置 nginx.conf 控制全部服务行为，二者在启动时按编译指定路径绑定，修改 conf 后需 reload 才生效。
sbin 存放 Nginx 的可执行主程序（nginx），是启动、重载、停止服务的核心二进制文件；conf 存放所有配置文件，默认主配置为 nginx.conf，控制服务行为、模块加载、虚拟主机、反向代理等全部逻辑。
sbin 文件夹：Nginx 的“执行引擎”
该目录下通常只有一个关键文件：nginx（无扩展名），它是编译后生成的静态或动态链接可执行程序。它不依赖外部脚本，直接解析 conf 中的指令并调度 worker 进程。
- 常见操作都通过调用此二进制完成：如
./sbin/nginx启动、./sbin/nginx -s reload热重载、-t检查配置语法 - 生产环境常将
sbin/nginx软链到/usr/sbin/nginx或加入 PATH，便于全局调用 - 注意：它本身不读取 conf 目录路径，而是靠编译时指定默认配置位置（可通过
nginx -V查看--conf-path参数）
conf 文件夹：Nginx 的“行为说明书”
这是 Nginx 运行逻辑的唯一来源。主配置文件 nginx.conf 采用块（block）、指令（directive）、上下文（context）三层结构，所有功能均由其驱动。
-
nginx.conf必须存在，且需包含events和http块才能正常工作；最小可用配置仅需几行 - 常用拆分方式：用
include mime.types;加载类型映射，用include conf.d/*.conf;引入站点配置，提升可维护性 - 敏感配置如 SSL 证书路径、代理地址、访问控制规则，都必须在 conf 中显式声明，sbin 不参与决策
二者协作关系：启动时的一次关键绑定
Nginx 启动流程中，sbin 与 conf 的关联发生在初始化阶段——不是运行时动态查找，而是一次性加载解析。
- 若未用
-c指定配置路径，sbin 会严格按编译参数中的--conf-path（如/usr/local/nginx/conf/nginx.conf）去读取 - 修改 conf 后，sbin 不自动感知；必须执行
nginx -s reload（发信号给 master 进程）才重新读取并平滑切换 - 误删 conf 文件夹会导致
nginx -t报错 “no such file”，即使 sbin 完好也无法启动
实际部署中的典型误区
很多问题源于对两个目录职责边界的模糊理解。
- 把自定义脚本（如日志切割 shell）放进 sbin —— 应放入
scripts/或系统/usr/local/bin/，sbin 只管 nginx 本体 - 在 conf 中写绝对路径指向其他分区的证书，但忘记同步更新 SELinux 上下文或文件权限 —— 导致 sbin 执行时因权限拒绝而失败
- 使用容器时，习惯性挂载整个 conf 目录却忽略
nginx.conf内的include路径是否仍有效 —— 实际上 include 是相对 conf 目录解析的
