OkHttp se connecte-t-il directement lorsqu'un proxy échoue ?
Utilisez la version du client, les candidats de routage et le chemin de nouvelle tentative de l'application pour décider si un proxy défaillant peut mener à un accès direct.
Dans le cas historique du proxy HTTP système, OkHttp a changé de comportement en 3.5.0 : il a cessé de tenter une connexion directe après l'échec de ce proxy. Un rapport plus ancien sur un repli silencieux peut décrire le comportement antérieur à ce changement.
Cet historique ne tranche pas la politique de routage de chaque application. Pour interpréter un rapport issu de votre propre application, suivez ces trois vérifications :
- Trouvez la version d'OkHttp résolue. Utilisez les informations de dépendances de l'application, y compris la version réellement embarquée par un framework, plutôt que l'âge de l'exemple copié.
- Trouvez comment ce client choisit une route. Un proxy explicite et un ProxySelector personnalisé sont des configurations différentes. Si le sélecteur fournit un candidat direct après un proxy, il propose une alternative directe.
- Suivez le gestionnaire d'échec. Cherchez du code applicatif qui réessaie avec un autre client. Une requête directe effectuée par ce remplaçant échappe à la décision du premier client.
Pour une exigence de proxy obligatoire, la politique du client concerné doit s'arrêter au lieu de proposer une alternative directe. Vérifiez le client réel et le chemin de nouvelle tentative au regard de cette exigence ; le changement de 3.5.0 à lui seul n'est pas une règle de trafic à l'échelle de la machine.