v2ranN-VLESS-HY2 支持 Reality 协议与 Hysteria2 协议节点并存
需求
v2ranN-VLESS 支持了 reality, 基于 xray 内核
v2ranN-HY2 支持了 hy2, 基于 v2ray 内核
reality和hy2都好用, 都需要.
我是在VPS上同时部署了多个协议的(只要用不同的端口, 不冲突就可以了).
在客户端, 我可不想为了换个协议用用, 就要关个软件再开个软件.
那么, 就要在 v2rayn.exe 的目录下同时放 xray.exe 和 v2ray.exe 然后要根据不同的协议来调用不同的内核.
分析
我们先来看看目前的代码逻辑是怎样的.
根据之前的开发经验, 我们知道, 启动内核是在 V2rayHandler 模块的 V2rayStart 函数 里的 p.Start ()
倒着走读代码, 发现 V2rayFindexe 函数是用来判断启动哪个内核程序的.
在 lstV2ray 这个列表中取字符串出来, 再拼上 .exe 的后缀, 然后看当前目录有没有这样的文件存在.
而这个 lstV2ray 列表呢. 存着这些.
也就是说, v2rayN 3.29 的原始逻辑是, 当前目录下, 这3个内核的文件, 找到哪个就启动哪个.
那么, 我们要做的是:
建一个"全局"变量, 用于保存 指定的内核程序名称.
在启动内核之前, 要先根据使用的协议来判断是否需要指定内核程序名称.
实践
添加 模板内"全局"的变量
而这个新增的 SetCoreExeByConfig 函数的实现呢. 就是根据节点信息里的特定属性, 判断是否reality协议, 是否hy2协议.
最后一个修改, 在查找内核程序的函数 V2rayFindexe 中,
原来的逻辑是遍历 { "xray", "wv2ray", "v2ray"} 这个列表.
现在修改为, 先构造一个列表. 规则是:
如果指定了内核, 那么列表中只有这个内核程序.
如果没有指定内核, 那么列表和原来的逻辑保持一致, 就是 { "xray", "wv2ray", "v2ray"}
好了, 跑起来测试一下.
主窗口里, 不管是放 reality 还是 hy2 都是正常的. 激活节点和测试节点都正常.
进一步测试, 主窗口里放一个 realiy 再加一个 hy2.
唉, 测试就出问题了. 哪个节点放上面, 激活 或 测试的时候就用那个节点的内核.
激活 或 测试下面那个节点, 用的内核就不对.
检视一下代码.
v2rayN 软件的配置信息 V2rayNappConfig 中, 节点服务器信息 outbound 是个列表. 你在主窗口放了多少节点, 这个列表中就有多少个元素.
我们刚刚的修改, 是使用这个列表中的第1个元素, 也就是窗口中最顶上的节点. 来判断应该使用哪个内核.
进一步的, v2rayN 软件的配置信息 V2rayNappConfig 中, 当前主窗口上激活了哪个节点, 是 index 这个变量.
所以, "设为活动服务器" 的功能, 最后启动内核之前, 加个判断内核的函数调用.
我们修改为
SetCoreExeByConfig( appConfig.outbound[ appConfig.index] );
而, 测速功能. 我们分析一下, _selecteds 是个列表, 表示 当前选择了哪些节点来测试.
我们修改为
SetCoreExeByConfig( appConfig.outbound[ _selecteds[0] ]);
意思是, 从选择的节点列表中, 选择第1个, 再传到 SetCoreExeByConfig 函数中去判断内核.
当然, 从这样的处理方式, 可以想到, 如果我们测试节点时, 同时选择了 reality 和 hy2, 肯定会出错.
我觉得, 我们做到目前这一步差不多可以了. 如果要进一步改下去, 解决同时选择 reality 和 hy2 的情况, 付出的代价和收获的好处不匹配了.
多说一句, v2rayN 原本的处理方式是怎样的.
如果测速的时候同时选择了多个节点.
在生成 json配置文本的时候, 会生成多个 http 代理的inbound, 当然你选择的那些节点也生成 outbound了.
然后生成很多个 路由规则 把这些http的inbound和要测试的节点的outbound 一一对应起来.
然后启动一个内核, 加载这些 inbound, outbound, 路由规则.
然后再用这些http代理的inbound, 一个一个去访问测试URL.
========
开了一个分支, 本文的修改内容已提交.
如果你有兴趣, 可以看到整个的开发过程.本次代码修改记录
打包发布在此
评论
发表评论