IP i port proxy: jakiego formatu potrzebuje aplikacja?

Niektóre aplikacje wymagają IP:port. Inne potrzebują adresu URL zaczynającego się od http:// lub socks5://. Ustawienia przeglądarki często mają osobne pola adresu i portu. Ten sam punkt końcowy może więc występować w kilku formatach bez zmiany adresu.

Wpis IPv4

Załóżmy, że lista proxy HTTP podaje przykładowe proxy HTTP 203.0.113.10:8080.

Nie podawaj portu dwukrotnie. Jeżeli aplikacja ma osobne pole portu, wpisanie 203.0.113.10:8080 w polu hosta może spowodować próbę rozwiązania całego ciągu jako nazwy hosta. Podobnie nie dodawaj schematu do pola, które wyraźnie oczekuje samego adresu IP.

Schemat musi odpowiadać usłudze. Przed przekształceniem adresu wybierz HTTP lub SOCKS5 zgodnie z obsługą klienta. Dopisanie socks5:// przed punktem końcowym HTTP zmienia to, co wysyła klient; nie włącza SOCKS5 na tym serwerze.

IPv6 wymaga nawiasów kwadratowych w URL

Adres IPv6 zawiera już dwukropki, dlatego w URL przed dodaniem portu ujmuje się adres w nawiasy kwadratowe:

http://[2001:db8::10]:8080
socks5://[2001:db8::10]:1080

Bez nawiasów granica między adresem a portem jest niejednoznaczna. Aplikacja z osobnymi polami zwykle oczekuje 2001:db8::10 jako hosta i 8080 jako portu; przestrzegaj jej formatu wejścia. Oba użyte tu adresy to przykłady dokumentacyjne, a nie działające proxy.

Parsuj URL zamiast dzielić przy każdym dwukropku

Krótki skrypt Pythona może obsłużyć URL IPv4 i IPv6 z nawiasami za pomocą standardowego parsera URL:

from urllib.parse import urlsplit

proxy = urlsplit("http://[2001:db8::10]:8080")
print(proxy.scheme)
print(proxy.hostname)
print(proxy.port)

Właściwość hostname zwraca adres bez nawiasów. Podział oryginalnego ciągu przy każdym dwukropku zepsułby ten przykład. W rzeczywistym importerze odrzucaj też brak hosta, nieobsługiwane schematy i porty spoza zakresu 1–65535. Parsowanie URL daje jego składniki; nie dowodzi istnienia usługi.

Gdy lista zawiera nazwę użytkownika i hasło

Typowy układ URL to http://username:password@host:port. Znaki takie jak @, # i / w danych logowania wymagają poprawnego kodowania URL. Jeżeli klient udostępnia osobne pola danych logowania, korzystanie z nich jest zwykle łatwiejsze niż ręczne tworzenie URL.

Przed przekształceniem ciągu danych logowania rozdzielonych dwukropkami sprawdź oryginalny format dostawcy. Cztery pola rozdzielone dwukropkami nie mają uniwersalnego znaczenia, a samo hasło może zawierać dwukropek. Parser prostych wierszy IP:port nie powinien po cichu zgadywać innego formatu.