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

SokWith · 2023-11-28T14:09:23Z

[自动过验证视频]

s.mp4

部署：
#263 (comment)
配置：
#263 (comment)

目前，只要经过认证（无论是登录用户还是匿名用户，即对本部署设置了过认证的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 · 2023-11-29T00:41:46Z

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

ENV Go_Proxy_BingAI_USER_TOKEN_1="ASDFGHJKLASDFQWERTVFRVDFBCBVXCXB"

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

SokWith · 2023-11-30T06:08:05Z

上一个可以过验证的地址含有前端，容易过大的消耗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 · 2023-11-30T08:58:37Z

采用上面的代理服务器，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 · 2023-12-01T05:22:43Z

看不懂。。干啥用的。

SokWith · 2023-12-01T08:49:37Z

看不懂。。干啥用的。

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

SokWith · 2023-12-01T08:58:49Z

weaigc/bingo#99 (comment)
相当于隔壁bingo设置自定义接入点

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

Harry-zklcdc · 2023-12-01T15:30:40Z

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

SokWith · 2023-12-02T01:46:09Z

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

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

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

SokWith · 2023-12-02T04:37:09Z

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

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

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

看取舍吧。

Harry-zklcdc · 2023-12-04T11:48:01Z

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

SokWith · 2023-12-04T12:03:38Z

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

谢谢。

SokWith · 2023-12-04T14:55:07Z

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

大佬，为什么z在内置cookie的时候，标头里面没有U\K\R值也能成功create，而在前端输入cookie后就有U\K\R值？

希望内置cookie也能响应有U\K\R值，似乎在套娃代理部署中内置cookie不能直接过验证与这个响应有关。

Harry-zklcdc · 2023-12-04T15:13:22Z

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

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

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

SokWith · 2023-12-04T15:22:55Z

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

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

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

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

b1ghawk · 2023-12-04T16:12:19Z

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

大佬，为什么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 · 2023-12-05T00:24:05Z

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

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

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

b1ghawk · 2023-12-05T00:38:59Z

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

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

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

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

SokWith · 2023-12-05T00:55:33Z

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

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

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

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

b1ghawk · 2023-12-05T01:27:43Z

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

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

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

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

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

SokWith · 2023-12-05T02:43:58Z

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

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

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

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

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

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

b1ghawk · 2023-12-05T06:00:42Z

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

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

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

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

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

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

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

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

SokWith · 2023-12-05T06:36:30Z

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

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

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

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

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

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

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

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

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

b1ghawk · 2023-12-05T06:39:21Z

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

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

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

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

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

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

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

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

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

SokWith · 2023-12-05T06:46:36Z

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

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

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

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

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

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

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

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

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

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

b1ghawk · 2023-12-05T06:50:49Z

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

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

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

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

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

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

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

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

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

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

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

SokWith · 2023-12-05T06:55:31Z

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。
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 · 2023-12-05T06:57:18Z

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

b1ghawk · 2023-12-05T06:58:33Z

搭了个新的，内置了账户，不确定能不能过验证，因为今天下午刚刚搭建，明后天再看看。
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本身就没过期，还谈不上“过验证”吧？

b1ghawk · 2023-12-12T07:13:36Z

@SokWith 已经添加Cookies推送，邮给你了。

SokWith · 2023-12-12T07:55:47Z

@SokWith 已经添加Cookies推送，邮给你了。

谢谢。有心了。
由于已经解决了内置cookie过验证，说明确实与显示cookie无关，也就不用在意了。

反而是如何推送cookie到服务器更值得期待。
我在想，由于U值可以在环境变量中读入，huggingface又可以定时重启读入配置。是否可以在dockerfile文件中读入指定服务器上的推送保存的cookie，实现cookie的更新。
而cookie的更新，似乎可以参照那个pass服务器，部署一个服务器，添加chrome浏览器，内置bing账户，定时打开浏览器加载官网和推送插件推送cookie，是不是就可以全自动更新cookie了？
@Harry-zklcdc @b1ghawk

SokWith · 2023-12-12T08:02:45Z

使用最新cookie的好处是能在huggingface上直接过验证，不需要特别的服务器。
比如今天，许多huggingface上的部署都会遇到create障碍，但只要把最新的匿名cookie完整输入，就能正常会话了。若使用登录账户的最新cookie，几乎都不会跳验证的。

