-
Notifications
You must be signed in to change notification settings - Fork 4.7k
VLESS protocol: Add Reverse Proxy (4) Command and extremely simple config #5101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
|
本来想着要不要把服务端改成默认允许开反向代理、同一个 UUID 即可使用,想想还是算了,原因有三:
|
|
the same old mux.cool reverse proxy, just simplified the configuration and limited to VLESS |
|
@gfw-killer 我说了这只是第一版,我也不觉得用 mux.cool 有什么不好的,你倒是说说存在什么问题?并且如果你看了“先前讨论”,就会知道更多的选项即将到来,mux.cool 本身也会在今年内的新版本中得到增强 |
|
@gfw-killer 就是说我觉得你颇有不满,所以你们这些人为什么就总是在提需求、一点都等不了?我又不是所有时间都拿来给你们开发这些东西,第一步把配置简化成这样就已经是进步了,此外 Xray-core 中的这些协议,还有 VLESS 不能覆盖的场景吗? |
There is nothing wrong with Mux.cool, but for Reverse it will be Mux in Mux for some transports, and as mux.cool in Reverse has no settings, it's a little hard to get the best performance
And I have not read the previous discussion yet, so I didn't knew about the process, sorry.
It will go off-topic if i answer it, but yeah, for a Relay (Port Forward / Reverse Port Forward) with a high traffic and low hw resources, there is a need for a lightweight Encryption or only a simple XOR. |
|
正常好人家谁用ray做反向代理,frp gost灵活功能强大 这玩意就是给伊朗特殊环境用的,他们在严管期限制境内发起的tcp连接带宽 私以为不值得为他们三秒钟制定的奇葩策略花什么精力 这种随心所欲的管控策略不知道什么时候就变动 而且frp gost在最外层完全能满足他们需求,毕竟他们明文面板都不怕。又何必在意frp们的tit |
|
测试发现我这完全靠想写出来的代码只需改了
|
This comment was marked as outdated.
This comment was marked as outdated.
|
When the goal is only to obfuscate, a simple XOR will do the job faster than anything with the lowest possible hw usage some ISPs limit even TLS from user to domestic servers, everyone found out the best performance is for RAW TCP HTTP-Header with no TLS, so everyone is using it for user to domestic relay I am not asking you to support it, just mentioned it as a scenario
Sometimes they work for years, specially the customizable ones like Freedom-Noises |
This comment was marked as outdated.
This comment was marked as outdated.
|
@gfw-killer Freedom-Noises 与其它小 tricks 有本质区别,因为 GFW 的算力难以分析每个 UDP 包,但封其它方法的成本很低
如果你使用 Xray-core 的 VLESS Encryption 加上 RAW 传输层的 HTTP-Header,对被代理的 TLSv1.3 并不会二次加解密 |
|
@Yochee 肯定不是硬编码的啊,只是示例,可以自定义 |
|
内网端可以设 CDN 等多条冗余线路均为 这也是 Xray-core / VLESS 做反向代理 / 内网穿透的优势之一,至于哪条线路更优先等设置,先看看用的人多不多吧 |
|
@Yochee 我在 #5101 (comment) 的表述有亿点小问题,因为当时我还没检查服务端 Vision 是否兼容它,你当时测试不能用只是因为没改 |
老版本并没有线路冗余一说,要在内网端手动修改出站才能切换线路,优点是公网端提前配置好几个入站(比如直连、cdn)后就不需要任何修改。如果新版想支持线路冗余,那公网端多个入站配置成相同tag的reverse出站就会有路由问题,可能要的不是优先级设置,而是类似连通性检测或者fallback设置 |
|
@Yochee 不会有路由问题,公网端多个入站 reverse tag 相同也只会产生一个出站,目前是多条线路同时存在、每次使用随机选择 所以说如果用的人多的话,我会加一些策略来控制这种随机,比如优先用哪个线路,或按比例分配流量,或动态监测并分配流量 |
|
@Yochee 现在有的功能是,假如某个线路不通了,比如说内网端没连上来,可用池中就不会有这条线路,流量会自动走其它线路 |
|
昨日群里一些补充性讨论:(
|
|
在这个简化配置出来前,我就已经使用XRay的反向代理好几年的时间了。 |
|
Please continue to support the old style reverse proxy for some time so we can migrate safely |
|
Hello! Initial data: I ask for help in solving the problem. |
|
12f4a01 VLESS Reverse Proxy 默认加了传递公网端的 Source & Local (IP & port) 到内网端,内网端可以在路由等处匹配它们,并且内网端的 Direct 出站设置发送 PROXY protocol 即可把它们传递至最终的应用程序比如 Nginx, 经测试没啥问题,双端升级至 Xray-core v25.10.15+ 默认启用,可以看到双端 log 中的 "from xxx" 已同步,三点注意事项:
下个版本会出个选项以解决第三点,当然如果你公网端是纯粹 Tunnel 入站的话就没有第三点的问题,也不会出现第二点的情况 |
|
Thank you for your hard work! |
|
因为这是vision的问题啊。。 #5189 |
@RPRX 您好,我有一个问题想咨询一下,不知您是否可以给予解答 设置好配置文件后如何访问内网的服务? {
// 转发到网页服务器
"tag": "out",
"protocol": "freedom",
"settings": {
"redirect": "127.0.0.1:80"
}
}是否可以认为在公网端和内网端的reverseObject里面添加一个 {
// 从 portal 过来的流量,也会从 bridge 出来,但是不带上面的domain
// 则路由到 out,即转发给网页服务器
"type": "field",
"inboundTag": ["r-inbound"],
"outboundTag": "out"
}这样之后就可以通过reverse-proxy.xray.internal域名来访问内网的网页服务了? |
|
@R3pl4c3r 你弄混了,这和旧版 reverse 配置没有任何关系,@Fangliding 把旧版文档删了吧, 你公网端把流量路由到 r-outbound 出站,会跑到内网端的 r-inbound 入站,其它的该咋写就咋写 |
@RPRX 我把原始内网客户端配置的direct后面加了一个 "settings": {
"redirect": "127.0.0.1:8000"
}就好了,我一会补充一下文档把 |
|
相比各位大神,本人确实小白,因为正好有反代需求,所以想询问一下: |
@zeratulyxl reverse部分不用管,你想怎么操作就在routing里面写就行了。比如按照上面的例子就是把全部流量发到内网端,内网端走直连。那么你可以有以下三种方法来控制:一是在你的xray公网客户端自定义代理部分内网IP,因为正常是跳过走直连,代理后这部分内网请求会发到你的内网端处理,这样就相当于你直接通过VPN回家了一样。二是你在公网服务端的routing里面规定只代理部分内网流量,这样你的正常流量是直接在服务端发出,内网请求发到内网端处理,相当于服务器既可以翻墙也同时反代。三是不通过xray客户端连接公网端,公网端使用tunnel协议,把访问tunnel协议监听的所有流量转发会内网端,这个时候需要在内网端的direct出口添加redirect目标(当然你也可以选择在routing里面写,只不过没这么方便),这样就可以做到正常frp那样访问公网端的某个端口被转发为内网的某个地址。你如果想要玩明白反向代理那么需要你吃透routing部分的文档 https://xtls.github.io/config/routing.html#ruleobject |
|
感谢回复,还不是十分明白,我会学习和尝试配置一下。对于极简配置,结合你的解答,我的理解:配置里for user这个部分,使用xray配置连接上,对应你所说的第一个方法,相当于vpn。配置里tunnel这个部分,公网可以直接开,对应第三个方法,但是因为没有配置redirect目标,所以还不能实际连接。 |
先前讨论:#5088 (comment)
反向代理(内网穿透),第一版先复用现有 reverse 的代码,未来肯定会 break,不保证跨版本兼容性,
大白鼠们小白鼠们来试试吧极简配置示例
公网端配置一个 VLESS 入站,与 UUID 同级配置
"reverse": { "tag": "xxx" },此 tag 视为出站,把流量路由至此即可使用所以公网端一定要有一个默认出站比如 direct,不然会有某一个 reverse 成为默认出站、谁都能访问
方便演示这里用 VLESS Encryption,实际上你直接过墙的话会用 REALITY,当然你也可以用 tunnel 直接暴露内网端口到公网
{ "inbounds": [ { "listen": "0.0.0.0", "port": 443, "protocol": "vless", "settings": { "decryption": "mlkem768x25519plus.native.600s.aCF82eKiK6g0DIbv0_nsjbHC4RyKCc9NRjl-X9lyi0k", "clients": [ { "id": "ac04551d-6ebf-4685-86e2-17c12491f7f4", // for establishing reverse connection "flow": "xtls-rprx-vision", "reverse": { "tag": "r-outbound" } }, { "id": "e8758aff-d830-4d08-a59e-271df65b995a", // for user "flow": "xtls-rprx-vision", "email": "[email protected]" } ] } }, { "listen": "0.0.0.0", "port": 80, "protocol": "tunnel", "tag": "t-inbound" } ], "routing": { "rules": [ { "user": [ "[email protected]" ], "outboundTag": "r-outbound" }, { "inboundTag": [ "t-inbound" ], "outboundTag": "r-outbound" } ] }, "outbounds": [ { "protocol": "direct" // essential } ] }内网端默认出站 direct 否则回环,另开一个 VLESS 出站配置
"reverse": { "tag": "yyy" }就会自动连接公网端,无需配置路由此 tag 视为入站,可以在内网端的路由等处作为入站 tag 使用,并且它与公网端 reverse 的 tag 没有任何关系,可以不同
这个 PR 顺便删除了 VLESS outbound 的 vnext 和 users 的 json 嵌套以简化配置,因为上一版 Xray 中已限制它们只能有一个成员
{ "outbounds": [ { "protocol": "direct" // essential }, { "protocol": "vless", "settings": { "address": "server.com", "port": 443, "encryption": "mlkem768x25519plus.native.0rtt.2PcBa3Yz0zBdt4p8-PkJMzx9hIj2Ve-UmrnmZRPnpRk", "id": "ac04551d-6ebf-4685-86e2-17c12491f7f4", "flow": "xtls-rprx-vision", "reverse": { "tag": "r-inbound" } } } ] }内网端可以设 CDN 等多条冗余线路均为
"reverse": { "tag": "yyy" }对应公网端多个相同的"reverse": { "tag": "xxx" }这也是 Xray-core / VLESS 做反向代理 / 内网穿透的优势之一,至于哪条线路更优先等设置,先看看用的人多不多吧
(不会有路由问题,公网端多个入站 reverse tag 相同也只会产生一个出站,目前是多条线路同时存在、每次使用随机选择)
(现在有的功能是,假如某个线路不通了,比如说内网端没连上来,可用池中就不会有这条线路,流量会自动走其它线路)
安全注意事项
公网端可以给不同 id 设不同 reverse 穿透至不同的内网设备,客户端应当用新的 id,不然拿到客户端配置就能劫持你的反向代理
用于内网穿透的连接即使开了 XTLS Vision,也只是吃到了 padding,并没有裸奔,是否给用于使用的连接开 XTLS 裸奔自行分析
内网端 direct 出站可以设置 redirect 以限制访问范围,或者你把默认出站设为 block,只路由允许访问的范围至 direct
如果你在用别人提供的内网穿透服务或不信任 VPS,内网应开一个 VLESS Encryption 服务端承接流量,确保身份认证及数据安全
NFTs
这功能不值得支持一下 NFT 吗VLESS NFT:https://opensea.io/collection/vless
Project X NFT:https://opensea.io/item/ethereum/0x5ee362866001613093361eb8569d59c4141b76d1/1