【提醒】内置PROXY套娃代理部署说明

[SokWith]

[自动过验证视频]

https://github.com/Harry-zklcdc/go-proxy-bingai/assets/129967025/866a2f75-5e3e-447e-a0cb-87d883d06ca8

部署： https://github.com/Harry-zklcdc/go-proxy-bingai/issues/263#issuecomment-1826357465 配置： https://github.com/Harry-zklcdc/go-proxy-bingai/issues/263#issuecomment-1829502617

目前，只要经过认证（无论是登录用户还是匿名用户，即对本部署设置了过认证的BING_PROXY_DM代理服务器），绝大多数WSS服务器都可以正常连接，就不需要设置SYDNEY_PROXY_DM代理服务器了。

注意：大佬的主仓从1.18.0开始已经增加了套娃处理，环境变量略有不同，请直接使用大佬的部署。

在huggingface部署时要注意端口PORT设置，Dockerfile里面设置的端口 ENV PORT XXXX 要与README.md里面的设置一致，否则会陷入长时间Building后失败。

### 另外，如果还有朋友悟出了套娃的妙处，也请保持保密。主要是担心本项目被官方监控，被针对性的封掉。

追记：

在huggingface上的部署本项目，似乎不能在其嵌套网页中预览运行，会出现无限循环认证。但是，直接访问 xxx-xxx.hf.space 站点，是可以直接过验证的。

[SokWith]

另外，部署的时候_U值最好添加上;

ENV Go_Proxy_BingAI_USER_TOKEN_1="ASDFGHJKLASDFQWERTVFRVDFBCBVXCXB"

追记：_U值不要直接复制，会造成很快耗尽匿名数量限制。需要随意设置。

[SokWith]

上一个可以过验证的地址含有前端，容易过大的消耗cf的请求数量，再给一个可以直接过验证的接入点服务器地址，只可以做后端，网页不可用的：

https://bing.cf03-b29.workers.dev

【经测试，这个接入点可以直接用于vercel、replit上的部署】 在huggingface上的部署需要对这个接入点反代后(比如replit上)当做代理服务器使用：

const express = require('express');
const httpProxy = require('http-proxy');

// 定义反向代理的目标 URL
const targetUrl = 'https://bing.cf03-b29.workers.dev';

// 创建反向代理服务器
const proxy = httpProxy.createProxyServer({
  target: targetUrl,
  changeOrigin: true
});

// 创建 Express 应用程序
const app = express();

// 添加反向代理规则
app.use('/', (req, res) => {
  // 将请求转发到反向代理服务器
  proxy.web(req, res, { target: targetUrl });
});

// 启动应用程序
const port = process.env.PORT || 3000;
app.listen(port, () => {
  console.log(`Server started on port ${port}`);
});

[SokWith]

采用上面的代理服务器，replit的部署也能正常过验证使用。 由于仅仅在每次发起新会话时才会调用BING_PROXY_DM代理服务器，这样一个服务器就可以服务非常多的终端使用。

@Harry-zklcdc 大佬，建议在main仓中加入套娃代理的代码，只需要改3处： 1、修改api/index.go,大致追加：

//var BingURL = os.Getenv("BING_PROXY_DM")

