Uzu prokurilan IP kun urllib3

Elektu ProxyManager por HTTP-prokurilo, inspektu la respondkampojn de urllib3 kaj konsideru reprovojn kaj la apartan SOCKS-administrilon.

Por malgranda urllib3-prokurila diagnozo uzu ProxyManager kun reprovoj malŝaltitaj. Tio raportas la unuan provon anstataŭ pli longe reprovi eron, kiu ne plu funkcias. En projekto regata de uv:

uv add urllib3

Anstataŭigu la dokumentan finpunkton per HTTP-prokurilo de via servo aŭ el la listo de HTTP-prokuriloj kaj faru la peton tra tiu administrilo:

import urllib3

proxy = urllib3.ProxyManager(
    "http://203.0.113.10:8080",
    timeout=urllib3.Timeout(connect=5, read=10),
    retries=False,
)

try:
    response = proxy.request("GET", "https://example.com/")
    print(response.status)
    print(response.data.decode("utf-8", errors="replace")[:200])
finally:
    proxy.clear()

Legu unue response.status, poste inspektu response.data. Tiuj estas la kampoj de urllib3; la Requests-stilaj status_code kaj text ne estas anstataŭaĵoj. Reteja rifuzo povas alveni tra funkcianta prokurilo. Escepto antaŭ respondo kontraŭe indikas malsukceson kompletigi la peton.

retries=False estas diagnoza elekto, ne produktada reprovpolitiko. La 5-sekunda konekta kaj 10-sekunda lega agordoj limigas siajn proprajn fazojn; ili ne sumiĝas al garantiita 15-sekunda tuta tempolimo. DNS kaj responda progreso povas influi la tutan atendon.

La ekzemplo antaŭŝargas la korpon kaj fine malplenigas la konektarojn de la administrilo. Por ripetaj petoj tra la sama finpunkto konservu tiun administrilon ĝis la laboro finiĝas por reuzi konektojn. Ŝanĝi al preload_content=False ŝanĝas tiun vivciklon: la alvokanto devas legi kaj liberigi la fluan respondon.

Elektu la administrilon laŭ la aŭskultanta servo. Ordinara PoolManager ne ekuzas prokurilon nur ĉar URL estas konservita aliloke; SOCKS uzas urllib3.contrib.socks.SOCKSProxyManager kaj ĝiajn nedevigajn dependecojn. La supra kodo sekvas la HTTP-ProxyManager-vojon.

Rilataj artikoloj