微软的Bug？

[SokWith]

在web目录下没有这些core.js文件规定的核心js文件

_w.rms.js(
{ 'A:rms:answers:Shared:BingCore.Bundle': '/rp/Pki1-YEXD6vos5MiDyyAeDq7sgs.br.js' },
{ 'A:rms:answers:Web:SydneyFSCHelper': '/rp/IKBASmxOJ_ubDLFkwxNAcql6AGY.br.js' },
{ 'A:rms:answers:VisualSystem:ConversationScope': '/rp/YFRe970EMtFzujI9pBYZBGpdHEo.br.js' },
{ 'A:rms:answers:CodexBundle:cib-bundle': '/rp/wy2Kbr72SvrxylJaHweOTCpPs14.br.js' },
{ 'A:rms:answers:SharedStaticAssets:speech-sdk': '/rp/6slp3E-BqFf904Cz6cCWPY1bh9E.br.js' },
{ 'A:rms:answers:Web:SydneyFullScreenConv': '/rp/qj7paUiWxhCdv2VxdV3OWsUIoZ8.br.js' },
);

[Harry-zklcdc]

Harry-zklcdc#12 (comment)

[SokWith]

复活了replit #388 (comment)

初步分析：
cf作为主要的网络加速器，微软很难全力封杀的，所以，cf做服务器是非常好的。
前端最重要的是要成功GET turing/conversation/create，目前代码是把这个GET放在前端服务器上，造成replit封杀了这个GET。应该把它放在后端服务器上。

[Harry-zklcdc]

image 复活了replit #388 (comment)

初步分析： cf作为主要的网络加速器，微软很难全力封杀的，所以，cf做服务器是非常好的。 前端最重要的是要成功GET turing/conversation/create，目前代码是把这个GET放在前端服务器上，造成replit封杀了这个GET。应该把它放在后端服务器上。

不错的思路，可以尝试一下，也很好实现

[Harry-zklcdc]

但是目前来说，Cloudflare的触发人机验证的概率太高了😂，还是私有vps部署稳定一些

[Harry-zklcdc]

目前进度：CF Worker没法获取请求Cookie，基本上这个思路没用了
不过还是有方法可以实现纯Worker部署，不过就得共享_U等Cookie了

[SokWith]

目前进度：CF Worker没法获取请求Cookie，基本上这个思路没用了 不过还是有方法可以实现纯Worker部署，不过就得共享_U等Cookie了

是的，我暂时就是用共享U复活replit的。

[SokWith]

但是目前来说，Cloudflare的触发人机验证的概率太高了😂，还是私有vps部署稳定一些

觉得不是cf触发的验证：
目前主要触发的方式大约为IP锁与ID锁：
IP锁就是单一ip上有太多的用户与访问，就被系统纳入风控了，一般过几天就解除了。屡教不改比如IDC等就进小黑屋长期锁死了。
ID锁就是用户ID访问量过大或者在太多IP上访问，就触发真人验证。
官方的这个策略就牢牢限制了使用，符合官方利益。
由于cf的ip地址池较大，且微软还需要cf来加速，就不能有效风控，所以，触发验证通常都不是cf服务器本身部署问题。
反而使用VPS有巨大风险，一旦用户访问过多，容易触发IP锁，就彻底搞废了VPS再使用的能力。
毕竟，VPS有限，CF转发ip的地址池可以无限。

[Harry-zklcdc]

你可以去看我最新的提交，微软现在加入了_RwBf这个Cookie的验证，带这个Cookie请求要求人机验证的概率就很低，因为获取到 ConversationID是BingProd的，不带这个Cookie的就会是BingProdUnAuthenticatedUsers，这个基本上，必定触发CF的人机验证

[Harry-zklcdc]

我现在的思路就是能让请求带上这个Cookie，然后通过Worker转发，但是Worker没法获取到这个Cookie

[Harry-zklcdc]

已经研究出来了，可以去看一下 Harry-zklcdc#71

[SokWith]

谢谢。
我就是采用内置ID思路的，只是不太会码代码（PS：我是小白只搞过一段时间linux玩具）。
今天我那两个 vercel和replit的网站都很给力，坚持一整天都没有被ip锁和id锁。只是replit中途down了一下。