Tarayıcı saat dilimi, dil ve konum: Sitelerin proxy'yi tespit ettiği üç alan

Giriş: Üç mütevazı alan bir hesabın kaderini nasıl belirliyor

Pasaport kontrolünü hayal edin. Bir ülkenin kimliğini uzatıyorsunuz, başka bir ülkenin dilinde konuşuyorsunuz ve kolunuzdaki saat üçüncü bir ülkenin saatini gösteriyor. Sınır görevlisinin karmaşık incelemelere ihtiyacı yok. Sadece birkaç ek soru sorar. Modern platformların antifraud sistemleri de hemen hemen böyle çalışır. Karmaşık ağ parmak izlerini çözmesine ya da grafik alt sistemlerin hash'lerini hesaplamasına gerek yok. Üç basit alanı karşılaştırması yeterli: tarayıcı saat dilimi, dil ve konum, ardından bunları IP adresinin anlattıklarıyla eşleştirmek.

Çoklu hesap projelerindeki gözlemlerimize göre, ilk 24 saat içinde profil kaybının nedenleri arasında ortam uyumsuzluğu açık ara birinci sırada. Hem proxy kalitesini hem de "ağır" parmak izlerini geride bırakıyor. Nedeni basit. İyi bir mobil proxy size gerçek bir operatörün temiz IP'sini verir, ancak bu IP'nin etrafındaki tüm ortamı siz kurarsınız. Ve işte tam burada, platformun milisaniyeler içinde fark ettiği çelişki çoğu zaman ortaya çıkar.

Bu rehberden öğrenecekleriniz:

• Sitelerin saat dilimini, dili ve konumu hangi API'ler ve başlıklarla okuduğunu;
• UTC'ye göre kaymanın ve bölge adının neden farklı varlıklar olduğunu ve fark üzerinden sahteciliğin nasıl yakalandığını;
• Accept-Language'in navigator.languages'ten farkını ve neden çelişmemeleri gerektiğini;
• Konum isteğiyle nasıl davranılacağını: reddetmek, izin vermek ya da koordinatları uyumlu hale getirmek;
• Mobil IP için uçtan uca bir ortam uyumlama çerçevesi ve öz-denetim protokolünün nasıl kurulacağını;
• Deneyimli ekiplerin bile yaptığı hataları ve bunlarla ne yapılması gerektiğini.

Canvas, WebGL, ses parmak izleri ve taşıma katmanı ağ imzalarına bilinçli olarak değinmiyoruz. Bloğun ayrı yazıları bu konulara ayrılmış. Buradaki odak tek: bağlam tutarlılığı. İlk kontrol edilen üç alan, antifraud için en ucuza aşılır ve birim çabaya karşılık en yüksek sinyali verir. Bu sinyali platforma hediye etmemeyi öğrenelim.

Temeller: Ortam uyumluluğu nedir ve IP neden her zaman haklı

Bağlam tutarlılığı kavramı

Ortam uyumluluğu, tarayıcının siteye verdiği kullanıcı konumu ve zamanına dair tüm sinyallerin aynı hikâyeyi anlatması durumudur. Referans noktası IP adresidir. Kullanıcı onu keyfi olarak değiştiremez, bu yüzden antifraud IP'yi en dürüst tanık olarak görür. Diğer tüm alanlar birbirleriyle değil, tam olarak onunla karşılaştırılır.

Buradan sonsuza kadar akılda tutulması gereken ilk kural çıkar: IP tarayıcıya uymaz, tarayıcı IP'ye uyar. Coğrafyası veritabanları tarafından Novosibirsk olarak belirlenen bir mobil proxy bağladıysanız, tüm profilin Novosibirsk ile "nefes alması" gerekir. Tarayıcı saat dilimi, dil, koordinatlar, tarih ve sayı biçimleri — hepsi sonuçtur, IP ise nedendir.

Üç alan yakın planda

Saat dilimi. Tarayıcı, işletim sisteminin hangi bölgede yaşadığını bilir ve bunu herhangi bir betiğe memnuniyetle bildirir. Üstelik birkaç yolla bildirir: IANA formatında bölge adı (örneğin Europe/Moscow veya Asia/Yekaterinburg), UTC'ye göre dakika cinsinden sayısal kayma ve tarih dizesinin içindeki yerelleştirilmiş etiket. Antifraud bu temsilleri hem birbirleriyle hem de IP için beklenen bölgeyle karşılaştırır.

Dil. En çok katmanlı alan budur. Dil, herhangi bir betik çalışmadan önce, her isteğin HTTP başlığı olan Accept-Language'de iletilir. Ardından JavaScript tarafında navigator.language ve navigator.languages aracılığıyla tekrarlanır. Daha sonra dil biçimlendirme yereline işler: tarihler, binlik ayırıcılar, ondalık virgül veya nokta, ay adları nasıl görünür. Son olarak, tarayıcının giriş olayları aracılığıyla gördüğü klavye düzenini etkiler.

Konum. Burada iki katman var. Pasif olan — IP coğrafi konum veritabanlarının sizin hakkınızda düşündükleri. Aktif olan — koordinatları yalnızca kullanıcı izniyle döndüren Geolocation API. "İzin ver"e basmadıysanız alanın boş kaldığını düşünmek hatalı. İzin durumunun kendisi, istek sırasındaki davranış ve dolaylı konum belirtileri de okunur.

Neden tam olarak bu üç alan kontrol ediliyor

Cevap antifraudun ekonomisinde yatıyor. Bu sinyaller:

• Ücretsiz okunur, ağır hesaplama ve özel izin gerektirmez (kesin koordinatlar hariç);
• Deterministiktir: gerçek bir kullanıcıda oturumdan oturuma neredeyse hiç değişmez;
• IP ile makine öğrenmesi olmadan basit bir kuralla doğrulanabilecek katı bir mantıksal bağa sahiptir;
• "Rastgele" sahteciliğe pek dayanmaz: bunları kaotik biçimde değiştirirseniz çelişkiler sadece çoğalır.

Başka bir deyişle, bu ilk filtredir. Tek başına banlamaz, ancak iç risk puanını yükseltir. Sonra daha pahalı kontroller devreye girer ve başlangıç puanı kötü olan profilin hata yapma hakkı çok daha az olur.

Normal bir kullanıcı nasıl görünür

Kazan'dan mobil internet üzerinden telefonuyla siteye giren gerçek bir aboneyi ele alalım. IP'si bir operatöre aittir ve coğrafi konum veritabanı adresi Tataristan Cumhuriyeti'ne ya da sıklıkla olduğu gibi adres havuzunun kayıtlı olduğu Moskova'ya atfedecektir. Tarayıcı saat dilimi — Europe/Moscow, kayma eksi 180 dakika. Dil — ru-RU, ikinci sırada en-US olabilir. Konum — ya hiç istenmemiştir ya da izin verilmiştir ve Kazan'ı onlarca metre hassasiyetle gösterir. Tarih biçimi — gün, ay, yıl, nokta ile. Her şey mantıklı, her şey uyuşuyor.