b1ghawk · 2023-12-12T08:15:01Z

使用最新cookie的好处是能在huggingface上直接过验证，不需要特别的服务器。比如今天，许多huggingface上的部署都会遇到create障碍，但只要把最新的匿名cookie完整输入，就能正常会话了。若使用登录账户的最新cookie，几乎都不会跳验证的。

没理解这句话。。

我这边目前就是用我邮件里的那一套，采用CloudFlare和Huggingface混搭。
默认情况下使用workers脚本里的旧的Cookies（这组Cookies目前应该还没到14天，每天会触发一次验证，自动过验证之后还可以继续使用）。

如果插件推送了最新的Cookies到Workers上，就会采用最新的Cookies。
（当然，就像我邮件里说的那样，每次推送成功之后，客户端需要做一次"一键重置"，才能够拉取到最新的Cookies。就是网页右上角的那个一键重置）

b1ghawk · 2023-12-12T08:17:27Z

使用最新cookie的好处是能在huggingface上直接过验证，不需要特别的服务器。比如今天，许多huggingface上的部署都会遇到create障碍，但只要把最新的匿名cookie完整输入，就能正常会话了。若使用登录账户的最新cookie，几乎都不会跳验证的。

没理解这句话。。

我这边目前就是用我邮件里的那一套，采用CloudFlare和Huggingface混搭。默认情况下使用workers脚本里的旧的Cookies（这组Cookies目前应该还没到14天，每天会触发一次验证，自动过验证之后还可以继续使用）。

如果插件推送了最新的Cookies到Workers上，就会采用最新的Cookies。（当然，就像我邮件里说的那样，每次推送成功之后，客户端需要做一次"一键重置"，才能够拉取到最新的Cookies。就是网页右上角的那个一键重置）

只要每过一两天，就点一次客户端的一键重置，基本上拉取到的都是最新的Cookies。

至于为什么不做成” 自动使用最新的Cookies来强刷客户端的Cookies“，
主要是我怕客户端会有在页面上自定义Cookies的需求，还是把这个选择权交给用户自己。

b1ghawk · 2023-12-12T08:24:32Z

目前我的组合是：

https://chromewebstore.google.com/detail/page-auto-refresh/ldgjechphfcppimcgcjcblmnhkjniakn

以及我邮件内的那个Cookies推送插件。

目前我的笔记本电脑在负责定期推送Cookies（一旦检测到Cookies发生了变化），还没部署到独立的服务器上。

SokWith · 2023-12-12T08:35:04Z

采用CloudFlare和Huggingface混搭

这确实是最优解，但是不利于推广。

我在考虑开源共享精神，找另外一条备用过验证的路线。
由于huggingface简直就像微软的亲儿子，大部分时候只要采用最新完整cookie，都是不跳验证的，所以值得一试。

b1ghawk · 2023-12-12T11:39:57Z

workers代码(Cookie项目).zip
PageRefresh插件
 CookiePush插件

这里提供一套Cookies推送方案，需要用到两个浏览器插件，以及一套cloudflare workers代码。

为简化问题，统一术语，暂且称这个cloud workers项目为：Cookie项目。

基本思路如下：

两个浏览器插件用于搭建推送服务器，定时地获取最新的cookies，推送到Cookie项目。
Cookie项目接收到这些最新的cookies以后，再注入到go-proxy-bingai项目的页面上。

部署教程以及使用方法：

Step.1 Cookie项目的部署：

1）部署压缩包内的Cookie项目代码，并绑定自定义域名。
2) 添加一个KV Namespace，

2）将刚才的KV绑定到Cookie项目里，注意变量的名字要叫作CookieStore

Step.2 推送服务器的搭建：

开启一台免费服务器，安装好Chromium浏览器，以及上面提到的两个浏览器插件。
打开www.bing.com标签页，配置 PageRefresh 插件的自动刷新间隔，注意，不要关闭该浏览器标签页，推荐的刷新间隔为每24小时之内刷新2次及以上。

配置CookiePush插件选项，推荐每24小时之内推送3次或以上（注意，这里要替换成你自己的Cookie项目的域名，url上的安全密码pwd可在worker.js里自行调整）

