Linux 命令报错怎么排查？文件路径与 Nginx 配置案例
Linux 服务器入门 · 第 17 篇 / 共 18 篇
看到错误先别改一串东西。把失败命令、时间和输出留下，先验证最接近的原因，再做一次明确修改。否则即使问题消失，也可能不知道哪一步起了作用。
本篇前半段只用自己的练习目录。Nginx 示例需要已经安装 Nginx；配置错误只放进个人目录，不修改系统服务配置。
案例一：文件明明准备了，为什么读不到
假设你按第 09 篇创建了 ~/linux-practice/logs/app.log，却在家目录执行：
cd ~
cat logs/app.log
echo $?如果家目录下没有 logs/app.log，cat 会报找不到文件，紧接的 echo $? 显示非零状态。$? 是上一条命令的退出状态，要立即查看；中间插入其他命令就换了对象。
先检查位置与目标：
pwd
ls -l ~/linux-practice/logs/app.log如果完整路径下文件存在，优先修正路径：
cat ~/linux-practice/logs/app.log
echo $?正常读取后，cat 通常返回 0。这次证据指向“相对路径的起点错了”，不需要加 sudo、重装软件或创建一个空文件冒充原数据。
案例二：用自己的配置重现一次语法错误
先在个人目录创建一份刻意缺少右花括号的教学配置。下面的写入只覆盖同名教学文件：
mkdir -p ~/linux-practice/nginx-check
cat > ~/linux-practice/nginx-check/nginx-bad.conf <<'EOF'
error_log stderr;
events {}
http {
access_log off;
EOF检查这份配置，不启动它：
nginx -t -e stderr -p "$HOME/linux-practice/nginx-check/" -c "$HOME/linux-practice/nginx-check/nginx-bad.conf"
echo $?这里 -c 指定个人配置，-p 指定前缀，-e stderr 把默认错误日志指向标准错误。预期检查失败，诊断会指向配置结尾或括号问题，具体文字因版本不同而异。
打开 nano ~/linux-practice/nginx-check/nginx-bad.conf，在最后增加一行 } 并保存。重新执行同一条 nginx 检查命令，确认配置测试成功且退出状态为 0。只是修复了这份教学配置，没有改变正在运行的系统服务。
参数含义见 Nginx 官方命令说明。这套方式让你练习“根据错误修改一处、重新验证”，不用先破坏真实服务。
如果实际是服务启动失败
在专用 Ubuntu 练习服务器上，先收集：
systemctl status nginx --no-pager
sudo nginx -t
sudo journalctl -u nginx --since '30 min ago' -n 50 --no-pager配置检查通过仍不代表服务能占用需要的端口。若日志明确提示端口占用，再查监听者：
sudo ss -ltnp 'sport = :80'这只查看 TCP 监听与进程。确认是什么程序、为什么运行，再由有权限的人调整端口或服务；不要直接终止不认识的进程。
几类常见报错，分别从哪里查
| 提示 | 先做的检查 |
|---|---|
command not found | 拼写、是否安装、command -v、PATH；当前目录脚本是否应写 ./ |
No such file or directory | 当前目录、绝对路径、大小写；脚本也可能缺少解释器 |
Permission denied | 当前用户、目录访问权限、文件读写或执行权限；不要一律提权 |
| 缺少依赖或模块 | 当前环境与项目 README 的依赖步骤是否对应 |
| 服务启动失败 | 服务状态、配置检查、本次服务日志 |
发出求助前，整理“系统和版本、失败命令、发生时间、相关上下文、已经检查过什么”。将真实账号、令牌和敏感路径脱敏，保留判断问题所需的结构。
需要进一步协助时
如果真实任务仍有运行异常，整理软件版本、脱敏报错和复现步骤，再了解环境及技术支持范围。能协助哪些软件和环境问题，需要结合服务范围确认；不能把教学中的两个修复案例当作所有报错的通用答案。