Makale içeriği

Giriş: IP itibarı neden sandığınızdan daha önemli

Sıradan bir sabah hayal edin. Bir reklam kampanyası, bir e-posta gönderimi veya bir kazıyıcı (scraper) başlatıyorsunuz — ve karşılığında her adımda captcha alıyorsunuz, e-postalar spam'e düşüyor, hesaplar birer birer incelemeye gönderiliyor. Kodda hiçbir şey değişmedi. Ayarlar aynı. Değişen tek bir şey var: çalıştığınız IP adresinin itibarı. Adres bir IP kara listesine düştü ve tüm internet aniden size şüpheyle bakmaya başladı.

Tanıdık geldi mi? Günlük olarak mobil proxy'lerle çalışan pazarlamacılar, trafik uzmanları, geliştiriciler ve işletme sahipleri için bu soyut bir tehdit değil, operasyonel bir risk. IP adresi, her bağlantıda dijital pasaportunuzdur. Bu pasaportta "güvenilmez" damgası varsa, konuşma tamamen farklı bir şekilde ilerler.

Üstelik IP kara listeleri hakkında inanılmaz miktarda efsane birikmiş durumda. Kimileri sonsuza dek içine düşülen tek bir "ana" liste olduğuna emin. Kimileri adresi değiştirmenin yeterli olacağını ve sorunun kaybolacağını düşünüyor. Kimileri ise kaydın ertesi gün kendiliğinden silineceğini bilmeden "acil silme" için para ödüyor. Gerçek daha karmaşık ve daha ilginç.

Bu rehberde konuyu bütünüyle ele alacağız:

  • IP kara listesinin teknik düzeyde ne olduğu ve DNSBL'nin itibar skorlamasından farkı;
  • Bu veritabanlarını kimlerin tuttuğu — kâr amacı gütmeyen projelerden büyük platformların iç sistemlerine kadar;
  • Bir adresin hangi sinyallerle kötü itibar kazandığı ve bunun dürüst kullanıcılarda bile neden yaşandığı;
  • Adresin beş dakikada nasıl kontrol edileceği ve sonucun panik yapmadan nasıl okunacağı;
  • Delisting'in nasıl işlediği ve ne zaman gerçekten gerekli olduğu;
  • Sorunun tekrarlanmaması için mobil proxy havuzunun itibar yönetimi sisteminin nasıl kurulacağı.

İçeriğin sınırları hakkında bir açıklama. Bilinçli olarak adres itibarına odaklanacağız: listeler, skorlama, sinyaller ve prosedürler. Operatörlerin adresleri tahsis etme teknik özellikleri ve binlerce abonenin tek bir mobil IP'yi paylaşması — komşu blog yazılarında ele alınan ayrı bir konu. Burada yalnızca listelerin mantığını anlamak için gerekli olduğu ölçüde ona değineceğiz.

Temeller: IP kara listesi nedir ve hangi türleri vardır

Basitleştirmeden tanım

IP kara listesi (blacklist, blocklist, denylist) — belirli adreslere veya aralıklara olumsuz bir etiket atan yapılandırılmış bir veritabanıdır. Etiket, bu adresten istenmeyen aktivite gözlemlendiği anlamına gelir: spam gönderimi, port taraması, şifre deneme girişimleri, botnet katılımı, agresif otomatikleştirilmiş trafik ve benzeri.

Anahtar kelime — gözlemlendi. Liste niyeti değil, belirli bir liste operatörünün sensörleri tarafından kaydedilen davranışı kaydeder. Bu nedenle aynı adres bir veritabanında temiz, diğerinde "kirli" olabilir. Tek bir birleşik kayıt sistemi yoktur ve hiç olmamıştır.

Faydalı bir benzetme — kredi büroları. Birkaç tane var, her biri kendi verilerini toplar, kendi algoritmalarını kullanır ve banka hangi büroya güveneceğine ve hangi puanda reddedeceğine kendisi karar verir. IP itibarıyla da tamamen aynı: onlarca liste, milyonlarca liste tüketicisi var ve her tüketici kendi politikasını belirliyor.

Beş büyük liste ailesi

İsimlerde boğulmamak için IP kara listelerini çalışma prensibi ve amacına göre birkaç aileye ayırmak faydalıdır.

1. DNSBL ve RBL — posta güvenliğinin klasiği

