Наладзьце прамы проксі ў OkHttp, а затым перадайце гэты ж кліент у Retrofit:

import java.net.InetSocketAddress;
import java.net.Proxy;
import okhttp3.OkHttpClient;
import retrofit2.Retrofit;

Proxy proxy = new Proxy(
    Proxy.Type.HTTP,
    new InetSocketAddress("proxy.example", 8080));

OkHttpClient http = new OkHttpClient.Builder()
    .proxy(proxy)
    .build();

Retrofit retrofit = new Retrofit.Builder()
    .baseUrl("https://api.example/")
    .client(http)
    .build();

Гэты фрагмент будуе транспартны слой і асобнік Retrofit. Да выкліку build дадайце ў гэты будаўнік патрэбныя праграме фабрыкі канвертараў і адаптараў выклікаў, затым стварыце інтэрфейс службы з гэтага асобніка.

Пакідайце baseUrl накіраваным на сапраўдную службу API. Калі падставіць туды URL проксі, зменіцца мэта HTTP; гэта не наладжвае ўзгадненне з проксі. Базавы URL таксама захоўвае патрабаванне Retrofit да канцавога слеша. Дазволены тэст публічнага API без аўтэнтыфікацыі проксі можа ўзяць HTTP-адрас са спіса HTTP-проксі для асобнага аб’екта Proxy.

Яўны проксі OkHttp мае перавагу над яго ProxySelector. Выкарыстоўвайце гэта, калі кліент павінен мець фіксаванага пасярэдніка. Праграмам, якім патрэбна маршрутызацыя ў залежнасці ад мэты, лепш праектаваць гэтую палітыку праз падтрыманы селектар.

Калі інтэрфейс службы ўжо створаны з іншага асобніка Retrofit, пабудова новага асобніка не пераносіць запыты старога інтэрфейса. Трымайце наладжаны кліент, асобнік Retrofit і аб’ект службы на адным шляху стварэння.

Для проксі з аўтэнтыфікацыяй OkHttp прадастаўляе proxyAuthenticator асобна ад аўтэнтыфікацыі мэты. Наладзьце яго ў будаўніку OkHttp пры неабходнасці, затым перадайце гатовы кліент у Retrofit. Для проксі з Basic-аўтэнтыфікацыяй выкарыстоўвайце абмежаваную апрацоўку паўторных спроб proxyAuthenticator.

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