Jak sprawdzić, czy proxy działa (i czy nie ujawnia waszego IP)

Proxy może odpowiedzieć i mimo to ujawnić wasz prawdziwy adres IP. Przed wrzuceniem punktu końcowego na produkcję sprawdźcie wyjście, DNS, WebRTC, protokół i czarne listy.

Jak sprawdzić, czy proxy działa (i czy nie ujawnia waszego IP)

To, że proxy „działa”, oznacza dwie różne rzeczy. Brama musi przyjąć waszego klienta i pobrać stronę. Reszta urządzenia musi też przestać odsłaniać prawdziwy adres IP. Sporo punktów końcowych przechodzi pierwszy test i odpada na drugim.

Zróbcie to sprawdzenie, zanim przeskalujecie plan. Zróbcie je znowu po rotacji. Pule się zmieniają. Firmware przeglądarki w telefonie się zmienia. Wczorajszy zaliczony test nie jest umową.

01Najpierw potwierdźcie adres IP wyjścia#

Skierujcie prostego klienta na proxy. Użyjcie tego samego protokołu i uwierzytelniania, których użyjecie na produkcji. Potem poproście o stronę, która oddaje adres IP klienta.

Sprawdzanie proxy testuje, czy punkt końcowy odpowiada z serwera Top Proxy, i zgłasza pierwszy protokół, który przechodzi. Automatycznie próbuje SOCKS5, HTTP, SOCKS4 i HTTPS w tej kolejności, więc zaliczony wynik nie dowodzi, że działa każdy protokół. Sprawdzenie nie konfiguruje waszej przeglądarki i nie testuje jej DNS, WebRTC ani połączeń bezpośrednich. Jeśli dostawca stosuje listę dozwolonych IP, porażka po stronie serwera może oznaczać, że serwer sprawdzania nie jest dozwolony; zanim uznacie punkt końcowy za martwy, zweryfikujcie go z uprawnionego klienta.

Otwórzcie Wasze IP przez to samo proxy. Odczytajcie kraj, ASN oraz etykietę hosting kontra rezydenckie, jeśli strona ją pokazuje. Porównajcie to z tym, co kupiliście. Produkt „US residential”, który wychodzi na chmurowym ASN, to zły produkt, nie problem ustawień.

Powtórzcie lookup po rotacji. Mieszana pula może na następnym identyfikatorze sesji oddać inny kraj. Jeśli płaciliście za proxy US, druga próbka nadal powinna być w Stanach Zjednoczonych.

02Szukajcie wycieków wokół proxy#

Proxy pokrywa tylko ruch, który wasz klient przez nie wysyła. Wszystko inne nadal może używać waszej prawdziwej sieci.

Zachowanie DNS zależy od protokołu i klienta. W curl socks5:// rozwiązuje nazwy docelowe lokalnie, a socks5h:// prosi proxy SOCKS5, żeby je rozwiązało. Osobny resolver DNS zmienia, kto dostaje wasze zapytanie; nie dowodzi, że zapytanie idzie przez wasze proxy. Sprawdźcie własne ustawienia proxy i DNS przeglądarki, a potem w tym samym profilu puśćcie test wycieku DNS. Porównajcie wynik z resolverem, którego chcieliście użyć. Schematy opisuje dokumentacja proxy curl.

WebRTC może używać ścieżek połączenia poza proxy HTTP. W teście WebRTC w rzeczywistym profilu przeglądarki obejrzyjcie adresy kandydatów. Jeśli pojawia się wasz oryginalny publiczny IP, przejrzyjcie ustawienia prywatności WebRTC tej przeglądarki i powtórzcie test. Ograniczenia przeglądarki i maskowanie adresów bywają różne, więc sam wynik sprawdzania proxy nie ustala, że WebRTC jest pokryte. MDN wyjaśnia adresy kandydatów ICE i prywatność.

IPv4 i IPv6 wymagają osobnych obserwacji. Połączenie IPv4 z bramą HTTP albo SOCKS nie implikuje, że połączenie z celem jest IPv4, a sam fakt, że urządzenie ma IPv6, nie oznacza, że witryna omija proxy. Przetestujcie echo IPv4 i IPv6 przez rzeczywistego klienta, a potem obejrzyjcie reguły ominięcia i aplikacje, które potrafią łączyć się bezpośrednio. Wybierzcie dostawcę, który obsługuje rodzinę adresów, jakiej zadanie potrzebuje na celu.

Aplikacje mogą omijać systemowe proxy. Natywna aplikacja może zignorować ustawienie systemu i połączyć się bezpośrednio. Skonfigurujcie proxy metodą, którą aplikacja naprawdę obsługuje, a potem przetestujcie tę aplikację. Jeśli klient obsługuje oba, zobaczcie SOCKS5 a HTTP.

03Sprawdźcie reputację, nie tylko osiągalność#

Adres IP może pobrać stronę i nadal być bezużyteczny do waszego zadania. Flagowanie hostingu, czarne listy i wcześniejsze nadużycia siedzą na adresie.

Jeśli zadaniem jest poczta, rejestracja albo cokolwiek, co inni już spalili, puśćcie wyjście przez czarną listę IP. Wpis na liście to ostrzeżenie. To nie ocena moralna. Współdzielone pule rezydenckie zbierają wpisy. Dedykowane adresy datacenter też.

Jeśli zadaniem jest scraping, pobierzcie prawdziwy URL celu, nie tylko usługę echo. Część hostów wpuszcza https://httpbin.org i nadal blokuje stronę z katalogu. Zapiszcie kod statusu, długość ciała i to, czy pojawiło się wyzwanie. To jedyny wynik, który się liczy.

Jeśli zadaniem jest geo QA, porównajcie stronę, której chcieliście, ze stroną, którą dostaliście. Waluta, język i katalog powinny zgadzać się z krajem, który kupiliście. Poprawny ASN przy złym sklepie oznacza, że witryna używa innego sygnału.

04Zróbcie sprawdzenie powtarzalnym#

Zapiszcie kroki. Ten sam klient, to samo uwierzytelnianie, ten sam URL echo, ten sam URL celu, te same strony wycieków. Odpalajcie je przy zakupie. Odpalajcie przy rotacji. Odpalajcie, gdy zadanie zaczyna padać.

Zapisujcie adres IP wyjścia, ASN, protokół i to, czy DNS albo WebRTC pokazały wasz prawdziwy adres. Gdy sprzedawca zmieni port, będziecie wiedzieć, co się zmieniło.

Nie pomijajcie pomyłek uwierzytelniania. Użytkownik i hasło w złym polu wyglądają jak martwe proxy. Uwierzytelnianie listą IP wygląda jak martwe proxy z nowej sieci biurowej. Naprawcie auth, zanim otworzycie zgłoszenie.

Zanim przeskalujecie zakup, porównajcie proxy rezydenckie i proxy datacenter z protokołem, krajem i zachowaniem sesji, które właśnie przetestowaliście. Potwierdźcie te wymagania w opublikowanej ofercie dostawcy, a potem zacznijcie od małego planu.

Zaliczony test serwera ustala osiągalność dla tego sprawdzenia. Działająca konfiguracja wymaga też, żeby rzeczywisty klient używał oczekiwanego wyjścia i zwracał zamierzoną stronę celu, z osobnymi sprawdzeniami ścieżek połączenia, które chcecie pokryć. Zapisujcie każdy wynik, zamiast traktować jeden zielony status jako pełną gwarancję prywatności.