Residential IP neden proxy veya hosting görünür? IP denetimi rehberi

IP istihbaratı sağlayıcıları bir adresin arkasındaki cihazı hiçbir zaman görmez. Adresi kayıt kayıtlarına, yönlendirme verilerine, DNS adlarına ve gözlemledikleri davranışa bakarak etiketlerler. "Residential" bir IP, bu katmanlardan biri veri merkezine işaret ettiğinde proxy ya da hosting olarak işaretlenir. Bu, adresi duyuran ağ, adresin içinde bulunduğu /24 bloğu, WHOIS organizasyonu ya da reverse DNS kaydı, kayıt ülkesi ile coğrafi konumu arasındaki uyumsuzluk veya geçmişte proxy trafiği taşımış olması olabilir. Bu katmanların her birini ücretsiz araçlarla IP başına yaklaşık on dakikada kendiniz kontrol edebilirsiniz. Bu rehber nasıl yapılacağını gösteriyor.

IP itibarı ve fraud puanlaması yazımız, IPQualityScore gibi bir puanın nasıl oluşturulduğunu ve siteler tarafından nasıl kullanıldığını anlatıyor. Bu yazı onun pratik tamamlayıcısı: kararı hangi sınıflandırma sinyallerinin ürettiği, dört yaygın sağlayıcının bunları nasıl sunduğu ve tek bir IP ya da bir çıkış IP örneklemi için tekrarlanabilir bir denetim.

Bir IP neden proxy ya da hosting olarak işaretlenir?

Sözde residential IP'lere verilen "hosting" ya da "proxy" kararlarının çoğu beş sinyalden gelir. Önce ağ sahipliği ve yönlendirme, sonra adlar, ardından konum tutarlılığı ve son olarak gözlemlenen davranış. Sağlayıcılar bunları farklı biçimlerde birleştirir; aralarındaki anlaşmazlığın nedeni de budur.

1. ASN türü: adresi kim duyuruyor?

Yönlendirilen her IP, BGP'de bir otonom sistem (ASN) tarafından duyurulur. Sağlayıcılar ASN'leri arkalarındaki kuruluşun türüne göre sınıflandırır. IPinfo'nun ASN type alanı isp, hosting, business, education veya government değerlerinden birini alır. Ağların kendilerini tanımladığı PeeringDB'de ise bir info_types alanı bulunur. API'si Comcast (AS7922) için ["Cable/DSL/ISP"], Cloudflare (AS13335) için ["Content"] döndürür:

curl -s "https://www.peeringdb.com/api/net?asn=7922" | jq '.data[0] | {name, info_types}'

Duyuran ASN bir hosting şirketiyse, adres kime kayıtlı olursa olsun neredeyse tüm sağlayıcılar IP'yi hosting olarak görür. Bu, en ağır basan ve itiraz etmesi en zor sinyaldir.

2. Yalnızca ASN değil, duyurulan prefix

Statik "residential" ya da ISP IP'lerini denetlediğimizde işe yarayan birim çoğu zaman ASN değil, duyurulan prefix, genellikle de bir /24 oldu. Aksi hâlde temiz olan bir ISP ağı içindeki tek bir /24 hosting olarak görünürken aynı ASN'nin geri kalanı residential görünebilir. Muhtemel neden, sağlayıcıların verilerini prefix düzeyinde düzeltmesidir. Kiralanmış, yeniden yönlendirilmiş ya da üzerinde hosting sunucuları görülmüş bir blok tek başına yeniden etiketlenir, ASN'nin geri kalanı etiketini korur. Ayrıca /24, küresel yönlendirme tablosunda genel olarak kabul edilen en küçük IPv4 bloğudur; dolayısıyla kiralama ve yeniden duyurma için doğal birimdir. Bu yüzden bir IP işaretlendiğinde, tüm sağlayıcıyı ya da tüm ISP'yi suçlamadan önce aynı /24 içindeki komşularına bakın.

3. WHOIS organizasyonu ve reverse DNS

