nginx启动后仅有master进程而无worker进程，表明派生失败，需聚焦启动阶段配置解析、权限校验、模块初始化等前置环节；应优先运行nginx -t验证配置，检查error_log错误、user指令权限、系统资源限制及第三方模块依赖服务是否就绪。
当 Nginx 启动后只有 Master 进程、没有 Worker 进程，说明派生环节失败。这不是 Worker 崩溃后的恢复问题，而是启动阶段的初始化阻断——Master 本身已运行，但拒绝或无法 fork 出子进程。关键要聚焦在“启动时卡在哪一步”。
检查配置语法与加载阶段错误
Master 在 fork Worker 前必须完成配置解析、路径校验、模块初始化等前置动作。任一环节失败，它会静默停止派生，仅维持自身运行（表现为“有 master、无 worker”）。
- 运行 nginx -t：强制验证配置语法和文件路径可访问性。常见报错如
open() "/var/log/nginx/access.log" failed (13: Permission denied)或SSL certificate file not found都会导致派生中止 - 若使用第三方模块（如 fastdfs-nginx-module），需确认其依赖配置文件是否就位（如
/etc/fdfs/mod_fastdfs.conf）、tracker_server地址格式是否正确（不能带多余前缀如tracker:） - 检查
error_log级别是否设为info或更高，确保启动期关键错误不被过滤
验证用户权限与系统资源限制
Worker 进程默认以非 root 用户身份运行，Master 在 fork 后会尝试切换用户。若目标用户无权访问关键路径（如日志目录、SSL 证书、模块共享内存区），则 fork 后立即退出，且不拉起新进程。
- 查看 nginx.conf 中 user 指令：若注释了
#user nobody，Nginx 将以 nobody 用户启动 Worker；该用户需对access_log、error_log、pid、client_body_temp_path等所有路径有读写权限 - 临时改为
user root测试：若此时 Worker 正常出现，即可确认是权限问题；后续应修复路径属主（如chown -R nginx:nginx /var/log/nginx），而非长期用 root 运行 Worker - 检查系统级限制：
ulimit -n（文件描述符）、ulimit -u（最大进程数）、可用内存；Worker 启动需分配监听 socket、共享内存段等，资源不足时会静默失败
排查模块冲突与依赖服务缺失
部分模块（尤其是整合 FastDFS、Lua、Perl 等）在初始化阶段会主动连接外部服务或读取配置。若依赖未就绪，Master 可能卡在初始化，或初始化失败后放弃派生。
- 确认配套服务已启动：例如整合 FastDFS 时，必须先运行
fdfs_trackerd和fdfs_storaged，再启动 Nginx；否则 mod_fastdfs 初始化超时，Master 不继续派生 - 检查模块兼容性：动态模块需与当前 Nginx 版本 ABI 匹配；若加载失败（如
dlopen() failed），Master 日志中通常有明确提示，但 Worker 仍不会出现 - 禁用可疑模块测试：注释掉
load_module行，或移除nginx.conf中相关location块，观察 Worker 是否恢复
观察日志与进程行为特征
Master 不派生 Worker 是“无声失败”，必须依赖日志和进程状态交叉印证，避免误判为启动成功。
- 查看 error_log 的最开头几行：重点找
init_worker_processes() failed、failed to initialize、could not build the server_names_hash等启动期错误 - 执行 ps aux | grep nginx：确认只有带
master process字样的进程，且无任何worker process；同时注意 master 进程的 CPU 占用是否持续为 0 —— 若为 0，大概率已卡在初始化末尾 - 检查 systemctl status nginx 输出：若显示
active (running)但无 worker，说明 systemd 认为服务启动成功，实际业务层已失效，需人工介入
