后端转发绕过CORS时如何让fast.com识别客户端真实IP

核心前提 #

fast.com 测速节点的分配逻辑完全基于请求发起端的公网出口IP，目前没有公开支持透传客户端真实IP的专用请求头或URL参数，X-Forwarded-For、X-Real-IP这类通用代理透传头不会被接口识别，添加后无法改变节点匹配结果，无需在这部分做无效尝试。

可行实现方案 #

• 优先方案：前端JSONP直连接口（零偏差）
  无需后端参与首次接口请求，利用script标签不受同源策略限制的特性，通过JSONP方式直接从客户端发起调用，从根源上避免代理导致的IP错位：
  1. 定义全局回调函数，用于接收接口返回的测速URL数据
  2. 动态插入script标签，src属性指向https://api.fast.com/netflix/speedtest/v2并追加callback参数，值为之前定义的全局回调函数名
  3. 脚本加载完成后，接口会自动执行预设回调，传入包含5个动态匹配测速URL的响应对象。这一步请求从客户端浏览器直接发出，出口IP为用户真实公网IP，返回的节点完全匹配用户就近CDN位置
  4. 拿到测速URL后直接在前端发起测速请求即可，这部分测速资源接口默认携带CORS响应头，无跨域限制。
• 备选方案1：边缘节点代理转发（误差可控）
  如果因业务规则必须走后端转发首次请求，不要用中心服务器的固定出口IP发请求，改用离用户物理位置最近的边缘计算节点（比如边缘函数、边缘代理服务）做反向代理，直接用边缘节点的出口IP请求fast接口。由于边缘节点和用户的物理距离通常在几十公里范围内，匹配到的测速节点和用户真实IP匹配的节点几乎一致，测速误差可以控制在5%以内，满足绝大多数场景的精度要求。
• 备选方案2：多轮测速校准兜底
  如果既无法使用JSONP直连，也没有边缘节点资源，可以先用中心服务器代理拿到初始测速URL完成首轮测速，再追加1-2轮通用公共测速节点的补测，取多轮测试中的最高下行速率作为最终结果，能部分抵消节点跨地域带来的测速值偏低问题，但精度弱于前两个方案。

注意：不要尝试在后端伪造客户端源IP请求接口，这类操作不仅违反多数云服务商的使用条款，还会触发fast.com的反爬拦截机制，返回无效的测试节点导致测速完全失效。

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