Kayıt bilgileri ve PTR adları ucuz sinyallerdir; sağlayıcılar bunları eşitlik bozucu olarak kullanır. "hosting", "cloud", "server" ya da "VPS" gibi kelimeler içeren bir netname veya org ya da vps-123.example-host.net gibi bir PTR, kararı hosting'e doğru çeker. Residential aralıklarda genellikle erişim teknolojisini kodlayan ya da "dynamic" veya "pool" ifadesi içeren ISP tarzı PTR'ler bulunur. PTR'nin hiç olmaması tek başına hiçbir şey kanıtlamaz. Pek çok ISP reverse DNS kaydı tutmaz, pek çok hosting sağlayıcısı ise tutar.

4. Kayıt ülkesi ile coğrafi konum ülkesi

IP'nin kayıt ülkesi (bölgesel internet kayıt kuruluşundan, yani RIR'den) ile coğrafi konum sağlayıcılarının onu yerleştirdiği ülke arasındaki uyumsuzluk, statik bir IP'ye "hosting" ya da "proxy" kararı verilmesinde gördüğümüz en yaygın nedenlerden biridir. Gerçek ev internet bağlantıları nadiren yer değiştirir: Alman bir ISP'nin müşterileri Almanya'dadır. Kiralanan ve yeniden duyurulan bloklar ise sıklıkla yer değiştirir; kayıt asıl sahibinde kalırken adresler başka bir yerde kullanılır. Operatörler bir prefix'in gerçekte nerede kullanıldığını kendi yayımladıkları bir geofeed ile (RFC 8805) bildirebilir; bu geofeed WHOIS üzerinden RFC 9632 ile bulunabilir. Bu, coğrafi konumu değiştirir, ancak kayıt uyumsuzluğu bakan herkes için görünür kalır.

Çözümlemeye değer gerçek bir örnek: 1.1.1.1. Team Cymru'nun IP-ASN whois servisi (2026-10-03 tarihinde sorgulandı) tek satırda üç farklı bilgi gösteriyor:

$ whois -h whois.cymru.com " -v 1.1.1.1"
AS      | IP               | BGP Prefix          | CC | Registry | Allocated  | AS Name
13335   | 1.1.1.1          | 1.1.1.0/24          | AU | apnic    | 2011-08-11 | CLOUDFLARENET - Cloudflare, Inc., US

Blok APNIC üzerinden Avustralya'da kayıtlı (APNIC Labs'e ait). ABD'de kayıtlı olan Cloudflare ASN'si tarafından /24 olarak duyuruluyor ve ip-api onu hosting: true ile AU'ya konumlandırıyor. APNIC ve Cloudflare'in ortaklaşa işlettiği bir resolver için bunların hepsi beklenen şeyler. Size "ABD residential" olarak satılan bir IP'de ise aynı üçlü ayrışma her türlü hosting kararını açıklar.

5. Gözlemlenen davranış

Son katman, sağlayıcıların IP'nin ne yaptığını görmüş olmasıdır: honeypot'lara istek atması, kötüye kullanım listelerinde yer alması, VPN ya da proxy yazılımı çalıştırması veya bilinen bir residential proxy ağının çıkış noktası olarak görünmesi. Gerçek bir ISP'deki gerçek bir ev IP'sini işaretleyebilen tek katman budur. IPinfo'nun residential proxy API'si, IP'nin görüldüğü service bilgisini 7 günlük pencerede last_seen ve percent_days_seen ile birlikte döndürür. MaxMind, is_residential_proxy alanını "şüpheli bir anonimleştirme ağında bulunan ve bir residential ISP'ye ait" IP olarak tanımlar; peer-to-peer proxy IP'leri açıkça hariç tutulur. Sağlayıcılar bu çizgiyi farklı yerlere çeker ama sonuç değişmez: temiz bir ASN, gerçekten proxy olarak kullanılan bir IP'yi korumaz.

Dört sağlayıcı kararı nasıl sunuyor?

Her sağlayıcı biraz farklı bir soruyu yanıtlar. "Çelişen" iki sonuç çoğu zaman ikisi de doğrudur. Aşağıdaki alan adları her sağlayıcının güncel dokümantasyonundan alınmıştır.