func Index(w http.ResponseWriter, r *http.Request) {
    if r.URL.Path == "/" {
        http.Redirect(w, r, common.PROXY_WEB_PAGE_PATH, http.StatusFound)
        return
    }
    if strings.HasPrefix(r.URL.Path, "/turing") {
        if !helper.CheckAuth(r) {
            helper.UnauthorizedResult(w)
            return
        }
//  if BingURL == "" {
//      BingURL = common.BING_URL.String()
//  }
//  proxyurl, _ := url.Parse(BingURL)
//      common.NewSingleHostReverseProxy(proxyurl).ServeHTTP(w, r)
//  } else {

2、在api/sydney.go下追加：

//var SydneyURL = os.Getenv("SYDNEY_PROXY_DM")

func Sydney(w http.ResponseWriter, r *http.Request) {
    if !helper.CheckAuth(r) {
        helper.UnauthorizedResult(w)
        return
    }
//  if SydneyURL == "" {
//      SydneyURL = common.BING_SYDNEY_URL.String()
//  }
//  sydproxyurl, _ := url.Parse(sydneyURL)
//  common.NewSingleHostReverseProxy(sydproxyurl).ServeHTTP(w, r)

3、以及更改chat/chat.vue下：

CIB.config.captcha.baseUrl = location.origin;

我代码小白，上面的代码都是问bing要的，编写很不正规，也没有能力持续更新。拜托大佬合并进主仓中去，方便后面维护。

[b1ghawk]

看不懂。。干啥用的。

[SokWith]

看不懂。。干啥用的。

套娃，就是不让本项目的代理直接去反代bing官网，而是去反代指定的代理服务器。这样就便于将项目部署到不能很好连接bing官网的地方（主要是指能够连接bing官网，但却被上了ip锁的云商，比如replit，部分huggingface，zeabur等），但是又直接改变了出口ip。 当然，如果指定的代理服务器有自动过验证的功能，那么部署就继承了自动过验证的能力。

[SokWith]

https://github.com/weaigc/bingo/issues/99#issuecomment-1820266109 相当于隔壁bingo设置自定义接入点

本来，sydney服务器的自定义前端就有，但是，对普通用户，哪里知道该自定义哪一个，所以，还是在环境变量中部署为好。 而bing服务器前端没有自定义的地方，所以，更需要环境变量加入一个。

[Harry-zklcdc]

所以要追加哪些代码，我没看懂

[SokWith]

所以要追加哪些代码，我没看懂

就是上面提及的3处文件代码，我不确定代码风格是否合适，所以采用注释的方式做说明

PS:我推送了一个requests，说明一下，里面多改了一个proxy.go文件，增加了一个行为cookie，只是在实际测试中似乎作用很有限，可以不要。

[SokWith]

@Harry-zklcdc 还是有个缺陷，由于更改的这句：

CIB.config.captcha.baseUrl = location.origin;

造成不能使用MOD大法直接过内置账户的验证，应该也会影响whistle过验证的方法。 我之前也测试过很久，如果不改这句，套娃过验证服务器后似乎不成功。

看取舍吧。

[Harry-zklcdc]

我看了一下代码，我重写一下吧

[SokWith]

我看了一下代码，我重写一下吧

谢谢。

[SokWith]

我看了一下代码，我重写一下吧

大佬，为什么z在内置cookie的时候，标头里面没有U\K\R值也能成功create，而在前端输入cookie后就有U\K\R值？ 希望内置cookie也能响应有U\K\R值，似乎在套娃代理部署中内置cookie不能直接过验证与这个响应有关。

[Harry-zklcdc]

我看了一下代码，我重写一下吧

image 大佬，为什么z在内置cookie的时候，标头里面没有U\K\R值也能成功create，而在前端输入cookie后就有U\K\R值？ image 希望内置cookie也能响应有U\K\R值，似乎在套娃代理部署中内置cookie不能直接过验证与这个响应有关。

如果你愿意，你可以把 UKR 的值给返回给前端，但是这样你的账号等于是裸奔，为了安全考虑，并没有返回

[SokWith]

我看了一下代码，我重写一下吧

image 大佬，为什么z在内置cookie的时候，标头里面没有U\K\R值也能成功create，而在前端输入cookie后就有U\K\R值？ image 希望内置cookie也能响应有U\K\R值，似乎在套娃代理部署中内置cookie不能直接过验证与这个响应有关。

如果你愿意，你可以把 UKR 的值给返回给前端，但是这样你的账号等于是裸奔，为了安全考虑，并没有返回

给一个分支代码吧，或者告诉一下怎么打开，不值钱的账号打算内置，方便随时过验证，谢谢

[b1ghawk]

我看了一下代码，我重写一下吧

大佬，为什么z在内置cookie的时候，标头里面没有U\K\R值也能成功create，而在前端输入cookie后就有U\K\R值？ 希望内置cookie也能响应有U\K\R值，似乎在套娃代理部署中内置cookie不能直接过验证与这个响应有关。

前端设置的cookies是直接写入到document.cookies的，在前端没有设置的情况下，就会默认使用后端的内置cookies，类似于一种fallback机制，图1和图2里的后端实际上都不会返回cookies，没有很大的差别。

---

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。

https://bing-start.b1ghawk.xyz/

[SokWith]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。

https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

[b1ghawk]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。

https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

[SokWith]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

[b1ghawk]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

[SokWith]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

[b1ghawk]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

我测试了一下，CloudFlare内置了账号的情况下，刚刚弹了一次验证框，过验证看似成功了，但你让它画图，你会发现是匿名聊天。（我指的就是我上次发给你的那个，昨天我内置了一个账号进去（用的K和R），可以画图，今天这两个值应该是过期了，弹了一次验证框，一闪而过，但是继续聊天的话，是匿名的效果，让它画图，会要求进行登录）

看上去这个过验证没什么卵用。。

[SokWith]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

我测试了一下，CloudFlare内置了账号的情况下，刚刚弹了一次验证框，过验证看似成功了，但你让它画图，你会发现是匿名聊天。（我指的就是我上次发给你的那个，昨天我内置了一个账号进去（用的K和R），可以画图，今天这两个值应该是过期了，弹了一次验证框，一闪而过，但是继续聊天的话，是匿名的效果，让它画图，会要求进行登录）

看上去这个过验证没什么卵用。。

现在就是内置账号没法过验证，同样的cookie，在前端输入后，就能直接过验证了，到底是哪个环节出现了偏差，没有搞懂。

[b1ghawk]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

我测试了一下，CloudFlare内置了账号的情况下，刚刚弹了一次验证框，过验证看似成功了，但你让它画图，你会发现是匿名聊天。（我指的就是我上次发给你的那个，昨天我内置了一个账号进去（用的K和R），可以画图，今天这两个值应该是过期了，弹了一次验证框，一闪而过，但是继续聊天的话，是匿名的效果，让它画图，会要求进行登录） 看上去这个过验证没什么卵用。。

现在就是内置账号没法过验证，同样的cookie，在前端输入后，就能直接过验证了，到底是哪个环节出现了偏差，没有搞懂。

是吗？我这边测试了，确实是“过验证”了，但只有匿名权限。

[SokWith]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

我测试了一下，CloudFlare内置了账号的情况下，刚刚弹了一次验证框，过验证看似成功了，但你让它画图，你会发现是匿名聊天。（我指的就是我上次发给你的那个，昨天我内置了一个账号进去（用的K和R），可以画图，今天这两个值应该是过期了，弹了一次验证框，一闪而过，但是继续聊天的话，是匿名的效果，让它画图，会要求进行登录） 看上去这个过验证没什么卵用。。

现在就是内置账号没法过验证，同样的cookie，在前端输入后，就能直接过验证了，到底是哪个环节出现了偏差，没有搞懂。

是吗？我这边测试了，确实是“过验证”了，但只有匿名权限。

看我顶楼的过验证视频，过了验证就不是匿名了，我已经测试过zeabur、replit、huggingface的部署，都有效，前提是必须在前端输入。

[b1ghawk]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

我测试了一下，CloudFlare内置了账号的情况下，刚刚弹了一次验证框，过验证看似成功了，但你让它画图，你会发现是匿名聊天。（我指的就是我上次发给你的那个，昨天我内置了一个账号进去（用的K和R），可以画图，今天这两个值应该是过期了，弹了一次验证框，一闪而过，但是继续聊天的话，是匿名的效果，让它画图，会要求进行登录） 看上去这个过验证没什么卵用。。

现在就是内置账号没法过验证，同样的cookie，在前端输入后，就能直接过验证了，到底是哪个环节出现了偏差，没有搞懂。

是吗？我这边测试了，确实是“过验证”了，但只有匿名权限。

看我顶楼的过验证视频，过了验证就不是匿名了，我已经测试过zeabur、replit、huggingface的部署，都有效，前提是必须在前端输入。

没明白，你从bing.com里面直接拉取了有效的cookies（还未过期的），这个时候进行具名聊天，本身就不需要验证吧？ 但是第二天或者第三天的时候，你这几个Cookies过期了之后，不更换Cookies的情况下，还可以正常地聊天么（同样的具名聊天）？

[SokWith]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

我测试了一下，CloudFlare内置了账号的情况下，刚刚弹了一次验证框，过验证看似成功了，但你让它画图，你会发现是匿名聊天。（我指的就是我上次发给你的那个，昨天我内置了一个账号进去（用的K和R），可以画图，今天这两个值应该是过期了，弹了一次验证框，一闪而过，但是继续聊天的话，是匿名的效果，让它画图，会要求进行登录） 看上去这个过验证没什么卵用。。

现在就是内置账号没法过验证，同样的cookie，在前端输入后，就能直接过验证了，到底是哪个环节出现了偏差，没有搞懂。

是吗？我这边测试了，确实是“过验证”了，但只有匿名权限。

看我顶楼的过验证视频，过了验证就不是匿名了，我已经测试过zeabur、replit、huggingface的部署，都有效，前提是必须在前端输入。

没明白，你从bing.com里面直接拉取了有效的cookies（还未过期的），本身就不需要验证吧？

不是的，是已经过期的id，使用cn.bing登录，得到较新的cookie。但是，这个cookie，输入在大佬的huggingface上的部署上是无法正常会话的。切换到我在zeabur上的部署，就可以直接过验证然后正常绘画了。

[SokWith]

这个zeabur上的部署，就是套娃了cf上的匿名过验证服务器。

[b1ghawk]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

我测试了一下，CloudFlare内置了账号的情况下，刚刚弹了一次验证框，过验证看似成功了，但你让它画图，你会发现是匿名聊天。（我指的就是我上次发给你的那个，昨天我内置了一个账号进去（用的K和R），可以画图，今天这两个值应该是过期了，弹了一次验证框，一闪而过，但是继续聊天的话，是匿名的效果，让它画图，会要求进行登录） 看上去这个过验证没什么卵用。。

现在就是内置账号没法过验证，同样的cookie，在前端输入后，就能直接过验证了，到底是哪个环节出现了偏差，没有搞懂。

是吗？我这边测试了，确实是“过验证”了，但只有匿名权限。

看我顶楼的过验证视频，过了验证就不是匿名了，我已经测试过zeabur、replit、huggingface的部署，都有效，前提是必须在前端输入。

没明白，你从bing.com里面直接拉取了有效的cookies（还未过期的），本身就不需要验证吧？

不是的，是已经过期的id，使用cn.bing登录，得到较新的cookie。但是，这个cookie，输入在大佬的huggingface上的部署上是无法正常会话的。切换到我在zeabur上的部署，就可以直接过验证然后正常绘画了。

还是不理解你说的“过验证”和我理解的"过验证"是不是同一回事儿。

我说的过验证是： 用户的Cookies过期了之后，继续聊天的话，按照以往的情况，会无限弹出验证框。 如果实现了“过验证”，那么这个验证框弹出一次之后，就能够继续聊天了，而且依旧可以继续画图。

不知道你说的"过验证"是哪一方面？ 我看你视频里的操作，就只是把cn.bing.com上面的最新的Cookies填入到前端，而这组Cookies本身就没过期，还谈不上“过验证”吧？

[SokWith]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

我测试了一下，CloudFlare内置了账号的情况下，刚刚弹了一次验证框，过验证看似成功了，但你让它画图，你会发现是匿名聊天。（我指的就是我上次发给你的那个，昨天我内置了一个账号进去（用的K和R），可以画图，今天这两个值应该是过期了，弹了一次验证框，一闪而过，但是继续聊天的话，是匿名的效果，让它画图，会要求进行登录） 看上去这个过验证没什么卵用。。

现在就是内置账号没法过验证，同样的cookie，在前端输入后，就能直接过验证了，到底是哪个环节出现了偏差，没有搞懂。

是吗？我这边测试了，确实是“过验证”了，但只有匿名权限。

看我顶楼的过验证视频，过了验证就不是匿名了，我已经测试过zeabur、replit、huggingface的部署，都有效，前提是必须在前端输入。

没明白，你从bing.com里面直接拉取了有效的cookies（还未过期的），本身就不需要验证吧？

不是的，是已经过期的id，使用cn.bing登录，得到较新的cookie。但是，这个cookie，输入在大佬的huggingface上的部署上是无法正常会话的。切换到我在zeabur上的部署，就可以直接过验证然后正常绘画了。

还是不理解你说的“过验证”和我理解的过验证是不是一回事儿。

我说的过验证是： 用户的Cookies过期了之后，继续聊天的话，按照以往的情况，会无限弹出验证框。 如果实现了“过验证”，那么这个验证框弹出一次之后，就能够继续聊天了，而且依旧可以继续画图。

不知道你说的过验证是哪一方面？

就是24小时过期后可以继续聊天，但前提是得把cookie在前端输入，只要前端cookie没有被清除，就可以一直避免24小时过期认证。没有测试过14天过期的情况，从之前mod大法看，14天U值过期，1个月K值过期是不能直接过验证的，必须cn.bing登录获得最新cookie才行。其实，cn.bing和www.bing的cookie是一样的U\K\R。

[b1ghawk]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

我测试了一下，CloudFlare内置了账号的情况下，刚刚弹了一次验证框，过验证看似成功了，但你让它画图，你会发现是匿名聊天。（我指的就是我上次发给你的那个，昨天我内置了一个账号进去（用的K和R），可以画图，今天这两个值应该是过期了，弹了一次验证框，一闪而过，但是继续聊天的话，是匿名的效果，让它画图，会要求进行登录） 看上去这个过验证没什么卵用。。

现在就是内置账号没法过验证，同样的cookie，在前端输入后，就能直接过验证了，到底是哪个环节出现了偏差，没有搞懂。

是吗？我这边测试了，确实是“过验证”了，但只有匿名权限。

看我顶楼的过验证视频，过了验证就不是匿名了，我已经测试过zeabur、replit、huggingface的部署，都有效，前提是必须在前端输入。

没明白，你从bing.com里面直接拉取了有效的cookies（还未过期的），本身就不需要验证吧？

不是的，是已经过期的id，使用cn.bing登录，得到较新的cookie。但是，这个cookie，输入在大佬的huggingface上的部署上是无法正常会话的。切换到我在zeabur上的部署，就可以直接过验证然后正常绘画了。

还是不理解你说的“过验证”和我理解的过验证是不是一回事儿。 我说的过验证是： 用户的Cookies过期了之后，继续聊天的话，按照以往的情况，会无限弹出验证框。 如果实现了“过验证”，那么这个验证框弹出一次之后，就能够继续聊天了，而且依旧可以继续画图。 不知道你说的过验证是哪一方面？

就是24小时过期后可以继续聊天，但前提是得把cookie在前端输入，只要前端cookie没有被清除，就可以一直避免24小时过期认证。没有测试过14天过期的情况，从之前mod大法看，14天U值过期，1个月K值过期是不能直接过验证的，必须cn.bing登录获得最新cookie才行。其实，cn.bing和www.bing的cookie是一样的U\K\R。

但我这边测试，U\K\R只有一天的存活期，第二天就会跳验证框了。

[SokWith]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

我测试了一下，CloudFlare内置了账号的情况下，刚刚弹了一次验证框，过验证看似成功了，但你让它画图，你会发现是匿名聊天。（我指的就是我上次发给你的那个，昨天我内置了一个账号进去（用的K和R），可以画图，今天这两个值应该是过期了，弹了一次验证框，一闪而过，但是继续聊天的话，是匿名的效果，让它画图，会要求进行登录） 看上去这个过验证没什么卵用。。

现在就是内置账号没法过验证，同样的cookie，在前端输入后，就能直接过验证了，到底是哪个环节出现了偏差，没有搞懂。

是吗？我这边测试了，确实是“过验证”了，但只有匿名权限。

看我顶楼的过验证视频，过了验证就不是匿名了，我已经测试过zeabur、replit、huggingface的部署，都有效，前提是必须在前端输入。

没明白，你从bing.com里面直接拉取了有效的cookies（还未过期的），本身就不需要验证吧？

不是的，是已经过期的id，使用cn.bing登录，得到较新的cookie。但是，这个cookie，输入在大佬的huggingface上的部署上是无法正常会话的。切换到我在zeabur上的部署，就可以直接过验证然后正常绘画了。

还是不理解你说的“过验证”和我理解的过验证是不是一回事儿。 我说的过验证是： 用户的Cookies过期了之后，继续聊天的话，按照以往的情况，会无限弹出验证框。 如果实现了“过验证”，那么这个验证框弹出一次之后，就能够继续聊天了，而且依旧可以继续画图。 不知道你说的过验证是哪一方面？

就是24小时过期后可以继续聊天，但前提是得把cookie在前端输入，只要前端cookie没有被清除，就可以一直避免24小时过期认证。没有测试过14天过期的情况，从之前mod大法看，14天U值过期，1个月K值过期是不能直接过验证的，必须cn.bing登录获得最新cookie才行。其实，cn.bing和www.bing的cookie是一样的U\K\R。

但我这边测试，U\K\R只有一天的存活期，第二天就会跳验证框了。

只是24小时存活期，过了24小时必须验证一下，但是这些cookie都没有过期，至少可以使用14天。通过现在的过验证服务器，把这些cookie保存在前端，就可以直接过验证了。和我之前的mod大法一样，只是mod大法是把cookie可以前、后端存放的。目前这个只能前端存放，后端保存无效。

[SokWith]

由于cn.bing可以随时登录获得cookie，所以，一般使用直接用当天的cookie输入最安心。 当然，前提是账户已经获得过聊天权限了，新注册的cn账户是不行的。

[SokWith]

目前仍然是：1处过验证，处处24小时有效，手机端不方便输cookie，就在电脑端处理验证。 最希望的是内置cookie也能有效，就随处过验证了。

[b1ghawk]

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。 https://bing-start.b1ghawk.xyz/

测试了一下，似乎前端输入的cookie不起作用了

因为我这个站不会使用前端提供的cookie，完全走内置的。

每个账户每天的会话额度有限，所以还得允许前端随意输入token来匿名使用

好像是可以设定的吧，不太清楚…没有长期高频多人使用，。

这个项目现在很鸡肋，电脑端有插件可以直接用官网。只适合手机端使用。 但现在可以直接过验证了，使用体验就比官网要干净了。

我测试了一下，CloudFlare内置了账号的情况下，刚刚弹了一次验证框，过验证看似成功了，但你让它画图，你会发现是匿名聊天。（我指的就是我上次发给你的那个，昨天我内置了一个账号进去（用的K和R），可以画图，今天这两个值应该是过期了，弹了一次验证框，一闪而过，但是继续聊天的话，是匿名的效果，让它画图，会要求进行登录） 看上去这个过验证没什么卵用。。

现在就是内置账号没法过验证，同样的cookie，在前端输入后，就能直接过验证了，到底是哪个环节出现了偏差，没有搞懂。

是吗？我这边测试了，确实是“过验证”了，但只有匿名权限。

看我顶楼的过验证视频，过了验证就不是匿名了，我已经测试过zeabur、replit、huggingface的部署，都有效，前提是必须在前端输入。

没明白，你从bing.com里面直接拉取了有效的cookies（还未过期的），本身就不需要验证吧？

不是的，是已经过期的id，使用cn.bing登录，得到较新的cookie。但是，这个cookie，输入在大佬的huggingface上的部署上是无法正常会话的。切换到我在zeabur上的部署，就可以直接过验证然后正常绘画了。

还是不理解你说的“过验证”和我理解的过验证是不是一回事儿。 我说的过验证是： 用户的Cookies过期了之后，继续聊天的话，按照以往的情况，会无限弹出验证框。 如果实现了“过验证”，那么这个验证框弹出一次之后，就能够继续聊天了，而且依旧可以继续画图。 不知道你说的过验证是哪一方面？

就是24小时过期后可以继续聊天，但前提是得把cookie在前端输入，只要前端cookie没有被清除，就可以一直避免24小时过期认证。没有测试过14天过期的情况，从之前mod大法看，14天U值过期，1个月K值过期是不能直接过验证的，必须cn.bing登录获得最新cookie才行。其实，cn.bing和www.bing的cookie是一样的U\K\R。

但我这边测试，U\K\R只有一天的存活期，第二天就会跳验证框了。

只是24小时存活期，过了24小时必须验证一下，但是这些cookie都没有过期，至少可以使用14天。通过现在的过验证服务器，把这些cookie保存在前端，就可以直接过验证了。和我之前的mod大法一样，只是mod大法是把cookie可以前、后端存放的。目前这个只能前端存放，后端保存无效。

测试过，在前端填入cookies，第一天可以画图，第二天会跳验证框，一闪而过，可以继续聊天，但只有匿名的聊天权限，无法进行画图。

[SokWith]

测试过，在前端填入cookies，第一天可以画图，第二天会跳验证框，一闪而过，可以继续聊天，但只有匿名的聊天权限，无法进行画图。

可能是我没有详细测试吧。之前一直MOD大法内置cookie，14天换新。 现在cn的cookie太易得了，又经常一键重置，都是用当天的cookie。但是，内置的cookie在前端过了验证后也是有效的，24小时内无论怎么一键重置，都无需再验证，依然可以14天不换。

[SokWith]

测试过，在前端填入cookies，第一天可以画图，第二天会跳验证框，一闪而过，可以继续聊天，但只有匿名的聊天权限，无法进行画图。

可能是我没有详细测试吧。之前一直MOD大法内置cookie，14天换新。 现在cn的cookie太易得了，又经常一键重置，都是用当天的cookie。但是，内置的cookie在前端过了验证后也是有效的，24小时内无论怎么一键重置，都无需再验证，依然可以14天不换。

确实，24小时过期的cookie不能在前端过验证，还是必须使用最新的cookie

只是奇怪，为什么mod大法就可以使用内置的24小时过期后的cookie？

[b1ghawk]

测试过，在前端填入cookies，第一天可以画图，第二天会跳验证框，一闪而过，可以继续聊天，但只有匿名的聊天权限，无法进行画图。

可能是我没有详细测试吧。之前一直MOD大法内置cookie，14天换新。 现在cn的cookie太易得了，又经常一键重置，都是用当天的cookie。但是，内置的cookie在前端过了验证后也是有效的，24小时内无论怎么一键重置，都无需再验证，依然可以14天不换。

确实，24小时过期的cookie不能在前端过验证，还是必须使用最新的cookie

只是奇怪，为什么mod大法就可以使用内置的24小时过期后的cookie？

mod大法是什么。。

[SokWith]

modheader大法，bing最初的逃逸方法，科学环境下，选择官方服务器，修改请求头，就可以实现过验证、聊天

[SokWith]

既然现在套娃过验证需要最新cookie，就不用折腾后端内置的问题了。

[b1ghawk]

既然现在套娃过验证需要最新cookie，就不用折腾后端内置的问题了。

我觉着，既然cn.bing.com的ID是可以正常使用的话，

完全可以在cloudflare的worker.js上开个接口，用于接收最新的Cookies并存入cloudflare KV。

然后编写一个提取cookies并发送到上面这个接口地址的浏览器扩展程序(手机端可以用kiwi浏览器，电脑端就随意了，支持扩展的浏览器那可太多了)。

每当访问cn.bing.com的时候，扩展程序自动把lsp.apx上的最新cookie更新到cloudflare KV里。

这样可以一定程度上简化操作.. 甚至可以做到24小时无人值守全天候自动更新Cookie(开一台服务器，里面跑着浏览器和我们的扩展程序，扩展程序按照一定的频率刷新bing的网页，读取最新的cookie，推送到cloudflare KV)。

至于为什么是扩展程序而不是油猴脚本，因为油猴脚本读取不了属性为HttpOnly的cookies，而扩展程序是可以的。

这个思路不是"过验证"，而是自动获取当前有效的cookies，自动替换掉旧的无效的cookies，由于刷入KV，所有用户都能毫无感知地用上新的共享cookies。

[b1ghawk]

类似于这种项目：

https://github.com/iszhouhua/cookie-push

[SokWith]

既然现在套娃过验证需要最新cookie，就不用折腾后端内置的问题了。

我觉着，既然cn.bing.com的ID是可以正常使用的话，

完全可以在cloudflare的worker.js上开个接口，用于接收最新的Cookies并存入cloudflare KV。

然后编写一个提取cookies并发送到上面这个接口地址的浏览器扩展程序(手机端可以用kiwi浏览器，电脑端就随意了，支持扩展的浏览器那可太多了)。

每当访问cn.bing.com的时候，扩展程序自动把lsp.apx上的最新cookie更新到cloudflare KV里。

这样可以一定程度上简化操作.. 甚至可以做到24小时无人值守全天候自动更新Cookie(开一台服务器，里面跑着浏览器和我们的扩展程序，扩展程序按照一定的频率刷新bing的网页，读取最新的cookie，推送到cloudflare KV)。

至于为什么是扩展程序而不是油猴脚本，因为油猴脚本读取不了属性为HttpOnly的cookies，而扩展程序是可以的。

这个思路不是"过验证"，而是自动获取当前有效的cookies，自动替换掉旧的无效的cookies，由于刷入KV，所有用户都能毫无感知地用上新的共享cookies。

工程浩大呀！小白们都不敢想。

[b1ghawk]

既然现在套娃过验证需要最新cookie，就不用折腾后端内置的问题了。

我觉着，既然cn.bing.com的ID是可以正常使用的话，

完全可以在cloudflare的worker.js上开个接口，用于接收最新的Cookies并存入cloudflare KV。

然后编写一个提取cookies并发送到上面这个接口地址的浏览器扩展程序(手机端可以用kiwi浏览器，电脑端就随意了，支持扩展的浏览器那可太多了)。

每当访问cn.bing.com的时候，扩展程序自动把lsp.apx上的最新cookie更新到cloudflare KV里。

这样可以一定程度上简化操作.. 甚至可以做到24小时无人值守全天候自动更新Cookie(开一台服务器，里面跑着浏览器和我们的扩展程序，扩展程序按照一定的频率刷新bing的网页，读取最新的cookie，推送到cloudflare KV)。

至于为什么是扩展程序而不是油猴脚本，因为油猴脚本读取不了属性为HttpOnly的cookies，而扩展程序是可以的。

这个思路不是"过验证"，而是自动获取当前有效的cookies，自动替换掉旧的无效的cookies，由于刷入KV，所有用户都能毫无感知地用上新的共享cookies。

工程浩大呀！小白们都不敢想。

其实也还好。。。很简单的。这几天有时间了我弄个试试吧。

[SokWith]

既然现在套娃过验证需要最新cookie，就不用折腾后端内置的问题了。

我觉着，既然cn.bing.com的ID是可以正常使用的话， 完全可以在cloudflare的worker.js上开个接口，用于接收最新的Cookies并存入cloudflare KV。 然后编写一个提取cookies并发送到上面这个接口地址的浏览器扩展程序(手机端可以用kiwi浏览器，电脑端就随意了，支持扩展的浏览器那可太多了)。 每当访问cn.bing.com的时候，扩展程序自动把lsp.apx上的最新cookie更新到cloudflare KV里。 这样可以一定程度上简化操作.. 甚至可以做到24小时无人值守全天候自动更新Cookie(开一台服务器，里面跑着浏览器和我们的扩展程序，扩展程序按照一定的频率刷新bing的网页，读取最新的cookie，推送到cloudflare KV)。 至于为什么是扩展程序而不是油猴脚本，因为油猴脚本读取不了属性为HttpOnly的cookies，而扩展程序是可以的。 这个思路不是"过验证"，而是自动获取当前有效的cookies，自动替换掉旧的无效的cookies，由于刷入KV，所有用户都能毫无感知地用上新的共享cookies。

工程浩大呀！小白们都不敢想。

其实也还好。。。很简单的。这几天有时间了我弄个试试吧。

期待ing。

[SokWith]

既然现在套娃过验证需要最新cookie，就不用折腾后端内置的问题了。

工程浩大呀！小白们都不敢想。

其实也还好。。。很简单的。这几天有时间了我弄个试试吧。

@b1ghawk 我应该是解决了内置账户过验证的问题了，期待你的推送cookie来解决14天有效期的问题。 我在replit部署的测试站点 https://replit.nbing.eu.org 上内置了3个账号，目前2个在14天有效期内，1个在有效期外，跟踪测试看看什么时候都失效。

主要是，如何解决其他部署自动更新内置cookie的问题？ @Harry-zklcdc 可以在主代码中增加接口服务吗？

[b1ghawk]

既然现在套娃过验证需要最新cookie，就不用折腾后端内置的问题了。

工程浩大呀！小白们都不敢想。

其实也还好。。。很简单的。这几天有时间了我弄个试试吧。

@b1ghawk 我应该是解决了内置账户过验证的问题了，期待你的推送cookie来解决14天有效期的问题。 我在replit部署的测试站点 https://replit.nbing.eu.org 上内置了3个账号，目前2个在14天有效期内，1个在有效期外，跟踪测试看看什么时候都失效。

主要是，如何解决其他部署自动更新内置cookie的问题？ @Harry-zklcdc 可以在主代码中增加接口服务吗？

你发的邮件内容我没有看明白，我把qq发给你了，直接交流吧。

[SokWith]

既然现在套娃过验证需要最新cookie，就不用折腾后端内置的问题了。

工程浩大呀！小白们都不敢想。

其实也还好。。。很简单的。这几天有时间了我弄个试试吧。

@b1ghawk 我应该是解决了内置账户过验证的问题了，期待你的推送cookie来解决14天有效期的问题。 我在replit部署的测试站点 https://replit.nbing.eu.org 上内置了3个账号，目前2个在14天有效期内，1个在有效期外，跟踪测试看看什么时候都失效。 主要是，如何解决其他部署自动更新内置cookie的问题？ @Harry-zklcdc 可以在主代码中增加接口服务吗？

你发的邮件内容我没有看明白，我把qq发给你了，直接交流吧。

目前我测试域上的多个内置账号已经稳定运行2天了，特别是replit上的内置多个账号，其中一个账号是与我的vercel主站 https://vercel.nbing.eu.org/ 共享（由于是主站，没有去套娃，内置账号只能靠其他方式过验证），通过replit站点过验证后保证vercel站点账号有效。

我已经全线修改了过验证服务器的内置过验证功能，使用我的这个docker 【FROM jokyo3/probingai:v1.18.3】的部署都自动具备了相应的能力。

但测试也发现，这样修改后，似乎不能当作bingo项目的 【ENDPOINT】 接入点了。

[SokWith]

大家可以使用自己还在大约14天有效期内的cookie去我的测试域站点测试。 由于没有大量访问，不知道访问量大后会不会触发ip锁。

[SokWith]

不同时期的cookie可以共存： replit上的cookie

vercel上的cookie：

[SokWith]

大家可以使用自己还在大约14天有效期内的cookie去我的测试域站点测试。 由于没有大量访问，不知道访问量大后会不会触发ip锁。

刚才虚惊一场，发现cf上的几个站点都不能建立会话，以为被官方封堵了BUG，换了一个cf账号重新复制建立了测试站点却又可用。看来cf也和huggingface一样，流量大一点就限流了。