after=单独使用无效，必须配合wants=或requires=才能触发依赖服务启动；例如仅写after=php-fpm.service会导致nginx与php-fpm并行启动而报502，正确写法是同时配置after=php-fpm.service和wants=php-fpm.service（弱依赖）或requires=php-fpm.service（强依赖）。
After= 单独写没用，必须配 Wants= 或 Requires=
很多人在 nginx.service 里只加一行 After=php-fpm.service，结果 Nginx 还是比 PHP-FPM 先启动，报 502 Bad Gateway。这是因为 After= 只控制时序，不触发依赖服务启动——systemd 会并行拉起两个服务，只要没显式声明“要它”，就不会等。
正确写法是在 [Unit] 段里同时写：
After=php-fpm.service-
Wants=php-fpm.service（弱依赖，PHP-FPM 启动失败也不拦 Nginx） - 或
Requires=php-fpm.service（强依赖，PHP-FPM 启动失败则 Nginx 直接 abort）
注意：若后端用 Unix socket（如 /run/php-fpm.sock），还得确保 socket 所在目录存在且权限正确，否则即使 PHP-FPM 起了，Nginx 也连不上。
挂载点没就绪，Nginx 会因证书/静态资源路径不存在而失败
如果你把 SSL 证书放在 /etc/nginx/ssl，而这个路径由 LVM 或 NFS 挂载，Nginx 启动时很可能遇到 open() "/etc/nginx/ssl/fullchain.pem" failed (2: No such file or directory)。这不是配置错，是挂载单元还没跑完。
解决方法是让 Nginx 显式依赖对应挂载单元：
- 确认挂载单元文件名是
/etc/systemd/system/mnt-ssl.mount（.mount后缀必须一致） - 在 Nginx 的
[Unit]段加：After=mnt-ssl.mount和Wants=mnt-ssl.mount - 不要写成
After=/mnt/ssl或After=ssl.mount——systemd 只认单元名，不是路径或缩写
挂载失败时，Wants= 不会阻止 Nginx 启动；如果必须确保挂载成功才继续，改用 Requires=mnt-ssl.mount。
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
network.target 不够用，真要等 IP 配好得用 network-online.target
After=network.target 只表示内核网络子系统已就绪，但 DHCP 可能还在跑、IP 地址还没分配。Nginx 绑定 0.0.0.0:443 时会失败，日志里出现 bind() to 0.0.0.0:443 failed (99: Cannot assign requested address)。
这时必须升级依赖：
After=network-online.targetWants=network-online.target
注意：network-online.target 默认不启用，需额外运行 sudo systemctl enable systemd-networkd-wait-online.service（使用 systemd-networkd 时）或确认 NetworkManager-wait-online.service 已启用（使用 NetworkManager 时）。否则 Wants= 什么也不会启动。
验证依赖是否生效，别只看配置文件
改完 /etc/systemd/system/nginx.service.d/depends.conf 后，必须执行 sudo systemctl daemon-reload，否则改动无效。但 reload 成功不代表依赖就对了——常见错误是循环依赖（比如 A Wants=B + After=B，B 又反过来依赖 A），systemd 会静默忽略或直接拒绝加载。
验证真实依赖链的命令：
-
systemctl list-dependencies nginx.service—— 看实际生效的直接依赖 -
systemd-analyze critical-chain nginx.service—— 查从 boot 到 Nginx 的完整路径，每一步耗时和状态都列出来 -
journalctl -u nginx.service -u php-fpm.service --since "1 hour ago" | grep -E "(started|failed|listening)"—— 对比时间戳，确认 PHP-FPM 的listening on日志是否真出现在 Nginx 的start之前
最易被忽略的是：systemd-analyze 默认只分析上次启动，重启后必须重新跑命令，旧结果不能复用。