AbuseIPDB sık göreceğiniz bir etiket daha ekler: "Data Center/Web Hosting/Transit" gibi değerler alan usageType (dokümantasyon).

ISP proxy'leri: neden gri bölgedeler?

"ISP" ya da "static residential" proxy'ler, bir ISP'ye kayıtlı ama veri merkezindeki sunuculara yönlendirilen adreslerdir. Gri bölgede olmalarının nedeni, kayıt katmanı residential derken yönlendirme ve davranış katmanlarının aynı şeyi söylemeyebilmesidir. Belirli bir IP'nin geçip geçmemesi, sağlayıcının o prefix için en çok hangi katmana güvendiğine bağlıdır.

İyi olan versiyon, ISP'nin kendi bloğunu kendi ASN'sinden duyurması ve sunucuların kendi ağında bulunmasıdır. Bu durumda ASN türü, WHOIS ve coğrafi konum birbiriyle uyuşur. Zayıf versiyon ise ISP'ye kayıtlı bir bloğun, çoğunlukla bir kiralamanın ardından, bir hosting şirketinin ASN'si tarafından duyurulmasıdır. Kayıt hâlâ "ISP" der, ama duyuran ASN hosting'dir ki bu en ağır sinyaldir; ayrıca kayıt ülkesi coğrafi konumla uyuşmayabilir. Sağlayıcılar bu blokları prefix prefix yakalar; aynı sağlayıcıdan bir /24'ün temiz, bir sonrakinin işaretli çıkmasının nedeni budur. ISP proxy yazımız işin ürün tarafını ele alıyor. Aşağıdaki denetim ise size hangi versiyonun satıldığını anlamanın yolu.

Bir IP'yi adım adım kendiniz nasıl denetlersiniz?

Her IP'de aynı beş adımı uygulayın: çıkış IP'sini alın, kaydı sorgulayın, yönlendirmeyi sorgulayın, DNS'i kontrol edin, ardından iki üç sağlayıcıya sorun. Karşılaştırmayı /24 düzeyinde yapın. Aşağıdakilerin hepsi ücretsiz endpoint'lerle çalışır.

Adım 1: gerçek çıkış IP'sini alın

Hedefin gerçekte hangi adresi gördüğünü doğrulayın. Panele güvenmeyin. Bir proxy için:

curl -s -x "http://USERNAME:PASSWORD@gate.proxyhat.com:8080" https://api.ipify.org

Script yazmak istemiyorsanız proxy checker aracımız aynı işi tarayıcıda yapar.

Adım 2: kayıt (RDAP, Team Cymru)

IP=1.1.1.1
# rdap.org yönlendiricisi üzerinden RDAP: kayıtlı aralık, sahip, kayıt ülkesi
curl -sL "https://rdap.org/ip/$IP" | jq '{name, handle, country, type, startAddress, endAddress}'
# Tek satırlık özet: ASN, BGP prefix, kayıt CC, kayıt kuruluşu, AS adı
whois -h whois.cymru.com " -v $IP"

country ve sahip name alanlarını not edin. 1.1.1.1 için RDAP "name": "APNIC-LABS", "country": "AU" döndürür.

Adım 3: yönlendirme (RIPEstat, bgp.he.net)

RIPEstat Data API ücretsizdir, anahtar gerektirmez ve yalnızca RIPE'nin değil tüm RIR'lerin adres alanını kapsar.

# Duyuran ASN ve duyurulan prefix'in tam hâli
curl -s "https://stat.ripe.net/data/network-info/data.json?resource=$IP" | jq '.data'
# Bu ASN kimde ve prefix duyuruluyor mu
curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=$IP" | jq '.data | {resource, announced, asns}'
# RIR tahsis istatistiklerinden ülke
curl -s "https://stat.ripe.net/data/rir-stats-country/data.json?resource=$IP" | jq '.data.located_resources'
# ASN'nin duyurduğu tüm prefix'ler; bu /24 aykırı mı, görmek için
curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS13335" | jq '.data.prefixes | length'

