对接第三方 API 的时候，经常遇到返回 403 或者请求被拒绝的情况。大部分时候可能不是接口地址写错了，是请求少了某个 Header 或者参数签名不对。摸清对方的反爬机制、验证自己的请求格式是否正确，是接口调试绕不开的步骤。
常见的反爬虫机制
请求头校验是最基础的防护。服务端会检查 User-Agent、Referer、Origin 等字段是否合法。客户端发出的请求如果缺少关键 Header，或者 UA 显示是 Python requests 库而不是正常浏览器或 App，就会被识别为爬虫直接拒绝。
签名验证是更严格的方式。客户端用密钥把请求参数拼成字符串、做 Hash 或 HMAC 签名，把签名带上传给服务端校验。如果参数被篡改或者签名算法不对，请求会失败。签名参数通常有时间戳和随机数，防止请求重放。
频率限制和行为分析也会拦截异常请求。同一个 IP 短时间内的请求次数超过阈值会被暂时封禁。设备指纹、Cookie 关联、鼠标轨迹和页面停留时间等行为数据也能用来区分人肉操作和自动化脚本。
Charles 和 Proxyman 调试反爬接口
对接有反爬保护的 API 时，Charles 可以用来查看实际发出的请求内容。在 SSL Proxying 开启后，请求的完整 Header、Cookie 和参数都会显示出来。如果接口返回签名错误，可以对比自己生成的签名和服务端收到的签名是否一致。
Charles 的 Breakpoint 功能可以在请求发出前拦截并修改参数，用于测试签名验证的边界条件。Repeat 和 Advanced Repeat 可以重放请求，验证频率限制的具体阈值。
Proxyman 在这些方面和 Charles 类似，它的脚本功能可以自动对请求做后处理，比如替换 Token 或更新签名参数。
SniffMaster 在反爬调试中的作用
SniffMaster 的几个模式在接口调试中各有用途。
代理抓包模式和 Charles 类似，适合在开发阶段查看自己 App 或浏览器的实际请求内容——确认 Header 是否带上、签名参数是否正确生成、Cookie 有没有正常传递。SniffMaster 的证书安装有操作引导，配置起来比 Charles 少一些步骤。
暴力抓包模式走 USB 直连，不走代理通道，所以服务端看到的请求来源是设备的真实网络环境，不会被代理服务器的 IP 地址干扰。对于某些根据来源 IP 做风控的接口，暴力抓包模式下调试能避免因为走代理而被误判。
数据流抓包能看 TCP/UDP 层面的连接情况。如果怀疑反爬机制把整个 IP 段封禁了，可以在数据流层面看 TCP 连接是否被服务端主动 RST 断开。
调试建议
对接反爬 API 时，先用浏览器开发者工具或 Charles 确认请求的完整参数和 Header 形式，确保本地生成的签名和服务端校验的签名一致。加了请求频率限制的情况下，测试时注意控制请求间隔，避免测试 IP 被临时封禁。不同工具覆盖不同环节，按需选就行。
