Выкарыстоўвайце IP проксі з urllib3

Для невялікай дыягностыкі проксі ў urllib3 выкарыстоўвайце ProxyManager з адключанымі паўторнымі спробамі. Гэта паказвае першую спробу замест доўгага паўтарэння запісу, які ўжо не працуе. У праекце пад кіраваннем uv:

uv add urllib3

Замяніце дакументацыйны канцавы пункт HTTP-проксі вашага сэрвісу або запісам са спіса HTTP-проксі і выканайце запыт праз гэты менеджар:

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

Спачатку прачытайце response.status, потым праверце response.data. Гэта палі urllib3; status_code і text у стылі Requests іх не замяняюць. Адмова сайта можа прыйсці праз працоўны проксі. Выключэнне да адказу, наадварот, азначае, што запыт не ўдалося завяршыць.

retries=False — дыягнастычны выбар, а не палітыка паўтораў для працоўнага асяроддзя. Налады 5 секунд на злучэнне і 10 секунд на чытанне абмяжоўваюць свае этапы; яны не складаюць гарантаванага агульнага тэрміну 15 секунд. DNS і ход атрымання адказу могуць уплываць на агульнае чаканне.

Прыклад загадзя загружае цела і напрыканцы ачышчае пулы менеджара. Для паўторных запытаў праз той жа пункт захоўвайце менеджар да канца працы, каб паўторна выкарыстоўваць злучэнні. Пераход на preload_content=False змяняе жыццёвы цыкл: выклікальнік мусіць прачытаць і вызваліць струменевы адказ.

Выберыце менеджар адпаведна службе, якая слухае. Звычайны PoolManager не пачынае выкарыстоўваць проксі ад таго, што URL захаваны недзе яшчэ; SOCKS выкарыстоўвае urllib3.contrib.socks.SOCKSProxyManager і яго неабавязковыя залежнасці. Код вышэй ідзе шляхам HTTP ProxyManager.