接下来就可以观察到浏览器会按照设定不断地刷新www.bing.com标签页，当cookies发生变化时或者Cookie推送的时间点抵达时，CookiePush插件会自动推送到我们的Cookie项目。(当然你也可以在www.bing.com页面的右键菜单上找到一个"推送cookie"的按钮，人工发起一次推送)。

Step.3 go-proxy-bingai项目的改造：

在go-proxy-bingai项目的前端页面增加下面的script标签 (同样地，也要替换成自己Cookie项目的域名)

<script src="https://cookie.b1ghawk.xyz/KVCookies.js"></script>

Step.4 至此，你的go-proxy-bingai项目就可以不间断地获取到最新的不需要进行人机验证的cookies了。

(完结)

b1ghawk · 2023-12-12T11:47:23Z

@SokWith
这样就是一个从完整方案剥离出来的可开源部分了。
至于我们那个可以自动过验证的版本，
不需要这么高的刷新频率，
14天之内1~2次即可。

SokWith · 2023-12-12T14:12:18Z

@SokWith 然后你就可以实现，作为一个开源的备用方案：将项目部署在Huggingface或者其它的云服务商上，每当访问web前端时，最新的cookies总是被注入到页面里。（↑改造的成本相当小，仅仅只是往本项目的index.html添加一个script标签）

而推送服务器（也就是安装了浏览器、自动刷新插件、cookies推送插件的服务器），则负责定期将最新的 cookies 同步到 workers站点里。

如此甚好。还没来得及部署，先谢谢了。

剩下来的工作就是部署推送服务器了。

b1ghawk · 2023-12-12T14:38:50Z

@SokWith 然后你就可以实现，作为一个开源的备用方案：将项目部署在Huggingface或者其它的云服务商上，每当访问web前端时，最新的cookies总是被注入到页面里。（↑改造的成本相当小，仅仅只是往本项目的index.html添加一个script标签）

而推送服务器（也就是安装了浏览器、自动刷新插件、cookies推送插件的服务器），则负责定期将最新的 cookies 同步到 workers站点里。

如此甚好。还没来得及部署，先谢谢了。

剩下来的工作就是部署推送服务器了。

我重新整理了一下语言，尽可能简单地说明：

#267 (comment)

SokWith · 2023-12-12T14:47:06Z

@SokWith 然后你就可以实现，作为一个开源的备用方案：将项目部署在Huggingface或者其它的云服务商上，每当访问web前端时，最新的cookies总是被注入到页面里。（↑改造的成本相当小，仅仅只是往本项目的index.html添加一个script标签）
而推送服务器（也就是安装了浏览器、自动刷新插件、cookies推送插件的服务器），则负责定期将最新的 cookies 同步到 workers站点里。

如此甚好。还没来得及部署，先谢谢了。
剩下来的工作就是部署推送服务器了。

我重新整理了一下语言，尽可能简单地说明：

#267 (comment)

很详细了，非常感谢！

SokWith · 2023-12-12T15:00:26Z

基于能白嫖就白嫖的精髓，下一步优化推送服务器的部署方案，如同pass服务器一样，直接dockerfile来一键部署。
先研究一下那2个插件的配置文件，搞个有默认配置的插件安装包，让chrome浏览器安装插件后就自动配置好了，方便dockerfile调用。
......
年纪大了，思路太杂了，先不想了。

Harry-zklcdc · 2023-12-12T15:28:26Z

说简单点，就是内置了已经通过了人机验证的 Cookie 来实现的过验证

b1ghawk · 2023-12-12T15:31:23Z

基于能白嫖就白嫖的精髓，下一步优化推送服务器的部署方案，如同pass服务器一样，直接dockerfile来一键部署。
先研究一下那2个插件的配置文件，搞个有默认配置的插件安装包，让chrome浏览器安装插件后就自动配置好了，方便dockerfile调用。
......
年纪大了，思路太杂了，先不想了。

如果走dockerfile的话，
从 技术角度 的话，我会优先考虑方案1：undetected-browser+py脚本，也就是不要依赖于扩展插件，彻底用自己的代码来实现整个登录+刷新+推送逻辑。

如果上面的那个路径不好实现的话，
我会再考虑方案2：即本文提到的chrome+扩展插件。

而对于方案2，就会有 2.1 和2.2 两种不同的实现方法。

