New Bing 封锁原理探讨

[weaigc]

经过一段时间的观察及网友们的探索，目前已知 New Bing 的封锁等级为以下几种，程度依次递增，不同强度的解决办法也不一样：

封锁程度	现象	解决办法
1	偶发性中断	重试
2	出现人机校验	1. 录入身份信息 2. 更换 MUID 3. 通过人机校验
3	接口 404/wss 200/unexpected end of JSON input	1. 增加 x-forwarded-for 模拟正常美国地址 2. 换机器
4	接口 5xx 或域名无法解析	1. 换机器 2. 配置 ENDPOINT 转发
5	跳 cn.bing.com	1. 换机器 2. 配置 ENDPOINT 转发

除第5级封锁外，其它级别的过段时间会自动解除，但是很容易再次出现，所以比较好的办法是直接换机器

[SokWith]

@weaigc 大佬，你更新的muid（）采用随机数现在基本上不可行的，官方已经用muid全面取代终端机器验证了，对muid的生成有自己的规则，一般生成的都会出错。
目前我测试出来的是可以用已知可行的muid，随便更换最后2位字符，大概率是可用的。所以，让ai生成的一段代码：

const MUID_ADDRESSES: string[] = [
    "074AD7F106536BC6392FC4C907CA6AEA",
    // 添加更多的IP地址
];

function getRandomMUID(): string {
    const timestamp = Date.now();
    const randomIndex = Math.floor(Math.random() * MUID_ADDRESSES.length * timestamp);
    const IPSTR = MUID_ADDRESSES[randomIndex % MUID_ADDRESSES.length];
    const trimmedIPStr = IPSTR.slice(0, IPSTR.length - 2);
    const randomString = generateRandomString(2);
    const USER_MUID = trimmedIPStr + randomString;
    return USER_MUID;
}

export function muid() {
//  return md5(new imei().random()).toUpperCase()
    return getRandomMUID()
}

[weaigc]

@weaigc 大佬，你更新的muid（）采用随机数现在基本上不可行的，官方已经用muid全面取代终端机器验证了，对muid的生成有自己的规则，一般生成的都会出错。 目前我测试出来的是可以用已知可行的muid，随便更换最后2位字符，大概率是可用的。所以，让ai生成的一段代码：

const MUID_ADDRESSES: string[] = [
    "074AD7F106536BC6392FC4C907CA6AEA",
    // 添加更多的IP地址
];

function getRandomMUID(): string {
    const timestamp = Date.now();
    const randomIndex = Math.floor(Math.random() * MUID_ADDRESSES.length * timestamp);
    const IPSTR = MUID_ADDRESSES[randomIndex % MUID_ADDRESSES.length];
    const trimmedIPStr = IPSTR.slice(0, IPSTR.length - 2);
    const randomString = generateRandomString(2);
    const USER_MUID = trimmedIPStr + randomString;
    return USER_MUID;
}

export function muid() {
//  return md5(new imei().random()).toUpperCase()
    return getRandomMUID()
}

@SokWith MUID 我不想硬编码，按照标准的 MUID 生成规则又很容易跟真实的用户冲突，所以故意写了一个错误的。不过确实更容易被封禁。我有办法生成真实的 MUID ，只不过速度还不太快，如果你这个可行，我后面专门做一个服务来生成 MUID。谢谢反馈！

[SokWith]

vercel上面部署的1.0.0，无I内置ID，可以说很简单的几个字符，比如 “hi”，但也足以说明vercel没有被官方封禁。

[SokWith]

官方10月更新API后，似乎原来的许多限制都解除了，几乎没有IP锁和MUID锁了（随便32个16进制字符串都可以），目前还剩下的只有根据连接网络属性来是否进行账户验证，我的部署测试表明，目前云服务器中抱脸、render、vercel都不需要验证匿名账户，replit、cf需要验证账户。

[weaigc]

官方10月更新API后，似乎原来的许多限制都解除了，几乎没有IP锁和MUID锁了（随便32个16进制字符串都可以），目前还剩下的只有根据连接网络属性来是否进行账户验证，我的部署测试表明，目前云服务器中抱脸、render、vercel都不需要验证匿名账户，replit、cf需要验证账户。

@SokWith 你说的那种方案试过了，流量一大了就不行，自用确实没啥问题。

[renqabs]

netlify也复活了

[weaigc]

netlify也复活了
netlify 一般只能复活一天，不能持续，https://effulgent-bubblegum-e2f5df.netlify.app/ 你可以用用看

[renqabs]

netlify也复活了
netlify 一般只能复活一天，不能持续，https://effulgent-bubblegum-e2f5df.netlify.app/ 你可以用用看

试了下，确实不稳定，今天我这一条都不能用了。。。

[maggieqnr]

@weaigc 大佬，你更新的muid（）采用随机数现在基本上不可行的，官方已经用muid全面取代终端机器验证了，对muid的生成有自己的规则，一般生成的都会出错。
目前我测试出来的是可以用已知可行的muid，随便更换最后2位字符，大概率是可用的。所以，让ai生成的一段代码：

const MUID_ADDRESSES: string[] = [
    "074AD7F106536BC6392FC4C907CA6AEA",
    // 添加更多的IP地址
];

function getRandomMUID(): string {
    const timestamp = Date.now();
    const randomIndex = Math.floor(Math.random() * MUID_ADDRESSES.length * timestamp);
    const IPSTR = MUID_ADDRESSES[randomIndex % MUID_ADDRESSES.length];
    const trimmedIPStr = IPSTR.slice(0, IPSTR.length - 2);
    const randomString = generateRandomString(2);
    const USER_MUID = trimmedIPStr + randomString;
    return USER_MUID;
}

export function muid() {
//  return md5(new imei().random()).toUpperCase()
    return getRandomMUID()
}

