사기 방지

가짜 가입을 막는 방법: IP 유형별 가짜 계정 탐지

IP 유형으로 가짜 가입을 막으세요. 2026년 11월 2일의 실시간 조회 7건, 각각에 적용할 가입 조치, 자체 코드에서 쓸 /24 및 /64 요청 빈도 제한을 소개합니다.

작성자GeoIPHub 팀게시일2026년 11월 2일읽는 시간28분 분량

Okta Threat Intelligence는 무료 체험에 가짜 가입 시도가 쏟아진 AI 영상 서비스 사례를 소개했습니다. 한 고객의 로그에는 이렇게 나와 있습니다. "Between June 1, 2026, and July 1, 2026, logs show over 105,000 brute force attempts to sign up from 251 distinct IPs likely connected to bots."(2026년 6월 1일부터 7월 1일 사이, 봇과 관련된 것으로 보이는 251개의 서로 다른 IP에서 105,000건이 넘는 무차별 가입 시도가 로그에 기록되었습니다.) 해당 등록은 "were tied to proxy providers and VPNs"(프록시 제공업체와 VPN에 연결되어 있었습니다)였습니다. Okta의 수치를 GeoIPHub가 계산하면 한 달 동안 주소당 약 418건, 하루 약 14건이므로, IP당 시간당 몇 건으로 정한 제한은 한 번도 작동하지 않을 수 있습니다.

어려운 점은 가짜 가입과 실제 고객이 같은 네트워크를 쓴다는 것입니다. 실제 사람도 VPN과 클라우드 데스크톱을 쓰고, iCloud Private Relay, 모바일 통신사, 통신사급 NAT처럼 실제 사람들이 공유하는 주소는 본래 붐비는 것처럼 보입니다. 차단만 하는 규칙은 풀 전체를 들여보내거나 고객을 내쫓게 됩니다.

아래에서는 가입이 들어올 수 있는 일곱 가지 주소, 2026년 11월 2일에 GeoIPHub IP 조회 API가 각각에 반환한 결과와 폼에서 우리가 취할 조치, 공유 주소를 점수만으로 거부하면 안 되는 이유, 테스트를 거친 코드와 함께 요청 빈도 제한, 그리고 IP가 볼 수 없는 것을 다룹니다.

주소 유형이 조치를 결정하고, 카운터가 풀을 잡아냅니다.

가입 시 가짜 계정 탐지가 확인하는 것, 그리고 항상 가지고 있는 한 가지 신호

가짜 계정 탐지는 새 가입을 네트워크, 요청 빈도, 이메일, 전화, 기기, 행동 전반에 걸쳐 점수화합니다. 폼이 전송되는 순간 서버가 사용자에게 아무것도 요청하지 않고도 항상 가지고 있는 것은 이 가운데 IP뿐이며, 그래서 IP 위험 점수가 보통 첫 번째 검사가 됩니다.

OWASP는 이 공격을 OAT-019 Account Creation이라고 부르며 이렇게 정의합니다. "Bulk account creation, and sometimes profile population, by using the application’s account sign-up processes."(애플리케이션의 계정 가입 절차를 이용한 대량 계정 생성, 그리고 때로는 프로필 채우기.) 가짜 계정 생성은 그 자체가 목적인 경우가 드물고, 프로모션 및 추천 보상 악용, 차단을 피하려는 한 운영자의 다중 계정, 또는 크리덴셜 스터핑 공격 준비를 위한 사전 작업입니다.

가입 사기는 대비해야 할 만큼 흔합니다. Auth0 플랫폼 데이터를 바탕으로 한 Okta의 Customer Identity Trends Report 2025는 이렇게 말합니다. "In 2024, an average of 46% of all registration attempts across the Auth0 platform were identified as signup attacks."(2024년 Auth0 플랫폼 전체에서 등록 시도의 평균 46%가 가입 공격으로 식별되었습니다.) Stripe는 2026년 4월 29일 Sessions 2026을 발표하며 자사 네트워크의 수치를 이렇게 밝혔습니다. "Across AI services running on Stripe, one in six attempted sign-ups is made by a bad actor."(Stripe에서 운영되는 AI 서비스 전반에서 가입 시도 여섯 건 중 한 건이 악의적 행위자의 것입니다.)

각 계층에 필요한 것과 IP 조회로 답할 수 있는 계층은 다음과 같습니다.

