学习目标：通过“服务器日志怎么读：Access Log 与 Error Log 的排查顺序”掌握可在真实项目里复用的工程方法。本文不只解释概念，还给出环境要求、实施顺序、代码/配置、验证方法和故障排查。
适用场景与前置条件
拥有测试服务器或容器、非 root 日常用户、sudo 权限和日志查看权限；修改 SSH/Nginx 前保留可用回退会话。
如果这是第一次接触该主题，建议先在独立测试环境完成一遍完整流程，再把变更拆成小步骤进入真实项目。重要配置和数据修改都应先有备份或可恢复版本。
核心知识地图
- Linux 权限由用户、组、文件模式和 sudo/Capability 共同决定。
- systemd 管理服务生命周期，journalctl 提供统一日志入口。
- Nginx 请求会经过 server/location 匹配，再进入静态文件、FastCGI 或 proxy_pass。
- TLS、代理头、超时和缓存是生产反代最容易配置错的部分。
实施步骤
- 步骤 1：先备份配置并运行 nginx -t / systemd-analyze verify 等语法检查。
- 步骤 2：用 curl 从本机验证后端端口，再验证 Nginx 层，最后验证公网 DNS/TLS。
- 步骤 3：明确 Host、X-Forwarded-*、超时和上传大小等代理边界。
- 步骤 4：用 access/error log 与 journalctl 对齐同一时间点排查。
- 步骤 5：确认 reload 成功、旧连接不受影响，并保留一键回滚配置。
代码 / 配置演示
下面的片段使用示例域名、测试数据和非真实凭据，重点展示结构与验证方式。复制到项目后，要根据当前版本的官方文档调整参数。
#!/usr/bin/env sh
set -eu
since="${1:-15 minutes ago}"
printf '== nginx service ==
'
systemctl --no-pager --full status nginx || true
printf '
== recent journal ==
'
journalctl -u nginx --since "$since" --no-pager | tail -n 80
printf '
== access status summary ==
'
awk '{print $9}' /var/log/nginx/access.log 2>/dev/null | sort | uniq -c | sort -nr | head
如何验证结果
不要只看“页面能打开”或“命令没有报错”。验证应至少包含三个维度：一是功能结果是否符合预期；二是日志、状态码、查询计划或指标能否证明请求走了正确路径；三是失败场景是否会返回明确错误并保持系统可恢复。对上线变更，建议记录变更前后数据，便于回归比较。
常见问题与排错
- 修改 sshd 后直接断开唯一会话，配置错误导致无法登录。
- proxy_pass 尾部斜杠造成 URI 重写与预期不同。
- 只看浏览器错误，不看 Nginx/应用日志。
- 配置测试通过但证书链、文件权限或防火墙仍有问题。
如果问题仍然存在，按配置 → 运行时 → 网络/依赖 → 数据 → 缓存的顺序逐层缩小范围。每次只改变一个主要变量，并保留失败日志；一次同时改多处会让真正原因更难确认。
上线检查清单
- 版本和依赖已确认，示例配置没有直接复制生产密码或 Token。
- 关键路径有可重复的验证命令、自动测试或健康检查。
- 日志能定位一次请求/任务，且不会记录密码、Cookie、Token 等敏感值。
- 数据库、配置、证书或部署变更有备份和回滚步骤。
- 已阅读当前版本的官方文档，确认没有依赖过时 API 或废弃配置。
总结
“服务器日志怎么读：Access Log 与 Error Log 的排查顺序”的价值不在于记住某一段命令，而在于建立稳定的判断流程：明确边界、做最小验证、观察真实运行结果、处理失败路径，再把验证固化为测试和文档。这样即使框架或版本变化，也能快速判断哪些部分需要调整。