Im historischen Fall des System-HTTP-Proxys änderte OkHttp sein Verhalten in 3.5.0: Nach dem Fehlschlagen dieses Proxys versuchte es keine direkte Verbindung mehr. Ein älterer Bericht über stillen Rückfall kann das Verhalten vor dieser Änderung beschreiben.

Diese Historie entscheidet nicht über die Routing-Richtlinie jeder Anwendung. Um einen Bericht aus Ihrer eigenen Anwendung zu deuten, befolgen Sie diese drei Prüfungen:

  1. Ermitteln Sie die aufgelöste OkHttp-Version. Nutzen Sie die Abhängigkeitsinformationen der Anwendung, einschließlich der von einem Framework tatsächlich gebündelten Version, statt des Alters des kopierten Beispiels.
  2. Ermitteln Sie, wie dieser Client eine Route wählt. Ein expliziter Proxy und ein benutzerdefinierter ProxySelector sind unterschiedliche Konfigurationen. Liefert der Selektor nach einem Proxy einen direkten Kandidaten, so bietet er eine direkte Alternative an.
  3. Verfolgen Sie den Fehlerbehandler. Suchen Sie Anwendungscode, der mit einem anderen Client erneut versucht. Eine direkte Anfrage dieser Ersetzung liegt außerhalb der Entscheidung des ersten Clients.

Bei einer Pflicht-Proxy-Vorgabe muss die betreffende Client-Richtlinie abbrechen, statt eine direkte Alternative anzubieten. Prüfen Sie den tatsächlichen Client und den Wiederholungspfad gegen diese Vorgabe; die Änderung in 3.5.0 allein ist keine maschinenweite Verkehrsregel.

Ähnliche Artikel