Czy OkHttp połączy się bezpośrednio, gdy proxy zawiedzie?
Użyj wersji klienta, kandydatów routingu i ścieżki ponownej próby aplikacji, aby zdecydować, czy nieudane proxy może prowadzić do bezpośredniego dostępu.
W historycznym przypadku systemowego proxy HTTP OkHttp zmieniło zachowanie w wersji 3.5.0: przestało próbować bezpośredniego połączenia po awarii tego proxy. Starszy raport o cichym powrocie może opisywać zachowanie sprzed tej zmiany.
Ta historia nie rozstrzyga polityki routingu każdej aplikacji. Aby zinterpretować raport z własnej aplikacji, wykonaj trzy kontrole:
- Znajdź rozwiązaną wersję OkHttp. Użyj informacji o zależnościach aplikacji, w tym wersji faktycznie dołączonej przez framework, zamiast wieku kopiowanego przykładu.
- Sprawdź, jak ten klient wybiera trasę. Jawny proxy i niestandardowy ProxySelector to różne konfiguracje. Jeśli selektor po proxy podaje bezpośredniego kandydata, oferuje bezpośrednią alternatywę.
- Prześledź obsługę błędu. Poszukaj kodu aplikacji, który ponawia próbę z innym klientem. Bezpośrednie żądanie wykonane przez ten zamiennik znajduje się poza decyzją pierwszego klienta.
Przy wymogu obowiązkowego proxy odpowiednia polityka klienta musi się zatrzymać, a nie oferować bezpośrednią alternatywę. Sprawdź rzeczywistego klienta i ścieżkę ponowienia wobec tego wymogu; sama zmiana w 3.5.0 nie jest regułą ruchu dla całej maszyny.