2.1：
往dockerfile里塞一个类似于undetected-browser的headlesss类型的浏览器，这个浏览器还必须支持插件，并且要完成bing.com的自动登录，感觉可行性不高。
(自动登录、headless 等等因素都会降低这个方案的稳定性和可用性；有时候模拟的内容越多，打的补丁越多，很可能会适得其反，加大了被检测的机率)

2.2：
往dockerfile里塞一个原生的chrome浏览器并预装好插件，再进行x11转发(轻量化)或者vnc转发(重量级)，然后通过x11服务端或者连接到chrome vnc客户端连接到docker内部，对chrome进行远程图形化配置，也就是打开一个www.bing.com的tab，然后配置刚刚说的那两个插件。(像这种chrome+x11转发的docker镜像可以在dockerhub上直接找到)

但从 性价比 来说，仅仅是为了白嫖一个推送服务器，那么建议直接走2.2，可以省去很多麻烦事，只是它不像1和2.1那样完全地自动化。

1和2.1实现稍困难，投入较大，而且看起来也很容易被封禁，最后很有可能会"白白浪费时间"。

追加：
意外地，发现了更加有趣的东西，不晓得这种东西能不能放到hugging face上运行，每隔xx小时重启的问题又该如何解决？？？

https://baijiahao.baidu.com/s?id=1771635159018577721

https://github.com/cardinalby/chrome-remote-desktop-image

追加：
方案2.2已实现，#273

b1ghawk · 2023-12-12T15:52:56Z

说简单点，就是内置了已经通过了人机验证的 Cookie 来实现的过验证

也可能有一些不同，应该是说内置了"无需进行人机验证的Cookies"。

cn.bing.com和www.bing.com上的旧的K/U/R需要通过人机验证才可以重复使用。

cn.bing.com和www.bing.com上的最新K/U/R总是不触发人机，一天之后就会变成旧的K/U/R。

通过不断刷新bing.com页面(当然频率也不要太高吧...)，在K/U/R被标记为"需要进行人机验证"时，新的可用的K/U/R就会自动在bing.com的cookies里冒出来了，我们总是提取这个最新的K/U/R，注入到web前端，直接抛弃掉旧的K/U/R。

Harry-zklcdc · 2023-12-12T15:56:43Z

也可能有一些不同。

cn.bing.com和www.bing.com上的旧的K/U/R需要通过人机验证才可以重复使用。

cn.bing.com和www.bing.com上的最新K/U/R总是不触发人机。

最新产生的K/U/R的获取成本很低，不断刷新bing.com页面(当然频率也不要太高吧...)，在旧的K/U/R被标记为"需要进行人机验证"时，新的可用的K/U/R就会自动在bing.com的cookies里冒出来了，我们总是提取这个新的cookies，注入到web前端。

也算是，因为人机验证有显式和隐式之分。
当隐式人机验证不通过的时候才会触发显式人机验证

SokWith · 2023-12-13T00:26:53Z

每隔xx小时重启的问题又该如何解决？？？

隔壁bingo的作者弄了个action，通过在github上的动作更改huggingface的项目文件，而huggingface检测到项目文件有变动就触发重新部署动作。
https://github.com/weaigc/bingo/blob/main/.github/workflows/huggingface.yml

是我很早之前就想要的功能 #201 (comment)

SokWith · 2023-12-13T00:39:00Z

也可能有一些不同。
cn.bing.com和www.bing.com上的旧的K/U/R需要通过人机验证才可以重复使用。
cn.bing.com和www.bing.com上的最新K/U/R总是不触发人机。
最新产生的K/U/R的获取成本很低，不断刷新bing.com页面(当然频率也不要太高吧...)，在旧的K/U/R被标记为"需要进行人机验证"时，新的可用的K/U/R就会自动在bing.com的cookies里冒出来了，我们总是提取这个新的cookies，注入到web前端。

也算是，因为人机验证有显式和隐式之分。当隐式人机验证不通过的时候才会触发显式人机验证

还有更惊奇的，主要针对huggngface，简直就是微软的亲儿子，不需要登录用户的最新K/U/R，普通匿名的完整cookie在huggingface上也几乎不用验证，觉得起作用的是最新的M/R值和SRCHHPGUSR。匿名限制时完全清除浏览器缓存后会产生新的一组cookie，就又可以使用了。

b1ghawk · 2023-12-13T01:06:19Z

