[feature] 反向代理支持监听`HTTPS`、`QUIC`协议

[WankkoRee]

[feature] 反向代理支持监听`HTTPS`、`QUIC`协议

[WankkoRee]

QUIC反向代理相关支持的前置条件是完成 #413

[MegatronKing]

我理解你说的功能和反向代理看起来没有关系

[WankkoRee]

有关系的，而且是直接相关的需求，我说的这一套方案我今天用 https://github.com/masx200/http3-reverse-proxy-server-experiment 走通了。

比如说我这有一个客户端需要抓包，但是它的流量是走quic的，而且不支持自适应降级，所以只能连接到https。

我可以通过修改客户端二进制文件来控制其接口的域名，所以我可以将其改成一个反向代理的域名，这时候可以通过反向代理抓包。

但是因为上述的必须要连接到https的原因，这个反向代理必须要是能够配置证书来监听和解密tls流量的，但是这个需求目前 Reqable 并不支持。

[MegatronKing]

@WankkoRee 抱歉，忘记跟进这个issue了。不知道你说的反向代理是不是和Reqable的反向代理功能是同一个？

[WankkoRee]

是同一个。

当前的Reqable只支持：客户端-http-http/https服务端。

我的需求是支持：客户端-http/https/quic-http/https/quic服务器。

[MegatronKing]

目前反向代理涉及下面：

• 客户端和反向代理服务器。这个目前是HTTP1.1明文协议。
• 反向代理客户端到真实服务器。这个目前是HTTP1.1协议，如果真实服务器强制HTTP2或者QUIC则会请求失败。
  不知道你说的是否是第二个要支持HTTP2和QUIC？

[WankkoRee]

我的需求是第一个和第二个都支持HTTP2和QUIC，因为我遇到的情况是，除了有些服务器端会强制协议外，有些客户端也会强制协议，这一点我在上面有提到过。

比如说我这有一个客户端需要抓包，但是它的流量是走quic的，而且不支持自适应降级

[MegatronKing]

我的需求是第一个和第二个都支持HTTP2和QUIC，因为我遇到的情况是，除了有些服务器端会强制协议外，有些客户端也会强制协议，这一点我在上面有提到过。

比如说我这有一个客户端需要抓包，但是它的流量是走quic的，而且不支持自适应降级

我还是不能理解你的这个需求，或者是你没有理解反向代理功能的工作原理，所以我们说的应该不是同一件事情。关于Reqable的反向代理，请阅读文档：https://reqable.com/zh-CN/docs/capture/reverse-proxy

[WankkoRee]

我说的就是反向代理，这一点我可以确认，因为我使用 https://github.com/traefik/traefik 和 https://github.com/masx200/http3-reverse-proxy-server-experiment 都实现了一部分我的需求，这两个项目都是反向代理功能直接相关的。

我就是在试了其他项目确认这个需求是可行的，才过来提 issue 的。

我还是不能理解你的这个需求

如果可以的话，希望能够提出不理解的地方。

[MegatronKing]

我说的就是反向代理，这一点我可以确认，因为我使用 https://github.com/traefik/traefik 和 https://github.com/masx200/http3-reverse-proxy-server-experiment 都实现了一部分我的需求，这两个项目都是反向代理功能直接相关的。

你看下Reqable的文档，此反向代理非Reqable的反向代理。

[WankkoRee]

我看了，而且我确认两个反向代理的含义是一致的，你说的两者的不同是？

[MegatronKing]

Reqable的反向代理是用来解决客户端不走系统代理和证书信任问题的。要求客户端通过HTTP1.1明文连接到Reqable代理服务器，不存在你说的我的需求是第一个和第二个都支持HTTP2和QUIC，因为我遇到的情况是，除了有些服务器端会强制协议外，有些客户端也会强制协议，这一点我在上面有提到过。这种需求。

[WankkoRee]

但是HTTP2和QUIC也存在证书信任问题，我是在确认客户端不承认本地额外配置的证书后，才尝试反向代理方案的。

而HTTP2和QUIC很明显是不支持直接使用只支持HTTP/1.1的反向代理的。

[WankkoRee]

我理解的是你认为 Reqable 实现 C-http-R-http/https-S 来解决不走代理和证书不可信的痛点就足够，但是实际情况是客户端在只支持http2或quic的情况下， Reqable 的反向代理并不能很好地满足需求。

[MegatronKing]

客户端只支持http2或quic

请问这是为啥呢？现在基本上所有HTTP网络库都支持HTTP1吧。

[WankkoRee]

我这边碰到的是使用 golang 手搓客户端的一个项目，其大致代码如下：

• http2

	return &http.Client{
		Transport: &http2.RoundTripper{
		},
	}

• quic

	return &http.Client{
		Transport: &http3.RoundTripper{
			QuicConfig: &quic.Config{
				MaxIncomingStreams:    100,
				MaxIncomingUniStreams: 100,
			},
		},
	}

http2 那个我不确定能否自适应降级为 https over http1.1 ，但是 quic 那个我是测试过不支持自适应降级为 https over http1.1 的。

[MegatronKing]

我不了解golang，但是你请求http://127.0.0.1肯定都是走HTTP1。如果你说客户端无法请求http://127.0.0.1，那你需要修改代码了，Reqable反向代理本来就需要修改代码将真实域名替换成127.0.0.1。

现在唯一的问题是，如果真实服务器强制要求HTTP2或QUIC，会导致反向代理失败。你希望解决的就是这个吧？

[WankkoRee]

Reqable反向代理本来就需要修改代码将真实域名替换成127.0.0.1

我无法修改代码来实现复杂的逻辑，如自适应降级、更换http协议版本，但是我可以通过修改二进制文件中的字符串来实现一些简单的域名替换需求。

现在唯一的问题是，如果真实服务器强制要求HTTP2或QUIC，会导致反向代理失败。你希望解决的就是这个吧？

是的。

[MegatronKing]

我无法修改代码来实现复杂的逻辑，如自适应降级、更换http协议版本，但是我可以通过修改二进制文件中的字符串来实现一些简单的域名替换需求。

那你这个估计就用不了Reqable反向代理，本来就是要通过将https改成http明文请求来解决证书问题的。HTTP2和QUIC的实现都是强制要走HTTPS的。

[WankkoRee]

证书问题我在最开始有提到过解决方案。

这种情况下，反向代理的证书问题需要用户自行解决，如反向代理监听一个域名，这个域名会解析到反向代理的主机IP上，而这个域名在事先已经在公网中申请了一个可信的证书，用户只需要导入这个证书和私钥即可实现客户端可信的反向代理。

我有一个域名，并且这个域名已经事先通过公网服务器申请了一个可信的证书，我现在只需要将这个域名指向 127.0.0.1 ，即可使用这个域名作为反向代理使用。