Skip to content

Conversation

@RPRX
Copy link
Member

@RPRX RPRX commented Sep 7, 2025

先前讨论:#5088 (comment)

反向代理(内网穿透),第一版先复用现有 reverse 的代码,未来肯定会 break,不保证跨版本兼容性,大白鼠们小白鼠们来试试吧

这个 PR 的目的就是为了让 Xray 更适合做反向代理 / 内网穿透,独特的优势是你可以直接复用拿来翻墙的那台 VPS、复用 REALITY 的抗量子加密且防封,因为 REALITY 不仅可以稳定地穿透 GFW,也可以穿透公司网络那些奇奇怪怪的审计

极简配置示例

公网端配置一个 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

@RPRX RPRX changed the title VLESS protocol: Add Reverse (4) Command and simple config VLESS protocol: Add Reverse Proxy (4) Command and simple config Sep 7, 2025
@RPRX RPRX changed the title VLESS protocol: Add Reverse Proxy (4) Command and simple config VLESS protocol: Add Reverse Proxy (4) Command and extreme simple config Sep 7, 2025
@RPRX RPRX changed the title VLESS protocol: Add Reverse Proxy (4) Command and extreme simple config VLESS protocol: Add Reverse Proxy (4) Command and extremely simple config Sep 7, 2025
@RPRX
Copy link
Member Author

RPRX commented Sep 7, 2025

老规矩代码是今天写的,也就糊了几个小时,测试是明天的事

@RPRX
Copy link
Member Author

RPRX commented Sep 8, 2025

本来想着要不要把服务端改成默认允许开反向代理、同一个 UUID 即可使用,想想还是算了,原因有三:

  1. 客户端配置泄露比较猖獗,如果这样做了,拿到客户端配置的人不仅能访问反向代理,甚至还能劫持反向代理,肯定不行
  2. 反向代理子协议尚不稳定,未来肯定会 break,不保证跨版本兼容性
  3. 随着 IPv6 的普及,内网穿透的需求会锐减

@gfw-killer
Copy link

the same old mux.cool reverse proxy, just simplified the configuration and limited to VLESS
if it's not possible to have a Reverse function without mux.cool, at least add some options like mux settings and keep-alive interval

@RPRX
Copy link
Member Author

RPRX commented Sep 8, 2025

@gfw-killer 我说了这只是第一版,我也不觉得用 mux.cool 有什么不好的,你倒是说说存在什么问题?并且如果你看了“先前讨论”,就会知道更多的选项即将到来,mux.cool 本身也会在今年内的新版本中得到增强

@RPRX
Copy link
Member Author

RPRX commented Sep 8, 2025

@gfw-killer 就是说我觉得你颇有不满,所以你们这些人为什么就总是在提需求、一点都等不了?我又不是所有时间都拿来给你们开发这些东西,第一步把配置简化成这样就已经是进步了,此外 Xray-core 中的这些协议,还有 VLESS 不能覆盖的场景吗?

@gfw-killer
Copy link

I don't think there's anything bad about using mux.cool

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 if you look at “previous discussion”, you will know that more options are coming

And I have not read the previous discussion yet, so I didn't knew about the process, sorry.

are there scenarios that VLESS cannot cover?

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.
But it covers almost all scenarios, there is no problem. Thanks once again.

@Meo597
Copy link
Collaborator

Meo597 commented Sep 8, 2025

正常好人家谁用ray做反向代理,frp gost灵活功能强大

这玩意就是给伊朗特殊环境用的,他们在严管期限制境内发起的tcp连接带宽

私以为不值得为他们三秒钟制定的奇葩策略花什么精力

这种随心所欲的管控策略不知道什么时候就变动
以前的又不是不能用,只是机场用起来不爽

而且frp gost在最外层完全能满足他们需求,毕竟他们明文面板都不怕。又何必在意frp们的tit

@RPRX
Copy link
Member Author

RPRX commented Sep 9, 2025

