nginx启动失败但systemctl status显示active，实为systemd启动顺序问题：未等待network-online.target就绪或SSL挂载点未就绪，导致绑定443端口失败；需配置Requires=network-online.target、After=network-online.target及Wants=mnt-ssl.mount等。
nginx 启动失败但 systemctl status 显示 active，实际无法监听 443 端口
这通常不是 nginx 自身问题，而是 systemd 启动顺序没等 SSL 证书就位或网络未真正就绪。systemd 默认只认 network.target，但它不保证网卡已获取 IP 或路由可达——nginx 绑定 0.0.0.0:443 会直接失败，但进程可能仍被判定为“启动成功”。
- 必须用
Requires=network-online.target+After=network-online.target，不能只写After= - 若证书放在独立挂载点（如
/etc/nginx/ssl），需同步添加Wants=mnt-ssl.mount和After=mnt-ssl.mount - 检查
systemctl is-active network-online.target，返回active才算真正就绪；若为inactive，说明systemd-networkd-wait-online.service或NetworkManager-wait-online.service没跑起来
php-fpm 服务已运行，但 nginx 反向代理仍报 502 Bad Gateway
502 不是 nginx 配置错，而是它启动时 php-fpm 的 Unix 套接字（如 /run/php/php-fpm.sock）还没创建好。systemd 启动 php-fpm.service 后，进程起来、套接字路径却可能延迟几毫秒才出现——nginx 若抢在前头去 connect，就会失败。
- 在 nginx 的
[Unit]段加After=php-fpm.service和Wants=php-fpm.service是必要但不充分的 - 必须配合
ExecStartPre=-/bin/mkdir -p /run/php和ExecStartPre=-/bin/chmod 755 /run/php，确保目录存在且权限正确 - 更稳妥的做法是在 nginx 配置里用
proxy_next_upstream error timeout http_502;，靠重试兜底，而非全压在 systemd 顺序上
自定义服务 myapp.service 启动后立即退出，journalctl 显示 “No such file or directory”
systemd 报告 active (exited) 并不意味着业务逻辑跑通了——它只管 ExecStart 进程是否退出。报错里的路径往往不是 unit 文件写的，而是程序运行时动态加载的配置、库或 socket 路径。
- 先查真实启动命令：
systemctl show -p ExecStart myapp.service - 再用
ldd /path/to/myapp看缺哪些.so；用strace -e trace=openat,stat -f systemctl start myapp.service 2>&1 | grep "No such"定位具体缺失文件 - 不要在 unit 文件里硬写
Requires=某个库服务——systemd 管不了 libc 或 openssl，这类依赖得靠包管理器或容器环境保证
想让数据库服务 postgresql.service 必须先于 myapp.service 启动，且任一崩溃另一方也停
单纯用 Requires=postgresql.service + After= 只能保启动顺序，不能保运行中的一致性。比如 PostgreSQL 进程意外退出，myapp 还在跑，就可能连不上并持续报错。
- 改用
BindsTo=postgresql.service替代Requires=：它既是强依赖，又带反向约束——PostgreSQL 停，myapp 会被 systemd 自动 stop -
BindsTo不会自动启动被绑定服务，所以仍需搭配Wants=postgresql.service - 注意
BindsTo对目标服务的Restart=设置敏感：若 PostgreSQL 设了Restart=always，它重启时 myapp 也会被先 stop 再 restart，可能引发短暂中断
After 和 Wants。 