계층	예시	IP 조회로 볼 수 있나요?
네트워크	Tor 출구, VPN 서버, 클라우드 서버, 릴레이, 모바일 통신사	예
요청 빈도	한 시간 또는 하루 동안 주소, 프리픽스, 네트워크별 가입 수	키만 제공하며, 집계는 직접 만든 코드의 몫
이메일	일회용 도메인, 플러스 주소와 점 변형	아니요
전화	VoIP 번호, 재활용된 번호	아니요
기기	여러 계정에서 반복되는 브라우저 및 하드웨어 특성	아니요. 기기 핑거프린팅 참고
행동	폼 입력 속도, 복사 및 붙여넣기, 마우스 움직임	아니요

기기 행은 별개의 도구입니다. 기기 핑거프린팅과 IP 데이터를 비교한 글에서 두 가지를 어떻게 결합하는지 다룹니다.

가입 IP 7건, 결정 7가지: 2026년 11월 2일 GeoIPHub가 반환한 결과

GeoIPHub는 2026년 11월 2일 UTC 04:51에서 04:52 사이에 가입이 들어올 수 있는 주소 7개를 조회했습니다. 아래는 GeoIPHub의 위험 점수 기준 시작값 중 가입 행을 적용했을 때의 점수, 사유, 그리고 폼에서 우리가 취할 조치입니다. 마지막 두 행은 조회가 아니라 점수 구성에 있는 규칙입니다.

주소	정체	점수, 조치	detection_methods	가입 시
185.220.101.1	Tor 출구, zen.spamhaus.org에도 등재	100, block	tor_exit, datacenter_blocklisted, no_ptr_datacenter, known_spammer	거부
185.213.155.73	VPN 서버. vpn_provider가 Mullvad를 가리킴	100, block	known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter	기본 거부. 사용자가 VPN을 쓰고 악용 사유가 없다면 대신 인증
45.83.220.7	Mullvad VPN 네트워크 주소, vpn_provider "Mullvad (31173 Services)"	46, review	known_vpn_server, datacenter_ip	생성하되 제한하고 플래그 지정
45.33.32.156	scanme.nmap.org, Linode 클라우드 서버	10, allow	datacenter_ip	허용. 호스팅 네트워크별로 집계
104.28.46.99	iCloud Private Relay 출구	9, allow	relay_ip	허용. 더 느슨한 요청 빈도 제한
66.249.66.1	검증된 Googlebot (crawler.operator Google)	0, allow	datacenter_ip, verified_crawler	계정 없음: 크롤러는 가입하지 않음
162.142.125.10	Censys 인터넷 스캐너 (is_scanner true)	0, allow	반환된 사유 없음	계정 없음
모든 CGNAT 주소	조회가 아니라 점수 구성에 있는 규칙	50으로 상한 제한	주소 자체의 VPN, 프록시, Tor, 프로토콜, 봇넷 또는 악용 증거가 있을 때만 상한 해제	점수만으로 거부하지 않음
모든 모바일 통신사 주소	조회가 아니라 점수 구성에 있는 규칙	12점 감점	위협 증거가 없을 때의 mobile_carrier	점수만으로 거부하지 않음

두 개의 100점은 똑같아 보이지만 같지 않습니다. Tor 출구에는 스팸 이력이 있고, VPN 서버에는 익명성 사유만 있을 뿐 악용 증거는 전혀 없습니다. 이 차이가 VPN 가입을 거부할지 인증할지를 결정합니다.

API 자체의 recommended_action은 75를 넘을 때만 차단합니다. GeoIPHub의 가입 기준 시작값은 71부터 차단하며, 2026년 11월 2일의 행 중 두 선 사이에 걸친 것은 없었습니다.

가정용 광대역은 가구 주소를 공개하지 않으므로 행이 없습니다. GeoIPHub의 점수 산정은 주거 패턴의 역방향 DNS 이름이 있는 주소에만 가정 회선 할인을 적용하므로, 이름이 없는 가정 회선은 주거용 할인을 받지 못하고 어떤 위협 사유든 그대로 반영됩니다.

숫자가 아니라 사유를 읽으세요: 가입 하나를 끝까지 추적하기

점수는 주소가 얼마나 위험한지를, scoring.detection_methods는 그 이유를 알려 주며, 제한할지, 인증할지, 거부할지는 이유가 결정합니다. 다음은 2026년 11월 2일 UTC 04:51:58에 조회한 45.83.220.7의 응답을 줄인 것입니다.

