Xray 加载多个 链式代理 配置文件 多inbound 多outbound 一对一 本地提供Socks端口

点击标签看相关主题:

上回说到, 我们实现了在v2rayN中设置下一跳Socks端口, 这样可以进行链式代理, 救被墙的落地节点.

如果是工作需要, 要同时开好多个链式代理的话, 就要开好多个v2rayN, 有点麻烦.


正好, 最近Xray更新了特性, 可以加载多个配置文件合并入站 合并出站.

那么我们顺势而为, 把路由规则也合并了.

* 这个修改比较草率, 适用于解决本文的需求, 但对于广大Xray使用者的各种场景, 处理得未必妥当, 所以没有提交主线PR. 


再加上 v2rayN-VLESS 小改一下, 配置文件里明确指定inbound和outbound的routing关系.


条件就都齐全了.


具体实践

(1) 下载 v2rayN-VLESS v3.29.0.7 

保存两份, 一个是隧道, 一个是落地.

* 如果你明白如何用其它软件在本地搭一个Socks端口作为隧道的话, 那就按你的方法搭隧道. 落地节点一定要用 v2rayN-VLESS v3.29.0.7 


(2) 把你的链式代理设置好, 测试正确.

略.  参考以前的教程和视频.


(3) 落地节点右键菜单导出客户端配置(.json文件)

找个新目录存放. 不要放其它东西.


(4) 修改落地节点配置文件(.json文件)

把 inbound outbound rules 里的 tag 改成唯一的, 不会与其它配置文件重复的.

比如, 我就在后面加上端口号. 


(5) 关闭落地节点v2rayN


(6) 得到 Xray-routing-rule-override 

可以照教程自己修改自己编译.

也可以下载我编译的成品.

放到 落地节点配置文件目录 (第3步的目录)


(7) 带参数运行 Xray-routing-rule-override 

.\xray.exe run -confdir .

* 这一整行看仔细了, 不要少了参数!


(8) 按你原来的方法使用本地Socks端口

好了, 你原来怎么使用这些Socks端口的, 就怎么使用. 运行这一个 xray.exe 相当于原来跑好多个v2rayN了.


操作视频


========

Update

在 v2rayN-VLESS-v3.29.0.12 中, 把多选测速的配置文件保存出来了. 可以直接用内核加载.

https://zelikk.blogspot.com/2024/11/v2rayn-vless-xray-httpinbound-outbound.html


评论

发表评论

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 »