文章总结： 本文记录了一次二维码扫码失败的排查过程，通过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辅助流量分析｜记一次二维码扫码失败原因分析》