介绍
# Linux & service basics: logs, systemd/PM2, permissions, Nginx reverse proxy, DNS checks
## 目的 使用日志、systemd/PM2、文件权限、Nginx 反向代理检查以及 DNS 完整性检查来诊断常见的 Linux 服务问题。
## 何时使用 - 触发条件： - 使用日志展示服务失败的原因，然后给出确切的修复命令。 - 干净地重启此应用程序并确认其正在正确的端口上监听。 - 修复此文件夹的权限，以便服务可以安全地读写。 - 为此端口设置 Nginx 反向代理，并验证 DNS 和 TLS 是否正常。 - 为此脚本创建 systemd 服务并使其在重启后自动运行。 - 请勿在以下情况使用： - 需要内核调试或深度性能分析。 - 试图利用系统或绕过访问控制。
## 输入 - 必需： - 服务类型：systemd 单元名称或 PM2 进程名称。 - 观察到的症状：错误消息、状态输出或日志（由用户粘贴）。 - 可选： - Nginx 配置片段、域名、预期的上游端口。 - 服务使用的文件系统路径。 - 示例： - `systemctl status myapp` 输出 + `journalctl` 摘录 - Nginx server 块 + 域名 + 上游端口
## 输出 - 默认：分类报告（可能的原因、日志证据、最小修复计划）。 - 如果明确请求且安全：应用修复的确切 shell 命令。 成功 = 服务运行、在预期端口监听、且反向代理/DNS 路径正确。
## 工作流 1. 确认范围和安全： - 识别服务名称以及是否允许进行更改。 2. 收集证据： - 状态输出 + 近期日志（参见 `references/triage-commands.md`）。 3. 分类故障： - 配置错误、依赖缺失、权限被拒绝、端口冲突、上游不可达、DNS 不匹配。 4. 提出最小修复 + 验证步骤。 5. 验证网络路径（如果是 Web 服务）： - 应用程序监听 → Nginx 代理 → DNS 解析 → （如适用，TLS 完整性）。 6. 提供重启/重载计划并确认健康检查。 7. 停止并询问用户，如果： - 缺少日志/状态输出， - 操作需要未确认的特权访问， - 需要 TLS/证书管理但设置情况未知。
## 输出格式 ```text TRIAGE REPORT - Symptom: - Evidence (what you provided): - Most likely cause: - Fix plan (minimal steps): - Exact commands (ONLY if user approved changes): - Verification: - Rollback: ```
## 安全与边界情况 - 默认为只读：根据提供的输出进行诊断；不要假设可以运行命令。 - 避免破坏性更改；对于任何有风险的操作都需要明确确认。 - 在重载之前优先使用 `nginx -t`，并使用 `ss` 验证端口。
## 示例 - 输入：“journal 显示 /var/app/uploads 权限被拒绝。” 输出：路径权限分析 + 安全的 chown/chmod 计划 + 验证。
- 输入：“应用在本地正常工作，但域名返回 502。” 输出：上游端口检查 + nginx 错误日志解读 + proxy_pass 修复计划。