주거용 IP가 프록시·호스팅으로 잡히는 이유와 점검법

IP 인텔리전스 업체는 주소 뒤에 있는 기기를 직접 보지 못합니다. 레지스트리 기록, 라우팅 데이터, DNS 이름, 그리고 그동안 관찰한 행동을 근거로 주소에 라벨을 붙입니다. 이 중 한 계층이라도 데이터센터를 가리키면 "주거용" IP가 프록시나 호스팅으로 판정됩니다. 그 IP를 공지하는 네트워크일 수도 있고, IP가 속한 특정 /24일 수도 있고, WHOIS 조직명이나 역방향 DNS, 등록 국가와 지리 위치의 불일치, 혹은 프록시 트래픽을 중계한 이력일 수도 있습니다. 이 계층들은 무료 도구로 IP 하나당 10분 정도면 직접 확인할 수 있습니다. 이 가이드에서 그 방법을 설명합니다.

IP 평판과 사기 점수에 관한 해설에서는 IPQualityScore 같은 점수가 어떻게 만들어지고 사이트에서 어떻게 쓰이는지 다뤘습니다. 이 글은 그 실전편입니다. 어떤 분류 신호가 판정을 만드는지, 대표적인 네 업체가 그 신호를 어떻게 노출하는지, 그리고 IP 하나 또는 출구 IP 샘플에 반복 적용할 수 있는 점검 절차를 다룹니다.

주거용 IP가 프록시나 호스팅으로 판정되는 이유

주거용이라고 알려진 IP에 붙는 "호스팅"이나 "프록시" 판정은 대부분 다섯 가지 신호에서 나옵니다. 네트워크 소유와 라우팅이 가장 먼저이고, 그다음이 이름, 위치 일관성, 관찰된 행동 순입니다. 업체마다 이 신호를 조합하는 방식이 달라서 판정이 엇갈립니다.

1. ASN 유형: 누가 주소를 공지하는가

라우팅되는 모든 IP는 BGP에서 자율 시스템(ASN)이 공지합니다. 업체는 ASN 뒤에 있는 조직의 유형으로 ASN을 분류합니다. IPinfo의 ASN type은 isp, hosting, business, education, government 중 하나입니다. 네트워크가 스스로를 소개하는 PeeringDB에는 info_types 필드가 있습니다. 이 API는 Comcast(AS7922)에 대해 ["Cable/DSL/ISP"]를, Cloudflare(AS13335)에 대해 ["Content"]를 반환합니다.

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

공지 ASN이 호스팅 회사라면 주소의 등록 명의와 상관없이 거의 모든 업체가 그 IP를 호스팅으로 판정합니다. 가중치가 가장 높고 반박하기도 가장 어려운 신호입니다.

2. ASN만이 아니라 공지된 프리픽스

저희가 고정 "주거용" IP나 ISP IP를 점검해 보면 의미 있는 단위는 ASN보다 공지된 프리픽스, 보통 /24인 경우가 많았습니다. 전체적으로 깨끗한 ISP 네트워크 안에서도 /24 하나만 호스팅으로 읽히고 나머지 ASN은 주거용으로 읽힐 수 있습니다. 업체가 프리픽스 단위로 데이터를 수정하기 때문일 가능성이 큽니다. 임대되었거나, 경로가 바뀌었거나, 호스팅 서버가 관찰된 블록은 따로 재분류되고 나머지 ASN은 기존 라벨을 유지합니다. 또한 /24는 글로벌 라우팅 테이블에서 일반적으로 허용되는 가장 작은 IPv4 블록이라 임대와 재공지의 자연스러운 단위가 됩니다. 그러니 IP 하나가 플래그되었다면 공급자나 ISP 전체를 탓하기 전에 같은 /24의 이웃 IP부터 확인하세요.

3. WHOIS 조직명과 역방향 DNS

레지스트리 기록과 PTR 이름은 얻기 쉬운 신호라 업체가 판정이 애매할 때 결정 요인으로 씁니다. netname이나 org에 "hosting", "cloud", "server", "VPS" 같은 단어가 들어 있거나 vps-123.example-host.net 같은 PTR이 있으면 호스팅 쪽으로 기웁니다. 주거용 대역은 보통 접속 기술을 담거나 "dynamic", "pool"이라고 적힌 ISP 스타일 PTR을 씁니다. PTR이 없다는 사실은 어느 쪽도 증명하지 않습니다. 역방향 DNS를 설정하지 않는 ISP도 많고, 설정하는 호스팅 업체도 많습니다.

