4、应用层故障排查：HTTP状态码详解（4xx/5xx）、请求头与响应头异常、Cookie/Session失效、API接口调用失败
各位同行，咱们今天聊聊应用层故障排查。说实话，这是CMS运维里最让人头疼的一层。网络通、服务器跑、数据库连，但用户就是报错——十有八九是应用层出了问题。
我个人习惯把应用层故障分成四类：状态码异常、请求头/响应头异常、会话失效、API调用失败。咱们一个一个来拆。
4.1 HTTP状态码详解：4xx和5xx
状态码是服务器给客户端的「回话」。我见过不少运维只看200和500，其实中间大有文章。
4.1.1 4xx客户端错误
说白了，这是客户端的问题。但别急着甩锅给前端——很多时候是配置不当导致的。
| 状态码 | 含义 | 常见原因 | 排查方向 |
|---|---|---|---|
| 400 Bad Request | 请求格式错误 | JSON格式不对、参数类型不匹配 | 检查请求体、Content-Type头 |
| 401 Unauthorized | 未认证 | Token缺失或过期 | 检查Authorization头 |
| 403 Forbidden | 无权限 | IP白名单、角色权限不足 | 检查Nginx/Apache配置 |
| 404 Not Found | 资源不存在 | URL写错、路由未注册 | 检查路由表、静态资源路径 |
| 405 Method Not Allowed | 请求方法不支持 | POST写成GET | 检查API文档 |
| 429 Too Many Requests | 请求频率过高 | 触发限流 | 检查限流配置、增加重试间隔 |
避坑指南：我曾经遇到一个诡异问题——用户登录后一直403。查了半天，发现是Nginx配置里把静态资源目录的权限设成了deny all。嗯，运维手滑了。
4.1.2 5xx服务端错误
5xx是服务器自己的问题。我一般按「从外到内」的顺序排查：先看负载均衡，再看应用服务器，最后看代码。
| 状态码 | 含义 | 常见原因 | 排查方向 |
|---|---|---|---|
| 500 Internal Server Error | 服务器内部错误 | 代码异常、数据库连接失败 | 查看应用日志、错误堆栈 |
| 502 Bad Gateway | 网关错误 | 上游服务挂了、超时 | 检查PHP-FPM/Tomcat状态 |
| 503 Service Unavailable | 服务不可用 | 服务器过载、维护中 | 检查负载、重启服务 |
| 504 Gateway Timeout | 网关超时 | 上游响应太慢 | 增加超时时间、优化慢查询 |
个人经验：502和504是CMS运维的「老朋友」。我遇到过最离谱的一次——502持续了半小时，最后发现是PHP-FPM的进程数配得太小，高峰期直接打满了。调大pm.max_children后立刻恢复。
4.2 请求头与响应头异常
HTTP头就像快递的面单——写错了东西就送不到。我排查问题时，第一件事就是抓包看头。
4.2.1 常见请求头问题
- Content-Type 不匹配：前端传JSON但没设application/json，后端解析失败返回400
- Authorization 缺失或格式错误：Bearer token前面少了个空格，直接401
- Accept 头限制：客户端只接受application/xml，但服务器返回了JSON，导致解析失败
- User-Agent 被拦截：某些WAF会拦截非浏览器请求
4.2.2 常见响应头问题
- Content-Length 与实际不符：响应体被截断，客户端一直等待
- Transfer-Encoding: chunked 与 Content-Length 冲突：某些代理服务器会报错
- CORS 头缺失：跨域请求被浏览器拦截，控制台报错
- Cache-Control 设置不当：静态资源缓存时间过长，更新后用户看不到新内容
注意：我曾经排查过一个CORS问题——前端死活调不通API，后端说没问题。最后发现是Nginx没加Access-Control-Allow-Origin头。加上后秒解决。
4.3 Cookie/Session失效
会话失效是CMS里最隐蔽的问题之一。用户说「我明明登录了，怎么又让我登录？」——嗯，八成是会话出问题了。
4.3.1 Cookie失效原因
- Domain/Path 不匹配：Cookie的domain设成了.example.com，但请求的是api.example.com
- Secure 标志：HTTPS页面下发了Secure Cookie，但后续请求走了HTTP
- HttpOnly 缺失：XSS攻击窃取Cookie
- SameSite 限制：跨站请求时Cookie不被携带
- 过期时间太短：Session超时设置不合理
4.3.2 Session失效排查步骤
- 检查Session存储方式（文件/Redis/数据库）
- 确认Session ID是否在Cookie中正确传递
- 查看Session过期时间配置
- 检查是否有多个应用共享Session（跨域问题）
- 确认服务器时间是否一致（时间偏差会导致Session立即过期）
避坑指南：我曾经遇到一个奇葩问题——用户登录后过几分钟就掉线。查了三天，最后发现是两台Web服务器的系统时间差了5分钟。Session在A服务器创建，B服务器验证时认为已过期。嗯，NTP没配好。
4.4 API接口调用失败
CMS系统里API调用失败是最常见的故障场景。我一般按「请求-处理-响应」三段式排查。
4.4.1 请求阶段
- URL拼写错误：多了一个斜杠、少了一个参数
- 参数格式错误：日期格式不对、数字传成了字符串
- 签名验证失败：API鉴权的签名算法没对上
- 请求超时：网络延迟高，客户端提前断开
4.4.2 处理阶段
- 数据库慢查询：接口响应慢，最终超时
- 第三方服务依赖：调用的外部API挂了
- 内存溢出：处理大文件时OOM
- 死锁：多个请求互相等待锁资源
4.4.3 响应阶段
- 响应体过大：返回了太多数据，客户端解析失败
- 编码问题：UTF-8和GBK混用，中文乱码
- 字段缺失：接口升级后删除了某个字段，客户端报错
- 状态码与业务状态不一致：返回200但业务逻辑失败
个人经验：我排查API问题时，习惯先看响应体里的错误信息。很多开发会在JSON里加一个error字段，比看状态码有用多了。比如：{"code": 1001, "message": "用户不存在"}——直接定位问题。
4.5 知识体系总览
下面这张图是我自己总结的应用层故障排查框架。你想想看，每次出问题按这个流程走一遍，基本不会漏。
4.6 实战排查工具推荐
最后分享几个我常用的工具。说实话，工具不在多，顺手就行。
| 工具 | 用途 | 我的使用习惯 |
|---|---|---|
| curl | 模拟HTTP请求 | 加 -v 看完整请求响应头 |
| Chrome DevTools | 查看网络请求 | 重点看Headers和Preview标签 |
| Postman | API调试 | 保存常用请求，方便回放 |
| Wireshark | 抓包分析 | 排查TCP层问题，很少用 |
| tcpdump | 服务器端抓包 | 线上环境首选，轻量无侵入 |
个人经验：我排查问题时，90%的情况用curl + Chrome DevTools就够了。别一上来就上Wireshark，那是杀鸡用牛刀。
公众号:蓝海资料掘金营，微信deep3321