Sorry, looks like your network settings are preventing access to this feature. 省流：微软疑似封禁了部分 idc 节点，使用其他更好的代理节点或使用请求头插件伪造来源地址

先说解决方法：

1. 换节点
2. 使用 ModHeader 等修改请求头的插件 /软件 /方式将X-Forwarded-For 修改为任意非黑名单 ip(如 1.1.1.1)

我怎么知道我节点被封禁了？ 直接访问或 curl https://www.bing.com/turing/conversation/create

• 如果返回的是{"result":{"value":"UnauthorizedRequest","message":"Sorry, you need to login first to access this service."} 或任意内容，说明节点未被封禁
• 如果返回一片空白，那就是没了

测试： 使用 oci(已封禁节点) 直接 get 空白 使用 oci 修改来源为 1.1.1.1 成功 使用 oci 修改来源为另一台 oci ip 失败 使用 gcp 直接 get 成功 使用 gcp 修改来源为 1.1.1.1 成功 使用 gcp 修改来源为 oci ip 失败

分析： 做网站的都知道在有前端 cdn 情况下后端是没法知晓访问者的 ip 的，需要 cdn 给源站传递访客信息。

最传统的方式就是让 cdn 修改 header 中的 X-Forwarded-For 为访客 ip ，后端再执行相应逻辑。

但鲜有人知 header 在结构上更接近一个二元数组，而非字典，也就是说一个 header 的 key(比如 X-Forwarded-For)可以对应多个 value(1.0.0.1,1.0.0.2)

而后端若采用字典方式去获取，只能解得第一个(1.0.0.1)。

正常情况下，访客发出的请求 header 中是不会存在X-Forwarded-For，所以 bing cdn 采取的加入访客 ip 方式应该是 append(添加，而非修改)。但当我们提前加入一个伪造的 ip ，这将成为第一个，而 cdn 添加的真实 ip 则成为第二个，使得欺骗后端防火墙认为自己的来源是第一个 ip 。换句话说，你只要把来源伪造成任意非黑名单 ip 即可。

此漏洞明显，修复方式简单，故修改 header 的可能不会存留很久。 原文出处