在Replit上跑cloudflare的workers脚本 运行gh-proxy 墙内VPS访问GITHUB资源

之前为了解决访问github资源的问题, 在cloudflare的worker上面搭了一个ghproxy. 

而workers.dev域名被墙了, 如果没有自己的域名的话, 没办法用自定义路由的方式. 

现在有一些免费域名和便宜的域名 

除此之外, 我们还可以利用Replit域名没有被墙, 搭建ghproxy.


注册Replit

https://replit.com/

略.


Cloudflare的Worker的模板

https://replit.com/@Cloudflare/Cloudflare-Workers



初始化环境

点击 Run 按钮


过程中都直接回车默认就好


部署Worker环境

再点击 Run 按钮


过程中直接回车默认就好


如果看到这样的结果, 说明前面的操作都是OK的.



使用自己的Worker脚本内容

打开 src/index.ts, 里面的内容全部删掉.


换成自己的 js 脚本内容.

比如, 换成 https://github.com/crazypeace/gh-proxy/blob/master/worker.js 的内容.


项目重启

点 Stop, 再点 Run.



如果看到 web 框里面显示正确就OK了.



把域名拿到浏览器里面, 不翻墙访问试试. 功能也是正常的.

https://ghproxy.crazypeace.repl.co/

https://ghproxy--crazypeace.repl.co/


此时, 在命令行中使用, 功能也是正常的. 比如,
bash <(curl -L https://ghproxy.crazypeace.repl.co/https://github.com/crazypeace/warp.sh/raw/main/warp.sh)
bash <(curl -L https://ghproxy--crazypeace.repl.co/https://github.com/crazypeace/warp.sh/raw/main/warp.sh)


===========

后记

需要注意的是, .repl.co 域名只有 IPV4的解析, 也就是说这个方案可以用于在墙内的IPV4机器上访问GITHUB资源, 不可以用于在纯IPV6机器上访问GITHUB资源.

过段时间 Replit 项目会自己休眠, 之后不管是通过浏览器访问网页, 还是丢到命令行里当ghproxy使用, 第一次都会异常. 等几秒钟再重复执行一次, 结果就正常了. 如果开着Replit后台能很清楚地看到这个启动的过程.


===========

update

经过时间比较长之后再访问 Replit 搭建的 gh-proxy, 会发现一直卡住.

登录 Replit 后台一看, 已经启动了, 但是卡在这个提问的步骤.


读 Readme.md, 里面写了设置的方法

在左边工具栏里展开 Tools, 点击 Secrets


在右边的窗口里添加一个Secret, Key为WRANGLER_SEND_METRICS, Value为true或者false都可以.


再试试. 过比较久之后 访问网页或者命令行调用, 第一次会失败, 等几秒钟之后 重试, 功能就正常了.


评论

发表评论

The Hot3 in Last 30 Days

用darkstat统计VPS上的流量

图片
感谢 https://0x3f.org/posts/darkstat-as-a-network-discharge-meter/ https://ilovn.com/2023/03/25/darkstat/ 安装 apt install -y darkstat 启用 darkstat -i 监听网卡 -p 网页端的端口号 如 darkstat -i eth0 -p 8964 页面端查看 http:// 你的vps的IP : 网页端的端口号 如 http:// 12.34.56.78 : 8964 效果类似下面这样 点 host 可以看到数字表格的统计信息. 点其中一条 可以看到更详细的信息. 能看到在本VPS上, 还有指定IP上, 分别用到了什么端口(包括TCP UDP), 以及分别跑了多少流量. 如果你有有更好的工具, 欢迎留言分享!
Read more »

用浏览器 检测Reality伪装效果 是否搭建成功 排错Troubleshoot

图片
Reality的原理: 当 Reality 节点收到数据包的时候, 如果 Reality 协议的验证通过, 就走节点的翻墙逻辑; 如果 Reality 协议的验证不通过, 就把数据包转发到伪装站. 后续的整个交互过程就像是在和伪装站交互一样. 我们可以简单地用浏览器验证 Reality 伪装效果. 也相当于检测 从你自己到 Reality 节点之间的数据通路是否畅通. 以这样的一个 Reality 节点为例. IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.237.9   然后在浏览器中, 访问 https://learn.microsoft.com: 18255 可以看到, TLS的锁是正常的. 验证证书, 也是正常的. 从你自己到Reality节点的数据路径是畅通的之后, 如果你的节点还不能用, 那么, 就应该检查你的Reality节点验证信息了 (UUID, 公钥) ======== update 如果是用了中转后的 Reality 节点 原 Reality 节点 IP  142.171.237.9 端口  18255 伪装站 learn.microsoft.com 中转 VPS  IP 142.171.223.56 端口 28828 那么, 在电脑的hosts文件中, 设置 learn.microsoft.com 解析的IP 为  142.171.223.56 然后在浏览器中, 访问 https://learn.microsoft.com: 28828 可以看到, TLS的锁是正常的. 验证证书, 也是正常的.
Read more »

233 sing-box 脚本 TCP 端口转发 Reality 协议 排错 Troubleshoot

图片
233 boy 的 TCP 端口转发的教程 https://233boy.com/sing-box/sing-box-direct/ 下图中示意, 左边的 142.171.237.9 是被墙的VPS, 右边的 142.171.223.56 是用来做端口中转的VPS. 如果你照着教程操作一遍, 发现不能正常使用. 那么本文指导你如何排查问题所在. ======== 首先, 你要理解整个原理是什么. 左边的, 本来的reality协议节点, 底层是TCP直连, 那么是从你的 翻墙客户端(手机/电脑/...) 去连接  142.171.237.9  的 18255 端口. 现在被墙了, 那么无法直接TCP连接了. 右边的, 用于中转的VPS, 设置的 TCP端口中转 的本质是,  142.171.223.56  从端口 28828 收到的TCP数据, 会转发给  142.171.237.9  的 18255 端口.  所以, 你现在可以把本来准备发送给  142.171.237.9  的  18255  端口 的realiy数据包, 发送给  142.171.223.56  的  28828  端口; 142.171.223.56  从端口  28828  收到的TCP数据, 转发给  142.171.237.9  的  18255  端口. ======== 我们延着数据路径一段一段的排查. 1. 从我们的翻墙客户端(手机/电脑/...)连接中转VPS  142.171.223.56  的  28828  端口; a) 可以用 tcp.ping.pe 检测 142.171.223.56  的  28828  端口是否正常; b) 在你自己的电脑  tcping 检测 142.171.223.56  的  28828  端口是否可连接. 2. 在中转VPS上查 sing-box 的 access.log cat /var/log/sing...
Read more »