先确认失败发生在哪一层
Linux 上的服务启动失败，很多时候并不是“程序坏了”这么简单。systemd 只是负责拉起进程、记录状态、管理依赖和超时；真正失败的原因可能在配置文件、端口占用、权限、环境变量、依赖服务、磁盘空间，甚至是启动脚本本身。排查时如果一上来就重装软件，往往会把现场破坏掉，后面反而更难判断。
比较稳妥的做法，是先把问题分成三层：第一层看 systemd 是否成功执行了启动命令；第二层看程序本身有没有报错退出；第三层看程序启动后是否真的提供了预期端口或功能。这样排查不会被一个笼统的 “failed” 带偏。
例如 Nginx、MySQL、Redis、PHP-FPM、Docker 这类服务，systemctl 显示失败只说明服务单元没有进入正常状态，并不能直接说明是端口问题、配置问题还是权限问题。下面按实际运维顺序，把常用检查方法串起来。
第一步看 systemctl 状态
最先执行的命令通常是：
systemctl status 服务名
比如：
systemctl status nginx
这里重点看三处信息。第一是 Active，它会显示服务是 active、failed、inactive 还是 activating。第二是 Process 或 ExecStart 附近的退出码，常见的 status=1/FAILURE 说明程序主动报错退出，status=203/EXEC 往往和可执行文件路径或权限有关。第三是最下面几行日志，它们通常会直接给出最近一次启动失败的提示。
不要只看第一行的红色 failed。systemd 的状态页会截取最近日志，有时已经足够定位。例如配置文件语法错误、端口被占用、目录不存在、用户权限不足，通常都会在这里露出关键词。
用 journalctl 查看完整日志
如果 systemctl status 只显示了很短的日志，就需要继续看 journal：
journalctl -u 服务名 -xe
更推荐在排查某次启动时加上时间范围，避免被历史日志干扰：
journalctl -u nginx --since "10 minutes ago"
如果你刚刚执行过重启，也可以使用：
journalctl -u nginx -n 100 --no-pager
journal 里常见的线索包括：配置文件某一行解析失败、绑定端口失败、读取证书失败、无法创建 PID 文件、目录权限不足、依赖服务未启动、启动超时等。看到这些信息后，再去改对应点，比盲目重启有效得多。
检查配置文件和启动命令
很多服务都提供配置检查命令，排查时要优先使用它，而不是直接反复 restart。以 Nginx 为例，可以执行：
nginx -t
如果是 Apache，可以看：
apachectl configtest
如果是 MySQL 或 Redis，则要结合各自日志目录与配置文件路径确认。systemd 服务文件本身也可能有问题，可以查看：
systemctl cat 服务名
这条命令会展示 systemd 实际加载到的 unit 文件和覆盖配置。重点关注 ExecStart、User、WorkingDirectory、EnvironmentFile、Restart、TimeoutStartSec 等字段。路径写错、环境变量文件不存在、工作目录被删除、运行用户没有权限，都会导致服务启动失败。
确认端口、权限和依赖
如果日志里出现 address already in use、bind failed、port is already allocated 等信息，通常是端口被占用。可以用：
ss -lntp
查看当前监听端口和进程。比如 Nginx 需要监听 80 或 443，但端口已经被另一个 Web 服务占用，就必须先确认哪个服务应该保留，而不是直接杀进程。
权限问题也很常见。服务以某个普通用户运行时，可能无法读取证书、写入日志、创建缓存目录或访问项目目录。可以检查目录属主和权限：
ls -ld /path/to/dir
ls -l /path/to/file
不要为了图省事直接把目录改成 777。正确做法是确认服务运行用户，再按最小权限授权。生产环境里如果需要迁移网站或调整 Web 服务，建议先在测试窗口完成验证；使用云服务器时，也可以把基础环境、备份和监控一起规划好。像 速维云云服务器 这类场景，部署前把 SSH、Web、数据库和备份目录权限定清楚，后面排障会省很多时间。
区分 restart、reload 和 daemon-reload
很多人改完配置后直接执行 restart，但不同命令的作用并不一样。restart 会停止再启动服务，影响更大；reload 通常是在不中断主进程的情况下重新加载配置，但前提是服务支持 reload；daemon-reload 不是重启服务，而是让 systemd 重新读取 unit 文件。
如果你修改的是 Nginx 配置文件，通常流程是先 nginx -t，通过后再 systemctl reload nginx 或 systemctl restart nginx。如果你修改的是 /etc/systemd/system/xxx.service 这类 unit 文件，就需要先执行：
systemctl daemon-reload
再重启对应服务。否则 systemd 可能仍然使用旧的 unit 配置，导致你以为“改了没生效”。
启动成功后也要验证业务可用
服务状态变成 active，并不代表业务一定正常。Web 服务还要验证 HTTP 状态码，数据库要确认连接和权限，缓存服务要确认应用能正常读写。比如网站服务启动后，可以用：
curl -I http://127.0.0.1
如果本机访问正常但外部访问失败，再继续看防火墙、安全组、CDN、DNS 和反向代理。排查顺序应该从本机到内网、从服务到网络、从源站到外部链路逐步推进。
对于线上业务，建议每次修复后记录三件事：失败现象、根因、最终改动。下次遇到类似问题时，就能快速判断是同类故障还是新问题。长期看，这比单次把服务拉起来更重要。
一份实用排查清单
遇到 systemd 服务启动失败，可以按下面顺序快速过一遍：
第一，执行 systemctl status 服务名，确认 Active 状态、退出码和最近日志。第二，执行 journalctl -u 服务名 -n 100 --no-pager，查看完整错误。第三，使用服务自带命令检查配置语法，例如 nginx -t。第四，检查端口占用、目录权限、证书路径、环境变量文件和依赖服务。第五，如果改过 unit 文件，执行 systemctl daemon-reload。第六，服务启动后再用 curl、客户端连接或业务页面做真实验证。
排查 systemd 问题的关键不是记住多少命令，而是不要跳步骤。先看状态，再看日志；先确认配置，再动服务；先验证本机，再排网络。这样处理，大多数“服务起不来”的问题都能在较短时间内缩小范围。
