nginx - 反向代理模式下的 mitmproxy + ALPN

Question

最近我需要 mitmproxy 启用 HTTP/2 的本地 nginx 服务器设置，所以我通过了 Modes Of operation 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 扩展字段，而从 Firefox 到 mitmproxy 的 ClientHello 确实包含它。我的假设是 mitmproxy 没有正确反射(reflect) ALPN 协商，所以我开始寻找解决方案，发现以下 mitmproxy option :

connection_strategy - Determine when server connections should beestablished. When set to lazy, mitmproxy tries to defer establishingan upstream connection as long as possible. This makes it possible touse server replay while being offline. When set to eager, mitmproxycan detect protocols with server-side greetings, as well as accuratelymirror TLS ALPN negotiation. Default: eager Choices: eager, lazy

据我了解，“准确镜像 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 . :)