也可能有一些不同。
cn.bing.com和www.bing.com上的旧的K/U/R需要通过人机验证才可以重复使用。
cn.bing.com和www.bing.com上的最新K/U/R总是不触发人机。
最新产生的K/U/R的获取成本很低，不断刷新bing.com页面(当然频率也不要太高吧...)，在旧的K/U/R被标记为"需要进行人机验证"时，新的可用的K/U/R就会自动在bing.com的cookies里冒出来了，我们总是提取这个新的cookies，注入到web前端。

也算是，因为人机验证有显式和隐式之分。当隐式人机验证不通过的时候才会触发显式人机验证

还有更惊奇的，主要针对huggngface，简直就是微软的亲儿子，不需要登录用户的最新K/U/R，普通匿名的完整cookie在huggingface上也几乎不用验证，觉得起作用的是最新的M/R值和SRCHHPGUSR。匿名限制时完全清除浏览器缓存后会产生新的一组cookie，就又可以使用了。

话说，匿名的cookies在非huggingface项目上可以使用吗？
我是指我们的那个自动过验证的版本。

以前在别的地方部署的话，匿名会无限跳验证，而且验证无法通过。

现在是不是可以任意云服务商上实现匿名了？(因为已经可以自动过验证了)。

↑我没试过，因为我一直稳定使用hugging face的匿名(在自动过验证被研究出来之前和之后，我都在使用hugging face)，你尝试过其它服务商现能匿名了吗(使用自动过验证的版本)。

SokWith · 2023-12-13T02:06:23Z

也可能有一些不同。
cn.bing.com和www.bing.com上的旧的K/U/R需要通过人机验证才可以重复使用。
cn.bing.com和www.bing.com上的最新K/U/R总是不触发人机。
最新产生的K/U/R的获取成本很低，不断刷新bing.com页面(当然频率也不要太高吧...)，在旧的K/U/R被标记为"需要进行人机验证"时，新的可用的K/U/R就会自动在bing.com的cookies里冒出来了，我们总是提取这个新的cookies，注入到web前端。

也算是，因为人机验证有显式和隐式之分。当隐式人机验证不通过的时候才会触发显式人机验证

还有更惊奇的，主要针对huggngface，简直就是微软的亲儿子，不需要登录用户的最新K/U/R，普通匿名的完整cookie在huggingface上也几乎不用验证，觉得起作用的是最新的M/R值和SRCHHPGUSR。匿名限制时完全清除浏览器缓存后会产生新的一组cookie，就又可以使用了。

话说，匿名的cookies在非huggingface项目上可以使用吗？我是指我们的那个自动过验证的版本。

以前在别的地方部署的话，匿名会无限跳验证，而且验证无法通过。

现在是不是可以任意云服务商上实现匿名了？(因为已经可以自动过验证了)。

↑我没试过，因为我一直稳定使用hugging face的匿名(在自动过验证被研究出来之前和之后，我都在使用hugging face)，你尝试过其它服务商现能匿名了吗(使用自动过验证的版本)。

这个套娃部署就是解决在其他地方部署过验证用的。只要套了能够过验证的服务器，就继承了过验证的能力。所以，理论上还是存在单点故障，必须依靠搭建在cf上的过验证服务器，纯属脱裤子放屁了。

但为了这个漏洞利用能够活得更久一点，是不得已的办法。

b1ghawk · 2023-12-13T02:13:06Z

也可能有一些不同。
cn.bing.com和www.bing.com上的旧的K/U/R需要通过人机验证才可以重复使用。
cn.bing.com和www.bing.com上的最新K/U/R总是不触发人机。
最新产生的K/U/R的获取成本很低，不断刷新bing.com页面(当然频率也不要太高吧...)，在旧的K/U/R被标记为"需要进行人机验证"时，新的可用的K/U/R就会自动在bing.com的cookies里冒出来了，我们总是提取这个新的cookies，注入到web前端。

也算是，因为人机验证有显式和隐式之分。当隐式人机验证不通过的时候才会触发显式人机验证

还有更惊奇的，主要针对huggngface，简直就是微软的亲儿子，不需要登录用户的最新K/U/R，普通匿名的完整cookie在huggingface上也几乎不用验证，觉得起作用的是最新的M/R值和SRCHHPGUSR。匿名限制时完全清除浏览器缓存后会产生新的一组cookie，就又可以使用了。

话说，匿名的cookies在非huggingface项目上可以使用吗？我是指我们的那个自动过验证的版本。