这段代码在部署的时候应该放在哪里？

[SokWith]

@weaigc 大佬，你更新的muid（）采用随机数现在基本上不可行的，官方已经用muid全面取代终端机器验证了，对muid的生成有自己的规则，一般生成的都会出错。
目前我测试出来的是可以用已知可行的muid，随便更换最后2位字符，大概率是可用的。所以，让ai生成的一段代码：

const MUID_ADDRESSES: string[] = [
    "074AD7F106536BC6392FC4C907CA6AEA",
    // 添加更多的IP地址
];

function getRandomMUID(): string {
    const timestamp = Date.now();
    const randomIndex = Math.floor(Math.random() * MUID_ADDRESSES.length * timestamp);
    const IPSTR = MUID_ADDRESSES[randomIndex % MUID_ADDRESSES.length];
    const trimmedIPStr = IPSTR.slice(0, IPSTR.length - 2);
    const randomString = generateRandomString(2);
    const USER_MUID = trimmedIPStr + randomString;
    return USER_MUID;
}

export function muid() {
//  return md5(new imei().random()).toUpperCase()
    return getRandomMUID()
}

这段代码在部署的时候应该放在哪里？

现在几乎没有MUID锁了，这段代码基本不需要了，有了由于MUID被频繁使用，反而容易上锁。

[weaigc]

确实跟muid没什么关系了，但是目前这些免费平台每次解禁都活不过一天。

[SokWith]

确实跟muid没什么关系了，但是目前这些免费平台每次解禁都活不过一天。

不是吧，vercel、render都一直活起的哟。

[weaigc]

确实跟muid没什么关系了，但是目前这些免费平台每次解禁都活不过一天。

不是吧，vercel、render都一直活起的哟。

render能用是因为很多人会被封账号，我也被封了。vercel目前有10秒限制，也不支持websocket，所以没法正常使用，你试试让它写诗，就能看出问题

[SokWith]

确实跟muid没什么关系了，但是目前这些免费平台每次解禁都活不过一天。

不是吧，vercel、render都一直活起的哟。

render能用是因为很多人会被封账号，我也被封了。vercel目前有10秒限制，也不支持websocket，所以没法正常使用，你试试让它写诗，就能看出问题

确实，render会封账号，特别是部署隔壁go-proxy时，秒封，但却不封重写核心的这个项目和NewBingGoGo。
vercel也确实限制了时间，只能问很短的问题。go-proxy在vercel上的部署本质还是用的cf的wss，所以没有时长限制。但是因为实质是cf，而和cf沾边的网络几乎都要验证账户不能匿名使用。但使用vercel来获得id，是能够匿名的，就不知道可否与cf结合起来，使用cf来连接wss。只是，你那个cf-proxy的代码似乎不能直接路由，会跳转cn。

[maggieqnr]

确实跟muid没什么关系了，但是目前这些免费平台每次解禁都活不过一天。

不是吧，vercel、render都一直活起的哟。

render能用是因为很多人会被封账号，我也被封了。vercel目前有10秒限制，也不支持websocket，所以没法正常使用，你试试让它写诗，就能看出问题

我今天申请render新账号部署bingo，结果被告知在进行suspicious actions，然后账号被suspended...

[SokWith]

确实跟muid没什么关系了，但是目前这些免费平台每次解禁都活不过一天。

不是吧，vercel、render都一直活起的哟。

render能用是因为很多人会被封账号，我也被封了。vercel目前有10秒限制，也不支持websocket，所以没法正常使用，你试试让它写诗，就能看出问题

我今天申请render新账号部署bingo，结果被告知在进行suspicious actions，然后账号被suspended...

不好意思哈。也幸好你用的新号。看来我也得把我的部署停了换新号了。

ps：
果然，新部署直接秒封。

[weaigc]

确实跟muid没什么关系了，但是目前这些免费平台每次解禁都活不过一天。

不是吧，vercel、render都一直活起的哟。

render能用是因为很多人会被封账号，我也被封了。vercel目前有10秒限制，也不支持websocket，所以没法正常使用，你试试让它写诗，就能看出问题

确实，render会封账号，特别是部署隔壁go-proxy时，秒封，但却不封重写核心的这个项目和NewBingGoGo。 vercel也确实限制了时间，只能问很短的问题。go-proxy在vercel上的部署本质还是用的cf的wss，所以没有时长限制。但是因为实质是cf，而和cf沾边的网络几乎都要验证账户不能匿名使用。但使用vercel来获得id，是能够匿名的，就不知道可否与cf结合起来，使用cf来连接wss。只是，你那个cf-proxy的代码似乎不能直接路由，会跳转cn。

cf没可能了，它的流量自带特征，只要访问过去就会被 new bing 检测到

[SokWith]

确实跟muid没什么关系了，但是目前这些免费平台每次解禁都活不过一天。

不是吧，vercel、render都一直活起的哟。

render能用是因为很多人会被封账号，我也被封了。vercel目前有10秒限制，也不支持websocket，所以没法正常使用，你试试让它写诗，就能看出问题

确实，render会封账号，特别是部署隔壁go-proxy时，秒封，但却不封重写核心的这个项目和NewBingGoGo。 vercel也确实限制了时间，只能问很短的问题。go-proxy在vercel上的部署本质还是用的cf的wss，所以没有时长限制。但是因为实质是cf，而和cf沾边的网络几乎都要验证账户不能匿名使用。但使用vercel来获得id，是能够匿名的，就不知道可否与cf结合起来，使用cf来连接wss。只是，你那个cf-proxy的代码似乎不能直接路由，会跳转cn。

cf没可能了，它的流量自带特征，只要访问过去就会被 new bing 检测到

