name: linux-service-triage
description: 使用日志、systemd/PM2、文件权限、Nginx反向代理检查和DNS合理性检查，诊断常见的Linux服务问题。适用于服务器应用故障、无法访问或配置错误时。

Linux 与服务基础：日志、systemd/PM2、权限、Nginx反向代理、DNS检查

目的

通过日志、systemd/PM2、文件权限、Nginx反向代理检查和DNS合理性检查，诊断常见的Linux服务问题。

使用时机

• 触发场景：
• 请使用日志告诉我此服务失败的原因，并提供确切的修复命令。
• 干净地重启此应用，并确认它在正确的端口上监听。
• 修复此文件夹的权限，以便服务可以安全地读写。
• 为此端口设置Nginx反向代理，并验证DNS和TLS配置合理。
• 为此脚本创建systemd服务，并确保其能在重启后存活。
• 不适用场景：
• 需要进行内核调试或深度性能分析。
• 意图利用系统或绕过访问控制。

输入

• 必需信息：
• 服务类型：systemd单元名称或PM2进程名称。
• 观察到的症状：错误信息、状态输出或日志（由用户粘贴）。
• 可选信息：
• Nginx配置片段、域名、预期的上游端口。
• 服务使用的文件系统路径。
• 示例：
• systemctl status myapp 输出 + journalctl 摘录
• Nginx服务器块配置 + 域名 + 上游端口

输出

• 默认：问题排查报告（可能原因、日志证据、最小修复计划）。
• 若明确请求且安全：应用修复的确切Shell命令。
  成功标准：服务运行、在预期端口监听、反向代理/DNS路径正确。

工作流程

1. 确认范围与安全性：
   - 识别服务名称，确认是否允许更改。
2. 收集证据：
   - 状态输出 + 近期日志（参见 references/triage-commands.md）。
3. 故障分类：
   - 配置错误、依赖缺失、权限拒绝、端口冲突、上游不可达、DNS不匹配。
4. 提出最小修复方案 + 验证步骤。
5. 验证网络路径（若为Web服务）：
   - 应用监听 → Nginx代理 → DNS解析 → （若适用，TLS合理性检查）。
6. 提供重启/重载计划并确认健康检查。
7. 若出现以下情况，请停止并询问用户：
   - 缺少日志/状态输出，
   - 操作需要未确认的特权访问，
   - 需要TLS/证书管理但设置未知。

输出格式

问题排查报告
- 症状：
- 证据（您提供的内容）：
- 最可能原因：
- 修复计划（最小步骤）：
- 确切命令（仅在用户批准更改时提供）：
- 验证：
- 回滚方案：

安全与边界情况

• 默认只读：根据提供的输出进行诊断；不假设可以运行命令。
• 避免破坏性更改；任何有风险的操作都需要明确确认。
• 在重载前优先使用 nginx -t 测试配置，并使用 ss 验证端口。

示例

• 输入：“journal日志显示在 /var/app/uploads 上权限被拒绝。”
  输出：路径权限分析 + 安全的 chown/chmod 计划 + 验证步骤。

• 输入：“应用本地运行正常，但域名返回502错误。”
  输出：上游端口检查 + Nginx错误日志解读 + proxy_pass 修复计划。