编译 Xray 遇到 gvisor 报错 通过 Github Codespaces 下载模块 修改编译环境 指定模块路径

点击标签看相关主题:

之前自己手动编译Xray没遇到啥问题.

但今天重施故伎时发现报错.

看上去是没有成功下载 gvisor 模块


根据一些资料和telegram群友的指点, 设置了 GOPROXY

export GOPROXY=https://proxy.golang.org,direct

还是报一样的错.


在Google上猛地搜索一翻, 找到一篇文

https://medium.com/@carolegibbs007/我是如何解决xray编译-invalid-version-unknown-revision-1f7806d17489-错误的-51d5754bee6a

用他的思路解决了问题. 

记录一下详细操作, 如下.


打开 Xray 的 Github Repo 

https://github.com/XTLS/Xray-core

进入Github Codespaces

* 注意, 你需要登录 Github 账户才能用这个 Codespaces 功能.

执行编译命令, 一是检测能否编译成功, 二是在编译过程中下载了依赖的模块 (其中就包括了gvisor模块)

go build -o xray -trimpath -ldflags "-s -w -buildid=" ./main


ls 检查一下是否编译成功


find 命令找一下 gvisor 模块的位置

 find / -name "*1f7806d17489*"

其中 1f7806d17489 是来自于目标模块的版本(tag)的一部分


得到 gvisor 模块的位置结果


进入 .zip 文件所在目录

cd /go/pkg/mod/cache/download/gvisor.dev/gvisor/@v/

开一个http服务

python3 -m http.server 8000

弹出的窗口中选择 "Open in Browser" 按钮


会打开一个新的tab页 (访问这个http服务)

点击 .zip 文件下载.


到此, 我们拿到了 gvisor.dev/gvisor/@v/v0.0.0-20231202080848-1f7806d17489.zip 的包


回到本来的编译 Xray 的环境, 上传刚拿到的 gvisor 模块的zip包, 并解压.

想放什么位置随便你, 我这里举例为下面的目录:

/home/ubuntu/gvisor.dev/gvisor@v0.0.0-20231202080848-1f7806d17489


修改编译环境 指定模块路径

go mod edit -replace 指定的模块=本地路径

go mod edit -replace gvisor.dev/gvisor@v0.0.0-20231202080848-1f7806d17489=/home/ubuntu/gvisor.dev/gvisor@v0.0.0-20231202080848-1f7806d17489

指定的模块就是之前报错的

然后再编译, 就成功了.



========

完

评论

发表评论

The Hot3 in Last 30 Days

用浏览器 检测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 »