Görsel bir görünüm için bgp.he.net aynı ASN ve prefix'i upstream'ler ve peer'larla birlikte gösterir. Bir veya iki transit sağlayıcısı hosting şirketi olan küçük bir ASN size çok şey anlatır.

Adım 4: reverse DNS

dig +short -x $IP

Adım 5: iki üç sağlayıcı, sonuçlar yan yana

# ip-api: ücretsiz, anahtarsız, yalnızca HTTP
curl -s "http://ip-api.com/json/$IP?fields=status,countryCode,isp,org,as,reverse,mobile,proxy,hosting"
# IPinfo Lite: token ile ücretsiz, ülke + ASN
curl -s "https://api.ipinfo.io/lite/$IP?token=$IPINFO_TOKEN"
# AbuseIPDB: ücretsiz anahtar, günde 1.000 sorgu
curl -sG https://api.abuseipdb.com/api/v2/check --data-urlencode "ipAddress=$IP" \
  -H "Key: $ABUSEIPDB_KEY" -H "Accept: application/json" | jq '.data | {usageType, isp, abuseConfidenceScore}'

Çıkış IP örneklemini prefix'e göre denetlemek

Tek bir IP yerine bir havuzu denetliyorsanız sonuçları duyurulan prefix'e göre gruplayın. Aşağıdaki script bir IP listesi dosyasını okur, ip-api'nin batch endpoint'ini (POST başına en fazla 100 IP, ücretsiz pakette dakikada 15 istek) ve RIPEstat'ı kullanır ve her prefix için bir satır yazdırır:

import json, sys, time, urllib.request
from collections import defaultdict

def get(url, data=None):
    req = urllib.request.Request(url, data=data, headers={
        "User-Agent": "ip-audit/1.0", "Content-Type": "application/json"})
    with urllib.request.urlopen(req, timeout=20) as r:
        return json.load(r)

def ripestat(call, resource):
    return get(f"https://stat.ripe.net/data/{call}/data.json?resource={resource}")["data"]

ips = [l.strip() for l in open(sys.argv[1]) if l.strip()]

geo = {}
fields = "query,countryCode,isp,org,as,proxy,hosting,mobile"
for i in range(0, len(ips), 100):
    chunk = ips[i:i + 100]
    for row in get(f"http://ip-api.com/batch?fields={fields}", json.dumps(chunk).encode()):
        geo[row["query"]] = row
    time.sleep(4)  # dakikada 15 batch isteğinin altında kal

by_prefix = defaultdict(list)
for ip in ips:
    net = ripestat("network-info", ip)
    reg = ripestat("rir-stats-country", ip)["located_resources"]
    reg_cc = reg[0]["location"] if reg else "?"
    by_prefix[(net["prefix"], ",".join(net["asns"]))].append((ip, reg_cc, geo.get(ip, {})))

for (prefix, asns), rows in sorted(by_prefix.items()):
    hosting = sum(1 for _, _, g in rows if g.get("hosting"))
    proxy = sum(1 for _, _, g in rows if g.get("proxy"))
    mismatch = sum(1 for _, cc, g in rows if g.get("countryCode") and cc != g["countryCode"])
    print(f"{prefix:<20} AS{asns:<8} n={len(rows):<3} hosting={hosting} proxy={proxy} "
          f"reg!=geo={mismatch}  isp={rows[0][2].get('isp', '?')}")

python3 audit.py exits.txt şeklinde çalıştırın. Büyük bir örneklemde RIPEstat çağrıları arasına kısa bir bekleme ekleyin. Çıktı genellikle durumu hemen ortaya koyar. İşaretli IP'ler bir iki prefix'te toplanıyorsa sorun prefix'tedir. ASN genelinde eşit dağılmışlarsa sorun ASN'dedir. Pek çok temiz prefix'e dağınık hâldeyse sorun davranıştır: bu IP'ler bilinen proxy çıkış noktalarıdır.

Sağlayıcılar arasındaki anlaşmazlık nasıl okunur?