不是吧，隔壁go-proxy就可以纯js部署在cf上，只是不能匿名访问bing而已。只是不清楚决定是否要进行账户验证是在create时决定的还是在wss握手时决定的。如果是在create时决定的，就可以使用vercel来获取无需验证的连接id，如果是在wss握手时那就没办法了。目前看上去是在create时决定的，因为go-proxy部署在vercel上时，是使用的vercel的代理网络获得的连接id，然后路由的cf的wss，刚才测试表明也可以匿名访问。

[weaigc]

确实跟muid没什么关系了，但是目前这些免费平台每次解禁都活不过一天。

不是吧，vercel、render都一直活起的哟。

render能用是因为很多人会被封账号，我也被封了。vercel目前有10秒限制，也不支持websocket，所以没法正常使用，你试试让它写诗，就能看出问题

确实，render会封账号，特别是部署隔壁go-proxy时，秒封，但却不封重写核心的这个项目和NewBingGoGo。 vercel也确实限制了时间，只能问很短的问题。go-proxy在vercel上的部署本质还是用的cf的wss，所以没有时长限制。但是因为实质是cf，而和cf沾边的网络几乎都要验证账户不能匿名使用。但使用vercel来获得id，是能够匿名的，就不知道可否与cf结合起来，使用cf来连接wss。只是，你那个cf-proxy的代码似乎不能直接路由，会跳转cn。

cf没可能了，它的流量自带特征，只要访问过去就会被 new bing 检测到

不是吧，隔壁go-proxy就可以纯js部署在cf上，只是不能匿名访问bing而已。只是不清楚决定是否要进行账户验证是在create时决定的还是在wss握手时决定的。如果是在create时决定的，就可以使用vercel来获取无需验证的连接id，如果是在wss握手时那就没办法了。目前看上去是在create时决定的，因为go-proxy部署在vercel上时，是使用的vercel的代理网络获得的连接id，然后路由的cf的wss，刚才测试表明也可以匿名访问。

不匿名部署cf bingo一直可以的呀，不过不能匿名就不能不限量使用了

解决方案里不是说了吗，要么账号没被封，要么vps没被封

[SokWith]

你那个cf不是部署，包括replit里面的，都只是反代。这个项目本来就是纯js，是可以直接部署的，只是需要把next编译一下吧？。

[weaigc]

你那个cf不是部署，包括replit里面的，都只是反代。这个项目本来就是纯js，是可以直接部署的，只是需要把next编译一下吧？。
@SokWith
cf部署的代码没有开放了（因为没有解决根本问题），实际上bingo可以把 ENDPOING 设置为其他项目的代理，包括 cf，你可以试试

[SokWith]

你那个cf不是部署，包括replit里面的，都只是反代。这个项目本来就是纯js，是可以直接部署的，只是需要把next编译一下吧？。
@SokWith
cf部署的代码没有开放了（因为没有解决根本问题），实际上bingo可以把 ENDPOING 设置为其他项目的代理，包括 cf，你可以试试

ENDPOINT是指的WS_ENDPOINT的环境变量吗？这个变量是wss服务器的地址吧，换成cf的代理服务器并没有改善vercel的连接时长限制，主要还是vercel与wss服务器之间的数据交换时间。
所以，有没有可能，将create获取连接id的实现放在vercel上，就是原本访问 www.bing.com/turing/conversation/create换成访问 vercel.nbing.eu,org/turing.conversation/create,这样获得连接id，而客户端界面实现在cf worlers上？
这样折腾的意义主要是抱脸的反应实在太慢了，给项目部署留一条后路。

[weaigc]

你那个cf不是部署，包括replit里面的，都只是反代。这个项目本来就是纯js，是可以直接部署的，只是需要把next编译一下吧？。
@SokWith
cf部署的代码没有开放了（因为没有解决根本问题），实际上bingo可以把 ENDPOING 设置为其他项目的代理，包括 cf，你可以试试

ENDPOINT是指的WS_ENDPOINT的环境变量吗？这个变量是wss服务器的地址吧，换成cf的代理服务器并没有改善vercel的连接时长限制，主要还是vercel与wss服务器之间的数据交换时间。 所以，有没有可能，将create获取连接id的实现放在vercel上，就是原本访问 www.bing.com/turing/conversation/create换成访问 vercel.nbing.eu,org/turing.conversation/create,这样获得连接id，而客户端界面实现在cf worlers上？ 这样折腾的意义主要是抱脸的反应实在太慢了，给项目部署留一条后路。

ENDPOINT和WS_ENDPOINT是两个，WS封杀力度不大，不用管

[weaigc]

@SokWith v1不推荐用hf了呀，文档都改了，v2在用是因为v2版本对配置要求比较高，只有hf能给这么好的配置

[SokWith]

@SokWith v1不推荐用hf了呀，文档都改了，v2在用是因为v2版本对配置要求比较高，只有hf能给这么好的配置

v2版给出的部署都是反代，和直接用你的部署是一样的，属于单点配置。

刚才我按上面的思路，对go-proxy项目对replit部署路由vercel的create，是可以匿名了。
但对这个项目采用类似处理，总是用户无效。

[weaigc]

@SokWith v1不推荐用hf了呀，文档都改了，v2在用是因为v2版本对配置要求比较高，只有hf能给这么好的配置

v2版给出的部署都是反代，和直接用你的部署是一样的，属于单点配置。

刚才我按上面的思路，对go-proxy项目对replit部署路由vercel的create，是可以匿名了。 但对这个项目采用类似处理，总是用户无效。

v2不是反代，反代是v1的

[SokWith]

你那个cf不是部署，包括replit里面的，都只是反代。这个项目本来就是纯js，是可以直接部署的，只是需要把next编译一下吧？。
@SokWith
cf部署的代码没有开放了（因为没有解决根本问题），实际上bingo可以把 ENDPOING 设置为其他项目的代理，包括 cf，你可以试试

