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/证书管理但设置未知。

输出格式

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验证端口。

示例

• 输入：“日志显示/var/app/uploads权限被拒绝。”
  输出：路径权限分析 + 安全的chown/chmod方案 + 验证。

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