No caso histórico do proxy HTTP do sistema, o OkHttp mudou o comportamento na versão 3.5.0: deixou de tentar uma conexão direta depois que esse proxy falhou. Um relatório mais antigo sobre retorno silencioso pode descrever o comportamento anterior a essa mudança.

Esse histórico não resolve a política de roteamento de cada aplicação. Para interpretar um relatório da sua própria aplicação, siga estas três verificações:

  1. Encontre a versão resolvida do OkHttp. Use as informações de dependências da aplicação, incluindo a versão realmente incluída por um framework, em vez da idade do exemplo copiado.
  2. Descubra como este cliente escolhe uma rota. Um proxy explícito e um ProxySelector personalizado são configurações diferentes. Se o seletor fornece um candidato direto após um proxy, está oferecendo uma alternativa direta.
  3. Siga o manipulador de falhas. Procure código da aplicação que tente novamente com outro cliente. Uma solicitação direta feita por esse substituto fica fora da decisão do primeiro cliente.

Para um requisito de proxy obrigatório, a política do cliente em questão deve parar em vez de oferecer uma alternativa direta. Verifique o cliente real e o caminho de nova tentativa em relação a esse requisito; a mudança na 3.5.0 por si só não é uma regra de tráfego para a máquina inteira.

Artigos relacionados