以前在别的地方部署的话，匿名会无限跳验证，而且验证无法通过。

现在是不是可以任意云服务商上实现匿名了？(因为已经可以自动过验证了)。

↑我没试过，因为我一直稳定使用hugging face的匿名(在自动过验证被研究出来之前和之后，我都在使用hugging face)，你尝试过其它服务商现能匿名了吗(使用自动过验证的版本)。

这个套娃部署就是解决在其他地方部署过验证用的。只要套了能够过验证的服务器，就继承了过验证的能力。所以，理论上还是存在单点故障，必须依靠搭建在cf上的过验证服务器，纯属脱裤子放屁了。

但为了这个漏洞利用能够活得更久一点，是不得已的办法。

huggingface触发隐式验证对吧。
或者说，只有huggingface可以通过验证(在白嫖的前提条件上)？

SokWith · 2023-12-13T02:33:32Z

也可能有一些不同。
cn.bing.com和www.bing.com上的旧的K/U/R需要通过人机验证才可以重复使用。
cn.bing.com和www.bing.com上的最新K/U/R总是不触发人机。
最新产生的K/U/R的获取成本很低，不断刷新bing.com页面(当然频率也不要太高吧...)，在旧的K/U/R被标记为"需要进行人机验证"时，新的可用的K/U/R就会自动在bing.com的cookies里冒出来了，我们总是提取这个新的cookies，注入到web前端。

也算是，因为人机验证有显式和隐式之分。当隐式人机验证不通过的时候才会触发显式人机验证

还有更惊奇的，主要针对huggngface，简直就是微软的亲儿子，不需要登录用户的最新K/U/R，普通匿名的完整cookie在huggingface上也几乎不用验证，觉得起作用的是最新的M/R值和SRCHHPGUSR。匿名限制时完全清除浏览器缓存后会产生新的一组cookie，就又可以使用了。

话说，匿名的cookies在非huggingface项目上可以使用吗？我是指我们的那个自动过验证的版本。
以前在别的地方部署的话，匿名会无限跳验证，而且验证无法通过。
现在是不是可以任意云服务商上实现匿名了？(因为已经可以自动过验证了)。
↑我没试过，因为我一直稳定使用hugging face的匿名(在自动过验证被研究出来之前和之后，我都在使用hugging face)，你尝试过其它服务商现能匿名了吗(使用自动过验证的版本)。

这个套娃部署就是解决在其他地方部署过验证用的。只要套了能够过验证的服务器，就继承了过验证的能力。所以，理论上还是存在单点故障，必须依靠搭建在cf上的过验证服务器，纯属脱裤子放屁了。

但为了这个漏洞利用能够活得更久一点，是不得已的办法。

huggingface触发隐式验证对吧。或者说，只有huggingface可以通过验证(在白嫖的前提条件上)？

套娃的方式可以任意部署，我已经验证过了 huggingface，zeabur，replit，vercel等云商；

至于上面推送最新cookie的方式，目前还必须是微软亲儿子huggingface才最好使，但它也经常抽疯。

SokWith · 2024-05-18T03:11:19Z

#276 (comment)

发在另外一个贴里面了，应该在这

SokWith changed the title ~~【提醒】在huggingface部署时要注意端口PORT设置~~ 【提醒】内置PROXY套娃代理部署说明 Nov 29, 2023

SokWith mentioned this issue Nov 29, 2023

is:issue is:open 一直转圈！！！！443开着的 adams549659584/go-proxy-bingai#409

Open

b1ghawk mentioned this issue Dec 13, 2023

[Help] 🤔 有谁知道如何让Hugging Face上的部署定时重启？ #201

Closed

b1ghawk mentioned this issue Dec 14, 2023

[证实无效，请勿尝试] 🌈 免费Cookies推送服务器搭建教程。 #273

Closed

SokWith closed this as completed Dec 23, 2023

This was referenced Dec 23, 2023

[Feature] 🌈 近期的改善点暨隐匿拉取服务器设置 #276

Closed

发现官方wss可用了 #275

Closed

SokWith mentioned this issue Jun 8, 2024

请问如何使用它？ SokWith/setpushcookie#1

Open

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

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

Comments

SokWith commented Nov 28, 2023 • edited Loading

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

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

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

SokWith commented Nov 29, 2023 • edited Loading