ENDPOINT是指的WS_ENDPOINT的环境变量吗？这个变量是wss服务器的地址吧，换成cf的代理服务器并没有改善vercel的连接时长限制，主要还是vercel与wss服务器之间的数据交换时间。 所以，有没有可能，将create获取连接id的实现放在vercel上，就是原本访问 www.bing.com/turing/conversation/create换成访问 vercel.nbing.eu,org/turing.conversation/create,这样获得连接id，而客户端界面实现在cf worlers上？ 这样折腾的意义主要是抱脸的反应实在太慢了，给项目部署留一条后路。

ENDPOINT和WS_ENDPOINT是两个，WS封杀力度不大，不用管

与WS连接的网络(ip)很重要，所以，薅了一下render的羊毛：replit的前端+render的ws：
https://rpbingo.nbing.eu.org

---

唉，帅不过3秒，测试5次后似乎ip上锁了

[SokWith]

目前封锁升级了：
1、对ENDPOINT，大面积的ip锁，目前只有少数几个云商还能够阵发性连接官网ENDPOINT，大多数的VLESS机场都受到限制了;
2、对WS_ENDPOINT，目前是行为封控，能够匿名访问的云商就更少了，迫切需要单独建立WSS代理服务器。
@weaigc 大佬，能抽空出一个单独建立WSS代理服务器的代码吗？
ps：我在cf上大致按proxy.js建的服务器，是可以工作的（WS_ENDPOINT = "https://prosydney.nbing.eu.org“ ，限于登录用户可连接)，但采用CLI部署到render、replit和huggingface都不可以，完全就是本地网络上一样。

[weaigc]

(PS：在replit上编译现在的版本真辛苦，得在周末中午国外人用的少的时候启动编译，否则一过载就终止编译)

1.1版本是存在一些问题的，你试试1.2或者1.3版本

@weaigc 奇怪了，同一个仓库，同一个BING_HEADER，同是部署在huggingface上，采用仓库里面的docker.yml先打包后再使用镜像部署，可以绘图；直接使用dockerfile文件编译的部署，就不能绘图。这个dockerfile文件的编译指令不全吗？

FROM node:18

ARG DEBIAN_FRONTEND=noninteractive