GeoIPHub API

{
  "ip": "45.83.220.7",
  "asn": {
    "asn": 39351,
    "org": "ESAB-AS - 31173 Services AB",
    "connection_type": "datacenter"
  },
  "detection": {
    "is_vpn": true,
    "is_hosting": true,
    "is_relay": false,
    "is_mobile": false,
    "vpn_provider": "Mullvad (31173 Services)"
  },
  "threat": { "is_cgnat": false },
  "scoring": {
    "fraud_score": 46,
    "recommended_action": "review",
    "detection_methods": ["known_vpn_server", "datacenter_ip"]
  }
}

두 가지 사유가 작동했습니다. known_vpn_server가 36점(신뢰도 0.9에서 40점)을, datacenter_ip가 10점(0.5에서 20점)을 더해 점수는 46입니다. 이는 GeoIPHub 가입 기준 시작값의 26~50 구간, 즉 생성 후 플래그 지정에 해당합니다. 이메일이 확인될 때까지 체험 크레딧이나 보너스 없이 제한된 상태로 계정을 만들 것입니다. detection.is_hosting이 true이므로 이 가입은 아래 요청 빈도 검사에서 AS39351에도 집계됩니다. 체험 시작이나 크레딧 지급 같은 첫 가치 이벤트에서 IP를 다시 조회하세요.

185.213.155.73의 Mullvad 서버는 100점 block을 받았고, 네 가지 사유 모두 악용이 아니라 익명성에 관한 것입니다. 가입 시 기본 조치는 거부입니다. 실제 사용자가 VPN을 쓰는 제품은 점수 숫자가 아니라 사유를 기준으로 규칙을 작성해서 익명성 사유만 있고 악용 사유가 없는 이런 100점을 이메일이나 전화 인증으로 보낼 수 있습니다. VPN 자체는 프라이버시를 위한 선택이고, 그것이 보호하는 사람들이 흔히 잘못 플래그되는 대상입니다. 스팸 이력이 있는 Tor 출구는 어느 쪽이든 계속 거부합니다.

점수 0은 통과가 아닙니다: 가입 폼에 오는 크롤러와 스캐너

2026년 11월 2일 GeoIPHub 조회에서 가장 우호적인 결과 두 가지, 즉 66.249.66.1의 검증된 Googlebot과 162.142.125.10의 Censys 스캐너는 둘 다 0점 allow를 받았지만, 이 둘은 절대 계정을 만들어서는 안 되는 대상입니다. 어떤 100점보다도 이 결과가 더 놀라웠습니다.

GeoIPHub의 verified_crawler 사유는 28.5를 빼므로 검증된 크롤러는 척도의 맨 아래에 놓입니다. 크롤링에는 맞지만 폼 POST에는 틀린 값입니다. 가입 요청에서 threat.crawler.verified가 true이면 계정을 만들지 마세요. 이를 판단할 때는 crawler.name이 아니라 crawler.verified와 crawler.operator를 읽으세요.

threat.is_scanner는 점수에 전혀 반영되지 않습니다. Censys 주소는 사유가 하나도 반환되지 않았습니다. 플래그를 직접 확인하고, true이면 가입을 거부하세요.

공유 주소는 점수만으로 거부하지 마세요: 릴레이, CGNAT, 모바일

iCloud Private Relay 출구, 통신사급 NAT 주소, 모바일 게이트웨이에는 많은 실제 사람이 있을 수 있습니다. GeoIPHub의 점수 산정은 주소 자체에 위협 증거가 없는 한 릴레이 주소를 60으로, CGNAT 주소를 50으로 제한하고 깨끗한 모바일 주소는 감점하며, 위협 증거가 있는 모바일 주소는 오히려 위험 점수가 가산됩니다. 규칙은 이런 주소가 자체 증거를 갖고 있지 않는 한 차단 구간에 들어가지 않도록 해야 합니다.

GeoIPHub의 점수 산정에서 relay_ip는 8.5를 더하고 릴레이 할인은 없으므로, 우리 릴레이 샘플은 9점을 받았습니다. CGNAT 상한은 주소 자체의 VPN, 프록시, Tor, 프로토콜, 봇넷 또는 악용 증거가 있을 때만 해제됩니다. 모바일 통신사 주소는 mobile_carrier를 받으며, 위협 증거가 없으면 점수가 12 낮아집니다.

