OpenBMC：Web 页面功能异常排查
1. 从失败请求入手
WebUI 的基本交互链路为：
浏览器 → HTTPS → bmcweb → D-Bus → 后台服务打开浏览器开发者工具，重点检查：
- Network：请求地址、方法、状态码和响应体
- Console：JavaScript 异常
- 页面加载的静态资源是否完整
- 请求是否携带有效认证信息
先找到具体失败请求，比直接重启全部后台服务更容易确定原因。
2. 根据 HTTP 响应定位
| 表现 | 常见排查方向 |
|---|---|
| 请求未发出 | 前端事件处理或脚本错误 |
| 连接失败 | 网络、TLS 或 bmcweb 未监听 |
401 |
登录失效、Token 或 Cookie 问题 |
403 |
用户角色和操作权限 |
404 |
接口路径、资源 ID 或功能配置 |
400 |
请求字段和参数不符合要求 |
500 |
bmcweb 或后台处理异常 |
200 但页面异常 |
返回字段、前端解析或显示条件 |
错误响应中的扩展消息通常比状态码更具体，应一并保留。
3. 对比 curl 与后台数据
使用 curl 重现浏览器中的请求，保持相同路径、方法和参数。
如果 curl 同样失败：
systemctl status bmcweb --no-pager -l
journalctl -u bmcweb -b -n 100 --no-pager随后检查请求对应的 D-Bus 服务：
busctl introspect <service> <object>
journalctl -u <backend-service> -b --no-pager如果 curl 返回正常而页面失败，检查 WebUI 与 bmcweb 版本是否匹配、前端是否假设固定资源 ID，以及浏览器是否缓存了旧静态文件。
4. 区分请求成功与业务完成
点击上电、升级或清理日志后，接口返回成功可能只表示请求已接受。
页面应通过状态查询、任务资源或事件机制继续获取最终结果：
提交操作
↓
请求被接受
↓
后台执行
↓
查询最终状态
↓
页面更新远程控制台等功能还可能依赖 WebSocket 和独立后端服务，应单独检查连接握手、认证和代理通道。