文章总结: 本文记录了一次二维码扫码失败的排查过程,通过tcpdump抓包发现客户端请求被转换后发送至服务器,使用AI将抓包数据转换为curl命令进行验证,最终定位到前置机IP被服务器限制及网络链路不稳定问题,经配置调整和物理链路重插后解决。AI在此次排查中主要承担数据翻译和分析提效作用,将复杂网络数据转换为可执行命令,显著提升排查效率。
综合评分: 75
文章分类: AI安全,网络安全,应急响应,实战经验,安全工具
AI辅助流量分析|记一次二维码扫码失败原因分析
原创
小话安全
小话安全
2025年12月10日 15:24
山东
一、问题现象与排查历程
问题现象
用户扫描二维码后,客户端发送POST请求到前置机,但长时间无响应,最终前端显示超时错误。
排查历程
前置机地址 192.168.88.56 服务器地址10.0.100.123
先测试服务器端口发现端口时通时不通,但是从扫码结果看是全部失败了。
在前置机上tcpdump抓包
发现,客户端发送过来的请求1,被转换成了请求2,然后发送给了服务器
请求1与请求2对比分析
请求1示例(客户端 → 前置机):
POST/api/qrcode/scanHTTP/1.1Host: 192.168.88.56:8098User-Agent: App/1.0 (iOS; iPhone)Content-Type: application/jsonAuthorization: Bearer client_token_123Content-Length: 87
{"qrcode_id":"abc123def456","scan_time":"2024-01-15T10:30:00Z","device_id":"ios_device_001"}
请求2示例(前置机 → 服务器):
POST/internal/api/v2/scan/processHTTP/1.1Host: 10.0.100.123:8089X-Forwarded-For: 192.168.1.100X-Real-IP: 192.168.1.100X-API-Version: v2.1X-Signature: sha256_encrypted_signature_hereX-Timestamp: 1705300200X-Request-ID: req_7890123456Content-Type: application/x-encrypted-jsonX-Encryption-Algorithm: AES-256-GCMContent-Length: 256
<加密后的数据块>{"encrypted_data": "U2FsdGVkX1+abc...加密内容...","iv": "随机初始化向量","tag": "认证标签"}
使用AI将抓包得到的内容转换成curl命令行。
将url里的地址替换成服务器的地址,在前置机进行访问。发现请求1正常访问,请求2无法正常访问。在其他电脑上访问这两个请求,发现都可以访问。大致可以确认原因为前置机地址被限制。访问请求2被限制,请求1没有被限制。这个请求2存在某些限制策略。
排查历程总结
二、问题解决
我们将分析结果同步给服务器运维团队,经对方调整配置后,扫码功能暂时恢复,但随后仍会出现间歇性失败。结合前期观测到的 tcping 时断时续的现象,判断网络中仍存在不稳定节点。最终,运维人员通过重新插拔电口链路,彻底解决了该问题。
AI在此次故障排查中主要扮演智能协作者的角色:
- 数据翻译 – 将抓包工具捕获的原始网络流量,自动转换为可直接执行的
curl命令,节省了人工解析协议、拼接参数的时间。 - 分析提效 – 帮助快速验证不同场景下的请求有效性(如转换前后的请求1和请求2),加速了“问题复现与对比”环节,让团队能更聚焦于分析差异背后的原因。
- 辅助决策 – 通过快速模拟和验证,协助排除部分可能性,缩小问题范围,引导团队将根本原因锁定在服务器对前置机IP的访问限制上。
简单来说,AI的作用是:将复杂的底层网络数据,变成工程师能快速理解和验证的实操指令,显著提升排查效率。 但最终的根因判断、配置调整与物理操作(如重插电口)仍需运维人员的专业知识与经验。
免责声明:
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景,旨在提升网络安全防护能力,具有明确的技术研究属性。
任何单位或个人未经授权,将本文内容用于攻击、破坏等非法用途的,由此引发的全部法律责任、民事赔偿及连带责任,均由行为人独立承担,本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布,若存在版权侵权或其他异议,请通过邮件联系处理,具体联系方式可点击页面上方的联系我。
本文转载自:小话安全 小话安全《AI辅助流量分析|记一次二维码扫码失败原因分析》