Rotera proxy-IP:n utan VPN: vad utgången ser

Proxyrotation och en VPN ändrar din offentliga adress på olika lager, och den skillnaden avgör vad som läcker. En VPN flyttar varje paket in i en tunnel, så källadressen som målet ser är tunnelns ändpunkt. En proxy sitter ovanför nätverkslagret: bara de förfrågningar du skickar genom den syns från utgången, medan allt annat på maskinen behåller den riktiga adressen. Får du den uppdelningen rätt blir rotation från en kryssruta till ett designbeslut.

Varifrån den offentliga adressen egentligen kommer

Adressen ett mål ser är den som din trafik senast lämnade, och på en hemanslutning är det leverantörens adress på din router, inte något maskinen äger. Att starta om routern kan ge samma lease tillbaka, och att ändra dess MAC-adress ger ibland en ny, men ingen av dem ger dig ett landsval. En VPN ersätter källadressen på IP-lagret, så varje paket från maskinen, inklusive DNS och bakgrundsuppdateringar, lämnar tunnelns ändpunkt. En proxy arbetar ett lager högre: den tar emot en förfrågan, öppnar sin egen anslutning till målet, och bara den förfrågan syns från utgången. Allt annat på maskinen använder fortfarande den riktiga adressen.

Den uppdelningen förklarar de flesta överraskningarna. Ett webbläsartillägg riktat mot en proxy ändrar bara det webbläsaren skickar och inget annat, så ett andra program på samma värd läcker fortfarande den ursprungliga adressen. En systemomfattande VPN har det motsatta felläget: den täcker trafik du ville hålla lokal och stängs bara om klienten är konfigurerad för det. Att välja mellan de två är egentligen att välja vilken trafik som måste flytta sig.

Rotation gäller då för det lager du valde. Med en proxy betyder rotation att nästa förfrågan använder en annan utgång. Med en VPN betyder det att riva tunneln och bygga upp den igen, vilket är långsammare och visar sig som en synlig återanslutning.

Vad en HTTP-proxy kan läsa, och vad den inte kan

Vid vanlig HTTP ser proxyn en absolut URI i förfrågningsraden, varje header och kroppen. Den kan logga allt detta och skriva om vilken del som helst, och därför gör en gratis proxy som injicerar ett skript i svar exakt det protokollet tillåter. Autentisering använder Proxy-Authorization, och en saknad eller felaktig inloggningsuppgift ger 407 Proxy Authentication Required i stället för ett anslutningsfel.

Vid HTTPS skickar klienten CONNECT host:port och proxyn öppnar en rå tunnel, och därefter ser den krypterade byte. Den lär sig fortfarande värdnamnet från CONNECT-raden och vanligtvis från SNI-fältet i TLS-handskakningen, så loggning på värdnamnsnivå överlever även när nyttolasten inte gör det. Att läsa nyttolasten kräver att avsluta TLS med ett certifikat som klienten litar på, vilket är en annan produkt med en annan risk. Den HTTP-semantikspecifikationen definierar CONNECT som en tunnelbegäran, vilket är rätt tankemodell för vad en utgång kan och inte kan se.

curl -v -x http://proxy.example.net:8080 https://example.com 2>&1 | grep -E 'CONNECT|Proxy-'

Den utförliga utdata visar CONNECT-raden före all TLS-trafik, och det är ögonblicket då proxyn lär sig din destination. En proxy som svarar med 407 öppnade aldrig tunneln, så ett nytt försök med andra TLS-inställningar hjälper inte.

Rotationsgranulariteten avgör vad som går sönder

Att rotera vid varje förfrågan är inställningen som ser säkrast ut och bryter mest. Cookies, CSRF-token och sessioner på serversidan är bundna till en identitet, och en identitet som ändras mellan inloggningen och nästa anrop ser för målet ut som sessionskapning. Många leverantörer erbjuder en klibbig session genom att koda den i proxyns användarnamn, så utgången förblir fast under ett valt fönster.

Välj granulariteten utifrån uppgiften, inte utifrån leverantörens standard. En crawler som hämtar oberoende sidor kan rotera per förfrågan, medan ett betalningsflöde eller ett autentiserat API måste hålla en utgång genom hela flödet. De två anropen nedan visar ett klibbigt användarnamn och en vanlig roterande slutpunkt, och socks5h schemat löser namn hos proxyn i stället för lokalt.

curl -sS -x http://user-session-a1b2:[email protected]:8080 https://ifconfig.me
curl -sS -x socks5h://127.0.0.1:1080 https://ifconfig.me

Lokal DNS är ett tyst läckage. Om klienten löser namnet innan den ansluter lär sig resolvern fortfarande varje värd du besöker, även om HTTP-förfrågan lämnar någon annanstans. Den socks5h formen och upplösningen på proxysidan undviker det, och det kostar ingenting att använda dem.

Vad målet klassificerar utöver adressen

Adressens rykte är en ingång bland flera. Mål kombinerar ASN och dess etikett datacenter eller bostad, klientens TLS-fingeravtryck, HTTP/2-inställningar, headerns ordning, förfrågningsfrekvens och navigeringens form. En bostadsutgång som drivs av en huvudlös webbläsare kan misslyckas där en datacenterutgång som drivs av en riktig session går igenom.

Utgångstypen avgör vad du ärligt kan påstå om trafiken, och var och en bär en annan kostnad.

En delad utgång är inte neutral. Allt annat som körs från den adressen landar i samma rykteshink, och en adress som andra hyresgäster redan bränt misslyckas innan din första förfrågan läses.

Välj en utgång du kan beskriva i en policy

Den användbara frågan är inte hur du döljer adressen utan vem som ansvarar för trafiken som lämnar den. Din egen molnutgång per uppgift, en kontrakterad leverantör med ett databehandlingsavtal och publicerad lagring, och en självhostad VPN med en identitet per uppgift kan alla beskrivas i en mening. En gratis lista kan inte, eftersom dess operatör inte har någon skyldighet mot dig och har varje incitament att logga.

Håll dina egna hastighetsgränser under det målet tolererar, och samla bara de fält uppgiften behöver, så att ett fel förblir litet. Snabbare rotation för att slippa undan en blockering höjer oftast den förfrågningsfrekvens som orsakade den.

Skriv den valda utgången, dess rotationsfönster och dess ägare i jobbkonfigurationen före första körningen. När blockeringen kommer är det anteckningen som säger om du ska byta utgång eller ändra beteende.