이 중 어느 것도 "신뢰하라"는 뜻이 아닙니다. IP만으로는 같은 주소 뒤의 한 명의 악의적 행위자와 다수의 고객을 구분할 수 없다는 뜻입니다. 그러니 이런 가입은 점수만으로 거부하지 말고 추가 확인을 요구하되, 평소 요청 빈도 제한의 열 배를 적용하세요. Private Relay에 대해서는 통과시키고 이후 계정이 하는 행동으로 세션을 점수화하라는 것이 우리의 조언입니다.

자체 코드에서 IP, /24, IPv6 /64, 호스팅 네트워크별로 가입 수 세기

GeoIPHub API는 주소 하나를 점수화할 뿐, 그 주소와 /24, /64, 네트워크가 지난 24시간 동안 만든 계정 수는 세지 않습니다. 그 카운터는 직접 만든 코드에 있고, 조회 결과가 어떤 키를 쓸지 알려 줍니다. asn.asn, detection.is_hosting, detection.is_relay, detection.is_mobile, asn.connection_type, threat.is_cgnat입니다.

Okta의 AI 영상 사례에서 가짜 가입 시도는 251개 주소에 걸쳐 주소당 하루 평균 약 14건이었습니다. IP별 카운터만으로는 한 번도 작동하지 않을 수 있습니다. 프리픽스 및 네트워크 카운터는 바로 이런 경우를 위해 존재합니다.

아래는 업계 벤치마크가 아니라 우리가 정한 시작값이므로, 자사 가입 데이터로 조정하세요.

키	기간	시작 제한값	비고
정확한 IPv4 주소	1시간	3
IPv4 /24	1시간	10	하나의 블록 안에서 돌아가는 풀을 잡아냄
IPv6 /64	1시간	3	/64를 IPv4 주소 하나처럼 취급. 하나의 할당 대역에서 새 /64가 계속 들어오면 /56 또는 /48로 확대
ASN, 호스팅만 (detection.is_hosting true)	24시간	20	실제 고객이 클라우드 서버에서 가입하는 경우는 드묾
공유 주소 (릴레이, CGNAT 또는 모바일)	동일한 기간	IP 및 프리픽스 제한의 열 배	요청 빈도만으로 차단하지 않음

제한을 넘으면 거부가 아니라 단계적 인증(이메일 또는 전화 인증, 혹은 CAPTCHA)이나 제한된 생성으로 대응합니다. IPv6에서는 전체 주소가 아니라 프리픽스를 세세요. 그렇지 않으면 한 명의 행위자가 수천 개의 "서로 다른" 가입이 됩니다. 가정은 보통 /56이나 /48을 받으므로 표에서 범위를 넓힌 것이며, 할당 크기는 프리픽스 단위로 IPv6 요청 제한하기 가이드에서 다룹니다.

아래 코드는 Node 18 이상에서 의존성 없이 실행됩니다. 신뢰할 수 있는 프록시 체인에서 클라이언트 주소를 가져온 뒤, ::ffff:192.0.2.1 같은 IPv4 매핑 형식을 포함해 Node가 보고하는 그대로의 주소를 입력으로 받습니다. 고정 윈도를 사용하므로 슬라이딩 윈도를 단순화한 것입니다.

GeoIPHub API

// Signup velocity keys: exact IP, IPv4 /24, IPv6 /64, and ASN for hosting.
// Starting limits, not benchmarks. Tune them on your own signups.
import { isIPv4, isIPv6 } from "node:net";

const HOUR = 3600e3, DAY = 24 * HOUR;
const LIMITS = {
  ip:    { window: HOUR, max: 3 },  // one IPv4 address, or one IPv6 /64
  v4_24: { window: HOUR, max: 10 },
  asn:   { window: DAY,  max: 20 }, // hosting networks only
};
const SHARED_FACTOR = 10;           // relay, CGNAT and mobile egress

function expandIPv6(addr) {
  const [head, tail = ""] = addr.toLowerCase().split("::");
  const h = head ? head.split(":") : [];
  const t = tail ? tail.split(":") : [];
  const fill = addr.includes("::") ? 8 - h.length - t.length : 0;
  return [...h, ...Array(fill).fill("0"), ...t].map((g) => g.padStart(4, "0"));
}