4. 레지스트리 국가와 지리 위치 국가

IP의 등록 국가(지역 인터넷 레지스트리, 즉 RIR 기준)와 지리 위치 업체가 판단한 국가가 다른 경우는 저희가 본 고정 IP의 "호스팅"이나 "프록시" 판정 원인 중 가장 흔한 축에 속합니다. 실제 가정용 회선은 거의 국경을 넘지 않습니다. 독일 ISP의 고객은 독일에 있습니다. 반면 임대되거나 재공지된 블록은 자주 이동합니다. 등록은 원래 보유자에게 남아 있는데 주소는 다른 곳에서 쓰이는 식입니다. 운영자는 자체 게시하는 geofeed(RFC 8805)로 프리픽스가 실제로 쓰이는 위치를 선언할 수 있고, 이는 RFC 9632에 따라 WHOIS에서 찾을 수 있습니다. 이렇게 하면 지리 위치는 바뀌지만, 레지스트리 불일치는 들여다보는 누구에게나 그대로 보입니다.

실제 사례 하나를 풀어 보겠습니다. 1.1.1.1입니다. Team Cymru의 IP-ASN whois 서비스(2026-10-03 조회)는 한 줄에 서로 다른 세 가지 사실을 보여 줍니다.

$ 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

이 블록은 APNIC을 통해 호주에 등록되어 있습니다(APNIC Labs 소유). 미국에 등록된 Cloudflare의 ASN이 /24로 공지하고, ip-api는 이를 AU로 지리 위치하면서 hosting: true를 붙입니다. APNIC과 Cloudflare가 공동 운영하는 리졸버라면 모두 예상 가능한 결과입니다. 하지만 "미국 주거용"으로 판매된 IP에서 이런 세 갈래 불일치가 나온다면 호스팅 판정은 충분히 설명됩니다.

5. 관찰된 행동

마지막 계층은 업체가 그 IP의 행동을 어떻게 관찰했는지입니다. 허니팟 접근, 악용 피드 등재, VPN이나 프록시 소프트웨어 실행, 알려진 주거용 프록시 네트워크의 출구로 등장한 기록 등이 여기에 해당합니다. 진짜 ISP의 진짜 가정용 IP를 플래그할 수 있는 건 이 계층뿐입니다. IPinfo의 주거용 프록시 API는 IP가 관찰된 service를 7일 창 기준의 last_seen, percent_days_seen과 함께 반환합니다. MaxMind는 is_residential_proxy를 "의심되는 익명화 네트워크에 있으면서 주거용 ISP에 속한" IP로 정의하고, P2P 프록시 IP는 명시적으로 제외합니다. 업체마다 선을 긋는 위치는 다르지만 요점은 같습니다. 실제로 프록시로 쓰이는 IP라면 ASN이 깨끗해도 보호받지 못합니다.

네 업체가 판정을 노출하는 방식

업체마다 답하는 질문이 조금씩 다릅니다. "서로 다른" 두 결과가 사실 둘 다 맞는 경우도 많습니다. 아래 필드명은 각 업체의 현재 문서 기준입니다.

AbuseIPDB에서도 자주 보게 되는 라벨이 하나 더 있습니다. "Data Center/Web Hosting/Transit" 같은 값을 갖는 usageType입니다(문서).

ISP 프록시가 회색 지대인 이유

"ISP" 또는 "고정 주거용" 프록시는 ISP 명의로 등록되었지만 데이터센터의 서버로 라우팅되는 주소입니다. 레지스트리 계층은 주거용이라고 말하는데 라우팅과 행동 계층은 그렇지 않을 수 있어서 회색 지대입니다. 특정 IP가 통과하느냐는 업체가 해당 프리픽스에서 어떤 계층을 가장 신뢰하느냐에 달려 있습니다.