Şimdi aynı tablo, ancak tipik bir çoklu hesap operatörü hatasıyla: IP aynı, ama tarayıcı America/New_York gösteriyor, dil en-US ve koordinatlar eski profil şablonundan Berlin'in merkezi. Her alan tek başına masum görünüyor. Birlikte, var olmayan bir kullanıcı oluşturuyorlar.

Unutulan mobil IP özelliği

Burada tam olarak mobil proxy kitlesi için önemli bir incelik var. Coğrafi konum veritabanları abonenin fiziksel konumunu değil, operatörün adres aralığını bağladığı bölgeyi belirler. Bu yüzden Tümen'den gerçek bir kullanıcı, veritabanlarının Yekaterinburg'a hatta Moskova'ya atfettiği bir IP alabilir. Peki ne yapmalı? Fiziksel modemin nerede olduğuna değil, veritabanlarının ne gördüğüne odaklanın. Platform profilinizi gerçeklikle değil, kendi dizinlerindeki kayıtlarla karşılaştırır. Bu nedenle herhangi bir kurulumun ilk adımı, IP'nizin birkaç popüler veritabanı tarafından tam olarak nasıl sınıflandırıldığını öğrenmek ve ortamı zaten buna göre kurmaktır.

Derinlemesine inceleme: Siteler üç alanı gerçekte nasıl okuyor

Tarayıcı saat dilimi: Tek bir gerçeğin üç kaynağı

Antidetect kullanıcılarının çoğu saat dilimini tek bir sayı olarak düşünür. Pratikte tarayıcı en az üç bağımsız temsil verir ve antifraud bunların birbiriyle tutarlılığını kontrol eder.

Birincisi — Intl.DateTimeFormat().resolvedOptions().timeZone metodunun döndürdüğü IANA standardına göre bölge adı. Bu, Europe/Moscow, Asia/Novosibirsk, Europe/Berlin gibi bir dizedir. Kaymadan daha fazla bilgi taşır, çünkü yaz saati uygulaması geçiş kurallarını ve bölge değişiklik geçmişini kesin olarak belirler.

İkincisi — new Date().getTimezoneOffset()'ten sayısal kayma. UTC ile yerel saat arasındaki farkı dakika cinsinden, ters işaretle döndürür: Moskova için bu eksi 180. Kilit nokta: kayma belirli bir tarih için hesaplanır. Yaz saati olan bir bölge için Ocak ve Temmuz sonuçları farklıdır.

Üçüncüsü — Date.prototype.toString() aracılığıyla tarihin dize temsili; burada parantez içinde "Moskova, standart saat" veya "Central European Summer Time" gibi yerelleştirilmiş bölge adı belirtilir. Dikkat: etiket tarayıcı arayüz dilinde oluşturulur. Bu, tarayıcı saat dilimi ile dilin doğrudan kesiştiği ender noktalardan biridir ve bu kesişimde acemi sahtecilikler iyi görülür.

Bu size karşı nasıl kullanılıyor? Klasik teknik — 1 Ocak ve 1 Temmuz için kaymayı hesaplamak. Beyan edilen bölge Europe/Berlin ise, kaymalar 60 dakika farklı olmalı. Her iki değer de aynıysa, biri tarayıcıya yaz saati kurallarını öğretmeden bölgeyi değiştirmiş demektir. Ters durum da göstergeseldir: 2014'ten beri yaz saati olmayan Europe/Moscow bölgesi birden farklı kaymalar gösteriyor. Bir başka teknik — toString'deki yerelleştirilmiş etiketi navigator.language ile karşılaştırmak. Beyan edilen İngilizce dilinde Rusça etiket — bir işaret.

Bölgenin kendisinin yanı sıra siteler sistem saati senkronizasyon bozukluğuyla da ilgilenir. Betik sunucuya Date.now() değerini gönderir ve isteğin alınma zamanıyla karşılaştırır. Birkaç saniye içindeki fark normaldir. Dakikalar hatta saatler cinsinden fark, sistem saatının elle ve özensizce ayarlandığı anlamına gelir. Tek başına bu bir mahkûmiyet değildir, ancak diğer sinyallerle toplandığında ağırlık artar.

2026'da bu kümeye yavaş yavaş eski Date nesnesinin yerini alan Temporal API ekleniyor. Zamanı IANA bölgesine daha da sıkı bağlıyor ve basit kayma yoluyla sahteciliği neredeyse anlamsız kılıyor. Eğilim açık: tarayıcılar bölgenin sayı değil, adlandırılmış bir varlık olması yönünde ilerliyor.

Dil: Başlıktan sayı biçimine

Dil, üç alan arasında sunucunun sayfa yüklenmeden önce gördüğü tek alandır. Accept-Language başlığı ilk istekle birlikte gider ve şuna benzer: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7. q değerleri tercih ağırlıklarıdır, ilk elemandan sonuncuya doğru azalır. Dize formatı tarayıcıya ve sisteme bağlıdır: Chrome onu bir şekilde, Safari başka bir şekilde kurar ve antifraud şablonları ayırt edebilir.

Ardından dil istemci tarafında tekrarlanır. navigator.language ana dili, navigator.languages sıralı diziyi döndürür. Düzgün çalışan bir tarayıcıda bu dizi ile Accept-Language başlığı içerik ve sıra olarak eşleşir. Aralarındaki fark, ortamın farklı parçalardan toplandığının en sık ve en belirgin göstergelerinden biridir: başlık proxy istemcisi düzeyinde değiştirilmiş, JavaScript nesnesi ise sistem ayarlarıyla kalmış ya da tam tersi.

Sonra dil daha derine iner. Intl.DateTimeFormat().resolvedOptions().locale metodu biçimlendirme yerelini döndürür. Parametresiz toLocaleDateString() çağrısı tarihi bu yerelin formatında çizer: Rusça için 05.03.2026, Amerikan için 3/5/2026. Intl.NumberFormat binleri neyin ayırdığına karar verir — boşluk, virgül veya nokta. Tüm bunlar da beyan edilen dille ve özellikle saat dilimiyle dikkatlice karşılaştırılır. Asia/Tokyo bölgesi ve ru-RU biçimlendirme yereli olan bir kullanıcı mümkündür ama nadirdir ve risk puanı ortalamanın üzerinde olacaktır.

