反向代理模式下的mitmproxy + ALPN

Question

最近，我需要使用一个启用了HTTP/2的本地nginx服务器设置，因此我浏览了mitmproxy的操作方式文档页面，并以如下方式启动了它：

./mitmdump --mode reverse:https://localhost -p 8080 --ssl-insecure

此命令以反向代理模式启动，该模式侦听端口8080。此外，它不验证上游TLS证书。

在通过火狐访问https://localhost:8080之后，我看到nginx使用HTTP/1.1进行应答。此外，在Wireshark中，我看到从mitmproxy到nginx服务器的TLS ClientHello不包含ALPN扩展字段，而从火狐到mitmproxy的ClientHello包含它。我的假设是mitmproxy没有正确反映ALPN协商，所以我开始寻找解决方案，并找到了下面的米特姆代理期权

connection_strategy -确定何时应该建立服务器连接。当被设置为懒惰时，mitmproxy试图尽可能地推迟建立上游连接。这使得在脱机时使用服务器重放成为可能。当设置为“热切”时，mitmproxy可以检测带有服务器端问候的协议，并准确地反映TLS ALPN协商。默认值:热切的选择:热切的，懒惰的

以我的理解，“精确镜像TLS ALPN协商”正是我所需要的，但由于它是mitmproxy的默认行为，而且正如我所描述的，它不起作用，所以我决定检查如果我把它设置为这样的懒惰会发生什么：

./mitmdump --mode reverse:https://localhost -p 8080 --ssl-insecure --set connection_strategy=lazy

而且起作用了。我可以看到nginx使用HTTP/2进行响应。

有人能告诉我为什么我对connecttion_strategy选项的理解是错误的吗？它一定要用反向代理的方式做些什么吗？

Answer 1

您已经正确地理解了一切，而不是镜像ALPN是我们当前实现中的一个错误。我在这里提交了一个问题：https://github.com/mitmproxy/mitmproxy/issues/5369。:)