좋은 경우는 ISP가 자기 블록을 자기 ASN에서 공지하고 서버도 자기 네트워크에 두는 형태입니다. 이때는 ASN 유형, WHOIS, 지리 위치가 모두 일치합니다. 약한 경우는 ISP 명의 블록을 호스팅 회사의 ASN이 공지하는 형태로, 흔히 임대 이후에 생깁니다. 레지스트리는 여전히 "ISP"라고 하지만 가장 무거운 신호인 공지 ASN은 호스팅이고, 레지스트리 국가가 지리 위치와 다를 수도 있습니다. 업체는 이런 블록을 프리픽스 단위로 따라잡기 때문에 같은 공급자의 /24 하나는 깨끗하고 다음 하나는 플래그되는 일이 생깁니다. 제품 측면은 ISP 프록시 해설에서 다룹니다. 아래 점검 절차로 내가 받은 것이 어느 쪽인지 구분할 수 있습니다.

IP를 직접 점검하는 단계별 방법

모든 IP에 같은 다섯 단계를 적용합니다. 출구 IP 확인, 등록 정보 조회, 라우팅 조회, DNS 확인, 그리고 두세 업체에 조회하기입니다. 비교는 /24 단위로 합니다. 아래 내용은 모두 무료 엔드포인트로 가능합니다.

1단계: 실제 출구 IP 확인

대시보드를 믿지 말고 대상 사이트가 실제로 보는 주소를 확인하세요. 프록시라면 다음과 같습니다.

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

스크립트를 쓰기 번거롭다면 프록시 체커로 브라우저에서 같은 확인을 할 수 있습니다.

2단계: 등록 정보(RDAP, Team Cymru)

IP=1.1.1.1
# RDAP via the rdap.org redirector: registered range, holder, registry country
curl -sL "https://rdap.org/ip/$IP" | jq '{name, handle, country, type, startAddress, endAddress}'
# One-line summary: ASN, BGP prefix, registry CC, registry, AS name
whois -h whois.cymru.com " -v $IP"

country와 보유자 name을 기록해 두세요. 1.1.1.1의 경우 RDAP는 "name": "APNIC-LABS", "country": "AU"를 반환합니다.

3단계: 라우팅(RIPEstat, bgp.he.net)

RIPEstat Data API는 무료이고 키가 필요 없으며, RIPE뿐 아니라 모든 RIR의 주소 공간을 다룹니다.

# Announcing ASN and the exact announced prefix
curl -s "https://stat.ripe.net/data/network-info/data.json?resource=$IP" | jq '.data'
# Who holds that ASN, and is the prefix announced at all
curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=$IP" | jq '.data | {resource, announced, asns}'
# Country from RIR delegation stats
curl -s "https://stat.ripe.net/data/rir-stats-country/data.json?resource=$IP" | jq '.data.located_resources'
# Every prefix the ASN announces, to see whether this /24 is an outlier
curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS13335" | jq '.data.prefixes | length'

시각적으로 보고 싶다면 bgp.he.net에서 같은 ASN과 프리픽스를 업스트림, 피어와 함께 확인할 수 있습니다. 트랜짓 사업자가 한두 곳뿐인 작은 ASN인데 그 사업자가 호스팅 회사라면 많은 것을 알 수 있습니다.

4단계: 역방향 DNS

dig +short -x $IP

5단계: 두세 업체 결과를 나란히 기록

# ip-api: free, no key, HTTP only
curl -s "http://ip-api.com/json/$IP?fields=status,countryCode,isp,org,as,reverse,mobile,proxy,hosting"
# IPinfo Lite: free with a token, country + ASN
curl -s "https://api.ipinfo.io/lite/$IP?token=$IPINFO_TOKEN"
# AbuseIPDB: free key, 1,000 checks/day
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}'

출구 IP 샘플을 프리픽스별로 점검하기

IP 하나가 아니라 풀 전체라면 결과를 공지 프리픽스별로 묶으세요. 아래 스크립트는 IP 목록 파일을 읽어 ip-api의 배치 엔드포인트(POST당 최대 100개 IP, 무료 등급에서 분당 15회)와 RIPEstat을 사용하고, 프리픽스마다 한 줄씩 출력합니다.

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)  # stay under 15 batch requests/minute

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로 실행합니다. 샘플이 크다면 RIPEstat 호출 사이에 짧은 sleep을 넣으세요. 출력만 봐도 대개 상황이 바로 드러납니다. 플래그된 IP가 한두 프리픽스에 몰려 있다면 프리픽스 문제입니다. ASN 전체에 고르게 퍼져 있다면 ASN이 문제입니다. 깨끗한 여러 프리픽스에 흩어져 있다면 행동 문제, 즉 그 IP들이 알려진 프록시 출구라는 뜻입니다.