Dolaylı belirtiler de var. Klavye olayları tuşun fiziksel kodunu ve ürettiği karakteri verir. Beyan edilen dil en-US iken kullanıcı düzen değiştirmeden Kiril yazıyorsa ve sistem düzeni tek düzen olarak görünüyorsa, bu da bir çelişkidir. Davranış analizine dalmayacağız, ancak şunu anlamak önemli: dil bir dize değil, tarayıcı davranışının bütün bir katmanıdır.

Konum: Pasif ve aktif katmanlar

Pasif katman — IP coğrafi konum veritabanları. Birkaç büyük olanı var ve her zaman birbirleriyle hemfikir değiller. Mobil aralıklar için tutarsızlıklar özellikle belirgindir: bir dizin bölge merkezini, bir diğeri başkenti, bir üçüncüsü şehirsiz sadece ülkeyi gösterir. Bu nedenle tek bir veritabanındaki tek bir kontrol hiçbir şeyi garanti etmez. Büyük platformlar birkaç kaynak ve bir zamanlar konum erişimine izin vermiş milyonlarca kullanıcının gerçek koordinatlarıyla eşleştirilmiş adresleri içeren kendi birikmiş verilerini kullanır.

Aktif katman — Geolocation API. navigator.geolocation.getCurrentPosition metodu enlem, boylam, metre cinsinden doğruluk ve varsa yükseklik, hız ve yön ile birlikte zaman damgası döndürür. Akıllı telefonda kaynak uydu navigasyonu ve hücre kuleleridir, doğruluk 5–50 metre. Masaüstü bilgisayarda koordinatlar çevredeki kablosuz ağlara ve IP'ye göre hesaplanır, doğruluk yüzlerce metreden kilometrelere kadar. Bu fark kritik: profil mobil tarayıcıyı taklit ediyorsa ama doğruluk 5000 metre ve yükseklik sıfır dönüyorsa, tablo doğal görünmez.

Ayrı bir konu — izin durumu. navigator.permissions.query aracılığıyla site konum erişiminin izinli, yasaklı veya henüz istenmemiş olduğunu öğrenebilir. Bu sessizce, açılır pencere olmadan yapılır. Gerçek kullanıcılar üç duruma da dağılmıştır, ancak tipik yeni bir ziyaretçide izin "henüz sorulmadı" durumundadır. Aynı ağdan yüzlerce yeni hesabın konumu aynı şekilde ve anında yasaklıysa, bu otomatik kurulumun bir işaretidir.

Çapraz kontroller: Üç alanın kesiştiği yer

En ilginç kısım, antifraudun alanlara ayrı ayrı bakmayı bıraktığında başlar. Antifraud sistemlerinde karşılaşılan birkaç bağlantı:

• Koordinatlar ve bölge. Enlem ve boylamdan saat dilimi kesin olarak hesaplanır. Krasnodar'ın koordinatları ile Asia/Vladivostok bölgesi — açıklama gerektirmeyen bir çelişki.
• IP ülkesi ve dil. Her ülkenin beklenen dil dağılımı vardır. ru-RU dilli Almanya IP'si yasak değildir ama istatistiklerden sıyrılır, yani risk puanı ekler.
• Bölge ve etkinlik. Europe/Moscow bölgesine sahip ve yerel saatle sabah üç ile altı arasında istikrarlı biçimde aktif olan hesap, başka bir dilimden yönetilen bir hesap gibi görünür.
• Bölge ve kayıt tarihi. Platform hesabın hangi dilimde oluşturulduğunu hatırlar. Taşınma halinde bölge değişikliği kabul edilebilir, ancak uyumsuz bölgeler arasında sık atlamalar bir sinyaldir.
• Koordinat doğruluğu ve cihaz türü. Kilometre hassasiyetli mobil User-Agent veya üç metre hassasiyetli masaüstü tarayıcı — her iki durum da doğal değildir.

Bu bağlantıları anlamak başarının yarısıdır. Diğer yarısı ise şimdi geçeceğimiz kurulum disiplinidir.

Yöntem 1. Tarayıcı saat dilimi: Mobil IP'ye çelişkisiz uyarlama

Teori: Bölgeye karşı kayma

Ana kavramsal hata, saat dilimini sayı olarak düşünmektir. Doğru olan, onu adlandırılmış bir IANA bölgesi olarak düşünmektir. Sayı (kayma), bölge ve tarihin türevidir. Profil ayarlarında tam olarak bölge adını belirlediğinizde, tarayıcı herhangi bir tarih için kaymayı kendisi doğru hesaplar, yaz saatini doğru işler ve yerelleştirilmiş etiketi doğru oluşturur. Yalnızca kaymayı belirlediğinizde ise geri kalan her şeyi elle sürdürme sorumluluğunu üstlenirsiniz ve neredeyse kesinlikle bir yerde hata yaparsınız.

Rusya için bu özellikle uygundur: yaz saati yok ve her bölgede kayma yıl boyunca sabit. Ancak Avrupa veya Kuzey Amerika'dan proxy'lerle çalışıyorsanız, yaz saati geçiş kuralları mevsimsel çöküş kaynağı haline gelir. Kışın sabit kayma üzerinden profil kuran ekipler, baharda aniden, nedenini anlamadan bir uyumsuzluk dalgası alırlar.

Adım adım kurulum

1. Fiziksel modemin değil, IP'nin bölgesini belirleyin. Mobil proxy adresini en az iki-üç coğrafi konum veritabanında kontrol edin. Belirttikleri bölgeyi ve şehri kaydedin. Veritabanları çelişiyorsa, hedef platformlarınızın görüşüyle daha sık örtüşene odaklanın (bu deneysel olarak ilk oturumlardan anlaşılır).
2. Bölgeyi IANA bölgesiyle eşleştirin. Rus bölgeleri için on bir bölge geçerlidir: Europe/Kaliningrad (UTC+2), Europe/Moscow (UTC+3), Europe/Samara (UTC+4), Asia/Yekaterinburg (UTC+5), Asia/Omsk (UTC+6), Asia/Krasnoyarsk (UTC+7), Asia/Irkutsk (UTC+8), Asia/Yakutsk (UTC+9), Asia/Vladivostok (UTC+10), Asia/Magadan (UTC+11), Asia/Kamchatka (UTC+12). Dikkat: bazı bölgelerin aynı kaymaya sahip kendi IANA bölgeleri vardır, örneğin Europe/Volgograd veya Asia/Tomsk. Bölge için doğru adı kullanmak, en yakın "büyük" benzerden daha çok tercih edilir.
3. Bölgeyi kayma değil, ad olarak belirleyin. Profil ayarlarında Asia/Novosibirsk gibi bir dizenin belirtildiği seçeneği seçin. Araç yalnızca sayısal kayma sunuyorsa, olgunluğundan şüphe etmek için nedendir.
4. Sistem saatını senkronize edin. İşletim sisteminin zamanı ağ senkronizasyon protokolü aracılığıyla aldığından emin olun. Gerçek zamanla fark saniyeler içinde kalmalı. Bu sanal makineler için de geçerlidir: saatları askıya almadan sonra sıklıkla "kayar".
5. Üç temsili kontrol edin. Konsolu açın ve Intl.DateTimeFormat().resolvedOptions().timeZone sonucunu, getTimezoneOffset() değerini ve new Date().toString() etiketini karşılaştırın. Üçü de tek bir bölgeyi tanımlamalı ve etiket profil dilinde olmalı.
6. Kış ve yaz kaymasını kontrol edin. Cari yılın 15 Ocak ve 15 Temmuz tarihleri için getTimezoneOffset'u hesaplayın. Rus bölgeleri için değerler eşittir. Yaz saati olan bölgeler için fark 60 dakikadır. Bunun dışındaki herhangi bir davranış bozuk emülasyon anlamına gelir.
7. Bölgeyi rotasyona bağlayın. Mobil proxy'niz IP değişiminde başka bir bölgeye taşınabilirse, bölge de onunla birlikte değişmelidir. Proxy'yi rotasyonun tek bir bölge içinde gerçekleşecek şekilde ayarlamak ve bunu profil kartında sabitlemek daha iyidir.