ENV BING_HEADER = "Y3VybCAnaHR0cHM6Ly93d3cuYmluZy5jb20vdHVyaW5nL2NhcHRjaGEvY2hhbGxlbmdlJyBcICAgLUggJ2F1dGhvcml0eTogd3d3LmJpbmcuY29tJyBcICAgLUggJ2FjY2VwdDogdGV4dC9odG1sLGFwcGxpY2F0aW9uL3hodG1sK3htbCxhcHBsaWNhdGlvbi94bWw7cT0wLjksaW1hZ2UvYXZpZixpbWFnZS93ZWJwLGltYWdlL2FwbmcsKi8qO3E9MC44LGFwcGxpY2F0aW9uL3NpZ25lZC1leGNoYW5nZTt2PWIzO3E9MC45JyBcICAgLUggJ2FjY2VwdC1sYW5ndWFnZTogemgtQ04semg7cT0wLjknIFwgICAtSCAnY2FjaGUtY29udHJvbDogbWF4LWFnZT0wJyBcICAgLUggJCdjb29raWU6IF9nYV9NTTVKNVg4UVFDPUdTMS4xLjE2OTgyMjQwMTYuMS4xLjE2OTgyMjU2MzguMC4wLjA7IFNSQ0hEPUFGPU5PRk9STTsgU1JDSFVJRD1WPTImR1VJRD0wNTY0NUI2QUEzMDg0NDQ4QTQ1QTQ2NUREQjkyN0M5OSZkbW5jaGc9MTsgTVVJRD0xRUZGMUNDNDUzNEE2RjRDMTdCNjBFODQ1MjEwNkUxOTsgX1VSPVFTPTAmVFFTPTA7IE1VSURCPTFFRkYxQ0M0NTM0QTZGNEMxN0I2MEU4NDUyMTA2RTE5OyBNTUNBU009SUQ9REYwMUU5RTFBMDIzNEQ3OUEwNzIxODM3OUYzQzUxNUU7IEJDUD1BRD0xJkFMPTEmU009MTsgTWljcm9zb2Z0QXBwbGljYXRpb25zVGVsZW1ldHJ5RGV2aWNlSWQ9MzlkMDNjMjQtYTYxZS00MDA4LTlkOTktYmIwNTRlZTI2MTA3OyBfRURHRV9DRD11PWVuLXVzOyBVU1JMT0M9SFM9MSZFTE9DPUxBVD0yOS4zODU3MTE2Njk5MjE4NzV8TE9OPTEwNi40OTkxNjgzOTU5OTYxfE49QmFcJ25hbiUyMERpc3RyaWN0JTJDJTIwQ2hvbmdxaW5nfEVMVD00fDsgU1JDSFVTUj1ET0I9MjAyMzEwMjYmVD0xNzAwNDU2OTIyMDAwJlRQQz0xNzAwNDQ1MjI3MDAwJlBPRVg9VzsgX1U9MWh1MFBzNkQ4YWxIVmZkSWp5aTJ4UXVPV08xbkJabm1qYzBvbUQ3Yko5cnpCU002NzFjVmFMeEdJcElGVXczUWVLaGtDYWg0elhiS1N1QVNEbm1lYXdwdllPODRWUFZBckZPa3hoOFFOcl93TzE3b19ranRRYzQtNE50NFY1c1V3YUs5TnhNZVU2a2tlU0hLd0oyVnM2enlQR1JkeXhVY2s2c0hhTml0UlVXUGZ0M29id2VBeXpmZ1VxdGNtY2diRDJYcm1aQXpMR0pjdElMRWtsU0ZmVlE7IFBQTFN0YXRlPTE7IE5BUD1WPTEuOSZFPTFjYjkmQz12VVAybzVtMmhZal9GTDN4STlEZFY1QXR3cTVDTjJya0IteTBEQTRWTUIwbGRmMXlIVjhQb3cmVz0xMDsgS2lldlJQU1NlY0F1dGg9RkFCYUJCUmFUT0pJTHRGc01rcExWV1NHNkFONkMvc3ZSd05tQUFBRWdBQUFDQnhyQnFCdTlHNmxHQVRrd1lDSWV5enEvblVRZjJQVENTUmMzQ2dNNVhsTUx4Y3phdzl0ekx1Z25QT3IxNlRjWW9TdGg2SytCekI0ZCtQSllZSjFZeE1udWIrSHdlTEdqWkUxOGNKNVJHZVhPb05kZ0pWWSs2S3A0NDAwVmpranQ5TWJDTUFUV1ExMjZpV3hxTHAwUDdCRlRZaWhURUFwcC90ZkxuNkViTUo0dnNFK3dQUWRMK3RZQmQrWXdETm9ITnJFL1FocXZwQmxtNVkzMVdvc3Yrd3piSVpKa0oyejFjZXR0VlpUcVNISHE3TkRpRTVWa2E0c2VHdzVoanlJUXpMcUorWFpXdVRMaVg4djFibUt6VEZkaWE2Q2JzdkRjTVo4bHJoTmNpUm1MamRHelZad3VlOVZNNkNqSE95SldyQjA5Y29JWGYvL2tUTGNnVTg4ckE3OE80TmZoaHB4SmxoQ3diVDI5U0dIOHpZby91dWlRK0hFNXBwNEk2b3hacnBtaG8vQ3lYZndWZnF5VEhYcGNFUUdwRE03L202TzhMZXJFMVdqeFVpYUV5ZXdRUERtUlc3WUJSUXF5UFN5ZWxZZmRQOGNGNnhON3FWRDJBOFJQN0JMTDRQay9uTE15NFN6eU5TcTFLVVRiZ2Y0ZW5iTk5GM0pja3VGU1Z4b1U4MUc0U04rL0lZeUF0N3ZoQkpyMFkwc0JNaFZUT1VzUTdtR0JoSDdweVJ2ODdaNGVzVkR6VWREcFVEVk5xUGNoMzRKOGJ5Wk95UDVMVUh3Y1c4QldPQURmc2dQNTJSSE41RlMza2JVQkZkZURpckVFK0hiLzB5OTQzaTgzaDBEanpqaFZ4MW01VmZGNzI5dlNkczhDU2NFVjhZa1dFY3pyNmFYb2tVdEJEejUwUkJpR2JSeVFnZk1BTlB6bXFncys0UWpxL2NpSUtPMG5NNjJsalljSm0rS21KSTZKc0syTDlhWmVvNXlsaWpFRFg4dzI4VDVmWnFydzV0Um96RGlnZzFSQVZINjVmSDk4bUdVUEtnOFRaTzZDZklnSWx4WmJoL2JIbFQ5aWxzN3l5VnU3cXVTTFRqMGYxN3V6UGllUXFqbEdjT2RBbDE1dFBQOVlXY05mRVFIbzUySkhDeVZ1NzltdnVLZEIyU1lodmU1U2NHS2pYVVVsR01mbWZrMnpxbEdFSzg2UGRhM0grN2JJczdnNGQzVGZLRnFUSlFVeFBqdnFTUFVtWG9La3VXeEw5ckxzTFZMajkrRE1OdVBNUzk4Sng5M0ltazFpQ2lzN1Y4T0dtQUZ2Y0pQLzdvaWZCRnNyRXhvRmNnbWg3UUJpQ0o3Z21ETmIyb2dBWVNGYmZON2ZDbDJieU5PNTBXVWdueXBrTlRTL3MyZjZSNm92NEdiZjlmVi92OHV5VURIdDBKay9FSUNJT29ZdHpmRVM5V3liaXhMYnpJZHk3YjJtVWF3RzJDQnhOVGR4UmlhNW1kNzZjZlViK1pHcnFGYTV1WDZLcmRXQkkzbGtISnhwVU93anIvdlNmaGo3aWM4TzdoNGg2VHNPcEViMlJCQ01UR1BDdTlLWGh4YzB0ejA2YVYySzVaeWNLS0NkUnM0c0Y2MHNkMXcwcE1udldiU3JjVndmcGhYeU5oZ3hhakU1U0Y4NDM2V2ZrZHdaOTgxeEZYRHI2bGxLNXhMTmVRSDNmSUt1K21DSzEzVVFBLzdhdnpuYVJ4U3RtdWFYV2hoNU5TdC9tTDJocmFYdzNNTm1aSHg0VDIyeU0rUG1aU0FGOVB4cGhGUDdJWTByQWRFUUFkS0VhSFJ4YWJxZlU5MDhZS1RlNXh4Vkt1Ulo2K3FXVEZtNml5NVNKUTBqdGVoVC9oZEZBQURNZyt3WWZEQ3JJOTg2eXY0RlFoR2tnbXhKQT09OyBBTk9OPUE9OUEyNDcwQjc4MzI2NEIyMzMwNzAyOEFGRkZGRkZGRkYmRT0xZDEzJlc9MTE7IFdMSUQ9Q2JOVU96bnU1UHgyNy9scXpvVU1wRXQ0d2VkVHhkMnNCWGkrbFd5WlBTNndDdGk5ZDZQczFVMDhYeWZYK2FvbWFoQS80Mzh0M3RqbzZKVWMxcm13OFRoalBQYVhUZDRLeWhURVBGdG9KTVU9OyBfSFBWTj1DUz1leUpRYmlJNmV5SkRiaUk2T0N3aVUzUWlPakFzSWxGeklqb3dMQ0pRY205a0lqb2lVQ0o5TENKVFl5STZleUpEYmlJNk9Dd2lVM1FpT2pBc0lsRnpJam93TENKUWNtOWtJam9pU0NKOUxDSlJlaUk2ZXlKRGJpSTZPQ3dpVTNRaU9qQXNJbEZ6SWpvd0xDSlFjbTlrSWpvaVZDSjlMQ0pCY0NJNmRISjFaU3dpVFhWMFpTSTZkSEoxWlN3aVRHRmtJam9pTWpBeU15MHhNUzB5TUZRd01Eb3dNRG93TUZvaUxDSkpiM1JrSWpvd0xDSkhkMklpT2pBc0lsUnVjeUk2TUN3aVJHWjBJanB1ZFd4c0xDSk5kbk1pT2pBc0lrWnNkQ0k2TUN3aVNXMXdJam8xTml3aVZHOWlZbk1pT2pCOTsgU25yT3ZyPVg9cmViYXRlc29uOyBfUndCZj1yPTEmaWx0PTImaWhwZD0yJmlzcGQ9MCZyYz00NiZyYj00NiZnYj0wJnJnPTAmcGM9MCZtdHU9MCZyYmI9MC4wJmc9MCZjaWQ9JmNsbz0wJnY9MyZsPTIwMjMtMTEtMTlUMDg6MDA6MDAuMDAwMDAwMFombGZ0PTAwMDEtMDEtMDFUMDA6MDA6MDAuMDAwMDAwMCZhb2Y9MCZvPTAmcD1CSU5HQ09QSUxPVFdBSVRMSVNUJmM9TVIwMDBUJnQ9NTI0NyZzPTIwMjMtMDgtMjJUMTE6MTU6NDguNjMxMjE2MSswMDowMCZ0cz0yMDIzLTExLTIwVDA1OjEwOjQ4LjU2ODg2NjYrMDA6MDAmcndyZWQ9MCZ3bHM9MiZ3bGI9MCZsa2E9MCZsa3Q9MCZhYWQ9MCZUSD0mbXRhPTAmZT1MaEFMSWJmMVV1elJYNS1FRENoTWFwUVBjMGtoTGc5STF3aHNheW5ScWVHbXRfWUdUOHJwU3c1RXdkZG1RNnRhNlFwOGxnX2w4S1EyS1VBaXdTRGxvUSZBPTlBMjQ3MEI3ODMyNjRCMjMzMDcwMjhBRkZGRkZGRkZGOyBTUkNISFBHVVNSPVNSQ0hMQU5HPWVuJkJaQT0wJkJSVz1OT1RQJkJSSD1TJkNXPTQyMiZDSD02MTEmU0NXPTQwNiZTQ0g9NjExJkRQUj0xLjMmVVRDPTQ4MCZETT0wJlBWPTAuMS4wJkhWPTE3MDA0NTcwNDgmV1RTPTYzODM2MDUzNzM3JklHPUQyOTZGNURBMTkzRjQ3Mzg5OTlGOTI0ODc0RUYxNTkyJlBSVkNXPTExNTImUFJWQ0g9NjExJkNJQlY9MS4xMzU5LjYmY2R4dG9uZT1DcmVhdGl2ZSZjZHh0b25lb3B0cz1oM2ltYWdpbmF0aXZlLGNsZ2FsaWxlbyxnZW5jb250ZW50djMsZmx1eHYxNDsgY2N0PVVrOXJqRFNWQXVlbUQ1aUU0NEJrMG8zYkJ6emRZTmIwSmsxbHpxb25EbzRBVExsRmxENXRUcnE5MmxEUW9CY09SNzhYNUVwT0Z5WmE4dTRiY01PY3JBOyBfRURHRV9TPVNJRD0yNENDOUFGOTQyQzE2MjkxMDVGMzg5MzY0Mzg1NjM5MDsgV0xTPUM9NjM2YWI2YWNiODU4YzBkMCZOPWpva3lvMjsgX1NTPVNJRD0yNENDOUFGOTQyQzE2MjkxMDVGMzg5MzY0Mzg1NjM5MCcgXCAgIC1IICdzZWMtY2gtdWE6ICJOb3RfQSBCcmFuZCI7dj0iOTkiLCAiR29vZ2xlIENocm9tZSI7dj0iMTA5IiwgIkNocm9taXVtIjt2PSIxMDkiJyBcICAgLUggJ3NlYy1jaC11YS1hcmNoOiAieDg2IicgXCAgIC1IICdzZWMtY2gtdWEtYml0bmVzczogIjY0IicgXCAgIC1IICdzZWMtY2gtdWEtZnVsbC12ZXJzaW9uOiAiMTA5LjAuNTQxNC4xMjAiJyBcICAgLUggJ3NlYy1jaC11YS1mdWxsLXZlcnNpb24tbGlzdDogIk5vdF9BIEJyYW5kIjt2PSI5OS4wLjAuMCIsICJHb29nbGUgQ2hyb21lIjt2PSIxMDkuMC41NDE0LjEyMCIsICJDaHJvbWl1bSI7dj0iMTA5LjAuNTQxNC4xMjAiJyBcICAgLUggJ3NlYy1jaC11YS1tb2JpbGU6ID8wJyBcICAgLUggJ3NlYy1jaC11YS1tb2RlbDogIiInIFwgICAtSCAnc2VjLWNoLXVhLXBsYXRmb3JtOiAiV2luZG93cyInIFwgICAtSCAnc2VjLWNoLXVhLXBsYXRmb3JtLXZlcnNpb246ICIwLjEuMCInIFwgICAtSCAnc2VjLWZldGNoLWRlc3Q6IGRvY3VtZW50JyBcICAgLUggJ3NlYy1mZXRjaC1tb2RlOiBuYXZpZ2F0ZScgXCAgIC1IICdzZWMtZmV0Y2gtc2l0ZTogY3Jvc3Mtc2l0ZScgXCAgIC1IICdzZWMtZmV0Y2gtdXNlcjogPzEnIFwgICAtSCAndXBncmFkZS1pbnNlY3VyZS1yZXF1ZXN0czogMScgXCAgIC1IICd1c2VyLWFnZW50OiBNb3ppbGxhLzUuMCAoV2luZG93cyBOVCAxMC4wOyBXaW42NDsgeDY0KSBBcHBsZVdlYktpdC81MzcuMzYgKEtIVE1MLCBsaWtlIEdlY2tvKSBDaHJvbWUvMTA5LjAuMC4wIFNhZmFyaS81MzcuMzYnIFwgICAtLWNvbXByZXNzZWQ="


