I det historiska fallet med systemets HTTP-proxy ändrade OkHttp sitt beteende i 3.5.0: det slutade försöka med en direkt anslutning efter att proxyn misslyckats. En äldre rapport om tyst återfall kan beskriva beteendet före den ändringen.

Den historiken avgör inte varje applikations routningspolicy. Följ dessa tre kontroller för att tolka en rapport från din egen applikation:

  1. Hitta den lösta OkHttp-versionen. Använd applikationens beroendeinformation, inklusive den version ett ramverk faktiskt buntar, i stället för åldern på exemplet som kopieras.
  2. Ta reda på hur den här klienten väljer en rutt. En uttrycklig proxy och en anpassad ProxySelector är olika konfigurationer. Om väljaren erbjuder en direkt kandidat efter en proxy erbjuder den ett direkt alternativ.
  3. Följ felhanteraren. Leta efter applikationskod som försöker igen med en annan klient. En direkt förfrågan från den ersättaren ligger utanför den första klientens beslut.

För ett krav på obligatorisk proxy måste den relevanta klientpolicyn stoppa i stället för att erbjuda ett direkt alternativ. Kontrollera den faktiska klienten och återförsöksvägen mot det kravet; ändringen i 3.5.0 ensam är inte en maskinomfattande trafikregel.

Relaterade artiklar