Pratikten örnek

Ekip, ilan platformunda Ural bölgesinden mobil proxy'lerle hesaplar yönetiyordu. Veritabanları adresleri Yekaterinburg olarak belirliyordu. Profil şablonunda önceki projeden Europe/Moscow bölgesi kalmıştı. İlk günler hiçbir şey olmadı, ancak beşinci günde tüm hesaplar genişletilmiş doğrulamaya takıldı. İncelemede, platformda tam olarak yukarıda tanımladığımız "koordinatlara karşı bölge" bağlantısının çalıştığı ortaya çıktı: beklenen ve gerçek bölge arasındaki iki saatlik fark iç eşiği aşmıştı. Bölge Asia/Yekaterinburg olarak değiştirildikten ve profiller yeniden oluşturulduktan sonra tekrarlanan doğrulamalar durdu.

Saat dilimi kontrol listesi

• Bölge, IP bölgesine karşılık gelen IANA adı olarak belirlendi.
• Sistem saati senkronize, sunucuyla fark 5 saniyeden az.
• Bölgenin üç temsili birbiriyle tutarlı.
• Kış ve yaz kayması bu bölge için doğru davranıyor.
• Yerelleştirilmiş bölge etiketi profil dilinde çıkıyor.
• IP rotasyonu adresi bölgenin dışına çıkarmıyor ya da bölge onunla birlikte güncelleniyor.
• Profil kartında hangi bölgenin ve neden olduğu kayıtlı.

Yöntem 2. Dil: Başlıkların, nesnelerin ve biçimlerin uyumluluğu

Teori: Dil çok katmanlı bir pasta

Dilin en az dört düzeyde yaşadığını gördük: HTTP başlığı, JavaScript nesneleri, biçimlendirme yereli ve klavye düzeni gibi sistem belirtileri. Her düzey kendi bileşeni tarafından oluşturulur. Başlığı tarayıcının ağ yığını dil ayarlarından toplar. navigator nesneleri aynı yerden alınır, ancak bir düzeydeki sahtecilik otomatik olarak diğerine geçmez. Biçimlendirme yereli sıklıkla tarayıcıdan değil işletim sisteminden miras alınır. Uyuşmazlıklar buradan kaynaklanır.

İkinci önemli düşünce: dil yalnızca IP ülkesine değil, aynı zamanda makul bir kullanıcı biyografisine uymalı. Tamamen tek dilli profiller göründüğünden daha nadirdir. Gerçek bir kişinin dil listesinde genellikle iki-üç madde olur: bölge kodlu ana dil, bölgesiz aynı dil ve yedek olarak İngilizce. İşte tam olarak bu tür bir liste, tipik bir tarayıcının varsayılan olarak oluşturduğu şeydir.

Adım adım kurulum

1. IP ülkesine göre ana yereli seçin. Rus mobil IP'si için bu ru-RU'dur. Kazakistan için ru-RU veya profil hikâyesine bağlı olarak kk-KZ, ikinci dil neredeyse zorunludur. Birden fazla resmi dili olan ülkeler için IP bölgesinde hangisinin baskın olduğunu araştırın.
2. Dil listesini oluşturun. Rusça profil için gerçekçi bir dizi: ru-RU, ru, en-US, en. Sıra önemli. Ana yerel Rusça ise İngilizce ile başlamayın.
3. Accept-Language başlığını kontrol edin. Aynı listeyi azalan q ağırlıklarıyla yeniden üretmelidir. Formatın profilin taklit ettiği tarayıcı tipine uygun olduğundan emin olun.
4. navigator.language ve navigator.languages'i karşılaştırın. Birinci değer dizinin ilk elemanına eşittir. Dizi, başlıkla içerik ve sıra olarak eşleşir.
5. Biçimlendirme yerelini kontrol edin. Intl.DateTimeFormat().resolvedOptions().locale'i, ardından new Date().toLocaleDateString() ve (1234567.89).toLocaleString()'i çağırın. Format ana dile uymalı: ru-RU için tarihte nokta ayırıcı ve binlikte boşluk.
6. Sistem arayüz dilini uyumlu hale getirin. Profil Rusça ama sanal makinenin sistem yereli İngilizce ise, bazı dizeler (saat dilimi etiketi dahil) İngilizce olacaktır. Sistemi düzene sokun ya da aracın bu değerleri doğru şekilde geçersiz kıldığından emin olun.
7. Klavye düzenini düşünün. Operatör Rusça metin giriyorsa, sistemde Rusça klavye düzeni olmalı ve profil Rusça olmalı. İngilizce profil ile aktif Kiril girişi şüpheli görünür.

Pratikten örnek

Arbitraj ekibi sosyal bir platformda Rus mobil proxy'leri kullanıyordu, ancak profil şablonları İngilizce konuşan kitleye yönelik bir projeden miras alınmıştı. Accept-Language başlığı antidetect aracı vasıtasıyla ru-RU olarak değiştiriliyordu ama navigator.languages nesnesi en-US, en olarak kalıyordu. Oturumlar ortalama bir günden kısa yaşıyordu. Dil dizisi ve biçimlendirme yereli başlıkla uyumlu hale getirildikten sonra ortalama profil ömrü kat kat arttı, üstelik proxy'ler ve diğer ayarlar değişmeden. Düzeltmenin maliyeti — şablonla bir akşamlık çalışma.

