理论上这个项目是可以部署在 cloudflare snippets

[devxiaopo]

如果能好好压缩 限制在 32kb 那么就可以部署在 cloudflare snippets
(优点：不产生 Worker 请求，支持大量使用 :/ 主要是无限流量 没有限制)
(主要太多注释了 注释删掉 再改改就可以用:/)
cloudflare snippets 很显然就是一个轻量级的workers
free 计划默认 没有 但是呢 一些用户域名是内测 也许可以好好利用这个 ?

[tdsq369]

你的想法很棒 我觉得可以在宝塔 或者docker 上运行就更棒了 归根结底 这个功能还是很棒的 就是cf一直封锁 导致部署难度变高了

[1234567Yang]

理论上可以：https://www.uglifyjs.net/
然后把客户端注入的脚本改为 <script src="the_client_js_cdn"></script>
这样就可以实现压缩到32kb，但是不会特意去实现，原因有几点：

• 不方便发布，即使发布了，有压缩的代码，瓜田李下
• 不方便维护，需要单独维护服务器代码 和 注入代码
• cdn 需要自己设置，如果我提供统一的 cdn 还会成为特征
• 如果以后继续扩充代码，终究还需要更好的压缩方式

[1234567Yang]

你的想法很棒 我觉得可以在宝塔 或者 docker 上运行就更棒了 归根结底 这个功能还是很棒的 就是 cf 一直封锁 导致部署难度变高了

😭😭我不会 docker，有时间去研究一下。这个 issue 先开着供大家讨论。

[devxiaopo]

你的想法很棒 我觉得可以在宝塔 或者 docker 上运行就更棒了 归根结底 这个功能还是很棒的 就是 cf 一直封锁 导致部署难度变高了

😭😭我不会 docker，有时间去研究一下。这个 issue 先开着供大家讨论。

我觉得吧 你可以看看这个框架 hono.nodejs.cn 如果我想的没错的话 主要重点还是js 注入还有一些处理逻辑 如果就是想完整的实现 还有乱七八糟的 而且还要安全的话 我觉得还不如 https://holyunblocker.org/scramjet 我基本上大部分用这个的情况下都是 api 再或者就是 紧急访问 (byd又跑路了) 的时候 不过我用得比较多的还是 https://github.com/netptop/siteproxy 其实这个项目做它本身就可以了 cloudflare平台上的一个简单的网页代理

[1234567Yang]

我主要重点还是js 注入还有一些处理逻辑

是这样的，现在是见到啥能绕过的方法就修修补补，尽量把它完善。至于安全问题，全部传输都是TLS加密过的，这个没必要再画蛇添足。你说的那个框架实际上就是一个 worker 的实现，有时间我会去看看的（我比较倾向于用 cf workered）

至于我为什么要从头造轮子：

• 原作者把代码闭源了，别人根本没法贡献和审查代码，还特意清空了之前的 git 日志
• 原项目我很怀疑它的加密的有效性，它好像把密钥写死在字符串里面了，而且和我之前说的一样，都已经TLS加密传输了，没必要再加密一层。
• 自己学习一下这个思路，中间还遇到了好多邪门的网站写法，这是最离谱的
• 给大家多一个选择，也许我这个代理不行的他的代理可以，他的代理不行的我的代理可以。
• 尽量把部署方法越简化越好，没人喜欢读 requirements.txt，尤其是没有技术背景的。

[Tmalll]

伸手党表示, 有没有精简好的版本...

[Tmalll]

我改了一个版本... 目前 github能凑活用用

• https://github.com/Tmalll/My_Tools_Save/tree/main/07_CF_Snippets_URP

[mumuhaha487]

用AI写了一个（看看能不能用）

• https://github.com/mumuhaha487/cf-proxy-Snippets

把一些js分离了，上传到eo page上或者是其他静态托管网站就行。

[Tmalll]

用AI写了一个（看看能不能用）

• https://github.com/mumuhaha487/cf-proxy-Snippets

把一些js分离了，上传到eo page上或者是其他静态托管网站就行。

你可以试试上面我的那个版本，反代github和一些doh都还正常。

ps：你们说的这些注入是，是干什么的？

[1234567Yang]

ps：你们说的这些注入是，是干什么的？

比如你正常访问网址，链接是 /about/index。为了代理，会注入一个js，把/about/index转换为绝对路径，否则就加载不出来。

当然实际上更复杂，这只是最简单的比喻。

[netptop]

你好！ 作为siteproxy的作者，我来回答下你对siteproxy的一些问题：

至于我为什么要从头造轮子：

• 原作者把代码闭源了，别人根本没法贡献和审查代码，还特意清空了之前的 git 日志
• =》 这种在线代理最大的风险就是钓鱼网站，完全开源后， 用它很容易就构造一个找不到破绽的钓鱼网站。 这就是我为啥把代码混淆了，目的是给钓鱼增加难度。
• 原项目我很怀疑它的加密的有效性，它好像把密钥写死在字符串里面了，而且和我之前说的一样，都已经TLS加密传输了，没必要再加密一层。
• =》 TLS加密到proxy server就终止了，不是end2end, 作为proxy server是可以看到user的任何内容的，包括密码， 这个加密目的就是防止proxy server 观察用户密码。实际上也只是增加难度， 完全防止是不可能的。
• 自己学习一下这个思路，中间还遇到了好多邪门的网站写法，这是最离谱的
• =>不理解这个问题。
• 给大家多一个选择，也许我这个代理不行的他的代理可以，他的代理不行的我的代理可以。
• =》 当然欢迎。
• 尽量把部署方法越简化越好，没人喜欢读 requirements.txt，尤其是没有技术背景的。
• =》 现在ai这么发达， 我们完全可以要ai部署就行。

另外，这些问题完全可以在我的项目中提出来， 没有必要预先假定答案。

[1234567Yang]

TLS加密到proxy server就终止了，不是end2end, 作为proxy server是可以看到user的任何内容的

啊，我还以为这个只是从客户端到代理服务器这一段的。是我没认真研究，我向您道歉！

但是这样的话就有两个新问题：

• 我看着代码里面有写死的公钥私钥：

BEGIN\x20PRIVATE\x20KEY-----

按理说如果是这样的话，即使是e2e，由于泄露了私钥，是否也可以直接MITM解密？（但是我不太确定我的理解是否正确，当然了即使是这样，这也已经比我的实现安全得多）

• 关于e2e这段描述，我不大理解，如果您有时间的话，能否再详细讲解一下您的思路？我现在的猜想：如果是自己通过tcp构建https的请求的话，而且客户端到代理服务器这一段请求经过cf转发且流量不会被解密，是否会出现tls in tls的相关特征？

【[客户端 ----> CF Server]{ ----> 服务器}】

如果按照我的理解的话，[]和【】在客户端到代理服务器这一段是会被两个TLS包裹的？

自己学习一下这个思路，中间还遇到了好多邪门的网站写法，这是最离谱的

没，就逆向分析网站的时候发现了几个之前不知道的JS/html用法。

最后非常感谢您抽出时间来交流，让我理清了好多细节，安全意识非常强。同时我也对我之前的任何误解道歉，以后会多交流合作。