DNSBL (DNS-based Blackhole List) ve tarihsel eşanlamlısı RBL (Real-time Blackhole List) — sıradan DNS sorgularıyla sorgulanan listelerdir. Bu en eski ve en yaygın teknolojidir: posta sunucuları her gelen bağlantıda göndericiyi DNSBL üzerinden kontrol eder. Tanınmış temsilciler — Spamhaus (ZEN'de birleştirilmiş SBL, XBL, PBL, CSS listeleri), Barracuda, SpamCop, Invaluement ve agresif ve tartışmalı UCEPROTECT.

2. İtibar beslemeleri ve skorlama veritabanları

Burada adrese ikili bir etiket değil, bir risk puanı atanır. Cisco Talos, IPQualityScore, Scamalytics, MaxMind minFraud, IP2Proxy gibi veritabanları ve büyük coğrafi konum sağlayıcılarındaki "gizlilik" belirleyicileri, adresin otomatik olarak kullanılma, veri merkezine ait olma, yakın zamanda saldırılara katılma olasılığını değerlendirir. Bu tür beslemeleri anti-fraud sistemleri, ödeme geçitleri, reklam ağları satın alır.

3. Kitle kaynaklı şikâyet veritabanları

AbuseIPDB, StopForumSpam, Project Honey Pot dünya çapında yöneticilerden gelen mesajları toplar. Herhangi bir sunucu sahibi, SSH'ine giren veya yorum formunu spam'le dolduran bir adrese şikâyet gönderebilir. Şikâyetler ne kadar çok ve ne kadar taze olursa, "kötü itibara duyulan güven düzeyi" o kadar yüksek olur. Bu tür veritabanlarının artısı — hız. Eksisi — yanlış pozitifler ve kötü niyetli şikâyet olasılığı.

4. Platformların iç listeleri ve WAF

En etkili aile — ve en kapalı olanı. Google, Meta, Amazon, büyük pazar yerleri, Cloudflare, Akamai, Imperva ve diğer bot koruma sağlayıcıları kendi itibar veritabanlarını tutar. Yayınlanmazlar, delisting formları yoktur ve milyonlarca bağlantının davranışına dayalı olarak gerçek zamanlı güncellenirler. Cloudflare arkasındaki bir site sizi tarayıcı kontrolüyle karşıladığında, tam da bu iç skorlama çalışıyor demektir.

5. Toplayıcılar ve altyapı düzeyi listeler

FireHOL, Emerging Threats, güvenlik duvarları için sektörel beslemeler onlarca kaynağı hazır kural setlerinde birleştirir. Bunlar şirketin ağ çevresinde bağlanır. Bir toplayıcıya girmek, istek uygulamaya ulaşmadan "girişte" engellenmek anlamına gelir.

Kara listenin engellemeden farkı

İki kavramı ayırmak önemlidir. Listeleme — adresin veritabanında bulunma gerçeğidir. Engelleme — belirli bir hizmetin listeleme ve kendi kurallarına dayanarak verdiği karardır. Bir posta sunucusu on listeden herhangi birine girmesi durumunda e-postayı reddeder, diğeri yalnızca Spamhaus'a girmesi durumunda reddeder, üçüncüsü sadece e-postanın önceliğini düşürür. Bu nedenle "IP'm kara listede mi?" sorusu her zaman daha spesifik olmalı: "hangi listede ve kim ona bakıyor?"

Derinlemesine: listeler kaputun altında nasıl çalışır

DNSBL sorgusunun mekaniği

Kontrolün teknik olarak nasıl gerçekleştiğini inceleyelim. Diyelim ki 203.0.113.5 adresinin bl.example.net bölgesine sahip belirli bir listedeki durumunu öğrenmek istiyoruz. Kontrol eden taraf adresin oktetlerini ters çevirir ve bölgeyi ekler: 5.113.0.203.bl.example.net alan adı elde edilir. Ardından sıradan bir A tipi DNS sorgusu çalıştırılır.

Yanıt yoksa (NXDOMAIN) — adres temizdir. 127.0.0.x aralığından bir kayıt dönerse — adres listededir ve yanıtın son okteti nedeni kodlar. Örneğin Spamhaus'ta 127.0.0.2 SBL'de spam nedeniyle doğrudan listeleme anlamına gelir, 127.0.0.4 enfekte bir cihaza veya açık bir proxy'ye işaret eder (XBL) ve 127.0.0.10 ve 127.0.0.11 — operatörün politikasına göre doğrudan posta gönderilmemesi gereken tüm aralıkların düştüğü politik PBL listesine işaret eder.

Bu zarif şema, DNSBL'nin neden bu kadar dayanıklı olduğunu açıklıyor. Kontrol milisaniyeler sürer, sıradan DNS çözümleyicileri tarafından önbelleğe alınır ve özel bir yazılım gerektirmez. Ayrıca birçok liste, insan tarafından okunabilir bir açıklama ve delisting sayfasına bağlantı içeren TXT kayıtları yayınlar.

Üç düzeyde ayrıntı: adres, alt ağ, otonom sistem

Yeni başlayanlar genellikle IP adresini izole bir birim olarak düşünür. Liste operatörleri farklı düşünür. İtibar en az üç düzeyde mevcuttur:

  • Tek adres — en kesin düzey. Buraya belirli olaylar nedeniyle düşülür.
  • Alt ağ (örneğin /24 — 256 adres). Bir alt ağdan farklı adreslerden düzenli olarak spam geliyorsa, liste operatörü tüm alt ağı engelleyebilir. Mantık: saldırgan sadece komşu adresleri deniyor ve "her birini yakalamak" yarışı anlamsızdır.
  • Otonom sistem (ASN) — tüm sağlayıcı. Şikâyetlere yanıt vermeyen barındırma hizmetlerine karşı aşırı bir önlem. UCEPROTECT Level 3 tam da bu şekilde çalışır ve iyi niyetli müşterileri ihlal edenlerle birlikte ele geçirmesiyle ünlüdür.

Mobil proxy kullanıcıları için bu kilit bilgidir. Mobil operatörler devasa adres havuzlarına sahiptir ve alt ağ düzeyindeki itibarları kural olarak istikrarlı biçimde nötr veya olumludur: hiçbir makul liste operatörü milyonlarca gerçek aboneyi engellemek istemez. Bu, mobil adreslerin "itibar fırtınalarını" veri merkezi adreslerinden daha iyi atlatmasının nedenlerinden biridir.

İtibar puanı nasıl hesaplanır

Skorlama sistemleri ikili listelerden daha karmaşıktır. Basitleştirilmiş olarak puan birkaç sinyal grubundan oluşur:

  1. Tarihsel olaylar — kaydedilen ihlallerin sayısı, ciddiyeti ve yaşı. Zayıflama çalışır: bir hafta önceki olay dünkünden daha az ağırlığa sahiptir.
  2. Ağ türü — veri merkezine, barındırmaya, kurumsal ağa, ev veya mobil operatöre ait olma. Veri merkezi adresleri varsayılan olarak ceza alır, çünkü gerçek insanlar neredeyse hiç oradan siteleri ziyaret etmez.
  3. Davranış metrikleri — istek sıklığı, 4xx hata oranı, gezinme kalıpları, başlıkların beyan edilen istemciye uygunluğu.
  4. Çapraz sinyaller — diğer kaynaklarla eşleşmeler: adres aynı anda üç şikâyet veritabanında görünüyorsa her birinin ağırlığı artar.
  5. Bağlam — bölge, günün saati, adresin coğrafi konumunun istemcinin beyan ettiği dile ve saat dilimine uygunluğu.

Nihai değer genellikle 0 ile 100 arasında bir ölçeğe normalize edilir ve tüketici sistem kendi eşiğini belirler. Ödeme geçidi 75'in üzerindeki puanda işlemleri reddedebilir, reklam ağı 60'ta tıklamayı şüpheli olarak işaretleyebilir, bir forum ise 40'ta sadece captcha gösterebilir.

Kaydın yaşam döngüsü: olaydan sona ermeye

IP kara listesindeki bir kayıt sonsuz değildir. Tipik yaşam döngüsü şöyle görünür: sensör olayı kaydeder, bir eşik tetiklenir (örneğin saatte beş şikâyet veya bir tuzak adrese bir e-posta), adres veritabanına düşer, ardından gözlem dönemi başlar. Yeni olay yoksa kayıt otomatik olarak sona erer. SpamCop'ta bu son mesajdan yaklaşık bir gün sonradır, Spamhaus XBL'de birkaç gün temiz davranış, UCEPROTECT Level 1'de yedi gün, kitle kaynaklı veritabanlarında kayıtlar "yaşlanır" ve kademeli olarak ağırlık kaybeder.

İstisnalar da var. Sistemik spam nedeniyle SBL'deki manuel listelemeler aylarca sürebilir ve operatörle diyalog gerektirir. Platformların iç veritabanları kendi kurallarına göre yaşar ve süre birkaç saat kadar kısa veya tekrarlanan ihlallerde belirsiz derecede uzun olabilir.

2026 trendleri: listelerin mantığında neler değişti

Sektör son yıllarda belirgin şekilde evrimleşti ve birkaç kaymayı anlamak gerekiyor.

Adresten davranışa kayma. Büyük koruma sistemleri IP'ye tek sinyal olarak giderek daha az güveniyor. Adres itibarı, tarayıcı parmak izi, etkileşim kalıpları, istemcinin TLS özellikleri yanında onlarca faktörden biri haline geldi. Temiz IP artık geçişi garanti etmiyor — ama kirli olan hâlâ sorunları garanti ediyor.

Skorlamada makine öğrenmesi. Modeller trafik akışları üzerinde eğitiliyor ve açık kurallar olmadan anormallikleri tespit ediyor. Yan etki — alt ağların toplu yanlış listelenmesi daha az oluyor, ancak teşhis edilmesi zor "yumuşak" kısıtlamalar daha sık ortaya çıkıyor.

Pazar konsolidasyonu. Bazı tarihsel DNSBL'ler çalışmayı durdurdu veya satın alındı. Örneğin en eski listelerden biri olan SORBS 2024'te kapandı ve verileri güncellenmeyi bıraktı. Aynı zamanda Spamhaus ve ticari beslemelerin etkisi arttı.

IPv6 ve itibar. Devasa adres alanı tek tek IPv6 adreslerinin listelenmesini anlamsız hale getirdi; operatörler /64 ve daha büyük öneklere yönelik itibara geçiyor. IPv6'nın baskın olduğu mobil ağlarda bu, daha da "kolektif" itibar anlamına geliyor.

Kitle kaynaklılığın artan rolü. Açık şikâyet veritabanları küçük yöneticiler için fiili standart haline geldi ve API'leri güvenlik duvarlarına varsayılan olarak entegre ediliyor. Bir bot korumasından gelen tek otomatik şikâyet artık dakikalar içinde binlerce sunucuya yayılabilir.

Yöntem 1: Teşhis — IP'nin kara listelerde nasıl kontrol edileceği ve sonucun doğru okunması

Neden tek seferlik kontrol değil metodoloji gerekiyor

Çoğu kullanıcı adresi yalnızca bir şey zaten bozulduğunda kontrol eder. Profesyonel yaklaşım bunun tersidir: teşhis düzenli bir prosedür haline gelir ve sonuç kırmızı ve yeşil simgeler kümesi değil, anlaşılır bir tablodur. Aşağıda ciddi çalışma öncesinde herhangi bir adrese uygulamanızı önerdiğimiz adım adım bir protokol var.

Adım adım kontrol protokolü

  1. Kullanım bağlamını belirleyin. E-posta gönderimi için posta DNSBL'leri kritiktir. Web platformlarıyla çalışmak için itibar beslemeleri ve ağ türü belirleyicileri. Kazıma için hedef sitenin WAF iç değerlendirmeleri. Bu adresten hiç e-posta göndermiyorsanız posta listelerini kontrol etmekle zaman kaybetmeyin.
  2. Adresi bir çoklu DNSBL denetleyicisinden geçirin. MXToolbox, MultiRBL veya benzeri hizmetler onlarca listeyi aynı anda sorgular. Eşleşme sayısına değil kalitesine dikkat edin: tek bir Spamhaus SBL eşleşmesi, kimsenin kullanmadığı beş az bilinen listenin eşleşmesinden daha önemlidir.
  3. İtibar puanına bakın. Adresi iki-üç skorlama hizmetinde kontrol edin. İlgilenilen: genel risk puanı, "proxy/veri merkezi/mobil" işareti, son olayın yaşı.
  4. Şikâyet veritabanlarını inceleyin. AbuseIPDB ve benzeri hizmetlerde son 30 gündeki rapor sayısına, kategorilerine (brute force, spam, tarama) ve zaman içinde dağılımına bakın. Altı ay önceki beş şikâyet — gürültü. Son haftada yirmi — aktif bir sorun.
  5. Ağ türünü ve sahibini kontrol edin. Adresin gerçekten bir mobil operatöre ait olduğundan ve mobil olarak belirlendiğinden emin olun. Bir itibar hizmeti adresi veri merkezi olarak görüyorsa, geçmişten bağımsız olarak varsayılan ceza alırsınız.
  6. Semptomlarla karşılaştırın. Temiz DNSBL'lerde Cloudflare koruması altındaki sitelerde captcha'lar WAF iç skorlamasına işaret eder. Temiz skorlama veritabanlarında spam'deki e-postalar posta listelerine veya IP değil alan adı itibarına işaret eder.
  7. Sonucu kaydedin. Basit bir tablo tutun: adres, tarih, bulunan listelemeler, puan, eylem. Bir ay içinde dinamikleri görecek ve havuzun kalitesini değerlendirebileceksiniz.

Nasıl yorumlanır: "kaynak — ağırlık" matrisi

Ekiplerde uygulanması kolay basit bir ağırlık sistemi öneriyoruz. Her liste ailesine koşullu bir ağırlık atayın ve toplayın:

  • Spamhaus SBL/CSS, büyük operatörlerin manuel listelemeleri — ağırlık 10 (kritik, eylem gerektirir);
  • Spamhaus XBL, Barracuda, Invaluement — ağırlık 6 (önemli, temiz davranışla büyük olasılıkla kendiliğinden sona erer);
  • İki veya daha fazla skorlama hizmetinde 70'in üzerinde itibar puanı — ağırlık 6;
  • Kitle kaynaklı veritabanlarında 10'dan fazla taze şikâyet — ağırlık 4;
  • UCEPROTECT Level 2 ve 3, az bilinen listeler — ağırlık 1 (bilgilendirici, neredeyse kimse bunlara göre engellemez);
  • Mobil adres için PBL Spamhaus — web görevleri için ağırlık 0 (doğrudan posta göndermek için tasarlanmamış herhangi bir mobil aralığın doğal durumudur).

Toplam 5'e kadar — adres çalışır durumda. 6 ile 12 arasında — kritik olmayan görevler için kullanın ve izleyin. 12'nin üzerinde — adresi karantinaya gönderin veya değişim talep edin.

Teşhis kontrol listesi

  • Adresi hangi görev için kontrol ettiğimi anlıyorum.
  • En az üç liste ailesini kontrol ettim: DNSBL, skorlama, şikâyetler.
  • İtibar hizmetlerinin görüşüne göre ağ türünü biliyorum.
  • Olayların varlığını değil, yaşını da değerlendirdim.
  • Listelemeleri gerçek semptomlarla karşılaştırdım.
  • Sonucu günlüğe kaydettim.

Yöntem 2: Nedenleri anlamak — adres neden kara listeye girer ve bundan nasıl kaçınılır

Listeleme nedenleri haritası

Sorunu önlemek için hangi eylemlerin IP kara listesine kayda yol açtığını bilmek gerekir. Nedenleri dört gruba ayıralım.

Posta nedenleri

  • Alıcıların rızası olmadan toplu gönderim, yüksek "bu spam" şikâyet oranı.
  • Tuzak adreslere (spam tuzakları) e-posta gönderme — hiçbir şeye abone olmamış özel olarak oluşturulmuş kutular. Oraya bir e-posta neredeyse garantili listelemektir.
  • Operatörün politikasına göre doğrudan SMTP'nin öngörülmediği bir aralığa ait adresten posta gönderme.
  • Yanlış yapılandırılmış kimlik doğrulama (SPF, DKIM, DMARC) — tek başına liste değildir, ancak şüphelilik düzeyini keskin biçimde artırır.

Ağ nedenleri

  • Port taraması ve şifre deneme — bunu siz değil cihazdaki bir virüs yapıyor olsa bile.
  • Aynı ağdaki enfekte cihazlarla DDoS saldırılarına katılım.
  • Kimlik doğrulaması olmadan açık proxy veya aktarıcı işletimi — sensörler bu tür düğümleri saatler içinde bulur.

Web davranış nedeni

  • Tek kaynağa çok sık istekler: tek adresten dakikada yüzlerce istek insana benzemez.
  • Sıradan kullanıcıya görünmeyen, ancak kazıyıcının özenle atladığı gizli bağlantı tuzakları (honeypot bağlantıları) ziyaret etmek.
  • Teknik parametrelerin tutarsızlığı: karakteristik başlıklar olmadan beyan edilen mobil tarayıcı, bölümler arasında inanılmaz hızda gezinme, sayfa kaynaklarının yüklenmemesi.
  • Kısa sürede birçok hesaptan toplu kayıt ve benzer işlemler.

Komşuluk itibarı

  • Aynı adresin veya alt ağın diğer kullanıcılarının olayları. Mobil ağlarda bir adres gün içinde birçok cihazdan geçer ve bazıları enfekte olabilir.
  • Tarihsel "miras": adres, operatörün kötü davranışlı başka bir müşterisine ait olmuş olabilir.

Dürüst kullanıcı da neden hedef olur

Bu nokta en çok kafa karışıklığına neden olur. Nasıl yani — kötü bir şey yapmadım ama adres listede? Cevap basit: sensörler sizi değil trafiği görüyor. Kazıyıcınız saat başına aynı aralıklarla 3000 istek gönderiyorsa, koruma sistemi için bu kötü niyetli bir bottan ayırt edilemez. Aynı aralıkta sizinle birlikte enfekte bir akıllı telefon çalışıyorsa, eylemleri kolektif itibara yansır.

Ters tarafı da var. Mobil adresler yerleşik bir "bağışıklığa" sahiptir: liste operatörleri bir adresin arkasında gerçek insanların olduğunu anlar ve barındırma hizmetlerine göre daha yumuşak politikalar uygular. Bu her istediğinizi yapabileceğiniz anlamına gelmez. Bu, makul davranış durumunda mobil adres itibarının daha hızlı geri kazanıldığı anlamına gelir.

Önleyici trafik hijyeni: adım adım talimat

  1. İstek sıklığını sınırlayın. Muhafazakâr bir limitle başlayın — örneğin bir adresten bir alan adına 2–4 saniyede birden fazla istek olmasın — ve yalnızca koruma sinyali yokluğunda artırın.
  2. Doğal çeşitlilik ekleyin. Rastgele duraklamalar, farklı oturum süreleri, eylem türlerinin değişimi. Düzgün ritim — otomasyonun ana işareti.
  3. Teknik parametreleri tutarlı tutun. Başlıklar, dil, saat dilimi, ekran çözünürlüğü beyan edilen mobil istemciye ve adres bölgesine uygun olmalıdır.
  4. Kaynağın kurallarına saygı gösterin. robots.txt dosyası, resmî API'ler ve limitler — biçimsel değil. Bunlara uyum, belirli bir platformun listesine girme olasılığını keskin biçimde azaltır.
  5. Görevleri tek adreste karıştırmayın. Posta işlemleri, kazıma ve hesaplarla çalışma — farklı risk profilleri. Bunları adresler ve oturumlar bazında ayırın.
  6. Sunucu yanıtlarını izleyin. 403, 429 kodlarının payının artması, captcha'ların ortaya çıkması — erken sinyaller. Bunlara paralelliği artırarak değil, yoğunluğu düşürerek tepki verin.
  7. Adresleri oturumlardan önce ve sonra kontrol edin. Böylece miras alınan itibarı kendi kazandığınızdan ayırt edebilirsiniz.

"Başlatmadan önce üç soru" çerçevesi

Herhangi bir otomatik aktiviteden önce kendinize üç soru sorun. Trafiğim tek bir canlı insanın eylemlerine ne kadar benziyor? Hedef kaynağın yöneticisi loglara bakmaya karar verirse ne görür? Bu adres yarın listeye düşerse görev ne olur? En az bir yanıt sizi tatmin etmiyorsa — planı listelemden sonra değil, başlatmadan önce değiştirin.

Yöntem 3: Delisting — IP kara listeden nasıl çıkarılır

Önce dürüst soru: delisting gerçekten gerekli mi

Talep yazmadan önce adresin kime ait olduğunu ve onu ne kadar süredir kullandığınızı belirleyin. Kendi sunucunuz veya tahsis edilmiş statik bir adres ise — delisting haklıdır ve genellikle gereklidir. Proxy hizmeti aracılığıyla aldığınız bir mobil operatör havuzundan bir adres ise durum farklıdır. Biçimsel olarak herkes silme talep edebilir, ancak adres üzerindeki fiili kontrol operatörde kalır ve birkaç saat içinde adres başka bir aboneye gidebilir. Böyle bir durumda liste operatörüyle yazışmak yerine adresi değiştirmek ve proxy sağlayıcısına sorunu bildirmek daha akılcıdır.

İkinci soru — kaydın kendiliğinden sona erip ermeyeceği. Tespit ettiğimiz gibi, çoğu otomatik listeleme yeni olay olmadığında bir günden bir haftaya kadar sürer. Sorun giderildiyse bazen beklemek yeterlidir.

Evrensel delisting algoritması

  1. Nedeni ortadan kaldırın. Bu zorunlu ilk adımdır. Liste operatörü talepten sonra adresin davranışını kontrol edecek ve olaylar devam ederse kayıt geri döner — bazen daha uzun bir süreyle.
  2. Kanıt toplayın. Loglar, alınan önlemlerin açıklaması, giderme tarihi. Posta listelemeleri için — kimlik doğrulama yapılandırmasının ve posta listesi temizliğinin onayı.
  3. Resmî silme sayfasını bulun. Saygın tüm listelerde vardır, genellikle DNSBL yanıtının TXT kaydında belirtilir. "Tüm listelerden para karşılığı silme" teklif eden aracıları görmezden gelin.
  4. Talebi doğru adresten veya ağdan gönderin. Birçok form talebin listelenen adresin kendisinden gelmesini gerektirir — bu şekilde adres üzerindeki kontrol doğrulanır.
  5. Durumu kısa ve öz açıklayın. Ne oldu, ne yapıldı, neden tekrarlanmayacak.
  6. Yanıtı bekleyin ve durumu kontrol edin. Otomatik silmeler dakikalar içinde, manuel olanlar birkaç saatten birkaç güne kadar sürer.
  7. İzleyin. Delisting'den sonra iki hafta boyunca adresin davranışına artırılmış dikkat gösterin.

Başlıca listelerin özellikleri

  • Spamhaus. Silme merkezi üzerinden: PBL, adresin statik olduğu ve posta için yapılandırıldığı doğrulandığında self-servis olarak kaldırılır; XBL otomatik sona erer ancak hızlandırılabilir; SBL yazışma ve inandırıcı önlem açıklaması gerektirir. Ücretsiz.
  • Barracuda. Neden ve iletişim bilgilerini içeren talep formu. Genellikle 12–24 saat içinde değerlendirilir. Ücretsiz.
  • SpamCop. Delisting gerekmez: kayıt son şikâyetten yaklaşık bir gün sonra kaldırılır.
  • UCEPROTECT. Level 1 olay olmadan 7 gün içinde sona erer. Ücretli "ekspres silme" sektör tarafından eleştiriliyor; pratik tavsiye — para ödemeyin, sona ermesini bekleyin. Level 2 ve 3 alt ağlara ve sağlayıcıya aittir, normal kullanıcı bunları etkilemez.
  • AbuseIPDB ve kitle kaynaklı veritabanları. Adres veya ağ sahibi, adres üzerindeki hakkı doğrulayarak form aracılığıyla raporların silinmesini talep edebilir. Raporlar zamanla ağırlık da kaybeder.
  • Cisco Talos ve ticari skorlama beslemeleri. İtibar itiraz formları vardır, ancak karar gerçek trafiğe dayalı olarak verilir. En iyi delisting — birkaç gün kusursuz davranış.
  • Platformların iç veritabanları ve WAF. Doğrudan delisting yok. Yalnızca zaman ve temiz davranış işe yarar. Kendi hizmetleriniz ve hesaplarınız için — durumu açıklayan bir destek başvurusu.

Delisting talep şablonu

Aşağıda herhangi bir listeye uyarlanabilecek bir e-posta yapısı var. Operatör uluslararası ise İngilizce yazın.

  • Konu: [IP] adresinin [liste adı] listesinden silinmesi talebi.
  • Kim olduğunuz: kuruluş, rol, adres üzerindeki hakkın doğrulanması.
  • Ne oldu: olayın kısa açıklaması ve tarihi. Nedeni ihlal ise açıkça söyleyin.
  • Ne yapıldı: tarihlerle somut önlemler: yazılım güncellendi, aktarıcı kapatıldı, SPF/DKIM/DMARC yapılandırıldı, limitler getirildi, geçersiz adresler posta listesinden çıkarıldı.
  • Neden tekrarlanmayacak: kurulan izleme, sorumlu iletişim.
  • Rica: kaydı silin ve mümkünse fark etmemiş olabileceğiniz ek sorunları bildirin.

İyi bir talebin üç ilkesi: dürüstlük, somutluk, duygusallıktan uzaklık. Liste operatörleri her gün "hiçbir şey yapmadık, derhal silin" şeklinde yüzlerce e-posta okur. Loglar ve önlem planı içeren bir e-posta bu fonun içinde anında fark edilir.

Delisting kontrol listesi

  • Olayın nedeni bulundu ve giderildi.
  • Adrese kimin sahip olduğunu ve talep hakkım olup olmadığını anlıyorum.
  • Kaydın kendiliğinden sona erip ermeyeceğini ve ne zaman ereceğini biliyorum.
  • Yalnızca liste operatörünün resmî formunu kullanıyorum.
  • Talep gerçekleri, tarihleri ve önlemleri içeriyor.
  • Silmeden sonra yeniden listeleme izlemesi kuruldu.

Yöntem 4: Mobil proxy havuzu itibarını sistem olarak yönetmek

Paradigma değişimi: adresten havuza

Mobil proxy'lerle çalışan profesyoneller er ya da geç önemli bir fikre varır. Tek bir adresin itibarını yönetmek — taktik. Havuzun itibarını yönetmek — strateji. Fark, tek bir arabayı tamir etmekle bir filoyu organize etmek arasındaki gibidir: ikinci durumda, tek tek birimlerin arızalanacağını kabul eder ve bunun işi durdurmayacağı şekilde süreçler kurarsınız.

"İtibar trafik ışığı" çerçevesi

Havuzdaki tüm adresleri üç duruma bölün ve aralarındaki geçiş kurallarını belirleyin.

  • Yeşil bölge — toplam listeleme ağırlığı 5'e kadar, itibar puanı 40'ın altında, taze şikâyet yok. Adresler kritik görevler için kullanılır: değerli hesaplarla çalışma, ödeme işlemleri, müşterilerle iletişim.
  • Sarı bölge — ağırlık 6 ile 12 arasında veya puan 40–70. Adresler kritik olmayan kazıma, test, keşif için uygundur. Her 24 saatte bir yeniden kontrol edilir.
  • Kırmızı bölge — ağırlık 12'nin üzerinde, puan 70'in üzerinde veya belirgin engelleme semptomları. Adresler rotasyondan çıkarılır ve değişime gönderilir. 72 saat sonra yeniden kontrol; itibar geri kazanılmadıysa — adres hariç tutulur.

Bölgeler arasındaki geçiş otomatik ve operatörün hislerine değil verilere dayalı olmalıdır. Sistemin manuel çalışmadan temel farkı budur.

Adım adım sistem kurulumu

  1. Envanter. Kullanılan tüm adreslerin ve edinme kanallarının listesini yapın. Her biri için operatörü, bölgeyi, rotasyon türünü kaydedin.
  2. Temel kontrol. Tüm havuzu birinci yöntemdeki teşhis protokolünden geçirin. Bölgelere göre dağıtın. Zaten bu adımda birçok kişi adreslerin bir kısmının uzun zamandır kötü itibarla çalıştığını keşfeder.
  3. Kontrolleri otomatikleştirin. Kilit listelerin ve skorlama API'lerinin düzenli sorgusunu kurun. Onlarca adreslik bir havuz için zamanlanmış bir betik yeterlidir; yüzlerce için — veritabanı ve bildirimleri olan ayrı bir hizmet.
  4. Görevleri bölgelere bağlayın. Kodda veya araç ayarlarında kırmızı bölge adreslerinin kullanımını yasaklayın ve sarı bölgeyi sınırlayın. Bu basit kural en pahalı hatayı önler — bozuk bir adres üzerinden değerli bir hesapla çalışmak.
  5. Zamanlayıcıyla değil veriyle rotasyon. Adresi koruma sinyalleri (429 artışı, captcha'lar, dönüşüm düşüşü) ortaya çıktığında değiştirin, sabit bir programa göre değil. Aşırı sık anlamsız rotasyon, platformlar için kendi başına şüpheli görünür.
  6. Karantina ve kurtarma. Kırmızı bölgeden çıkan adresleri önce sarıya döndürün ve kritik görevlere kabul etmeden önce bir hafta izleyin.
  7. Sağlayıcıyla geri bildirim. Bir bölgeden veya bir operatörden sistematik olarak kötü itibarlı adresler alıyorsanız — bu, proxy hizmetiyle konuşmak için veridir. İyi hizmetler havuzlarının itibarını kendileri izler ve bu tür geri bildirimle ilgilenir.

İzlenmesi gereken metrikler

  • Yeşil bölgedeki adreslerin oranı — havuzun genel sağlığı. Kaliteli bir mobil havuz için referans — %85'in üzerinde.
  • Ortalama kurtarma süresi — bir adresin geri dönmeden önce kırmızı bölgede geçirdiği gün sayısı. Artıyorsa, görevlerin davranışı daha agresif hale gelmiş demektir.
  • Görev başına engelleme oranı — 403/429/captcha ile karşılaşan isteklerin yüzdesi. Kamu listelerine düşmeden önceki erken gösterge.
  • İtibar olayının maliyeti — bir kırmızı bölge vakasının kaç para ve saat gerektirdiği. İzlemeye yatırımı gerekçelendirmeye izin verir.

Risk profillerini ayırma ilkesi

En hafife alınan pratiklerden biri — adreslere "uzmanlık" atamaktır. Hesaplarla çalışma adresleri asla kazıma için kullanılmaz. Test adresleri ödeme işlemlerine dokunmaz. Böyle bir ayrım, bir görevdeki olayın diğerinin itibarını kirletmemesini garanti eder. Benzetme — farklı amaçlar için farklı kredi kartları: biri ele geçirilse bile diğerleri çalışmaya devam eder.

Tipik hatalar: yapılmaması gerekenler

Proxy'lerle çalışan ekipleri yıllarca gözlemlediğimizde aynı hataları tekrar tekrar gördük. Başlıcalarını inceleyelim.

Hata 1: herhangi bir eşleşmeyi felaket saymak

Çoklu denetleyici üç kırmızı satır gösterdi — ve ekip tüm havuzu değiştiriyor. Ancak üç listelemden ikisi hiçbir önemli platformun kullanmadığı listelerde, üçüncüsü ise herhangi bir mobil aralık için doğal olan PBL'de. Sonuç: gerçek bir sorun olmadan kaybedilen zaman ve para. Kaynağın ağırlığını her zaman değerlendirin.

Hata 2: "ekspres silme" için para ödemek

Bazı operatörler ve aracılarda acil delisting hizmetleri — aslında birkaç gün içinde kendiliğinden olacak şey için ödeme. Dahası, ödeme olaylar devam ederse yeniden listelemeye karşı hiçbir koruma sağlamaz. Sektör bu tür pratiklere eleştirel yaklaşır ve saygın listeler delisting'i paraya çevirmez.

Hata 3: nedeni ortadan kaldırmadan delisting istemek

Uzun süreli bir kayıt almanın en hızlı yolu — silmeyi başarıp önceki davranışa devam etmek. Liste operatörleri bunu görür ve koşulları sıkılaştırır. Neden her zaman önce gelir.

Hata 4: captcha'lara paralelliği artırarak tepki vermek

Sezgisel "yavaşladı — akış ekleyelim" mantığı ters sonuç verir. Koruma sistemi yoğunluk artışını kaydeder ve önlemleri sıkılaştırır, bu da sonunda adresin itibarına yansır. Koruma sinyallerine doğru tepki — yükü azaltmak ve duraklamak.

Hata 5: IP itibarı ile diğer sinyaller arasındaki farkı görmezden gelmek

Ekip saatlerce adresleri kontrol ediyor ama sorun tutarsız istemci parametrelerinde, gönderici alan adında veya hesap davranışında. Diğer sinyaller otomasyon diye bağırıyorsa temiz IP kurtarmaz. Teşhis kapsamlı olmalıdır.

Hata 6: anlamsız rotasyon

Sakin çalışma sırasında her dakika adres değiştirmek itibarı iyileştirmez — tek bir oturum çerçevesinde ağ bağlamındaki keskin değişimleri izleyen platformlar için sizi daha görünür kılar. Veriyle rotasyon yapın.

Hata 7: tüm görevleri tek adreste karıştırmak

Aynı adres üzerinden aynı saatte e-posta gönderimi, kazıma ve değerli hesaplar — sorunu bir alandan diğerlerine aktarmanın garantili yolu.

Hata 8: günlük tutmamak

Kontroller, olaylar ve önlemler hakkında kayıtlar olmadan her seferinde sıfırdan başlarsınız ve liste operatörüne durumun kontrol altında olduğunu kanıtlayamazsınız. Günlük — itibar yönetiminin en ucuz aracı.

Araçlar ve kaynaklar

DNSBL kontrolü

  • Çoklu denetleyiciler (MXToolbox Blacklist Check, MultiRBL, DNSBL.info ve benzerleri) — bir adresi düzinelerce listede aynı anda hızlı kontrol. İlk teşhis için iyidir.
  • Kendi DNS sorgularınız — dig veya nslookup komutları, üçüncü taraf hizmetler olmadan bir adresi belirli bir bölgede kontrol etmenize olanak tanır ve kolayca otomatikleştirilir.
  • Liste operatörlerinin resmî araçları — Spamhaus, Barracuda ve diğerlerinin kendi kontrol ve delisting sayfaları vardır; her zaman toplayıcılardan daha doğrudur.

İtibar skorlaması ve ağ türü

  • IPQualityScore, Scamalytics, IP2Proxy, ipinfo — risk puanı, ağ türü belirleme (mobil, veri merkezi, barındırma), otomasyon işaretleri. Çoğunun API üzerinden ücretsiz istek limiti vardır, bu küçük havuzlar için yeterlidir.
  • Cisco Talos Intelligence — büyük bir güvenlik sağlayıcısı bakış açısından adres ve alan adı itibarı.
  • MaxMind minFraud — ödemelerde anti-fraud odaklı; işletme sahiplerinin ödeme sistemleri tarafından nasıl görüldüklerini anlamaları için faydalıdır.

Şikâyet veritabanları

  • AbuseIPDB — API'li en büyük kitle kaynaklı veritabanı; şikâyet kategorilerini ve yaşını gösterir.
  • StopForumSpam — kayıt ve form spam'ine odaklanır; topluluklarla çalışanlar için günceldir.
  • Project Honey Pot — adreslerin tuzak adreslerle etkileşimi hakkında veriler.

Posta itibarı (altyapı sahipleri için)

  • Google Postmaster Tools ve Microsoft SNDS — en büyük posta sağlayıcılarının IP'lerinizi ve alan adlarınızı nasıl değerlendirdiğini gösteren paneller.
  • SPF, DKIM, DMARC doğrulayıcıları — temel hijyen; olmadan herhangi bir gönderici itibarı kırılgandır.

Otomasyon

  • Python veya Go betikleri DNS sorguları ve HTTP istemcileri için kütüphanelerle — onlarca adreslik bir havuz için yeterlidir.
  • Görev zamanlayıcıları ve bildirim sistemleri — cron, sistem zamanlayıcıları, adresin kırmızı bölgeye geçişi hakkında bildirim için ekip mesajlaşma uygulamalarıyla basit entegrasyonlar.
  • Elektronik tablo veya hafif veritabanı itibar günlüğü için — basit çözümleri küçümsemeyin.

Kaliteli proxy hizmetlerinin sundukları

Olgun mobil proxy sağlayıcıları, mobileproxy.space dahil, kendi taraflarında havuz itibarına dikkat eder: olayları izler, sorunlu adresleri çıkarır, API üzerinden hızlı IP değişimi imkânı sunar. Bu sizin izlemenizi ortadan kaldırmaz ama önemli ölçüde basitleştirir — zaten filtrelenmiş adreslerle çalışırsınız ve hızlı değişim aracı elde edersiniz.

Vakalar ve sonuçlar

Aşağıda mobil proxy'lerle çalışan ekiplerin pratiğinden üç genelleştirilmiş vaka var. Ayrıntılar değiştirildi, rakamlar tipik sonuçları yansıtıyor.

Vaka 1: Trafik ekibi ve prelanding dönüşüm düşüşü

Durum. Altı kişilik bir ekip birkaç coğrafyada kampanyalar yürütüyordu. İki hafta içinde tıklamadan teklife geçiş dönüşümü kreatiflerde değişiklik olmadan %34'ten %19'a düştü. Trafiğin bir kısmı CDN koruması altındaki prelandinglerde tarayıcı kontrolüne takılıyordu.

Teşhis. 40 adreslik havuzun kontrolü, 11'inin 70'in üzerinde itibar puanı ve kitle kaynaklı veritabanlarında düzinelerce taze şikâyeti olduğunu gösterdi. Neden içsel çıktı: aynı adresler paralel olarak casus hizmetlerinin agresif kazıması için saatte yaklaşık 2000 istek yoğunluğuyla kullanılıyordu.

Çözüm. Risk profilleri ayrımı getirildi: kazıma ayrı adreslere taşındı, kampanyalarla çalışmak için yalnızca yeşil bölge bırakıldı. Günlük otomatik kontrol ve kırmızı bölgeye geçişte adresleri hariç tutma kuralı kuruldu.

Sonuç. 9 gün içinde dönüşüm %31–33'e döndü. Yeşil bölgedeki adres oranı %62'den %91'e çıktı. Ekibin manuel engelleme çözümüne harcadığı zaman haftada yaklaşık 10 saatten 2 saate düştü.

Vaka 2: Pazar yeri kazıyıcısı geliştiricisi ve captcha'lar

Durum. Bir fiyat izleme hizmeti birkaç pazar yerinden veri topluyordu. Captcha'ya takılan istek oranı %38'e ulaştı ve veri toplamayı ekonomik olarak anlamsız hale getirdi.

Teşhis. Kamu listeleri temizdi. Sorun platformların iç skorlamasıydı: kazıyıcı 0,4 saniyelik düzgün aralıklarla çalışıyordu, sayfa kaynaklarını yüklemiyordu ve beyan edilen mobil istemciye uymayan başlıklar gönderiyordu.

Çözüm. Yoğunluk adres başına saatte 300 isteğe, rastgele duraklamalarla düşürüldü, başlıklar mobil profile uygun hale getirildi, 429 kodlarına tepki eklendi: duraklama ve adres değiştirme. Her adres kullanılmadan önce ağ türü kontrolü getirildi — havuzdaki birkaç adresin hizmetlerce veri merkezi olarak belirlendiği ortaya çıktı.

Sonuç. İki haftada captcha oranı %4'e düştü. Adres başına yoğunluk azalmasına rağmen günlük toplanan toplam kayıt sayısı %27 arttı — sadece istekler artık kaybolmadığı için.

Vaka 3: Çevrimiçi mağaza ve posta sunucusunun SBL'de listelenmesi

Durum. Mağaza sahibi işlem e-postalarının müşterilere ulaşmayı bıraktığını fark etti. Kontrol, sunucunun statik adresinin Spamhaus SBL'de listelendiğini gösterdi.

Teşhis. Site üzerindeki açıklık içeren form aracılığıyla saldırganlar mağaza adına spam gönderiyordu — bir gecede birkaç bin e-posta, bir kısmı tuzak adreslere düştü.

Çözüm. Açıklık kapatıldı, form doğrulama ve limitlerle desteklendi, SPF, DKIM ve DMARC yapılandırıldı, kuyruklar temizlendi. Ardından loglar ve önlemlerin açıklamasını içeren şablona göre delisting talebi gönderildi.

Sonuç. Kayıt talepten 31 saat sonra kaldırıldı. Teslim edilebilirlik üç gün içinde geri kazandı. Ana DNSBL'lerde adres için haftalık izleme kuruldu — sonraki aylarda tekrar olay yaşanmadı.

Başarılı vakaları birleştiren ne

Üç hikâyede de ekipler sezgisel değil, üç şey sayesinde kazandı: panik yerine kesin teşhis, semptomlarla savaşmak yerine nedeni ortadan kaldırma ve tek seferlik eylemler yerine düzenli süreç kurma. İtibar yönetiminin özü de budur.

SSS: derin sorulara yanıtlar

Sonsuza dek düşülen tek bir IP kara listesi var mı?

Hayır. Farklı ilkelere sahip düzinelerce bağımsız veritabanı var ve kayıtların büyük çoğunluğu olaylar durduğunda otomatik olarak sona erer. Uzun süreli manuel listelemeler yalnızca sistemik ihlalcilerde görülür. "Sonsuz liste" efsanesi genellikle sürenin gerçekten belirsiz olduğu platformların iç veritabanlarından kaynaklanır, ama orada bile itibar temiz davranışla geri kazanılır.

Mobil IP neden PBL Spamhaus gösteriyor ve endişelenmeli miyim?

PBL — operatörlerin kendilerinin doğrudan posta göndermek için tasarlanmamış aralıkları eklediği politik bir listedir. Neredeyse tüm mobil ve ev adresleri varsayılan olarak oradadır. Web görevleri için bunun hiçbir önemi yoktur ve olumsuz itibar sayılmaz. Yalnızca böyle bir adresten doğrudan posta göndermeye çalışıyorsanız endişelenmelisiniz — ki bunu yapmamalısınız.

Bir olaydan sonra mobil adresin itibarı ne kadar hızlı geri kazanılır?

Kamu şikâyet veritabanlarında ve otomatik DNSBL'lerde — genellikle bir ila yedi gün temiz davranışta. Skorlama sistemlerinde puan, eski olaylar zayıfladıkça kademeli olarak düşer. Platformların iç veritabanları hem daha hızlı (saatler) hem de daha yavaş (tekrarlanan ihlallerde haftalar) olabilir. Ek faktör — kontrol edemediğiniz aralıktaki diğer kullanıcıların kolektif davranışıdır.

Proxy sağlayıcısı bilerek "kirli" bir adres verebilir mi?

Verebilir — ancak kaliteli hizmetler bunun tersini ister ve havuzlarının itibarını izler. Bu yüzden adresleri kendiniz kontrol etmek ve geri bildirim vermek önemlidir. Bir sağlayıcıda adreslerin sistematik olarak %20'sinden fazlası sarı veya kırmızı bölgeye düşüyorsa, bu işbirliğini gözden geçirmek için bir sebeptir.

Sorunun IP'de mi yoksa başka bir şeyde mi olduğunu nasıl anlarım?

Basit deney: aynı istemci profiliyle aynı görevi yeşil bölgeden kesinlikle temiz bir adres üzerinden gerçekleştirin. Semptomlar kaybolduysa — sorun adres itibarındadır. Devam ediyorsa — istemci parametrelerinde, davranışta, alan adında veya hesapta arayın. Temiz IP — gerekli ama yeterli olmayan koşul.

Rakiplerin itibarını bozmak için şikâyet göndermeli miyim?

Hayır ve sadece etik nedenlerle değil. Kitle kaynaklı veritabanları şikâyet edenlerin itibarını da izler: toplu asılsız raporlar tüm mesajlarınızın ağırlığını düşürür ve muhabir hesabınızın engellenmesine yol açabilir. Ayrıca bu tür eylemlerin hukuki sonuçları olabilir. Başkasının itibarını bozmaya değil, kendi itibarınıza yatırım yapın.

IPv6 adresleriyle çalışırken itibar nasıl hesaba katılır?

Liste operatörleri IPv6'yı tek tek adresler değil, çoğunlukla /64 düzeyindeki önekler düzeyinde değerlendirir. Bu, itibarınızın önekteki komşulara daha da güçlü bağlı olduğu anlamına gelir. Kontrolde tüm öneğin durumuna bakın ve adres seçerken IPv6 dağıtım politikası hakkında bilgi verebilen sağlayıcıları tercih edin.

Platformlar davranışa baktığına göre 2026'da IP itibarı ne kadar önemli?

IP'nin tek faktör olarak rolü azaldı, ancak kilit faktörlerden biri olarak korundu. Kötü adres itibarı istemciyi artırılmış kontrol moduna geçirir; burada diğer sinyaller daha sıkı değerlendirilir. İyi itibar, küçük davranış kusurlarının fark edilmemesine izin veren bir güven rezervi sağlar. Yani temiz IP bir geçiş izni değil, bir avantajdır.

Havuzdaki adresler ne sıklıkla kontrol edilmeli?

Kritik görevlerde kullanılan yeşil bölge adresleri için — işe başlamadan önce günlük. Sarı bölge için — her 24 saatte bir, dinamiklere artırılmış dikkatle. Yeni adresler için — alındığında hemen ve ilk oturumlardan bir gün sonra, miras alınan itibarı kendi kazandığınızdan ayırt etmek için. Yüksek görev yoğunluğunda sıklık günde birkaç kez artırılmalıdır.

Sonuç: itibar sorun değil, bir varlık

Özetleyelim. IP kara listesi bir hüküm veya tek bir monolit değil, farklı mantığa, farklı ağırlığa ve farklı kayıt ömrüne sahip düzinelerce veritabanından oluşan bir ekosistemdir. Adresler oraya sensörler tarafından kaydedilen davranış nedeniyle düşer — ve bu davranış size, aracınıza veya aralık komşunuza ait olabilir. Oradan nedenin ortadan kaldırılması, zaman ve gerekirse yetkin bir delisting talebi yoluyla çıkılır.

Ama bu rehberin ana fikri daha geniş. IP itibarı yönetilebilir bir varlıktır. Her varlık gibi muhasebe, izleme ve kurallar gerektirir. Ona sistemli yaklaşan ekipler olaylara günler yerine saatler harcar ve başkalarının captcha'lar ve engellemelerle boğuştuğu yerde istikrarlı sonuçlar elde eder.

Sonraki adımlarınız

  1. Şu anda kullandığınız adreslerin envanterini çıkarın ve onları teşhis protokolünden geçirin.
  2. Havuzu "trafik ışığı" bölgelerine göre dağıtın ve görevleri bölgelere bağlayın.
  3. Risk profillerini ayırın: hesaplar, kazıma, testler — farklı adreslerde.
  4. Günde en az bir kez otomatik kontrol kurun ve bir günlük tutun.
  5. Trafik hijyeni kontrol listesine göre otomatik görevlerin yoğunluğunu ve ritmini gözden geçirin.
  6. Adres kalitesi konusunda proxy sağlayıcısıyla geri bildirim kurun.

Her biri bir saatten bir güne kadar süren altı adım. Bir ay içinde çoklu denetleyici raporlarına endişeyle değil, profesyonel bir ilgiyle bakacaksınız — çünkü her satırın ne anlama geldiğini ve onunla ne yapacağınızı kesin olarak bileceksiniz. Uzmanı, sorunun kendi kendine çözülmesini bekleyen kullanıcıdan ayıran tam da budur.