Dil kontrol listesi

• Ana yerel IP ülkesine ve bölgesine karşılık geliyor.
• Dil listesi makul sırada iki-dört öğe içeriyor.
• Accept-Language ile navigator.languages içerik ve sıra olarak eşleşiyor.
• navigator.language dizinin ilk elemanına eşit.
• Biçimlendirme yereli, tarih ve sayılar ana dil formatında oluşturuluyor.
• Sistem yereli Rusça profilde İngilizce dizelere sızmıyor.
• Klavye düzeni ve gerçek giriş beyan edilen dille tutarlı.

Yöntem 3. Konum: Üç strateji ve koordinat kuralları

Teori: İzin, koordinatlardan daha önemli

Birçok kişi siteye hangi koordinatların verileceğine odaklanır ve çoğu platformun sıradan bir kullanıcıdan kesin konum istemediğini gözden kaçırır. Daha da önemlisi profilin isteğin kendisiyle nasıl davrandığı ve izin durumunun ne olduğudur. Buradan üç strateji çıkar.

"Sorulmadı" stratejisi. İzin başlangıç durumunda kalır, koordinatlar verilmez. Bu, çoğu sitenin yeni kullanıcısı için en doğal durumdur. Platformun kesin konum gerektirmediği senaryolar için uygundur: reklam hesapları, çoğu sosyal platform, bölgeyi elle seçen pazar yerleri.

"İzin verildi ve uyumlu" stratejisi. Profil, IP şehrine makul yakınlıkta, gerçekçi doğrulukta ve oturumlar arasında küçük sapmalı koordinatlar verir. Konumun işlevselliğin bir parçası olduğu hizmetler için uygundur: haritalar, teslimat, bölgeye bağlı ilanlar, web sarmalayıcıdaki bazı mobil uygulamalar.

"Yasak" stratejisi. Kitlesel uygulamada en riskli olan. Tek bir ret normaldir, ancak aynı ağdaki yüzlerce profilde aynı anda ret tanınabilir bir desen oluşturur. Yalnızca belirli bir hikâye için bilinçli karar olduğu yerlerde kullanın.

"İzin verildi ve uyumlu" stratejisi için adım adım kurulum

1. Veritabanlarının IP'ye hangi şehri atfettiğini öğrenin. Saat diliminde olduğu gibi, modemin fiziksel konumuna değil, dizinlere odaklanın.
2. Koordinatları veritabanının kendisinden almayın. Dizinler şehrin merkez noktasını verir — herkese tek bir nokta. Binlerce sahtecilik aracı kullanıcısı aynı noktayı kullanır. Merkezden bir ila on beş kilometre uzakta gerçek bir konut veya iş bölgesi seçin.
3. Gerçekçi doğruluk belirleyin. Mobil profil için 10 ila 80 metre, masaüstü için 500 ila 5000 metre. 1 metrelik veya tam 100 metrelik doğruluk sentetik görünür.
4. Sapma ekleyin. Oturumlar arasında gerçek bir kişinin koordinatları değişir: ev, iş, yol. Birkaç yüz metrelik kayma ya da iki-üç "ev" noktası arasında geçiş, aylarca tek bir sabit koordinattan daha doğaldır.
5. Ek alanları uyumlu hale getirin. Masaüstü profilde yükseklik, hız ve yön olmamalıdır. Mobilde yükseklik olabilir ama araziye uygun makul olmalıdır.
6. Bölgenin koordinatlardan türetildiğinden emin olun. Tarayıcı saat diliminin seçilen noktanın bölgesine karşılık geldiğini kontrol edin. Sınır bölgeleri için bu her zaman açık değildir.
7. İzin durumunu kontrol edin. Konum için navigator.permissions.query çağırın ve seçilen stratejiye uygun olduğundan emin olun.

Pratikten örnek

Teslimat hizmeti bölgenin konum yoluyla doğrulanmasını gerektiriyordu. Birkaç ortaklı hesabı yöneten ekip, tek bölgedeki mobil proxy'leri kullanıyor ve tüm profillere IP veritabanından şehir merkezini veriyordu. İki hafta sonra hesaplar manuel incelemeye düştü: onlarca hesabın virgülden sonra altıncı basamağa kadar aynı koordinatlara sahip olması açık bir anormallikti. Farklı bölgelerde sapmalı bireysel noktalarla değiştirmek yeni hesaplar için sorunu çözdü.

Konum kontrol listesi

• Bilinçli bir strateji seçildi: sorulmadı, izin verildi, yasaklandı.
• İzin durumu stratejiye uygun ve kitlesel profillerde aynı anda oluşmuyor.
• Koordinatlar veritabanlarına göre IP şehrine 1–30 km arasında.
• Koordinatlar şehir merkez noktasıyla örtüşmüyor ve her profil için benzersiz.
• Doğruluk profil cihaz türüne uygun.
• Oturumlar arasında sapma var.
• Saat dilimi seçilen koordinatların bölgesiyle örtüşüyor.

Yöntem 4. Uçtan uca "Profil Pasaportu" çerçevesi ve öz-denetim protokolü

Fikir: Bir kart — bir hikâye

Ayrı kontrol listeleri, profil sayısı onlarca olduğu sürece işe yarar. Yüzlerce olduğunda bir sisteme ihtiyaç vardır. Biz buna "Profil Pasaportu" diyoruz: her profil için doğruluk kaynağının ve ondan türeyen tüm alanların kaydedildiği bir belge veya tablo satırı. İlke: herhangi bir alan bir öncekinden türetilmeli ve hiçbiri IP ile çelişmemeli.

Pasaport yapısı

• IP ve operatör. Mobil proxy aralığı, operatör, iki-üç veritabanına göre bölge, kontrol tarihi.
• IANA bölgesi. IP bölgesinden türetilmiş. Kayma ve yaz saati varlığı belirtilmiş.
• Diller. Ana yerel, tam liste, Accept-Language dizesi.
• Biçimlendirme yereli. Tarih ve sayı formatı, beklenen toLocaleDateString çıktısı.
• Coğrafi strateji. Üç stratejiden biri; "izin verildi" ise temel koordinatlar, doğruluk, sapma kuralları.
• Sistem bağlamı. İşletim sistemi dili, saat senkronizasyon durumu, klavye düzenleri.
• Cihaz türü. Mobil veya masaüstü profil, çünkü konum doğruluğu beklentileri ve başlık formatı buna bağlı.
• Değişiklik geçmişi. Bölge ya da dillerin ne zaman ve neden değiştiği, ani sıçramalar yapılmaması için.

Başlatmadan önce öz-denetim protokolü