RUN apt-get update && apt-get install -y git

# Set home to the user's home directory
ENV HOME=/home/user \
	PATH=/home/user/.local/bin:$PATH

# Set up a new user named "user" with user ID 1000
RUN useradd -o -u 1000 user && mkdir -p $HOME/app && chown -R user $HOME

# Switch to the "user" user
USER user

# Set the working directory to the user's home directory
WORKDIR $HOME/app


# 从 GitHub 克隆 weaigc/bingo 项目到 /workspace/app 目录下
RUN git clone https://github.com/SokWith/bingo.git ./ 

# Copy the current directory contents into the container at $HOME/app setting the owner to the user
COPY --chown=user . $HOME/app/

RUN npm install && npm run build

RUN rm -rf src

ENV PORT 7860

EXPOSE 7860

CMD npm start

能不能绘图跟dockerfile没关系，应该是BING_HRADER设置问题

[SokWith]

Harry-zklcdc/go-proxy-bingai#251 (comment)
我在隔壁goproxybingai项目公开了一个自动过验证的接入点服务器地址：

ENDPOINT="cfree.nbing.eu.org"

能避免创建失败请重试故障，目前针对大多数云商（已测试replit，huggingface，zeabur）都是有效的。

[mlmk6698]

goproxybingai

好的，感谢

