Ці будзе OkHttp злучацца напрамую, калі проксі не працуе?

Выкарыстайце версію кліента, кандыдаты маршрутызацыі і шлях паўторных спроб праграмы, каб вызначыць, ці можа збой проксі прывесці да прамога доступу.

У гістарычным выпадку з сістэмным HTTP-проксі OkHttp змяніў паводзіны ў 3.5.0: ён перастаў спрабаваць прамое злучэнне пасля збою гэтага проксі. Больш старое паведамленне пра ціхі адкат можа апісваць паводзіны да гэтага змянення.

Гэтая гісторыя не вырашае палітыку маршрутызацыі кожнай праграмы. Каб інтэрпрэтаваць паведамленне з вашай праграмы, выканайце тры праверкі:

  1. Знайдзіце вызначаную версію OkHttp. Выкарыстоўвайце звесткі пра залежнасці праграмы, уключаючы версію, якую фактычна ўбудаваў фрэймворк, а не ўзрост скапіраванага прыкладу.
  2. Вызначце, як гэты кліент выбірае маршрут. Яўны проксі і ўласны ProxySelector — гэта розныя канфігурацыі. Калі селектар прапануе прамога кандыдата пасля проксі, ён прапануе прамую альтэрнатыву.
  3. Прасачыце апрацоўшчык збою. Шукайце код праграмы, які паўтарае спробу з іншым кліентам. Прамы запыт, зроблены гэтай заменай, знаходзіцца па-за рашэннем першага кліента.

Для патрабавання абавязковага проксі адпаведная палітыка кліента павінна спыніцца, а не прапаноўваць прамую альтэрнатыву. Праверце фактычны кліент і шлях паўтору супраць гэтага патрабавання; адно змяненне 3.5.0 не з'яўляецца правілам трафіку для ўсёй машыны.

Падобныя артыкулы