Vissa appar vill ha IP:port. Andra behöver en URL som börjar med http:// eller socks5://. Webbläsarinställningar har ofta olika fält för adress och port. Samma slutpunkt kan därför visas i flera format utan att adressen ändras.

En IPv4-post

Anta att en HTTP-proxylista ger dig exempelproxyn 203.0.113.10:8080 för HTTP.

Appen frågar efterAnge
Värd eller IP203.0.113.10
Port8080
HTTP-proxy-URLhttp://203.0.113.10:8080

Ange inte porten två gånger. Om appen redan har ett portfält kan 203.0.113.10:8080 i värdfältet få den att försöka slå upp hela strängen som ett värdnamn. Lägg inte heller till ett schema i ett fält som uttryckligen bara väntar sig en IP-adress.

Schemat måste passa tjänsten. Välj HTTP eller SOCKS5 efter klientens stöd innan du omvandlar adressen. Att skriva socks5:// framför en HTTP-slutpunkt ändrar det klienten skickar; det aktiverar inte SOCKS5 på servern.

IPv6 behöver hakparenteser i en URL

En IPv6-adress innehåller redan kolon, så URL:en omsluter adressen med hakparenteser innan porten läggs till:

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

Utan parenteserna är gränsen mellan adress och port tvetydig. En app med separata fält vill vanligen ha 2001:db8::10 som värd och 8080 som port; följ dess inmatningsformat. Båda adresserna här är dokumentationsexempel, inte aktiva proxyer.

Tolka URL:er i stället för att dela vid varje kolon

Ett litet Python-skript kan hantera IPv4-URL:er och IPv6-URL:er med parenteser med standardbibliotekets URL-tolk:

from urllib.parse import urlsplit

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

Egenskapen hostname returnerar adressen utan parenteserna. Att dela originalsträngen vid varje kolon skulle förstöra exemplet. I en verklig importfunktion ska även saknade värdar, scheman som inte stöds och portar utanför 1–65535 avvisas. URL-tolkning ger dess delar; det bevisar inte att tjänsten finns.

När listan innehåller användarnamn och lösenord

Ett vanligt URL-format är http://username:password@host:port. Tecken som @, # och / i inloggningsuppgifter kräver korrekt URL-kodning. Om klienten har separata fält för uppgifterna är det oftast enklare att använda dem än att bygga en URL manuellt.

Kontrollera leverantörens ursprungliga format innan du omvandlar en kolonseparerad sträng med inloggningsuppgifter. Fyra kolonseparerade fält har ingen universell betydelse, och lösenordet kan självt innehålla kolon. En tolk för enkla IP:port-rader ska inte tyst gissa sig genom ett annat format.

Relaterade artiklar