[SokWith]

Harry-zklcdc/go-proxy-bingai#273 (comment)
@weaigc 评估一下这个方案
bingo项目没有过验证的api，主要依赖直接过验证来实现wss会话。
目前官方对create、wss都封杀得厉害，要想服务不中断，还得靠有效的ID。

大佬，检讨一下利用这个自动更新cookie方案能不能获得稳定的wss连接？

[b1ghawk]

Harry-zklcdc/go-proxy-bingai#273 (comment)
@weaigc 评估一下这个方案
bingo项目没有过验证的api，主要依赖直接过验证来实现wss会话。
目前官方对create、wss都封杀得厉害，要想服务不中断，还得靠有效的ID。

大佬，检讨一下利用这个自动更新cookie方案能不能获得稳定的wss连接？

经测试，人机验证依旧反复出现，首页的最新cookies仍然需要认证，此方案无效。

反倒是尝试了一下挂机自动过验证。。

Harry-zklcdc/go-proxy-bingai#273 (comment)

[SokWith]

Harry-zklcdc/go-proxy-bingai#273 (comment)
@weaigc 评估一下这个方案
bingo项目没有过验证的api，主要依赖直接过验证来实现wss会话。
目前官方对create、wss都封杀得厉害，要想服务不中断，还得靠有效的ID。
大佬，检讨一下利用这个自动更新cookie方案能不能获得稳定的wss连接？

经测试，人机验证依旧反复出现，首页的最新cookies仍然需要认证，此方案无效。

反倒是尝试了一下挂机自动过验证。。

Harry-zklcdc/go-proxy-bingai#273 (comment)

我似乎又找到了一条bingo利用推送cookie的道路：
1、注释掉这行代码

2、ENDPOINT指向隔壁go-proxy-bingai项目部署在cf上的服务器
3、当然，cf服务器需要加载推送的cookie

效果如图：

再也不用担心服务不可用了，bingo做GPT的API也稳定了。

@weaigc 大佬，看看怎么优化？

[SokWith]

Harry-zklcdc/go-proxy-bingai#273 (comment) @weaigc 评估一下这个方案 bingo项目没有过验证的api，主要依赖直接过验证来实现wss会话。 目前官方对create、wss都封杀得厉害，要想服务不中断，还得靠有效的ID。

大佬，检讨一下利用这个自动更新cookie方案能不能获得稳定的wss连接？

发现简单的方法，在cf上的部署就可以直接调用KV存储的cookie。

自动登录帐号解决了，但是：
@weaigc 大佬，这个登录的帐号不能画图，为什么要做两套账户逻辑？直接合并了吧。

注：我两个项目调用同一个cookie，隔壁能画图，本项目不能直接画图。

[cakota6462]

Harry-zklcdc/go-proxy-bingai#273 (comment)
@weaigc 评估一下这个方案
bingo项目没有过验证的api，主要依赖直接过验证来实现wss会话。
目前官方对create、wss都封杀得厉害，要想服务不中断，还得靠有效的ID。
大佬，检讨一下利用这个自动更新cookie方案能不能获得稳定的wss连接？

经测试，人机验证依旧反复出现，首页的最新cookies仍然需要认证，此方案无效。
反倒是尝试了一下挂机自动过验证。。
Harry-zklcdc/go-proxy-bingai#273 (comment)

我似乎又找到了一条bingo利用推送cookie的道路： 1、注释掉这行代码 2、ENDPOINT指向隔壁go-proxy-bingai项目部署在cf上的服务器 3、当然，cf服务器需要加载推送的cookie

效果如图：

