Sie setzen einen deutschen Exit, die Adresse geolokalisiert korrekt, und das Ziel behandelt die Sitzung trotzdem als verdächtig oder liefert Ihnen Inhalte, die für einen anderen Ort gedacht sind. Die IP war richtig. Alles andere an der Anfrage beschrieb immer noch einen Besucher in einem anderen Land.
Standort ist kein einzelnes Signal. Es ist ein Cluster davon, und ein echter Besucher erzeugt sie alle vom selben Ort aus, weil sie von einer Maschine in einem Land stammen. Ein Scraper setzt sie aus verschiedenen Quellen zusammen: Das Land kommt aus einem Proxy-Parameter, die Zeitzone von der Uhr des Servers, die Locale von einem Bibliotheks-Standardwert, und der Language-Header von dem, was fest codiert wurde. Wenn diese nicht übereinstimmen, ist der Widerspruch leichter erkennbar als jeder einzelne Wert für sich, und er kann auch verändern, was Sie sammeln.
Die Signale, die übereinstimmen müssen
Sechs Dinge verraten einer Website, wo Sie sich befinden, und es lohnt sich, sie explizit aufzuzählen, da die meisten Scraper nur eines oder zwei kontrollieren.
Die IP-Adresse ist das primäre Signal und dasjenige, das Ihr Proxy setzt. Accept-Language ist der HTTP-Header, der die Sprachpräferenz ausdrückt, und viele Websites liefern Inhalte direkt danach aus. Zeitzone ist in einem Browser über die JavaScript-Date-API beobachtbar und, genauer, über die von der Intl-API aufgelöste Zeitzone. Locale umfasst navigator.language und die Formatierungskonventionen, die die Intl-API auflöst, welche bestimmen, wie Datum, Zahlen und Währung dargestellt werden. Währung und Einheiten, sofern eine Website dem Client erlaubt, diese anzudeuten. Und DNS-Auflösung, was unabhängig klingt, aber es nicht ist: Wenn Ihr Client Hostnamen lokal auflöst, während er remote exitet, findet die Auflösung von Ihrem Standort aus statt und kann Ihnen einen regional falschen Endpunkt zuweisen, was das Problem des DNS-Leaks ist.
Für reine HTTP-Arbeit sind nur die ersten beiden und DNS sichtbar, weshalb der Artikel über Header Accept-Language als die Haupt-Paarung behandelt. Für Browser-Automatisierung sind alle sechs beobachtbar, und dort treten Diskrepanzen üblicherweise auf.
Alles aus einer einzigen Quelle der Wahrheit ableiten
Die Lösung ist struktureller Natur, nicht nur eine Checkliste. Wenn das Land an einer Stelle gewählt wird und die Zeitzone an einer anderen, werden sie beim ersten Mal, wenn jemand einen neuen Markt hinzufügt, voneinander abweichen. Definieren Sie jeden Markt einmal, mit jedem Signal, das er impliziert, und leiten Sie die gesamte Sitzung aus diesem Datensatz ab.
MARKETS = {
"de": {"lang": "de-DE,de;q=0.9,en;q=0.8", "locale": "de-DE",
"tz": "Europe/Berlin", "currency": "EUR"},
"us": {"lang": "en-US,en;q=0.9", "locale": "en-US",
"tz": "America/New_York", "currency": "USD"},
"jp": {"lang": "ja-JP,ja;q=0.9,en;q=0.8", "locale": "ja-JP",
"tz": "Asia/Tokyo", "currency": "JPY"},
"br": {"lang": "pt-BR,pt;q=0.9,en;q=0.8", "locale": "pt-BR",
"tz": "America/Sao_Paulo", "currency": "BRL"},
}
def proxy_for(country, session=None):
user = f"customer-USERNAME-country-{country}"
if session:
user += f"-sid-{session}-ttl-600"
url = f"http://{user}:PASSWORD@p.shifter.io:443"
return {"http": url, "https": url}Jetzt ist ein Markt ein einzelnes Argument, und es gibt keinen Codepfad, in dem Land und Zeitzone voneinander abweichen können, weil niemand sie getrennt setzt.
Anwendung auf eine Browser-Sitzung
Frameworks für Browser-Automatisierung stellen Zeitzone und Locale als Kontextoptionen zur Verfügung, und das ist der richtige Ort, um sie zu setzen: Sie greifen, bevor irgendein Seitenskript läuft, sodass die Seite nicht die tatsächlichen Werte der Maschine beobachten kann.
# Playwright: proxy, timezone and locale all derived from one market record
m = MARKETS[country]
context = browser.new_context(
proxy={"server": "http://p.shifter.io:443",
"username": f"customer-USERNAME-country-{country}-sid-{sid}",
"password": "PASSWORD"},
locale=m["locale"], # navigator.language and Intl formatting
timezone_id=m["tz"], # Intl resolved time zone and Date offset
extra_http_headers={"Accept-Language": m["lang"]},
)Es ist wichtig, diese auf Kontextebene zu setzen, statt Eigenschaften nachträglich zu patchen, denn ein gepatchtes Intl.DateTimeFormat, das mit dem Date-Offset nicht übereinstimmt, ist selbst eine erkennbare Inkonsistenz, und Erkennungsskripte prüfen die beiden routinemäßig gegeneinander.
Präzision, und wie viel davon Sie brauchen
Länder-Granularität reicht für die meisten Arbeiten aus, da Zeitzone und Locale weitgehend national sind. Drei Fälle erfordern mehr Sorgfalt.
Länder mit mehreren Zeitzonen machen einen nationalen Standardwert für einen Teil der Bevölkerung falsch. Ein US-Exit ist in mehreren Zonen plausibel, daher sollten Sie, wenn Sie mit Targeting auf Stadtebene arbeiten, die Zeitzone von der Stadt statt vom Land ableiten, und wenn nicht, wählen Sie die Zone, die dem größten Anteil der Nutzer entspricht, und bleiben Sie konsistent, statt zu randomisieren.
Länder mit mehreren offiziellen Sprachen erfordern eine bewusste Wahl: Ein Schweizer oder kanadischer Exit kann plausibel mehrere Locales sein, und die richtige Antwort ist meist diejenige, die zu den Inhalten passt, die Sie sammeln, konstant gehalten.
Regionale Formatierungsunterschiede sind subtiler und selten der Mühe wert, ihnen nachzujagen, aber wenn Sie eine Locale angeben, lassen Sie die Intl-API die Formatierung übernehmen, statt Datums- und Zahlenformate selbst zu bauen, die möglicherweise nicht dem entsprechen, was diese Locale tatsächlich erzeugt.
Konsistenz über die Lebensdauer einer Sitzung
Eine Sitzung ist eine Geschichte, und die Geschichte darf sich nicht auf halbem Weg ändern. Wenn eine Sticky Session eine Adresse für einen mehrstufigen Ablauf hält, muss jede Anfrage in diesem Ablauf dieselbe Sprache, Zeitzone und Locale tragen. Eine dieser Angaben mitten im Ablauf zu ändern, beschreibt einen Besucher, der zwischen dem Klicken auf Suche und dem Betrachten eines Ergebnisses das Land gewechselt hat, was eine stärkere Anomalie ist als jede statische Diskrepanz.
Hier zahlt sich die Ableitung aus einem einzigen Marktdatensatz erneut aus: Die Sitzungskennung und das Locale-Bündel stammen aus derselben Quelle und dauern gleich lange. Verbinden Sie sie explizit miteinander, sodass die Freigabe der Sitzung die gesamte Identität freigibt, und eine neue Sitzung eine frische, in sich konsistente beginnt. Die gleiche Logik gilt für die Paarung von Gerätefingerprints mit Netzwerkidentität in Antidetect-Browsern.
Überprüfen, ob Sie es richtig gemacht haben
Nehmen Sie nichts an und prüfen Sie beide Ebenen.
Erstens, was der Browser über sich selbst meldet. Führen Sie eine Seite aus, die die aufgelöste Zeitzone, navigator.language und ein formatiertes Datum ausliest, und bestätigen Sie, dass sie dem beabsichtigten Markt entsprechen. Dies erkennt Konfigurationsfehler sofort.
JSON.stringify({
tz: Intl.DateTimeFormat().resolvedOptions().timeZone,
lang: navigator.language,
langs: navigator.languages,
offset: new Date().getTimezoneOffset(),
})Zweitens, und aussagekräftiger, was das Ziel tut. Rufen Sie eine geo-sensitive Seite ab und bestätigen Sie, dass Währung, Sprache und regionale Inhalte dem entsprechen, was ein lokaler Besucher sehen würde. Das eigene Verhalten der Website ist das eigentliche Urteil, da Geolokalisierungsdatenbanken und die Einschätzung eines Ziels nicht immer übereinstimmen, und dafür ist das Testen der Standortgenauigkeit gedacht. Wenn die Adresse korrekt geolokalisiert, der Inhalt aber falsch ist, verdächtigen Sie zuerst die DNS-Auflösung, bevor Sie etwas anderes vermuten.
Fazit
Standort ist ein Cluster von Signalen, und eine Website liest sie gemeinsam. Ein Land am Proxy zu setzen, während Zeitzone, Locale und Sprache auf dem verbleiben, was Ihr Server standardmäßig vorgibt, erzeugt einen Besucher, der nicht existieren kann, was sowohl ein Erkennungssignal als auch eine Quelle still falscher Daten ist. Definieren Sie jeden Markt einmal mit jedem Signal, das er impliziert, leiten Sie die Proxy-Parameter und den Browser-Kontext aus diesem einen Datensatz ab, sodass sie nicht voneinander abweichen können, setzen Sie Zeitzone und Locale auf Kontextebene statt sie nach dem Laden zu patchen, halten Sie das gesamte Bündel über die Lebensdauer einer Sitzung konstant, und überprüfen Sie auf beiden Ebenen, was der Browser meldet und was das Ziel tatsächlich ausliefert. Dann sagt Ihr Traffic über seinen Standort nur genau das eine aus, was Sie gewählt haben.
Die Geografie selbst stammt von Residential Proxies, echten Adressen in Heimnetzqualität mit Land- und Stadt-Targeting, sodass der Standort, den Ihre Sitzung behauptet, ein Standort ist, von dem Sie tatsächlich exiten, mit Preisen pro GB, die sich dafür eignen, denselben Job über viele Märkte hinweg laufen zu lassen.