如何伪造请求使其看起来由Instagram App发起而非网页端？

首先明确：你原先认为Instagram网页端与App端请求逻辑差异不大的认知是错误的，二者从接口设计到校验规则都是独立的两套体系，不是简单修改请求头就能切换返回结果的。

两端核心差异点 #

• 接口域名与体系分离：网页端公开数据接口基本挂载在www.instagram.com域名下，大多是服务于前端渲染的GraphQL接口；App端所有接口走i.instagram.com域名下的私有API，参数结构、字段定义、查询逻辑和网页端完全不互通。
• 校验逻辑强度不同：网页端的校验主要围绕Cookie、CSRF Token、基础浏览器指纹展开；App端除了基础鉴权凭证外，所有请求都携带动态生成的请求签名，签名逻辑和App版本、设备信息、请求内容、会话状态强绑定，仅修改User-Agent为App标识100%会被服务端拦截。
• 返回规则独立：两端的内容排序、推荐逻辑、返回字段裁剪规则都是服务端按客户端类型独立配置的，不存在同一接口根据UA切换返回模板的情况。

可落地的获取App端结果的方案 #

• 不要尝试从零逆向所有签名逻辑，Instagram反爬规则迭代极快，纯手写的伪造请求逻辑通常短时间内就会失效。
• 先通过抓包工具抓取同版本真实Instagram App的全量请求，固定一套和真实设备完全一致的设备指纹参数（包括设备型号、系统版本、硬件标识、运营商信息、屏幕参数等），不要在请求中随机生成这类字段，否则会被直接判定为异常流量。
• 按照抓包拿到的签名生成逻辑，为每一次请求动态生成合法的签名字段，注意App端的鉴权凭证和网页端Cookie不通用，需要走App端的登录流程拿到对应token后再发起数据请求。
• 如果只是小批量获取数据，也可以通过在模拟器中运行Instagram App，配合抓包工具的脚本转发能力直接拿到真实App的返回结果，稳定性远高于纯手写伪造请求。

内容的提问来源于stack exchange，提问作者Stefan Urosevic