再也不用担心服务不可用了，bingo做GPT的API也稳定了。

@weaigc 大佬，看看怎么优化？

@SokWith 大佬，我是代码小白。想用bingo做GPT4的API。请问你是如何部署并让它稳定的？能出一个教程吗？另外，关于如何使用openai格式调用我也没有看懂，方便也出一个教程吗？

[SokWith]

想用bingo做GPT4的API。请问你是如何部署并让它稳定的？能出一个教程吗？另外，关于如何使用openai格式调用我也没有看懂，方便也出一个教程吗？

也是小白，都是按大佬的教程部署的，只是使用了登录帐号来使用。
运行下来发现做API有显著缺陷，每一个问话就消耗一个对话资格，1个对话问上7、8次就消耗7、8个对话资格，登录帐号一天也就100个左右的对话资格，很快就被用完达到数量限制了。

[cakota6462]

想用bingo做GPT4的API。请问你是如何部署并让它稳定的？能出一个教程吗？另外，关于如何使用openai格式调用我也没有看懂，方便也出一个教程吗？

也是小白，都是按大佬的教程部署的，只是使用了登录帐号来使用。 运行下来发现做API有显著缺陷，每一个问话就消耗一个对话资格，1个对话问上7、8次就消耗7、8个对话资格，登录帐号一天也就100个左右的对话资格，很快就被用完达到数量限制了。

@SokWith 请问大佬的教程在哪里，方便给个链接吗？
请问这个对话资格的消耗问题有没有解决方法？还是只能换个账号？

[SokWith]

想用bingo做GPT4的API。请问你是如何部署并让它稳定的？能出一个教程吗？另外，关于如何使用openai格式调用我也没有看懂，方便也出一个教程吗？

也是小白，都是按大佬的教程部署的，只是使用了登录帐号来使用。 运行下来发现做API有显著缺陷，每一个问话就消耗一个对话资格，1个对话问上7、8次就消耗7、8个对话资格，登录帐号一天也就100个左右的对话资格，很快就被用完达到数量限制了。

@SokWith 请问大佬的教程在哪里，方便给个链接吗？ 请问这个对话资格的消耗问题有没有解决方法？还是只能换个账号？

你都不看readme吗？
https://github.com/weaigc/bingo/blob/main/OPENAI.md

[Hansimov]

运行下来发现做API有显著缺陷，每一个问话就消耗一个对话资格，1个对话问上7、8次就消耗7、8个对话资格，登录帐号一天也就100个左右的对话资格，很快就被用完达到数量限制了。

@SokWith 事实上可以用数据缓存和匹配的方式来复用之前 create 好的 session，以减少对话额度的消耗。

比如，用户传入数据格式为：

{
   "model": "bingo",
   "messages": [
      {
         "role": "system",
         "content": "You are a helpful assistant."
      },
      {
         "role": "user",
         "content": "Hello!"
      }
   ],
   "temperature": "0.1",
   ...
}

那么 Bing 回复一次之后，用户再次传入的数据为：

{
   "model": "bingo",
   "messages": [
      {
         "role": "system",
         "content": "You are a helpful assistant."
      },
      {
         "role": "user",
         "content": "Hello!"
      },
      {
         "role": "assistant",
         "content": "Hi! How can I help you today?"
      }
   ],
   "temperature": "0.1",
   ...
}

也即其他参数和 message 相同，仅多了一条 role 为 assistant 的 message。
故而可将此特征视为用户在同一 session 的下一轮对话行为，因此可复用之前的 session。

在工程实现中需要考虑如下问题：

• 相同的消息数据，用户可能会发送多次（出于测试或多样化的目的）
  • 需要考虑是返回之前缓存的回复，还是新开一个 session
  • 可以根据请求来源的身份信息（如 IP）和频率（如上次和此次发送该条相同消息的间隔）来决定

我主页的 bing-chat-api 就在考虑实现这个机制。

以上讨论脱离了此 issue 的主题，可以新建一个 issue 讨论。

[SokWith]

我主页的 bing-chat-api 就在考虑实现这个机制

@Hansimov 爬过去看了一下，小白没明白怎么用？要自己写前端吗？不能像这个项目一样直接使用现有的前端（比如Nextchat）吗？

[b1ghawk]

我主页的 bing-chat-api 就在考虑实现这个机制

@Hansimov 爬过去看了一下，小白没明白怎么用？要自己写前端吗？不能像这个项目一样直接使用现有的前端（比如Nextchat）吗？

话说你nbing.eu.org上面那个自带ID的站为什么长期处于不可用状态，我自己没有搭建带ID的站点(基于推送)，偶尔点击你的站点使用。

最近发现进入站点之后，会有云服务商的错误❌提示。

而且有时候会这样：

[SokWith]

nbing.eu.org上面那个自带ID的站为什么长期处于不可用状态，我自己没有搭建带ID的站点(基于推送)，偶尔点击你的站点使用。

最近发现进入站点之后，会有云服务商的错误❌提示。

而且有时候会这样：

1、目前CSB的部署需要保活，测试性质没有管他。

PS:我自己有另外在huggingface上的推送站点就不存在保活的问题（使用同一个推送服务器）；

2、应该是我测试关闭了U值的推送（后来忘记打开了），造成不能画图。

推送确实很好用，即使不搭建自动推送服务器。由于CF的站点可以直接调用KV存储，所以站点上的部署最好都加上推送调用。想匿名使用就在非bing站点推送一下非法cookie，想登录使用就在bing站点推送一下，切换太方便了。

[Hansimov]

爬过去看了一下，小白没明白怎么用？要自己写前端吗？不能像这个项目一样直接使用现有的前端（比如Nextchat）吗？

@SokWith 不带前端，以 OpenAI API endpoint 的方式提供服务。支持在其他前端框架里用。