测试发现我这完全靠想写出来的代码只需改了 if !ob.Target.IsValid() { 就通了,心情好所以只各打五十大板吧:

  1. 这个 PR 的目的就是为了让 Xray 更适合做反向代理 / 内网穿透,独特的优势是你可以直接复用拿来翻墙的那台 VPS、复用 REALITY 的抗量子加密且防封,因为 REALITY 不仅可以稳定地穿透 GFW,也可以穿透公司网络那些奇奇怪怪的审计
  2. @gfw-killer 你提到的 lightweight Encryption,首先 256 和 128 就没什么区别,其次就算你想 simple XOR 但你能过墙吗?我看过你发在 net4people bbs 的那个讨论,由境外 VPS 发起连接,我确实可以做到让反向代理也是 1:1 的连接然后 XTLS 裸奔、性能拉满,但关键是你们发现的这种小 trick 能坚持多久?怕不是稍微有点规模就会被伊朗 GFW 注意到然后全给你们封了

@Yochee

This comment was marked as outdated.

@gfw-killer
Copy link

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
VLESS Partial Encryption has no effect on this type of connections, it must encrypt all of it
Needs of a Relay and a Proxy is different, you see they flex on speed, lower hw usage and latency, not on stronger encryption

I am not asking you to support it, just mentioned it as a scenario

But the point is how long does this little trick you guys found last?

Sometimes they work for years, specially the customizable ones like Freedom-Noises

@RPRX

This comment was marked as outdated.

@RPRX
Copy link
Member Author

RPRX commented Sep 9, 2025

@gfw-killer Freedom-Noises 与其它小 tricks 有本质区别,因为 GFW 的算力难以分析每个 UDP 包,但封其它方法的成本很低

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
VLESS Partial Encryption has no effect on this type of connections, it must encrypt all of it
Needs of a Relay and a Proxy is different, you see they flex on speed, lower hw usage and latency, not on stronger encryption

如果你使用 Xray-core 的 VLESS Encryption 加上 RAW 传输层的 HTTP-Header,对被代理的 TLSv1.3 并不会二次加解密

@RPRX
Copy link
Member Author

RPRX commented Sep 9, 2025

9fb7375 优化了代码,路由 "outboundTag" 不存在时改为失败,修改了 internalDomain 为 "reverse",经测试可以使用,兼容 XTLS

@Yochee 测试 9fb7375

@Yochee
Copy link

Yochee commented Sep 9, 2025

@RPRX
9fb7375 可以用了
请问现在“r-inbound”、“r-outbound”这两个tag是硬编码的嘛,如果一个公网端要反代多个内网端,路由规则不好写啊(都是r-outbound)

@RPRX
Copy link
Member Author

RPRX commented Sep 9, 2025

@Yochee 肯定不是硬编码的啊,只是示例,可以自定义

@RPRX
Copy link
Member Author

RPRX commented Sep 9, 2025

eda8be6 删除了 VLESS outbound 的 vnext 和 users 的 json 嵌套以简化配置, 6417c77 8c4e998 31f705b 最后完善代码

@RPRX RPRX merged commit 845010b into main Sep 9, 2025
78 checks passed
@RPRX RPRX deleted the vless branch September 9, 2025 14:19
@RPRX
Copy link
Member Author

RPRX commented Sep 10, 2025

内网端可以设 CDN 等多条冗余线路均为 "reverse": { "tag": "yyy" } 对应公网端多个相同的 "reverse": { "tag": "xxx" }

这也是 Xray-core / VLESS 做反向代理 / 内网穿透的优势之一,至于哪条线路更优先等设置,先看看用的人多不多吧

@RPRX
Copy link
Member Author

RPRX commented Sep 10, 2025

@Yochee 我在 #5101 (comment) 的表述有亿点小问题,因为当时我还没检查服务端 Vision 是否兼容它,你当时测试不能用只是因为没改 if !ob.Target.IsValid() { 那一行,现在提这件事是因为回想起自己只靠想写出来的代码几乎直接通了还有亿点小激动

@Yochee
Copy link

Yochee commented Sep 10, 2025

内网端可以设 CDN 等多条冗余线路均为 "reverse": { "tag": "yyy" } 对应公网端多个相同的 "reverse": { "tag": "xxx" }

这也是 Xray-core / VLESS 做反向代理 / 内网穿透的优势之一,至于哪条线路更优先等设置,先看看用的人多不多吧

老版本并没有线路冗余一说,要在内网端手动修改出站才能切换线路,优点是公网端提前配置好几个入站(比如直连、cdn)后就不需要任何修改。如果新版想支持线路冗余,那公网端多个入站配置成相同tag的reverse出站就会有路由问题,可能要的不是优先级设置,而是类似连通性检测或者fallback设置

@RPRX
Copy link
Member Author

RPRX commented Sep 10, 2025

@RPRX
Copy link
Member Author

RPRX commented Sep 10, 2025

@Yochee 不会有路由问题,公网端多个入站 reverse tag 相同也只会产生一个出站,目前是多条线路同时存在、每次使用随机选择

所以说如果用的人多的话,我会加一些策略来控制这种随机,比如优先用哪个线路,或按比例分配流量,或动态监测并分配流量

@RPRX
Copy link
Member Author

RPRX commented Sep 10, 2025

@Yochee 现在有的功能是,假如某个线路不通了,比如说内网端没连上来,可用池中就不会有这条线路,流量会自动走其它线路

@RPRX
Copy link
Member Author

RPRX commented Sep 11, 2025

昨日群里一些补充性讨论:(话说那个 AI bot 咋没了

  1. 有小白想要完整配置示例,然而这个 PR 的示例就已经是完整配置了,换成 REALITY 直接用,就是这么简洁,还要咋完整
  2. 两端各声明一个 reverse 就可以把 tag 当出入站来使用了(一是开启功能,二是作为 tag),没有任何复杂度
  3. 必须用 VLESS,因为这是 VLESS 协议新增的 Command,VLESS 已经覆盖几乎所有场景,暴力发包除外,除非改 Nginx
  4. 后续 Xray-core 的配置订阅功能肯定会自动屏蔽 reverse 等对于客户端来说不安全的东西,防止服务提供者作妖
  5. VLESS 出站简化配置或原配置方式二选一,原配置方式并没有被移除,感觉在说废话,没人会突然搞这种 breaking
  6. 有一些人提到三网优化美西线路可能比 IPv6 更强,跨网/跨省 QoS,光猫/路由器 IPv6 防火墙而且不知道在哪关什么的
  7. “公司防火墙才不管v4 v6...不过支持默认不开启,现在这样挺好的够简单了” “对于公司防火墙的场景肯定 IPv6 也没招,我的意思是大家有 IPv6 了相当于有公网 IP 了,这在 IPv4 时代是不存在的,以前只能内网穿透”

话说有人提到有了 TUN 之后组网起飞,不过有了方便的反向代理应该不需要“那种组网”了吧?不然 IP over TCP 体验岂不是很爆炸

@mclovin-2k
Copy link

在这个简化配置出来前,我就已经使用XRay的反向代理好几年的时间了。
这次的简化配置很好,比以前简单多了。
支持顶。

@engAmirEng
Copy link

Please continue to support the old style reverse proxy for some time so we can migrate safely

@2EneR2
Copy link

2EneR2 commented Sep 24, 2025

Hello!

Initial data:
Server – VPS 1x1x10, OS Debian 12, Xray-linux-64 version 25.9.11
Keenetic Giga Client Router (KN-1012)– OS Entware BusyBox v1.37.0, Xray-linux-arm64-v8a version 25.9.11
The configuration files correspond to the examples from #5101 .
Problem:
A direct connection is established with the VPS on the router and works. After adding - "reverse": {"tag": "r-outbound"} to the configuration file and restarting xray on the VPS, the xray core on the VPS crashes. There are no error records in the error.log file on the VPS. A restart is possible after deleting the entry "reverse": {"tag": "r-outbound"} and restarting the system. Tested on two different vps. The xray core on the client remains in operation. There are no error records in the error.log file on the client. The error information from the journalctl VPS is in the attached file.

I ask for help in solving the problem.
journalctl.txt

@RPRX
Copy link
Member Author

RPRX commented Oct 15, 2025

12f4a01 VLESS Reverse Proxy 默认加了传递公网端的 Source & Local (IP & port) 到内网端,内网端可以在路由等处匹配它们,并且内网端的 Direct 出站设置发送 PROXY protocol 即可把它们传递至最终的应用程序比如 Nginx,不再会是 127.0.0.1 了

经测试没啥问题,双端升级至 Xray-core v25.10.15+ 默认启用,可以看到双端 log 中的 "from xxx" 已同步,三点注意事项:

  1. 只给 VLESS Reverse Proxy 加了,旧的反向代理没加,并且旧的反向代理以后会被删掉,代码会被移至 VLESS
  2. 由于访问者也可以通过 VLESS 等入站协议访问到内网端,Source & Local 是 TCP 还是 UDP 不一定与 Target 相同
  3. XHTTP / WS 等入站目前有个问题是默认读取 X-Forwarded-For,没经过任何 HTTP 反代的话访问者可以伪造源地址

下个版本会出个选项以解决第三点,当然如果你公网端是纯粹 Tunnel 入站的话就没有第三点的问题,也不会出现第二点的情况

@RPRX
Copy link
Member Author

RPRX commented Oct 15, 2025

@2EneR2
Copy link

2EneR2 commented Oct 15, 2025

Thank you for your hard work!
On core version 25.10.15, the problem I described above has gone away. I also note that, as it turned out, it concerned the operation of the reverse at the "raw" transport level. On "xhttp", the reverse in my configuration also works on core version 25.9.11.

@Fangliding
Copy link
Member

因为这是vision的问题啊。。 #5189

@R3pl4c3r
Copy link
Contributor

R3pl4c3r commented Oct 29, 2025

昨日群里一些补充性讨论:(话说那个 AI bot 咋没了

  1. 有小白想要完整配置示例,然而这个 PR 的示例就已经是完整配置了,换成 REALITY 直接用,就是这么简洁,还要咋完整
  2. 两端各声明一个 reverse 就可以把 tag 当出入站来使用了(一是开启功能,二是作为 tag),没有任何复杂度
  3. 必须用 VLESS,因为这是 VLESS 协议新增的 Command,VLESS 已经覆盖几乎所有场景,暴力发包除外,除非改 Nginx
  4. 后续 Xray-core 的配置订阅功能肯定会自动屏蔽 reverse 等对于客户端来说不安全的东西,防止服务提供者作妖
  5. VLESS 出站简化配置或原配置方式二选一,原配置方式并没有被移除,感觉在说废话,没人会突然搞这种 breaking
  6. 有一些人提到三网优化美西线路可能比 IPv6 更强,跨网/跨省 QoS,光猫/路由器 IPv6 防火墙而且不知道在哪关什么的
  7. “公司防火墙才不管v4 v6...不过支持默认不开启,现在这样挺好的够简单了” “对于公司防火墙的场景肯定 IPv6 也没招,我的意思是大家有 IPv6 了相当于有公网 IP 了,这在 IPv4 时代是不存在的,以前只能内网穿透”

话说有人提到有了 TUN 之后组网起飞,不过有了方便的反向代理应该不需要“那种组网”了吧?不然 IP over TCP 体验岂不是很爆炸

@RPRX 您好,我有一个问题想咨询一下,不知您是否可以给予解答

设置好配置文件后如何访问内网的服务?
因为这个配置文件与官网文档里面关于反向代理的配置不一样,如果按照文档的写法需要配置bridge, portal以及对应的rule。在现在这个写法下,我应该如何访问内网设备绑定在127.0.0.1:80的服务呢?
在已有outbound:

{
  // 转发到网页服务器
  "tag": "out",
  "protocol": "freedom",
  "settings": {
    "redirect": "127.0.0.1:80"
  }
}

是否可以认为在公网端和内网端的reverseObject里面添加一个"domain": "reverse-proxy.xray.internal"然后在内网端rules里面加一个

{
      // 从 portal 过来的流量,也会从 bridge 出来,但是不带上面的domain
      // 则路由到 out,即转发给网页服务器
      "type": "field",
      "inboundTag": ["r-inbound"],
      "outboundTag": "out"
}

这样之后就可以通过reverse-proxy.xray.internal域名来访问内网的网页服务了?

@RPRX
Copy link
Member Author

RPRX commented Oct 29, 2025

@R3pl4c3r 你弄混了,这和旧版 reverse 配置没有任何关系,@Fangliding 把旧版文档删了吧,反正也没几个人能看懂

你公网端把流量路由到 r-outbound 出站,会跑到内网端的 r-inbound 入站,其它的该咋写就咋写

@R3pl4c3r
Copy link
Contributor

@R3pl4c3r 你弄混了,这和旧版 reverse 配置没有任何关系,@Fangliding 把旧版文档删了吧,反正也没几个人能看懂

你公网端把流量路由到 r-outbound 出站,会跑到内网端的 r-inbound 入站,其它的该咋写就咋写

@RPRX 我把原始内网客户端配置的direct后面加了一个

"settings": {
    "redirect": "127.0.0.1:8000"
}

就好了,我一会补充一下文档把

@zeratulyxl
Copy link

相比各位大神,本人确实小白,因为正好有反代需求,所以想询问一下:
1.上述公网端配置里,先配置了反代以及1个客户端配置接入入口和1个公网暴露入口;然后在路由配置中,客户端配置接入入口和公网暴露入口都直接导向了内网端。可以调整掉暴露部分略微提升下接入门槛?我的理解对不对?
2.前面有人提问,也有人回答,也看到了R大说的,增加了传递ip和port。但我还是不明白具体配置访问方法,想确认下:在上面极简配置下,作为客户端,怎么连接到内网端。按目前的vless版本,是否按上面大神说的,在公网端和内网端reverseObject里面配置"domain",作为访问地址,配置redirect定义具体端口?

@R3pl4c3r
Copy link
Contributor

R3pl4c3r commented Nov 3, 2025

相比各位大神,本人确实小白,因为正好有反代需求,所以想询问一下: 1.上述公网端配置里,先配置了反代以及1个客户端配置接入入口和1个公网暴露入口;然后在路由配置中,客户端配置接入入口和公网暴露入口都直接导向了内网端。可以调整掉暴露部分略微提升下接入门槛?我的理解对不对? 2.前面有人提问,也有人回答,也看到了R大说的,增加了传递ip和port。但我还是不明白具体配置访问方法,想确认下:在上面极简配置下,作为客户端,怎么连接到内网端。按目前的vless版本,是否按上面大神说的,在公网端和内网端reverseObject里面配置"domain",作为访问地址,配置redirect定义具体端口?

@zeratulyxl reverse部分不用管,你想怎么操作就在routing里面写就行了。比如按照上面的例子就是把全部流量发到内网端,内网端走直连。那么你可以有以下三种方法来控制:一是在你的xray公网客户端自定义代理部分内网IP,因为正常是跳过走直连,代理后这部分内网请求会发到你的内网端处理,这样就相当于你直接通过VPN回家了一样。二是你在公网服务端的routing里面规定只代理部分内网流量,这样你的正常流量是直接在服务端发出,内网请求发到内网端处理,相当于服务器既可以翻墙也同时反代。三是不通过xray客户端连接公网端,公网端使用tunnel协议,把访问tunnel协议监听的所有流量转发会内网端,这个时候需要在内网端的direct出口添加redirect目标(当然你也可以选择在routing里面写,只不过没这么方便),这样就可以做到正常frp那样访问公网端的某个端口被转发为内网的某个地址。你如果想要玩明白反向代理那么需要你吃透routing部分的文档 https://xtls.github.io/config/routing.html#ruleobject
总而言之,无论极简reverse配置是什么,你只需要把它当作一个正常的inbound/outbound,之后再根据你的需求调整routing部分的配置即可

@zeratulyxl
Copy link

感谢回复,还不是十分明白,我会学习和尝试配置一下。对于极简配置,结合你的解答,我的理解:配置里for user这个部分,使用xray配置连接上,对应你所说的第一个方法,相当于vpn。配置里tunnel这个部分,公网可以直接开,对应第三个方法,但是因为没有配置redirect目标,所以还不能实际连接。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.