Sağlayıcılar anlaşamadığında, kimin "haklı" olduğuna karar vermeden önce her birinin hangi katmanı okuduğunu belirleyin. Genellikle biri kaydı, diğeri yönlendirmeyi ya da davranışı okuyordur.

• Birinde "ISP", diğerinde "hosting". Kayıt ile yönlendirme çatışıyor. Duyuran ASN'yi kontrol edin. Bir hosting şirketiyse, sitelerin dikkate alacağı karar hosting kararıdır.
• Residential bağlantı türü artı proxy bayrağı. Gözlemlenmiş proxy etkinliği olan gerçek bir ISP adresi. Yönlendirmeyle ilgili hiçbir şey bunu düzeltmez. Bu bir geçmiş sorunudur.
• Bir sağlayıcının fraud puanı dışında her yerde temiz. Genellikle yakın tarihli kötüye kullanım geçmişi ya da strictness ayarlarından kaynaklanır. IP'yi gözden çıkarmadan önce sağlayıcının abuse alanlarına bakın.
• Farklı ülkeler. RIR ülkesini, geofeed'i ve sağlayıcının coğrafi konumunu karşılaştırın. Sağlayıcılar verilerini farklı hızlarda günceller; yakın zamanda taşınmış bir blok bir süre çelişkili görünebilir.

Önemli olan, ilgilendiğiniz sitenin hangi sağlayıcıyı kullandığıdır ve bunu genellikle bilemezsiniz. Tek bir sağlayıcının "temiz" demesinin yeterli kanıt olmamasının nedeni budur.

Sinyallere hızlı bakış

Sağlayıcılar ağırlıklarını yayımlamaz. "Ağırlık" sütunu, dokümantasyonlarını ve denetimler sırasında kararların nasıl değiştiğini bizim yorumlayışımızdır. Bunu bir şartname değil, bir yol gösterici olarak görün.

Statik, rotasyonlu residential ve mobil: denetim seçiminiz için ne anlama gelir?

Hangi ürünü alacağınız, aynı IP'ye uzun süre ihtiyaç duyup duymadığınıza bağlıdır; bu da denetimin ne kadar önemli olduğunu belirler.

• Statik / ISP IP'leri. Her IP'yi haftalarca kullanırsınız, bu yüzden taahhütte bulunmadan önce denetleyin. Size sunulan IP'lerde prefix script'ini çalıştırın, işaretli /24'leri ve kayıt-konum uyumsuzluklarını reddedin, hangi ASN'nin bunları duyurduğunu sorun. Denetimin en çok işe yaradığı yer burasıdır.
• Rotasyonlu residential. Tekil IP'ler gelip gider, bu yüzden tek bir çıkışı denetlemek size pek bir şey söylemez. 100'den fazla çıkış örnekleyin ve ASN türlerinin ve hosting bayraklarının dağılımına bakın. Çıkışlarının çoğu hosting ASN'lerinden duyurulan bir "residential" havuz residential değildir.
• Mobil. Operatör ASN'leri ve CGNAT, bunların hosting olarak işaretlenmesini en zor hâle getirir; ancak abuse geçmişi aynı adresin arkasındaki tüm gerçek kullanıcılarla paylaşılır. Mobil proxy rehberimiz artı ve eksileri ele alıyor, residential, datacenter ve mobil karşılaştırması da üçünü yan yana koyuyor.

Bu denetimin size söyleyemeyecekleri

Denetim, bir sağlayıcının bir IP'yi neden o şekilde etiketlediğini açıklar. Belirli bir sitenin sizi engelleyip engellemeyeceğini öngörmez. Siteler IP itibarını TLS, HTTP/2 ve tarayıcı parmak izleriyle ve davranışla birleştirir. Veri merkezi görünümlü bir TLS parmak izinin arkasındaki temiz bir residential IP yine de challenge ile karşılaşır. Denetim, sağlayıcının özel verilerini de göremez; yalnızca bu verilerin üzerine kurulduğu herkese açık katmanları görür. Kötü IP'leri elemek ve sağlayıcılara net sorular sormak için kullanın. Temiz bir sonucu garanti olarak görmeyin.