SokWith commented Nov 30, 2023 • edited Loading

SokWith commented Nov 30, 2023 • edited Loading

b1ghawk commented Dec 1, 2023

SokWith commented Dec 1, 2023 • edited Loading

SokWith commented Dec 1, 2023

Harry-zklcdc commented Dec 1, 2023

SokWith commented Dec 2, 2023 • edited Loading

SokWith commented Dec 2, 2023

Harry-zklcdc commented Dec 4, 2023

SokWith commented Dec 4, 2023

SokWith commented Dec 4, 2023

Harry-zklcdc commented Dec 4, 2023

SokWith commented Dec 4, 2023 • edited Loading

b1ghawk commented Dec 4, 2023 • edited Loading

SokWith commented Dec 5, 2023

b1ghawk commented Dec 5, 2023

SokWith commented Dec 5, 2023

b1ghawk commented Dec 5, 2023

SokWith commented Dec 5, 2023

b1ghawk commented Dec 5, 2023 • edited Loading

SokWith commented Dec 5, 2023

b1ghawk commented Dec 5, 2023

SokWith commented Dec 5, 2023

b1ghawk commented Dec 5, 2023 • edited Loading

SokWith commented Dec 5, 2023

SokWith commented Dec 5, 2023

b1ghawk commented Dec 5, 2023 • edited Loading

b1ghawk commented Dec 12, 2023

SokWith commented Dec 12, 2023

SokWith commented Dec 12, 2023

b1ghawk commented Dec 12, 2023

b1ghawk commented Dec 12, 2023

b1ghawk commented Dec 12, 2023 • edited Loading

SokWith commented Dec 12, 2023

b1ghawk commented Dec 12, 2023 • edited Loading

Step.1 Cookie项目的部署：

Step.2 推送服务器的搭建：

Step.3 go-proxy-bingai项目的改造：

Step.4 至此，你的go-proxy-bingai项目就可以不间断地获取到最新的不需要进行人机验证的cookies了。

b1ghawk commented Dec 12, 2023 • edited Loading

SokWith commented Dec 12, 2023 • edited Loading

b1ghawk commented Dec 12, 2023

SokWith commented Dec 12, 2023

SokWith commented Dec 12, 2023

Harry-zklcdc commented Dec 12, 2023

b1ghawk commented Dec 12, 2023 • edited Loading

b1ghawk commented Dec 12, 2023 • edited Loading

Harry-zklcdc commented Dec 12, 2023

SokWith commented Dec 13, 2023 • edited Loading

SokWith commented Dec 13, 2023

b1ghawk commented Dec 13, 2023 • edited Loading

SokWith commented Dec 13, 2023

但为了这个漏洞利用能够活得更久一点，是不得已的办法。

b1ghawk commented Dec 13, 2023 • edited Loading

但为了这个漏洞利用能够活得更久一点，是不得已的办法。

SokWith commented Dec 13, 2023

但为了这个漏洞利用能够活得更久一点，是不得已的办法。

SokWith commented May 18, 2024

SokWith commented Nov 28, 2023 •

edited

Loading

SokWith commented Nov 29, 2023 •

edited

Loading

SokWith commented Nov 30, 2023 •

edited

Loading

SokWith commented Nov 30, 2023 •

edited

Loading

SokWith commented Dec 1, 2023 •

edited

Loading

SokWith commented Dec 2, 2023 •

edited

Loading

SokWith commented Dec 4, 2023 •

edited

Loading

b1ghawk commented Dec 4, 2023 •

edited

Loading

b1ghawk commented Dec 5, 2023 •

edited

Loading

b1ghawk commented Dec 5, 2023 •

edited

Loading

b1ghawk commented Dec 5, 2023 •

edited

Loading

b1ghawk commented Dec 12, 2023 •

edited

Loading

b1ghawk commented Dec 12, 2023 •

edited

Loading

b1ghawk commented Dec 12, 2023 •

edited

Loading

SokWith commented Dec 12, 2023 •

edited

Loading

b1ghawk commented Dec 12, 2023 •

edited

Loading

b1ghawk commented Dec 12, 2023 •

edited

Loading

SokWith commented Dec 13, 2023 •

edited

Loading

b1ghawk commented Dec 13, 2023 •

edited

Loading

b1ghawk commented Dec 13, 2023 •

edited

Loading