export function velocityKeys(ip, lookup) {
  const keys = [];
  const m = ip.match(/^(?:::|(?:0{1,4}:){5})ffff:(\d+\.\d+\.\d+\.\d+)$/i);
  const v4 = m && isIPv4(m[1]) ? m[1] : ip;
  if (isIPv4(v4)) {
    keys.push(["ip", v4], ["v4_24", v4.split(".").slice(0, 3).join(".") + ".0/24"]);
  } else if (isIPv6(ip)) {
    keys.push(["ip", expandIPv6(ip).slice(0, 4).join(":") + "::/64"]);
  }
  const asn = lookup?.asn;
  if (lookup?.detection?.is_hosting && asn?.asn) keys.push(["asn", `AS${asn.asn}`]);
  return keys;
}

const counters = new Map(); // in-memory and unbounded; for a demo only; use Redis INCR + EXPIRE in production

export function checkVelocity(ip, lookup, now = Date.now()) {
  const shared = Boolean(
    lookup?.detection?.is_relay || lookup?.threat?.is_cgnat ||
    lookup?.detection?.is_mobile || lookup?.asn?.connection_type === "mobile");
  const hits = [];
  for (const [level, value] of velocityKeys(ip, lookup)) {
    const { window, max } = LIMITS[level];
    const limit = shared && level !== "asn" ? max * SHARED_FACTOR : max;
    const key = `${level}:${value}:${Math.floor(now / window)}`;
    const count = (counters.get(key) ?? 0) + 1;
    counters.set(key, count);
    if (count > limit) hits.push({ level, value, count, limit });
  }
  return { overLimit: hits.length > 0, hits }; // over the limit: step up, don't block
}

2026년 11월 2일 Node 24.20.0에서 이 코드 그대로 단위 테스트 16건을 실행했으며, 문서용 및 사설 주소 대역과 표에 나온 scanme.nmap.org 주소를 사용했고 조회는 하지 않았습니다. 16건 모두 통과했습니다. ::ffff:45.33.32.156 같은 IPv4 매핑 형식은 IPv4로 키가 만들어졌고, 하나의 /64 안에서 돌려 쓰면 4번째 가입에서 제한에 걸렸으며, 하나의 /24에 걸친 11개 주소는 /24 키에서만 제한에 걸렸고, 하나의 릴레이 출구에서 온 30건의 가입은 통과하고 31번째가 플래그되었습니다. 조회가 실패해도(null) IP 및 프리픽스 키는 만들어지므로, API가 응답하지 않아도 카운터는 계속 동작합니다.

IP 계층이 보지 못하는 곳

IP 조회는 임대한 가정용 회선이나 실제 휴대폰에서 가입하는 가짜 계정을 볼 수 없고, 이메일, 기기, 폼을 채운 방식은 전혀 보지 못합니다.

주거용 프록시가 가장 뚜렷한 사각지대입니다. GeoIPHub는 우리가 관측한 주거용 및 모바일 회선의 프록시를 플래그하며 제3자 목록이 릴레이로 보고하는 주소도 포함하지만, 자체 주거용 프록시 탐지는 없으므로 깨끗한 가정 회선은 통과할 수 있습니다. 실제 SIM 카드로 운영되는 클릭 팜과 기기 팜은 모바일 고객처럼 보이며, 우리 점수 산정은 모바일 고객을 일부러 너그럽게 다룹니다.

GeoIPHub는 IP를 점수화하며 이메일 주소나 전화번호는 검사하지 않습니다. IP 검사에 자체 이메일 검사(일회용 도메인, 플러스 주소와 점 정규화), 전화 인증, 기기 신호, 그리고 가입 후 키를 공유하는 계정 클러스터링을 함께 사용하세요.

제한된 상태 덕분에 중간 구간을 저렴하게 운영할 수 있습니다. 계정은 만들되 크레딧은 보류하고, 인증이나 첫 실제 행동 이후에 풀어 주세요. 인증하지 않는 가짜 계정이 치르게 하는 비용은 체험이 아니라 데이터베이스 행 하나입니다.

계정이 생기기 전에 가짜 가입을 막는 방법

전체 검사는 "제출"과 "생성" 사이에 이 순서로 이루어지는 조회 한 번과 요청 빈도 집계 한 번입니다.

