Erabili proxy IP bat urllib3-rekin

urllib3 proxy-diagnostiko txiki baterako, erabili ProxyManager berriz saiatzea desgaituta. Horrek lehen saiakera erakusten du, jada ez dabilen sarrera batekin denbora gehiago eman ordez. uv-k kudeatutako proiektu batean:

uv add urllib3

Ordeztu dokumentazioko amaierako puntua zure zerbitzuko HTTP proxyarekin edo HTTP proxyen zerrendako batekin, eta egin eskaera kudeatzaile horren bidez:

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()

Irakurri lehenik response.status eta gero aztertu response.data. Horiek urllib3-ren eremuak dira; Requestsen estiloko status_code eta text ez dira ordezkoak. Webgunearen ukapena proxy funtzional baten bidez irits daiteke. Erantzuna baino lehenagoko salbuespenak, aldiz, eskaera ezin amaitu izana adierazten du.

retries=False diagnostikorako hautua da, ez ekoizpenerako berriz saiatzeko politika. 5 segundoko konexioak eta 10 segundoko irakurketak bakoitzaren fasea mugatzen dute; ez dute 15 segundoko guztizko epe bermatua osatzen. DNSak eta erantzunaren aurrerapenak itxaronaldi osoan eragin dezakete.

Adibideak gorputza aurrez kargatzen du eta amaieran kudeatzailearen konexio-multzoak hustu. Puntu beretik eskaera errepikatuak egiteko, mantendu kudeatzaile hori lana amaitu arte, konexioak berrerabili ahal izateko. preload_content=False erabiltzeak bizi-zikloa aldatzen du: deitzaileak fluxuko erantzuna irakurri eta askatu behar du.

Hautatu entzuten ari den zerbitzuari dagokion kudeatzailea. Ohiko PoolManager batek ez du proxyrik erabiltzen URL bat beste nonbait gordetzeagatik; SOCKSek urllib3.contrib.socks.SOCKSProxyManager eta haren aukerako mendekotasunak erabiltzen ditu. Goiko kodeak HTTP ProxyManager bidea jarraitzen du.