В історичному випадку системного HTTP-проксі OkHttp змінив поведінку у версії 3.5.0: він перестав намагатися встановити пряме з'єднання після збою цього проксі. Старіший звіт про тихий відкат може описувати поведінку до цієї зміни.

Ця історія не вирішує політику маршрутизації кожного застосунку. Щоб інтерпретувати звіт із вашого застосунку, виконайте три перевірки:

  1. Знайдіть розв'язану версію OkHttp. Використовуйте відомості про залежності застосунку, включно з версією, яку фреймворк фактично включає, а не вік копійованого прикладу.
  2. З'ясуйте, як цей клієнт обирає маршрут. Явний проксі та власний ProxySelector — різні конфігурації. Якщо селектор після проксі пропонує прямого кандидата, він пропонує пряму альтернативу.
  3. Простежте обробник збою. Шукайте код застосунку, який повторює спробу з іншим клієнтом. Прямий запит цієї заміни перебуває поза рішенням першого клієнта.

Для вимоги обов'язкового проксі відповідна політика клієнта має зупинитися, а не пропонувати пряму альтернативу. Перевірте реальний клієнт і шлях повтору щодо цієї вимоги; сам лише змін 3.5.0 не є правилом трафіку для всієї машини.

Схожі статті