v2rayN-3.29-VLESS 生成配置文件 Xray链式代理 多http代理inbound 多落地节点outbound 一对一 隧道节点方便切换

点击标签看相关主题:
之前 做了一个Xray 加载多个 链式代理 配置文件 多inbound 多outbound 一对一方案, 要一个一个导出客户端配置文件, 还要修改 inbound 和 outbound 的 tag.
最终把多个配置文件放在同一个目录, 启动xray内核, 会合并所有配置文件的 inbound 和 outbound, 以及路由规则, 这样保证 inbound 和 outbound 一一对应.
整个过程还是有点麻烦的.

最近给 v2rayN-VLESS 开发 HY2 支持, 在处理 Reality 协议与 Hysteria2 协议节点并存 时, 走读代码的逻辑. 发现
如果多选了节点, 再用测速功能, 会先生成配置数据. 这个配置数据包含以下内容:
1. 在生成配置的时候, 会生成多个 http 代理的inbound.
2. 将你选择的那些节点也生成 outbound.
3. 生成很多个 路由规则  把这些http代理的inbound和要测试的节点的outbound 一一对应起来.
然后启动一个内核, 加载这个配置, 也就是包括了 上述这些 inbound, outbound, 路由规则.
然后再用这些inbound的http代理, 一个一个去访问测试URL, 也就一一测试了 outbound表示的节点.

那么我多想一步, 如果我们把这个配置数据用json文件保存出来. 自己另外用个裸内核加载跑起来, 不就是我们之前想达到的功能吗?
而且本来设置的下一跳socks5设置也保存, 方便你将一批落地节点套上隧道 加速.

在 GenerateClientSpeedtestConfigString 函数, 把生成的配置文本保存出来就行了.

那么, 实现原来这篇文 一个Xray 加载多个 链式代理 配置文件 多inbound 多outbound 一对一方案 的目的, 工作流程更新为:
在v2rayN (1)中添加隧道节点
在v2rayN (2)中添加全部落地节点
在v2rayN (2)中设置下一跳Socks5 为 v2rayN (1) 的监听Socks端口
在v2rayN (2)中 全选节点, Ctrl + R 测试真连接延迟. 此时, 会生成 testconfig.json 配置文件
在v2rayN (2)目录中, 命令行启动内核, 加载 testconfig.json 配置文件

testconfig.json 配置文件为每个落地节点设置了一个http代理端口.

你自己要用指纹浏览器, 或是其它软件的, 设置http代理为对应的端口就好了.

在这个方案中, 单独有一个v2rayN管理隧道节点, 切换会很方便. 如果你用的是便宜的隧道方案的话, 有可能会更需要维护?

如果你要共享代理给局域网的同事使用, 在testconfig.json中查找替换, 把 "listen": "127.0.0.1" 的前面加上 // 注释掉.

操作演示视频 


========

评论

发表评论

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 »

用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 »

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 »