1. IP'yi birkaç veritabanında kontrol edin. Ülke, bölge, şehri kaydedin. En az bir veritabanı farklı bölge veriyorsa, bunu risk olarak işaretleyin ve mümkünse proxy sağlayıcısından daha net coğrafyaya sahip bir adres isteyin.
2. Ortam kontrol sayfasını açın. Görüntülenen saat dilimini, dili ve konumu pasaportla karşılaştırın. Bunu iki farklı hizmette yapın: farklı veritabanları ve farklı yöntemler kullanırlar.
3. Kendi betiğinizi çalıştırın. Antifraudun topladığı aynı alanları toplamalı ve uyumsuzlukları hemen vurgulamalıdır. Aşağıda konsola yapıştırılabilecek minimum bir örnek var.
4. Çapraz bağlantıları kontrol edin. Koordinatlardan türeyen bölge, tarayıcı bölgesine eşit. Dil ülkeye uygun. Bölge etiketi profil dilinde.
5. Rotasyonu simüle edin. Proxy IP'sini değiştirin ve 1–4 adımlarını tekrarlayın. Bölgenin değişmediğinden ya da profilin yeniden yapılandığından emin olun.
6. Sonucu kaydedin. Kontrol tarihini pasaporta girin. Prosedürü tarayıcı, araç veya işletim sistemi güncellemesinden sonra tekrarlayın.

Öz-denetim betiği

Bu parça ana alanları toplar ve tek satırda yazdırır. Hiçbir şeyi değiştirmez, yalnızca okur — antifraudun ilk milisaniyelerde yaptığı tam olarak budur.

(function(){ var tz = Intl.DateTimeFormat().resolvedOptions().timeZone; var loc = Intl.DateTimeFormat().resolvedOptions().locale; var jan = new Date(new Date().getFullYear(), 0, 15).getTimezoneOffset(); var jul = new Date(new Date().getFullYear(), 6, 15).getTimezoneOffset(); var out = { zone: tz, offsetNow: new Date().getTimezoneOffset(), offsetJan: jan, offsetJul: jul, dst: jan !== jul, dateString: new Date().toString(), language: navigator.language, languages: navigator.languages.join(','), locale: loc, dateFormat: new Date().toLocaleDateString(), numberFormat: (1234567.89).toLocaleString() }; if (navigator.permissions) { navigator.permissions.query({ name: 'geolocation' }).then(function(p){ out.geoPermission = p.state; console.table(out); }); } else { console.table(out); } })();

Çıktıda ne aramalı? Bölge pasaportla eşleşmeli. dst işareti bölgenin kurallarına uygun olmalı. dateString dizesi profil dilinde etiket içermeli. languages dizisi başlıkla eşleşmeli. Tarih ve sayı formatı yerelle uyumlu olmalı. Konum durumu stratejiye uygun olmalı. Kontrole beş dakika ayırmak, hesap kurtarmaya günler harcamaktan tasarruf ettirir.

Çerçeveyi ekibe nasıl entegre etmeli

Profil şablonlarından sorumlu birini atayın. Şablondaki herhangi bir değişiklik öz-denetim protokolünden geçer. Üç ayda bir proxy bölgelerini gözden geçirin: operatörler aralıkları yeniden dağıtır ve veritabanı "taşınabilir". Proxy sağlayıcısı yeni bölgeler eklediğinde kısa bir yönetmelik oluşturun: önce pasaport, sonra başlatma. Bu sıkıcıdır, ama tam da sıkıcı süreçler ölçeklenebilen ekipleri her ay sıfırdan başlayan ekiplerden ayırır.

Tipik hatalar: Deneyimli ekiplerin bile yaptığı

Hata 1. Ortamı modemin fiziksel konumuna göre ayarlamak

Modem bir şehirde duruyor, veritabanları IP'yi başka bir şehre atfediyor, profil ise birincisine göre ayarlanmış. Platform ikinciyi görüyor. Her zaman donanımın coğrafyasına değil, dizinlere odaklanın.

Hata 2. Bölge yerine kayma belirlemek

Sabit sayı yaz saatini ve yerelleştirilmiş etiketi bozar. Rus bölgeleri için daha az fark edilir, Avrupa ve Kuzey Amerika için mevsimsel uyumsuzluk dalgalarına yol açar.

Hata 3. Yalnızca başlığı ya da yalnızca nesneyi değiştirmek

Accept-Language bir şey söylüyor, navigator.languages başka. Bu en sık ve en kolay tespit edilen hatadır. Her değişiklikten sonra her iki düzeyi de kontrol edin.

Hata 4. Biçimlendirme yerelini unutmak

Dil Rusça ama tarih 3/5/2026 olarak çiziliyor, çünkü biçimlendirme yereli İngilizce sistemden miras alınmış. Küçük bir şey, ama aynı çapraz analize giriyor.

Hata 5. Tüm profiller için tek konum noktası

IP veritabanından şehir merkez noktası — sahtecilik aracı kullanan binlerce kullanıcı için ortak nokta. Sapmalı benzersiz koordinatlar sorunu çözer.

Hata 6. Kitlesel anlık konum reddi

Ret tek başına normaldir. Ağdaki tüm hesaplarda aynı ret — değil. Stratejileri çeşitlendirin ya da "sorulmadı" durumunda bırakın.

Hata 7. Sistem saatını görmezden gelmek

Sanal makineler ve eski cihazlar zamanı kaybeder. Dakikalar cinsinden senkronizasyon bozukluğu sunucuda ilk istekten görülür. Ağ senkronizasyonunu açın ve kontrol edin.

Hata 8. Bölge rotasyonunu takip etmemek

IP rotasyonu adresi farklı bölgeye taşıdı ama profil aynı kaldı. Rotasyonu bölgeyle sınırlayın ya da her değişimde pasaportu güncelleyin.

Hata 9. Canlı hesapta bölgeyi aniden değiştirmek

Hesap Europe/Moscow'da kayıtlı, bir gün sonra Asia/Vladivostok'tan çalışıyor. Bölge değişikliği gerekiyorsa, bunu kademeli olarak ve davranış yoluyla mantıklı bir açıklamayla yapın: duraklamalar, ara bölgeler, uygun etkinlik saatleri.

Hata 10. Bir kez kontrol edip unutmak

Tarayıcı, araç veya işletim sistemi güncellemesi yerel ve bölge ayarlarını sıfırlayabilir. Herhangi bir güncellemeden sonra öz-denetim protokolünü tekrarlayın.

Araçlar ve kaynaklar

IP coğrafi konum veritabanları

