Ang file ng proxy mo ay isang pool, hindi routing table ng Requests

Gawing isang piling endpoint ang isang authenticated na entry sa listahan ng proxy nang hindi ginagamit ang mga address ng proxy bilang mga key ng routing ng destinasyon.

Pumili ng isang proxy mula sa file, pagkatapos ay buuin ang mapa ng ruta para sa kahilingan sa website. Ang pool ng mga kandidatong endpoint ay hindi mismo diksyunaryo ng routing ng Requests.

  1. I-parse ang entry ayon sa tinukoy na format. Ang impormal na linyang IP:port:user:password ay malabo kapag ang mga address ng IPv6 o kredensyal ay may mga tutuldok. Para sa isang host na IPv4, numeric na port at username na walang tutuldok, maaaring iwan ng limitadong paghati ang natitirang teksto bilang password. Gumamit ng hiwalay na structured na field kapag hindi angkop ang mga paghihigpit na iyon.
  2. Piliin ang endpoint para sa operasyong ito. Panatilihin ang totoong protocol nito at i-encode ang mga bahagi ng kredensyal kapag binubuo ang URL nito. Ilayo ang value na may lihim na iyon sa mga karaniwang log.
  3. I-map ang mga scheme ng destinasyon sa napiling URL na iyon. Para sa isang napiling HTTP proxy, maaaring ganito ang mapa:
routes = {
    'http': selected_proxy_url,
    'https': selected_proxy_url,
}

Pinipili ng mga key na http at https ang mga scheme ng destinasyon. Ang isang key na tulad ng http://203.0.113.10 ay pumipili sa halip ng mga kahilingan patungo sa eksaktong host ng destinasyong iyon; hindi nito nilalagyan ng label ang proxy sa address na iyon. Ang paggamit ng bawat IP ng proxy bilang key ay maaaring mag-iwan sa isang walang kaugnayang website na walang inaasahang ruta.

I-parse ang pool nang isang beses, pumili ng endpoint at gumawa ng mapping para sa tawag ng kliyente. Ang paghihiwalay ng mga hakbang na iyon ay nagpapahintulot sa iyong baguhin ang patakaran sa pagpili nang hindi binabago ang ibig sabihin ng mga key ng routing ng Requests.

Kaugnay na mga artikulo