업체 간 판정이 엇갈릴 때 읽는 법

업체 판정이 다르면 누가 "맞는지" 따지기 전에 각 업체가 어느 계층을 보고 있는지부터 파악하세요. 대개 한쪽은 등록 정보를, 다른 쪽은 라우팅이나 행동을 보고 있습니다.

• 한쪽은 "ISP", 다른 쪽은 "호스팅". 레지스트리 대 라우팅입니다. 공지 ASN을 확인하세요. 호스팅 회사라면 사이트가 실제로 반영하는 건 호스팅 판정입니다.
• 주거용 연결 유형에 프록시 플래그. 실제 ISP 주소인데 프록시 활동이 관찰된 경우입니다. 라우팅을 어떻게 해도 고쳐지지 않습니다. 이력의 문제입니다.
• 한 업체의 사기 점수만 빼고 모두 깨끗함. 대개 최근 악용 이력이나 strictness 설정 때문입니다. IP를 포기하기 전에 해당 업체의 악용 관련 필드를 확인하세요.
• 국가가 서로 다름. RIR 국가, geofeed, 업체 지리 위치를 비교하세요. 업체마다 갱신 속도가 달라서 최근 이동한 블록은 한동안 결과가 엇갈릴 수 있습니다.

중요한 건 내가 신경 쓰는 사이트가 어느 업체를 쓰느냐인데, 이는 보통 알 수 없습니다. 그래서 한 업체의 "깨끗함"만으로는 증거가 부족합니다.

신호 한눈에 보기

업체는 가중치를 공개하지 않습니다. "가중치" 열은 업체 문서와 점검 과정에서 판정이 움직이는 모습을 바탕으로 한 저희의 해석입니다. 명세가 아니라 참고용으로 보세요.

고정·로테이팅 주거용·모바일: 점검 결과가 선택에 주는 의미

어떤 제품을 살지는 같은 IP를 오래 써야 하느냐에 달려 있고, 이것이 점검의 중요도를 결정합니다.

• 고정 / ISP IP. IP 하나를 몇 주씩 쓰므로 계약 전에 점검하세요. 제안받은 IP에 프리픽스 스크립트를 돌리고, 플래그된 /24와 레지스트리-지리 위치 불일치를 걸러 내고, 어느 ASN이 공지하는지 물어보세요. 점검이 가장 큰 효과를 내는 경우입니다.
• 로테이팅 주거용. 개별 IP가 수시로 바뀌므로 출구 하나를 점검해서는 알 수 있는 게 적습니다. 100개 이상의 출구를 샘플링해 ASN 유형과 호스팅 플래그의 분포를 보세요. 출구 상당수가 호스팅 ASN에서 공지되는 "주거용" 풀은 주거용이 아닙니다.
• 모바일. 통신사 ASN과 CGNAT 덕분에 호스팅으로 판정되기가 가장 어렵지만, 악용 이력은 같은 주소 뒤의 모든 실사용자와 공유됩니다. 장단점은 모바일 프록시 가이드에서 다루고, 주거용 vs 데이터센터 vs 모바일에서 세 가지를 비교합니다.

이 점검으로 알 수 없는 것

이 점검은 업체가 IP에 왜 그런 라벨을 붙이는지 설명해 줄 뿐, 특정 사이트가 나를 차단할지는 예측하지 못합니다. 사이트는 IP 평판에 TLS, HTTP/2, 브라우저 지문과 행동을 함께 봅니다. 깨끗한 주거용 IP라도 데이터센터처럼 보이는 TLS 지문 뒤에 있으면 여전히 챌린지를 받습니다. 또한 이 점검은 업체의 비공개 데이터는 볼 수 없고, 그 데이터의 토대가 되는 공개 계층만 볼 수 있습니다. 나쁜 IP를 걸러 내고 공급자에게 정확한 질문을 하는 데 활용하세요. 깨끗한 결과를 보증으로 여기지는 마세요.