En az iki-üç bağımsız veritabanı kullanın: büyük jeo veri sağlayıcılarının ticari dizinleri ve birkaç kaynağı bir araya getirip uyumsuzlukları gösteren hizmetler. Mobil aralıklar için yalnızca şehri değil operatörü ve bağlantı türünü görme imkânı özellikle değerlidir. Kaliteye önem veren mobil proxy sağlayıcıları genellikle adres çıkış arayüzünde bölgeyi doğrudan veritabanına göre belirtir — bu bilgiyi kullanın ve kendiniz de doğrulayın.

Tarayıcı ortamı kontrol sayfaları

Herkese açık kontrol hizmetleri tarayıcı saat dilimini, dilleri, yereli, konum durumunu gösterir ve bunları IP ile karşılaştırır. Değerleri görsel netlikte ve farklı veritabanları kullanmalarındadır. Sınırlamaları — sizin hikâyenizi bilmezler ve belirli bir platformun yaptığı gibi çapraz bağlantıları kontrol etmezler. Bu nedenle onları kendi betiğinizle tamamlayın.

Antidetect araçları ve ayarları

Olgun çözümler IANA bölgesini ad olarak belirlemeye, onu IP'den otomatik türetmeye, dil listesini başlıkla senkronize etmeye ve konumu doğruluk ve sapmayla ayarlamaya izin verir. Araç seçerken dört soru sorun: bölge ad olarak belirlenebiliyor mu, sahtecilik sonrası başlık ve dil nesnesi eşleşiyor mu, profil başına benzersiz koordinat tanımlanabiliyor mu, IP değişiminde ortam güncelleniyor mu. Bunlardan herhangi birine olumsuz yanıt — alternatif arama ya da boşluğu elle kontrolle kapatma nedenidir.

Kendi betikleri ve otomasyon

Yukarıdaki parça bir başlangıç noktasıdır. Ekipteki geliştiriciler bunu otomatik kontrole dönüştürebilir: betik profil başlatıldığında çalışır, çıktıyı pasaportla karşılaştırır ve uyumsuzluk halinde çalışmayı bloke eder. API senaryoları için aynı mantık yönetim hizmeti tarafında uygulanmalıdır: profil operatöre verilmeden önce ortam otomatik kontrol edilir.

Bölge dizinleri ve yardımcı programlar

IANA bölge veritabanı herkese açıktır ve düzenli olarak güncellenir. Özellikle birkaç dilimi olan ülkeler için bölge-bölge eşleştirme tablosunu el altında tutun. Koordinattan bölge türetmek için otomasyona entegre edilen hazır kitaplıklar vardır. Zaman senkronizasyonu için işletim sisteminin standart araçlarını veya ayrı bir ağ zamanı istemcisini kullanın.

İç dokümantasyon

"Profil Pasaportu" tablosu, şablon değişiklik yönetmeliği ve kontrol günlüğü — herhangi bir hizmetten daha az önemli araçlar değildir. Onlar olmadan bilgi bir kişinin kafasında yaşar ve onunla birlikte gider.

Vakalar ve sonuçlar

Vaka 1. Reklam hesapları ve miras alınan şablon

Altı operatörden oluşan bir ekip, Rus mobil proxy'lerle büyük bir sosyal platformda reklam hesapları yönetiyordu. Profil şablonu İngilizce bir proje için oluşturulmuştu ve America/New_York bölgesi ile en-US, en dillerini içeriyordu. İlk yüklemeye kadar hayatta kalan hesap oranı yaklaşık üçte bir seviyesindeydi. Profil pasaportu uygulamaya konduktan sonra — Europe/Moscow bölgesi, ru-RU, ru, en-US, en dilleri ve "sorulmadı" konum stratejisiyle — oran bir ay içinde yaklaşık beşte dörde yükseldi. Proxy'ler, cihazlar ve diğer ayarlar değişmedi. Tek değişken — üç alanın uyumluluğuydu.

Vaka 2. Avrupa proxy'li ekipte mevsimsel çöküş

Ekip birkaç Avrupa ülkesinden proxy'lerle çalışıyor ve saat dilimini kışın sabitlenmiş sayısal kaymayla belirliyordu. Mart sonunda aynı anda üç platformda ek kontrol dalgası başladı. İnceleme şunu gösterdi: beyan edilen bölge yaz saatine geçişi ima ediyordu, ancak kayma kış değerinde kalmıştı. Adlandırılmış IANA bölgelerine geçiş sorunu bir günde çözdü ve sonbaharda çöküş tekrarlanmadı. Ders: kayma bölge değildir.

Vaka 3. Pazar yeri ve özdeş koordinatlar

Bir pazar yerinde birkaç hesabı olan satıcı, tek bölgeden mobil proxy'ler kullanıyor ve konuma izin vererek tüm hesaplara şehir merkezi koordinatlarını veriyordu. İki hafta sonra hesaplar belge talebiyle manuel incelemeye düştü. Yeni hesaplar farklı bölgelerde benzersiz koordinatlar, 20–60 metre doğruluk ve oturumlar arası sapmayla kuruldu. Sonraki çeyrekte yeni hesapların hiçbiri ek kontrol talebi almadı. Eskilerin destek üzerinden kurtarılması gerekti.

Vaka 4. Bölgesel içerik kazıma

Bir geliştirici, teklifleri konuma ve dile göre gösteren bir siteden bölgesel fiyatlar topluyordu. Sibirya mobil proxy'leriyle, ancak konteynerin varsayılan bölgesi ve diliyle (UTC ve en-US) site zaman zaman ortalamasız fiyatlar, bazen de bölge onay sayfası veriyordu. Her bölgesel havuza Asia/Novosibirsk bölgesi, ru-RU dili ve doğru Accept-Language başlığı bağlandıktan sonra doğru yanıt oranı yaklaşık üçte ikiden neredeyse tama yükseldi ve onay sayfalarının sayısı günde birkaç taneye düştü. Burada söz konusu olan engellemeler değil, veri kalitesiydi: uyumsuz ortam basitçe veri setini bozuyordu.

Vaka 5. Komşu dilime sürükleyen rotasyon

Ajans, rotasyonunun IP'yi zaman zaman Samara bölgesinden Tataristan'a taşıdığı proxy'lerle çalışıyordu. Birinci bölge Europe/Samara bölgesine, ikincisi Europe/Moscow'a aittir. Sabit bölgeli profiller birkaç günde bir IP'den "bir saat sapmış" hale geliyordu. Sağlayıcı rotasyonu tek bölgeyle sınırladıktan ve profil pasaportu her başlatmada kontrol edildikten sonra sapmalar ortadan kalktı. Dikkat çekici olan, sorunun yalnızca öz-denetim günlüğüyle fark edilmesiydi — görsel olarak her şey normal görünüyordu.

SSS: Saat dilimi, dil ve konum hakkında zor sorular