클라이언트가 임의의 값으로 설정할 수 있는 원시 X-Forwarded-For 헤더가 아니라 신뢰할 수 있는 프록시 체인에서 클라이언트 IP를 가져옵니다.
IP를 조회합니다.
Tor 출구, 검증된 크롤러, 스캐너는 거부합니다. 100점인 VPN 서버는 기본적으로 거부하되, 사용자가 VPN을 쓰고 악용 사유가 없으면 인증으로 보냅니다. 릴레이, CGNAT, 모바일 주소는 점수만으로 거부하지 않습니다. 나머지에는 GeoIPHub의 가입 기준 시작값을 적용합니다.
요청 빈도 검사를 실행하고, 제한에 걸리면 단계적 인증을 요구합니다.
조회가 실패하면 요청 빈도 검사와 이메일 확인으로 대체하고, 거부하지는 않습니다.
점수, 사유, 조회 시각을 계정과 함께 저장하고, 첫 가치 이벤트(체험 시작, 크레딧 지급, 첫 정산)에서 IP를 다시 조회합니다.

테스트를 거친 Node 및 Python 통합 예제에는 2단계와 3단계가 동작하는 코드로 나와 있습니다. GeoIPHub 무료 플랜은 모든 필드를 포함해 하루 1,500회 조회를 제공합니다.

가입 로그의 최근 IP 10개를 IP 위험 점수 검사기에 붙여 넣고 표의 행에 맞춰 분류해 보세요. 점수는 각 주소가 무엇인지 알려 주고, 카운터는 그 주소가 계정을 몇 개 만들었는지 알려 줍니다.

자주 묻는 질문

실제 사용자를 차단하지 않고 가짜 가입을 막으려면 어떻게 하나요?

계정을 만들기 전에 GeoIPHub API로 각 가입의 IP를 조회하세요. Tor 출구와 가장 높은 점수는 거부하고, 중간 구간은 이메일이나 전화로 인증하며, iCloud Private Relay, 통신사급 NAT(CGNAT), 모바일 게이트웨이처럼 공유되는 주소는 더 느슨한 요청 빈도 제한으로 통과시키세요. 이런 주소 하나에 실제 고객이 많이 있을 수 있기 때문입니다.

가입 사기는 얼마나 흔한가요?

Okta의 Auth0 플랫폼에서는 2024년 가입 시도의 평균 46%가 가입 공격으로 식별되었습니다. Stripe는 2026년 4월에 자사 네트워크의 AI 서비스 전반에서 가입 시도 여섯 건 중 한 건이 악의적 행위자의 것이라고 밝혔습니다. 두 수치 모두 각 업체가 자체 플랫폼에서 집계한 것입니다.

IP 주소만으로 가짜 계정을 탐지할 수 있나요?

아니요. IP 조회는 가입이 어떤 종류의 네트워크에서 들어왔는지와 그런 점수가 나온 이유를 보여 줄 뿐, 이메일, 전화번호, 기기, 또는 임대한 가정용 회선에서 가입하는 가짜 계정은 볼 수 없습니다. 첫 번째 계층으로 사용하고 이메일, 전화, 기기 검사와 함께 쓰세요.

GeoIPHub는 이메일 주소도 검사하나요?

아니요. GeoIPHub API는 IP 주소만 점수화합니다. 이메일과 전화번호는 자체 도구로 검사하고, 그 결과를 GeoIPHub의 점수 및 사유와 결합하세요.

VPN 사용자의 가입을 허용해야 하나요?

대체로 그렇습니다. VPN 자체는 프라이버시를 위한 선택이므로 VPN 가입을 거부하는 대신 이메일이나 전화 인증으로 보내고, 완전한 차단은 Tor 출구와 스팸 또는 악용 이력이 있는 주소에만 적용하세요.

IPv6에서는 가입 요청 빈도를 어떻게 제한해야 하나요?

한 가입자가 /64 전체를 돌려 쓸 수 있으므로 주소가 아니라 /64 단위로 세세요. 같은 할당 대역에서 새로운 /64가 계속 들어오면 /56이나 /48로 넓히고, 모바일 통신사에는 제한을 더 느슨하게 두세요.

작성자

GeoIPHub 팀

GeoIPHub API를 만드는 팀

GeoIPHub IP 인텔리전스 API와 스캐너를 만드는 GeoIPHub 팀이 작성했습니다. 초안은 AI의 도움을 받아 준비하고 팀이 편집합니다. API 예시는 예시용으로 표시된 경우를 제외하고 라이브 API에 대한 실제 조회 결과입니다.

LinkedIn에서 팔로우하세요

이 글 공유하기

더 많은 글