Sal OkHttp direk verbind wanneer 'n proxy misluk?

Gebruik die kliëntweergawe, roetekandidate en die toepassing se herprobeerpad om te besluit of 'n mislukte proxy tot direkte toegang kan lei.

Vir die historiese geval van die stelsel-HTTP-proxy het OkHttp sy gedrag in 3.5.0 verander: dit het opgehou om 'n direkte verbinding te probeer nadat daardie proxy misluk het. 'n Ouer verslag van stil terugval kan die gedrag vóór daardie verandering beskryf.

Daardie geskiedenis besleg nie elke toepassing se roetebeleid nie. Volg hierdie drie kontroles om 'n verslag uit jou eie toepassing te interpreteer:

  1. Vind die opgeloste OkHttp-weergawe. Gebruik die toepassing se afhanklikheidsinligting, insluitend die weergawe wat werklik deur 'n raamwerk ingebundel is, eerder as die ouderdom van die voorbeeld wat gekopieer word.
  2. Vind hoe hierdie kliënt 'n roete kies. 'n Eksplisiete proxy en 'n pasgemaakte ProxySelector is verskillende konfigurasies. As die keurder ná 'n proxy 'n direkte kandidaat verskaf, bied dit 'n direkte alternatief aan.
  3. Volg die mislukkingshanteerder. Soek toepassingskode wat met 'n ander kliënt herprobeer. 'n Direkte versoek deur daardie plaasvervanger val buite die eerste kliënt se besluit.

Vir 'n vereiste van 'n verpligte proxy moet die betrokke kliëntbeleid stop eerder as om 'n direkte alternatief te bied. Kontroleer die werklike kliënt en herprobeerpad teen daardie vereiste; die 3.5.0-verandering alleen is nie 'n masjienwye verkeersreël nie.

Verwante artikels