Bölge adı farklı olsa bile tarayıcı saat diliminin kayma olarak eşleşmesi yeterli mi?

Hayır. Europe/Moscow ve Europe/Istanbul bölgeleri aynı kaymaya sahiptir, ancak farklı değişiklik geçmişleri ve farklı yerelleştirilmiş etiketleri vardır. Ayrıca antifraud bölge adını kayma üzerinden değil, doğrudan IP şehriyle karşılaştırır. Her zaman bölgeyi bölgeye karşılık gelen ad olarak belirleyin.

Mobil IP veritabanları tarafından Moskova olarak belirleniyor, ancak modem başka bir bölgede. Profil hangisine göre ayarlanmalı?

Veritabanlarının gördüğüne göre. Platform profilinizi gerçeklikle değil, kendi dizinleriyle karşılaştırır. İki-üç veritabanı Moskova'da hemfikirse, Europe/Moscow ve Moskova hikâyesini kullanın. Veritabanları çelişiyorsa, sağlayıcıdan net coğrafyalı bir adres isteyin ya da ilk oturumlarda hedef platformlarınızın görüşüyle örtüşen seçeneği tercih edin.

Rusça konuşan bir profilin dil listesine İngilizce eklemek zorunlu mu?

Zorunlu değil ama arzu edilir. Çoğu tarayıcı varsayılan olarak İngilizceyi yedek dil olarak ekler ve ru-RU, ru, en-US, en listesi tek başına ru-RU'dan daha doğal görünür. Önemli olan İngilizcenin ilk sırada olmaması ve listenin başlıkta ve navigator.languages nesnesinde eşleşmesi.

Hangisi daha güvenli: konumu yasaklamak mı yoksa uyumlu koordinatlarla izin vermek mi?

Çoğu platform için en güvenlisi üçüncü seçenektir — izni "sorulmadı" durumunda bırakmak. Uyumlu koordinatlarla izin vermek, konumun işlevselliğin parçası olduğu yerlerde değerlidir. Kitlesel aynı yasak en az uygun seçimdir, çünkü tanınabilir bir desen oluşturur.

Hâlihazırda çalışan profillerin ortamı ne sıklıkla yeniden kontrol edilmeli?

En azından her tarayıcı, antidetect aracı veya işletim sistemi güncellemesinden sonra ve proxy bölgesi her değiştiğinde. Planlı kontrolü ayda bir kez yapmak mantıklıdır. Her profil başlatıldığında otomatik kontrol sorunu tamamen ortadan kaldırır.

Sistem saati senkronizasyon bozukluğu tek başına sorunlara yol açabilir mi?

Tek başına nadiren. Ancak risk puanı ekler ve platformların zaman damgalarına bağlı mantığının bir kısmını bozar. Saatler cinsinden senkronizasyon bozukluğu neredeyse her zaman zamanın elle ayarlandığı anlamına gelir ve bu sıradan bir kullanıcı hikâyesiyle pek uyuşmaz. Sapmayı saniyeler içinde tutun.

Hesap proxy ile birlikte başka bir bölgeye "taşınırsa" tarayıcı saat dilimi değiştirilmeli mi?

Evet, ama kademeli ve mantıklı bir şekilde. Bir bölgeden uyumsuz diğerine ani sıçrama soru işaretleri yaratır. Taşınma gerekiyse, etkinliğe ara verin, bölgeyi IP ile birlikte değiştirin ve etkinlik saatlerini yeni bölgeye uyarlayın. İleri geri sık atlamalar en kötü senaryodur.

Dil, tarayıcıdaki saat dilimi görünümünü nasıl etkiler?

Doğrudan. Tarihin dize temsilindeki yerelleştirilmiş bölge etiketi tarayıcı arayüz dilinde oluşturulur. Profil dili Rusça ama etiket İngilizceyse, bu sistem yerelinin beyan edilen dilden farklı olduğunun işaretidir. new Date().toString()'i bu tür sızmaların göstergesi olarak kontrol edin.

Uyumluluğu doğrulamak için tek bir herkese açık kontrol hizmeti yeterli mi?

Hayır. Farklı hizmetler farklı IP veritabanları kullanır ve alanları farklı yorumlar. İki-üç hizmet ve belirli hikâyeniz için çapraz bağlantıları kontrol eden kendi betiğinizi birlikte kullanın.

Sonuç: Üç çelişki yerine tek bir hikâye

Tarayıcı saat dilimi, dil ve konum — tarayıcının siteye verdiği tüm alanlar arasında kontrol edilmesi en ucuz ve en anlamlı olanlardır. Platformdan ne ağır hesaplama ne de makine öğrenmesi gerektirirler. Basit bir kural yeter: her şey IP ile uyuşmalı. Bu yüzden ortam uyumsuzluğu mobil proxy'lerle çalışanlar için çok pahalıya mal olur: gerçek bir operatörün temiz IP'si, etrafında var olmayan bir kullanıcı inşa edilirse değersizleşir.

Ana noktaları özetleyelim:

• IP doğruluk kaynağıdır. Modemin fiziksel konumuna değil, veritabanlarının onun hakkında söylediklerine odaklanın.
• Saat dilimini kayma değil, IANA bölge adı olarak belirleyin ve üç temsilini kış ve yaz döneminde kontrol edin.
• Dili tüm düzeylerde uyumlu hale getirin: başlık, navigator nesneleri, biçimlendirme yereli, sistem yereli ve klavye düzeni.
• Konumu koordinat değil, strateji olarak seçin. İzin veriyorsanız — benzersiz noktalar, gerçekçi doğruluk, sapma.
• Profil pasaportu tutun ve her başlatmada ve her güncellemeden sonra öz-denetim protokolünü çalıştırın.

Bundan sonra ne yapmalı? Bugün — çalışan profillerden birinde öz-denetim betiğini çalıştırın ve çıktıyı veritabanlarının IP'niz hakkında söyledikleriyle karşılaştırın. Muhtemelen en az bir uyumsuzluk bulacaksınız. Bu hafta — tüm aktif profiller için pasaport tablosu oluşturun. Bu ay — kontrolü başlatma sürecine entegre edin ve şablonlardan sorumlu birini atayın. Bu yeni bütçeler gerektirmez, ancak üç uyumsuz alan yüzünden yarı kapasiteyle çalışmış olabilecek kaliteli mobil proxy'lere yapılan yatırımı geri kazandırır.

Uyumlu ortam hesapların ölümsüzlüğünü garanti etmez — bunu hiçbir şey garanti etmez. Ancak herhangi bir kontrolün başladığı en gürültülü ve en belirgin sinyali ortadan kaldırır. Ve böylece doğru yaptığınız diğer her şeye işleme şansı verir.