最近我需要 mitmproxy 一個啟用 HTTP/2 的本地 nginx 服務器設定，所以我瀏覽了 mitmproxy 的Modes Of operation檔案頁面并像這樣啟動它：
./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 不能正確反映 ALPN 協商，所以我開始尋找解決方案并找到以下mitmproxy 選項：
connection_strategy - 確定何時應建立服務器連接。當設定為惰性時，mitmproxy 會嘗試盡可能長時間地推遲建立上游連接。這使得離線時可以使用服務器重播。當設定為 eager 時，mitmproxy 可以檢測帶有服務器端問候語的協議，以及準確地鏡像 TLS ALPN 協商。默認值：渴望選擇：渴望，懶惰
據我了解，“準確鏡像 TLS ALPN 協商”正是我所需要的，但由于它是 mitmproxy 的默認行為，而且正如我所描述的那樣它不起作用，我決定檢查如果我將它設定為懶惰會發生什么這個：
./mitmdump --mode reverse:https://localhost -p 8080 --ssl-insecure --set connection_strategy=lazy
它奏效了。我可以看到 nginx 使用 HTTP/2 進行回應。
有人可以向我指出為什么我對 connecttion_strategy 選項的理解是錯誤的嗎？它是否與反向代理的作業方式有關？
uj5u.com熱心網友回復：
您已經正確理解了所有內容，不鏡像 ALPN 是我們當前實作中的一個錯誤。我在這里提出了一個問題：https ://github.com/mitmproxy/mitmproxy/issues/5369 。:)
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/482788.html