사기 방지Google Ads IP 제외 한도: 500개 상한, CIDR, 그리고 차단할 수 없는 것
Google Ads IP 제외 한도는 캠페인당 500개, 계정당 500개입니다. CIDR로 슬롯 하나가 얼마나 넓어지는지, 어떤 IP가 슬롯을 쓸 가치가 있는지 실제 조회 6건으로 확인합니다.
클릭 로그가 있습니다. 몇몇 주소가 계속 돌아오는데 제외 칸에는 500개밖에 들어가지 않으니, 가득 차면 어떻게 되는지 궁금합니다. 한도를 검색하면 답해 주는 페이지는 거의 전부 클릭 사기 방지 벤더이고, 답은 거의 같은 말로 끝납니다. 저희 도구가 목록을 대신 돌려 드린다는 것입니다.
저희는 그 질문이 잘못되었다고 생각합니다. Google의 API 문서는 한도를 "IP 블록" 단위로 세므로 항목 하나가 범위 전체를 덮을 수 있고, 유용한 질문은 어떤 범위가 슬롯을 쓸 가치가 있는가로 바뀝니다. 저희의 입장은 단순합니다. 제외 목록은 사기가 아니라 사내 사무실이나 계속 나타나는 호스팅 블록처럼 안정적인 골칫거리를 위한 것입니다. Google은 이미 자체적으로 무효 클릭을 필터링한다고 밝히며, 그 페이지는 글 끝 부분에서 인용합니다.
아래에서는 두 한도를 Google의 표현 그대로 제시하고, 인터페이스에서 범위를 입력하는 방법과 API로 CIDR을 입력하는 방법을 보여 주며, 실제 주소 6개를 저희 API로 조회해 어느 주소가 슬롯을 쓸 가치가 있는지 판단하고, 어떤 제외로도 막을 수 없는 것을 정리합니다. 차단하지 않고 클릭마다 점수를 매기는 더 넓은 논거는 클릭 사기 가이드에서 시작하십시오.
Google Ads IP 제외 한도: 몇 개의 주소를 제외할 수 있나요?
캠페인당 IP 항목 500개, 계정당 500개를 제외할 수 있습니다. 두 숫자는 Google의 서로 다른 페이지에 있으며, 그래서 많은 글이 두 번째 숫자를 틀리게 적습니다.
이 글에 인용한 Google 페이지는 모두 2026년 10월 14일 06:12 UTC에 열어 확인했습니다. 캠페인 상한은 Google 도움말 페이지 Exclude IP addresses에 있습니다.
"캠페인당 최대 500개의 IP 주소를 제외할 수 있습니다."
도움말 페이지에는 계정 수준의 숫자가 없습니다. 계정 상한은 계정 수준 제외를 담는 리소스인 CustomerNegativeCriterion의 Google Ads API 레퍼런스에 있습니다. ip_block 필드에는 "Immutable. IpBlock. 계정당 최대 500개의 IP 주소를 제외할 수 있습니다."라고 적혀 있습니다. 일부 상위 노출 페이지는 이를 놓칩니다. 같은 시각에 열어 본 Lunio의 500개 한도에 관한 글은 "500개 IP 제외 한도는 계정이 아니라 캠페인에 적용됩니다."라고 말합니다. Google의 레퍼런스는 계정 목록에 자체 상한 500개가 있다고 말합니다.
숫자보다 단위가 더 중요합니다. Google의 API 시스템 한도 표에는 "캠페인당 제외된 IP 블록"이라는 행이 값 "500", 오류 ResourceCountLimitExceededError.CAMPAIGN_LIMIT로 올라 있습니다. 주소 하나 또는 CIDR 블록 하나당 조건(criterion)이 하나 생성되므로, Google의 API 문서상 /24를 한 번 입력하면 항목 하나입니다. 실제 계정에서 시험해 보지는 않았습니다. 그래서 500개 주소가 아니라 500개 슬롯이라고 부릅니다.
두 수준에 모두 항목이 있으면 Google 도움말 페이지에 따라 목록이 병합됩니다.
"동일한 CID 아래 계정 수준과 캠페인 수준 모두에 IP 제외를 설정한 경우: Google Ads는 제외 목록을 병합합니다. 즉, 어느 수준에서든 제외된 모든 IP 주소는 해당 캠페인에 대해 광고를 볼 수 없게 차단됩니다."
Google의 예시는 이렇습니다. "캠페인 수준(캠페인 A)에서 IP 주소 1, 2, 3을 제외한다고 가정해 보세요. 그런 다음 계정 수준에서 IP 주소 4, 5를 제외합니다. 설정한 캠페인(캠페인 A)에 대해 Google Ads는 IP 주소 1, 2, 3, 4, 5를 사실상 차단합니다." 두 상한이 서로 어떻게 작용하는지에 대해 Google은 더 말하지 않으며, 저희도 마찬가지입니다.
| 수준 | 상한 | Google이 밝힌 곳 | 적용 범위 |
|---|---|---|---|
| 캠페인 | 500 | 도움말 페이지 2456098, API CampaignCriterion.ip_block | 하나의 캠페인이며, 모든 캠페인 유형은 아님 |
| 계정 | 500 | API CustomerNegativeCriterion.ip_block에서만 | 실적 최대화를 포함한 계정의 모든 캠페인 |
| 둘 다 설정 | 캠페인별로 목록 병합 | 도움말 페이지 2456098 | 각 캠페인이 자체 항목과 계정 항목을 함께 차단 |
계정 수준과 캠페인 수준: IP 제외를 추가할 위치
모든 곳에 적용해야 하는 제외는 계정 수준에 추가하고, 한 캠페인에만 고유한 문제가 있을 때에 한해 캠페인 수준에 추가하십시오. Google이 드는 좋은 제외의 예가 자사 직원입니다. "회사 네트워크 IP 주소를 제외하기로 결정합니다." 이 주소는 계정 수준에 속합니다.
다음은 같은 도움말 페이지의 계정 수준 절차입니다.
- Google Ads 계정에서 관리자 아이콘을 클릭합니다.
- 계정 설정을 클릭합니다.
- "IP 제외" 섹션으로 이동합니다.
- 광고를 보지 않도록 제외할 IP 주소를 입력합니다.
- 저장을 클릭합니다.
하나의 캠페인에 대해서는 다음과 같습니다.
- Google Ads 계정에서 캠페인 아이콘을 클릭합니다.
- 섹션 메뉴에서 캠페인 드롭다운을 클릭합니다.
- 캠페인, 이어서 설정을 클릭합니다.
- IP 주소를 제외할 캠페인을 선택합니다.
- "설정" 페이지에서 추가 설정을 클릭합니다.
- "IP 제외" 섹션을 펼치고 주소를 입력한 뒤 저장을 클릭합니다.
항목 삭제는 어느 수준에서나 같은 경로를 씁니다. Google의 안내는 위 단계를 따라 "적용하고 싶지 않은 IP 주소 제외를 모두 삭제"한 다음 저장을 클릭하는 것입니다. 함정이 하나 있습니다. "개별 캠페인 안에서는 계정 수준 제외를 수정하거나 삭제할 수 없습니다." 항목이 캠페인에서 지워지지 않는 것 같다면 계정 설정을 확인하십시오.
좋은 계정 수준 항목은 자사 사무실, 대행사 사무실, 그리고 계속 클릭하는 것이 확인된 호스팅 블록입니다. 경쟁사의 고정 사무실 대역도 캠페인 수준에서 쓸 만한 슬롯입니다. 실제 목적이 지역이라면 Google은 다른 방법을 안내합니다. "특정 지역에 광고가 노출되지 않게 하려면 IP 주소를 제외하는 대신 지역에서 광고를 제외해 보세요."
어떤 캠페인 유형에서 캠페인 수준 IP 제외를 쓸 수 없나요?
동영상, 호텔, 앱, 실적 최대화, 스마트 디스플레이 캠페인은 캠페인 수준 IP 제외를 사용할 수 없습니다. Google 도움말 페이지는 이를 한 줄 참고로 밝힙니다.
"참고: 동영상 캠페인, 호텔 캠페인, 앱 캠페인, 실적 최대화 캠페인, 스마트 디스플레이 캠페인에서는 IP 제외를 사용할 수 없습니다."
계정 수준은 더 넓게 적용됩니다. Google은 이를 "실적 최대화, 디맨드젠, 검색, 쇼핑, 디스플레이, 디스커버, YouTube를 포함한 계정의 모든 캠페인에서 특정 IP 주소에 광고가 노출되지 않도록 제외"하는 데 쓸 수 있다고 말합니다. 따라서 실적 최대화는 계정 수준에서만 IP 제외를 받으며, 그 목록은 다른 모든 캠페인이 공유하는 같은 500개 항목입니다.
| 캠페인 유형 | 캠페인 수준 제외 | 계정 수준 제외 |
|---|---|---|
| 검색, 쇼핑, 디스플레이 | 사용 가능 | Google이 명시 |
| 실적 최대화 | 사용 불가 | Google이 명시 |
| 동영상 | 사용 불가 | Google이 YouTube를 명시 |
| 호텔, 앱, 스마트 디스플레이 | 사용 불가 | 페이지에 명시되지 않음 |
| 디맨드젠 | Google의 미지원 목록에 없음 | Google이 명시 |
벤더 페이지들은 이 목록에 대해 의견이 엇갈리는데, 일부는 Google 자체 페이지가 서로 다르기 때문입니다. 더 오래된 Search Ads 360 도움말 페이지는 동영상, 앱, 스마트 디스플레이, 디스커버리 캠페인을 명시합니다. 저희는 현재 Google Ads 페이지의 다섯 가지만 사용합니다.
IP 범위를 제외하는 방법: 별표, CIDR, IPv6
인터페이스에서 문서화된 범위 형식은 마지막 옥텟의 별표입니다. API에서는 IPv4 또는 IPv6 CIDR 블록 하나가 항목 하나입니다.
Google 도움말 페이지는 "특정 IP 주소를 입력하거나, 주소 블록을 제외하려면 마지막 3자리를 별표(*)로 바꿀 수 있습니다."라고 말합니다. 마지막 세 자리는 마지막 옥텟을 뜻합니다. 198.51.100.*는 /24와 같은 256개 주소를 포함합니다. Google은 그 위치의 별표 하나만 문서화하고 그 외에는 아무것도 문서화하지 않습니다. 별표가 두 개이거나 앞에 별표가 있는 형식이 일부 상위 노출 페이지에 나오지만, Google은 그런 구문을 문서화하지 않았으니 의존하지 마십시오.
API는 더 유연합니다. Google의 IpBlockInfo 레퍼런스는 이렇게 말합니다. "개별 IP 주소 또는 CIDR 블록 제외를 지원합니다. 제외하려는 개별 IP 주소 또는 CIDR 블록마다 IpBlockInfo 조건을 하나씩 만드십시오." 예시는 IPv4의 192.168.0.0/24와 단일 주소를 나타내는 192.168.0.1/32, IPv6의 2001:db8::/48과 2001:db8:a0b:12f0::1/128입니다.
인터페이스는 단일 주소와 별표를 문서화합니다. CIDR과 IPv6 블록은 API용으로 문서화되어 있습니다. 인터페이스가 CIDR이나 IPv6 항목을 어떻게 처리하는지는 시험하지 않았으므로 동작한다고 말씀드리지 않겠습니다.
슬롯 계산에서 CIDR의 효과가 나타납니다. 영국의 한 에이전시가 WebSuccess Insights에서 예로 드는 194.83.41.0에서 194.83.47.255까지의 범위를 Python의 ipaddress.summarize_address_range로 처리했습니다.
| 입력하는 형식 | 위치 | 포함되는 주소 수 | 사용되는 항목 수 |
|---|---|---|---|
194.83.41.*부터 194.83.47.*까지, /24마다 한 행 | 인터페이스 | 1,792 | 7 |
194.83.41.0/24, 194.83.42.0/23, 194.83.44.0/22 | API | 1,792 | 3 |
2001:db8::/48 | API | /64 서브넷 65,536개 | 1 |
Google의 IPv6 예시는 /48이며, 여기에는 /64 서브넷 65,536개가 들어 있습니다. 기기 하나의 네트워크는 보통 /64 하나인 반면 ISP는 가정에 흔히 /56이나 /48을 할당하므로, /48 항목 하나가 고객의 사이트 전체를 덮을 수 있습니다. /48이 /64에 비해 무엇을 포함하는지는 IPv6 글에서 설명합니다.
Google은 한 줄을 더 덧붙입니다. "IP 주소는 여러 버전으로 나타날 수 있으므로 제외하려는 IP 주소의 모든 버전을 사용해야 합니다." IPv4와 IPv6 주소를 모두 가진 사무실이나 서버는 두 항목이 모두 필요하다는 뜻으로 읽으십시오.
Google Ads API로 IP 제외를 일괄 추가하기
API에서 캠페인 제외는 ip_block이 있는 negative CampaignCriterion이고, 계정 제외는 ip_block이 있는 CustomerNegativeCriterion입니다. Google의 조건 표는 IP 블록을 캠페인 수준과 고객 수준에서 제외 전용으로만 나열합니다.
무엇이든 전송하기 전에 목록을 줄이십시오. 이 스크립트는 후보 주소와 블록을 그것을 모두 덮는 가장 적은 수의 CIDR 항목으로, 클릭이 많은 순서대로 500개까지 바꿔 줍니다. 10월 14일에 Python 3.9.6, 표준 라이브러리만으로 실행한 코드 그대로입니다.
"""Turn candidate IPs and CIDR blocks into a Google Ads exclusion list of at most 500 entries.
Input: one entry per line, an IPv4/IPv6 address or a CIDR block (for example the
registered block you looked up in RDAP), optionally followed by a click count.
Output: the fewest CIDR entries that cover every input, busiest first, capped at 500.
"""
import ipaddress
import sys
GOOGLE_ADS_LIMIT = 500 # per campaign, and per account, in Google's API reference
def build_exclusions(lines, limit=GOOGLE_ADS_LIMIT):
clicks = {}
for line in lines:
line = line.split("#", 1)[0].strip()
if not line:
continue
parts = line.split()
net = ipaddress.ip_network(parts[0], strict=False) # 1.2.3.4 -> 1.2.3.4/32
clicks[net] = clicks.get(net, 0) + (int(parts[1]) if len(parts) > 1 else 1)
merged = []
for version in (4, 6): # collapse_addresses refuses to mix IPv4 and IPv6
nets = [n for n in clicks if n.version == version]
merged += ipaddress.collapse_addresses(nets)
# Credit each merged entry with the clicks of everything it now covers.
totals = {m: sum(c for n, c in clicks.items() if n.version == m.version and n.subnet_of(m))
for m in merged}
ranked = sorted(merged, key=lambda m: totals[m], reverse=True)
return ranked[:limit], ranked[limit:], totals
if __name__ == "__main__":
keep, dropped, totals = build_exclusions(sys.stdin)
for net in keep:
print(f"{net}\tclicks={totals[net]}")
print(f"# {len(keep)} entries kept, {len(dropped)} over the limit", file=sys.stderr)
공개할 실제 클릭 로그가 없어서, 문서화용 주소 대역만으로 만든 합성 샘플을 입력했습니다. 이것은 실제 클릭이 아니며 조회한 적도 없습니다.
# SYNTHETIC sample: documentation ranges (RFC 5737, RFC 3849), not real clicks
198.51.100.7 3
198.51.100.0/25 12 # a registered block you looked up
198.51.100.128/25 9 # its neighbour: merges with the line above into one /24
203.0.113.10 2
203.0.113.11 2 # adjacent to .10: the two merge into one /31
192.0.2.200 1
2001:db8::42 4
2001:db8::/48 6 # covers the address above
python3 -I build_exclusions.py < synthetic_clicks.txt를 실행하면 다음이 출력되었습니다.
198.51.100.0/24 clicks=24
2001:db8::/48 clicks=10
203.0.113.10/31 clicks=4
192.0.2.200/32 clicks=1
# 4 entries kept, 0 over the limit
여덟 줄이 항목 네 개가 되었습니다. 198.18.0.0/15에서 서로 인접하지 않은 합성 /32 600개도 입력해 보았는데, 클릭이 많은 500개를 유지하고 한도를 넘은 100개를 보고했습니다.
이 스크립트가 일부러 하지 않는 일이 세 가지 있습니다.
- 주소를 절대 넓히지 않습니다.
collapse_addresses는 맞닿거나 겹치는 블록만 병합합니다. 주소 하나를 그 /24로 바꾸는 것은 RDAP 조회 후 여러분이 내리는 결정이지, 코드가 추측할 일이 아닙니다. - 인터페이스 구문을 신경 쓰지 않습니다. /31이나 /48은 API에서는 문제없습니다. 인터페이스에서는 /31을 주소 두 개로 입력해야 하고, Google은 거기서 쓸 IPv6 범위 형식을 문서화하지 않았습니다.
- 공유 주소를 걸러내지 않습니다. 다음 섹션들의 규칙으로 릴레이와 통신사 NAT 주소를 제거한 뒤에만 실행하십시오.
또한 이 스크립트는 저희 API를 호출하지 않습니다. 조회 단계를 추가한다면 API 레퍼런스에 나온 대로 경로에 IP를 넣고 x-api-key 헤더에 키를 넣은 주소당 GET 한 번입니다. 일괄 호출은 없습니다. Python의 urllib에서는 User-Agent를 명시적으로 설정하십시오. 저희 API는 현재 urllib의 기본 User-Agent에 403을 반환하기 때문입니다.
항목을 전송하는 코드는 다음과 같습니다. Google의 IpBlockInfo 및 CampaignCriterion 레퍼런스(10월 14일 기준 v25)를 바탕으로 Python 클라이언트 라이브러리의 명명 규칙에 맞춰 작성했습니다. 실제 계정에서 실행하지는 않았습니다.
# Written from Google's IpBlockInfo and CampaignCriterion reference (v25); not run against a live account.
operation = client.get_type("CampaignCriterionOperation")
criterion = operation.create
criterion.campaign = client.get_service("CampaignService").campaign_path(customer_id, campaign_id)
criterion.negative = True # IP blocks can only be excluded
criterion.ip_block.ip_address = "198.51.100.0/24" # one CIDR block = one criterion
client.get_service("CampaignCriterionService").mutate_campaign_criteria(
customer_id=customer_id, operations=[operation]
)
# Account level: CustomerNegativeCriterionOperation, criterion.ip_block.ip_address,
# CustomerNegativeCriterionService.mutate_customer_negative_criteria.
# At 501 campaign entries the API returns ResourceCountLimitExceededError.CAMPAIGN_LIMIT.
Google은 캠페인 상한에 대한 오류만 문서화합니다. 계정 상한에 대한 오류 코드는 문서에서 찾지 못했으므로 지정하지 않습니다. Google Ads Editor의 버전 2.11 노트에는 "계정 수준 게재위치 및 IP 제외"라는 제목이 있지만 Editor는 시험하지 않았으므로 Editor 절차는 제시하지 않습니다.
500개 항목으로는 호스팅 네트워크를 담을 수 없는 이유
500개 항목으로는 대형 클라우드 제공업체를 담을 수 없습니다. Google은 ASN으로 네트워크를 제외하는 방법을 문서화하지 않았고, 큰 제공업체는 수천 개의 프리픽스를 광고하기 때문입니다. 10월 14일 06:14 UTC에 세어 보았습니다.
| 네트워크 | 필요한 항목 수 | 출처 |
|---|---|---|
| AS16509 (Amazon) | 광고된 프리픽스 27,319개 (IPv4 21,267개, IPv6 6,052개) | RIPEstat announced-prefixes, 기간 2026-09-30~2026-10-14 |
| AWS 공개 대역 | 고유 프리픽스 11,336개 (IPv4 7,863개, IPv6 3,473개) | ip-ranges.amazonaws.com, createDate 2026-10-14-03-37-06 |
| AS63949 (Akamai Connected Cloud, 이전 Linode) | 452개 (IPv4 354개, IPv6 98개) | RIPEstat, 같은 기간 |
| AS39351 (31173 Services, Mullvad의 네트워크) | 74개 (IPv4 53개, IPv6 21개) | RIPEstat, 같은 기간 |
| AS60729 (TORSERVERS-NET) | 6개 (IPv4 3개, IPv6 3개) | RIPEstat, 같은 기간 |
RIPEstat의 수치에는 겹치는 더 구체적인 프리픽스와 2주 기간 동안 관측된 모든 것이 포함되므로, 고유한 주소 공간이 아니라 필요한 항목 수의 상한으로 보십시오. 수치는 매일 달라집니다. 그래도 Amazon 하나만으로 두 목록을 합친 것보다 훨씬 많은 항목이 필요합니다.
따라서 호스팅 문제는 "클라우드를 제외할 수 있는가?"가 아닙니다. 제외할 수 없습니다. 문제는 "내 로그에 계속 나타나는 호스팅 블록은 무엇인가?"입니다. 어떤 주소가 데이터센터 IP인지는 따로 설명합니다. 저희 API는 엄선한 호스팅 ASN 853개와 클라우드 제공업체 10곳의 공식 대역으로 호스팅을 표시하며, 무료 데이터센터 IP 확인에서 주소 하나를 시험해 볼 수 있습니다.
그 플래그로 규칙을 쓰기 전에 주의할 점이 하나 있습니다. 호스팅 트래픽은 MRC 표준에서 첫 번째 일반 무효 트래픽(GIVT) 카테고리이지만, 같은 표준은 정상적인 VPN 라우팅과 가상 머신 브라우징을 여기서 제외합니다. 이는 GIVT vs SIVT: Google의 무효 트래픽 카테고리에서 풀어 설명합니다. 호스팅만으로는 의도적으로 낮은 점수가 나옵니다. 아래의 45.33.32.156은 detection.is_hosting: true와 점수 10, allow를 반환합니다. 유료 클릭에서 호스팅 트래픽에 광고를 보여 줄지는 점수가 아니라 여러분이 정할 규칙입니다.
500개 슬롯 중 하나를 쓸 가치가 있는 주소
슬롯은 아무도 공유하지 않으며 자체 클릭 로그에서 확인한 안정적인 범위에 써야 합니다. 그것이 어떤 모습인지 보여 드리기 위해, 2026년 10월 14일 06:12 UTC에 익명 GET https://api.geoiphub.com/v1/lookup/{ip}로 공개 주소 6개를 조회했습니다. 6개 모두 HTTP 200을 반환했습니다. 이 중 누구의 광고도 클릭한 적이 없으며, 클릭 로그에 들어 있을 법한 주소 유형을 대표하는 예시입니다.
저희 응답에는 프리픽스 필드가 없으므로, 06:14 UTC에 rdap.org를 통해 각 등록 블록을 RDAP에서 가져왔고, 이 서비스는 ARIN과 RIPE로 리디렉션했습니다.
| IP, 정체 | asn / org | user_type | is_hosting | is_vpn | is_relay | is_cgnat | 점수, 조치 | detection_methods | RDAP 블록 | 슬롯? |
|---|---|---|---|---|---|---|---|---|---|---|
| 45.33.32.156, scanme.nmap.org | 63949 AKAMAI-LINODE-AP | hosting | true | false | false | false | 10, allow | datacenter_ip | 45.33.0.0/17 (LINODE) | 이 블록이 클릭 로그에서 반복될 때만, 자체 광고 트래픽 규칙으로 |
| 185.220.101.1, Tor 출구, 함부르크 | 60729 TORSERVERS-NET | hosting | true | false | false | false | 100, block | tor_exit, datacenter_blocklisted, rdns_tor, known_spammer | 185.220.101.0/27 (ARTIKEL10) | 예: 독립적인 이유가 네 가지인 안정적인 운영자 블록 |
| 45.83.220.7, Mullvad의 네트워크, 말뫼 | 39351 31173 Services AB | hosting | true | true, "Mullvad (31173 Services)", 85 | false | false | 46, review | known_vpn_server, datacenter_ip | 45.83.220.0/24 | 기본적으로 아니오: 클릭 시점에 점수 매기기 |
| 185.213.155.73, Mullvad de-fra-wg-001 | 39351 31173 Services AB | hosting | true | true, "Mullvad", 95 | false | false | 100, block | known_vpn_server, wireguard_open, datacenter_with_vpn_proxy, no_ptr_datacenter | 185.213.155.0/24 | 가능하지만, 같은 운영자가 위 행에서는 46점이었음 |
| 104.28.46.99, iCloud Private Relay | 13335 Cloudflare | consumer_privacy_network | false | false | true | false | 9, allow | relay_ip | 104.16.0.0/12 (CLOUDFLARENET) | 절대 안 됨 |
| 172.224.226.1, iCloud Private Relay | 36183 AKAMAI-AS | consumer_privacy_network | true | false | true | false | 24, allow | datacenter_ip, no_ptr_datacenter, relay_ip | 172.224.0.0/12 (AKAMAI) | 절대 안 됨. is_hosting: true인 릴레이 |
두 행에는 설명이 필요합니다. 45.83.220.7의 VPN 이름은 Mullvad 자체 서버 목록이 아니라 신뢰도 85의 저희 VPN 호스팅 네트워크 표에서 나왔습니다. 10월 13일에 확인했을 때 Mullvad의 목록에는 이 주소가 없었습니다. 그리고 104.28.46.99는 Cloudflare의 등록된 /12 안에 있지만 Cloudflare가 자사 네트워크용으로 공개한 대역 밖에 있으므로, "Cloudflare 블록을 제외"하면 Cloudflare 서버가 아니라 Apple 릴레이 사용자가 차단됩니다.
주소 하나를 처음부터 끝까지
185.220.101.1을 클릭에서 항목까지 따라가 봅니다. 자동 태그를 켜 두면 Google이 랜딩 URL에 GCLID를 추가하며, Google의 예시는 "www.example.com/?gclid=123xyz"입니다. 랜딩 페이지에서 gclid 옆에 클라이언트 IP를 기록하십시오. 주소를 유료 클릭과 연결하는 것이 바로 이 짝이기 때문입니다.
그런 다음 주소를 조회합니다. 다음은 06:12 UTC 응답을 줄인 사본이며, 중첩 구조는 유지하고 값은 수정하지 않았습니다.
{
"ip": "185.220.101.1",
"asn": {
"asn": 60729,
"org": "TORSERVERS-NET - Stiftung Erneuerbare Freiheit",
"user_type": "hosting"
},
"whois": {
"netname": "ARTIKEL10",
"status": "ASSIGNED PA"
},
"detection": {
"is_vpn": false,
"is_tor": true,
"is_hosting": true,
"is_relay": false,
"is_anonymous": true
},
"threat": {
"is_spammer": true,
"is_cgnat": false
},
"scoring": {
"fraud_score": 100,
"recommended_action": "block",
"detection_methods": ["tor_exit", "datacenter_blocklisted", "rdns_tor", "known_spammer"]
}
}
detection.is_tor가 true이고 점수는 100이며, 서로 다른 네 가지 방법이 발동했습니다. 응답은 등록된 네트워크의 이름은 알려 주지만 크기는 알려 주지 않아서 RDAP에 물었습니다. 185.220.101.0부터 185.220.101.31까지, 즉 /27입니다. 이 블록은 API를 통해 항목 하나인 185.220.101.0/27이 됩니다. 500개 슬롯 중 하나를 쓰고 한 Tor 운영자가 운영하는 주소 32개를 덮습니다. 좋은 거래입니다.
저희가 따르는 규칙
- 자체 클릭 로그에서 확인한 안정적이고 공유되지 않는 범위, 즉
is_relay: false인 호스팅 블록과 Tor 운영자 블록에만 슬롯을 쓰십시오. - 점수와 무관하게
detection.is_relay또는threat.is_cgnat이 true인 주소에는 슬롯을 절대 쓰지 마십시오. - 그 밖의 모든 것은 VPN을 포함해 랜딩 시점에 클릭마다 점수를 매기십시오. 한 VPN 운영자의 주소 두 개가 46점과 100점을 받았기 때문입니다.
- 블록은 저희 응답이 아니라 RDAP 또는 제공업체의 자체 대역 파일에서 가져오십시오.
이러한 조치의 기반이 되는 점수 구간은 25점까지 allow, 50점까지 review, 75점까지 step_up, 75점 초과는 block입니다. 위험 점수 구간의 작동 방식은 별도의 글에서 설명하며, 슬롯을 쓰기 전에 무료 IP 위험 점수 검사기에서 주소를 확인할 수 있습니다.
공유 주소에는 슬롯을 쓰지 마십시오: 통신사 NAT와 Private Relay
통신사 NAT와 iCloud Private Relay 주소는 한 번에 많은 실제 사용자를 태우므로, 하나를 제외하면 그 모두에게 광고가 보이지 않게 됩니다. 어떤 점수나 클릭 수도 이를 바꾸지 못합니다.
Private Relay부터 보겠습니다. 많은 Apple 사용자가 각 출구 주소를 공유하고, 저희 점수 산정은 릴레이를 60점으로 제한하므로 Private Relay IP는 block에 도달할 수 없습니다. 함정은 위 표에 있습니다. 172.224.226.1은 Apple의 릴레이 목록에 있는데도 Akamai의 데이터센터에서 운영되기 때문에 detection.is_hosting: true를 반환합니다. "모든 호스팅 블록을 제외한다"는 규칙은 Apple 사용자까지 제외하게 됩니다. 무엇보다 먼저 is_relay를 확인하십시오. 릴레이와 VPN 사용자를 통과시키는 방법에서 설명합니다.
통신사 NAT는 같은 문제의 모바일 버전입니다. 저희는 일반 사용자 주소를 조회하거나 공개하지 않기 때문에 보여 드릴 안전한 통신사 주소가 없어 이 부분은 글로만 설명합니다. threat.is_cgnat은 다수의 통신사 가입자가 공유하는 주소를 표시하며, 저희 점수 산정에는 통신사 NAT 상한 50점이 있어서 다른 불리한 요소가 없는 공유 통신사 주소는 step_up 아래에 머뭅니다. RFC 6598의 100.64.0.0/10 대역은 통신사 내부 측이며 클릭 IP로 나타나지 않습니다. 대신 통신사의 공인 주소가 보일 것입니다.
잘못했을 때의 대가는 오래전에 기록되었습니다. RFC 6269는 공유 주소에서 "로그인 시도에 여러 번 실패한 한 사용자가, 이전에 시도한 적이 없다가 이제 첫 시도에서 실패하게 되는 다른 사용자까지 차단할 수 있다"고 경고합니다. 로그인 시도를 광고 클릭으로 바꾸면 제외 문제가 됩니다. 허브 글에서는 공유 주소를 차단하면 실제 고객이 피해를 입는 이유를 더 자세히 다룹니다.
IP 제외로 차단할 수 없는 것
IP 제외는 한 주소의 모든 클릭을 막지 못하고, 네트워크를 지정할 수 없으며, 이미 지불한 클릭에는 영향을 주지 않습니다. 첫 번째 부분은 Google이 제외한 IP 주소에서 클릭이 발생하는 이유는 무엇인가요? 페이지에서 직접 말합니다.
"IP(인터넷 프로토콜) 제외 도구를 사용해도 제외된 IP 주소의 클릭이 웹 로그에 계속 나타날 수 있습니다."
Google은 세 가지 이유를 듭니다.
- 로테이션. "일부 인터넷 서비스 제공업체(ISP)는 사용자의 IP 주소를 계속 바꿉니다." 광고는 한 주소에 노출되고 클릭은 다른 주소에서 들어옵니다.
- 누락된 데이터. "일부 Google 네트워크 사이트는 IP 정보를 제공하지 않으므로, 제외된 IP 주소를 쓰는 사용자도 이런 사이트에서 광고를 볼 수 있습니다. 특정 IP 주소에서 클릭이 전혀 발생하지 않는다고 보장할 수 없습니다."
- 자연 검색 클릭. "Google 자연 검색 결과의 클릭과 광고 클릭의 리퍼러 URL은 같습니다. IP 제외는 광고에만 적용되므로, 보고 계신 클릭이 실제로는 검색 결과에서 발생했을 수 있습니다."
그리고 저희 입장 전체를 결정하는 문장이 이어집니다.
"Google은 계정에서 무효 클릭을 자동으로 선제 필터링합니다. 이 보호를 받기 위해 사용자가 할 일은 없습니다. 다만 IP 주소 제외 도구를 사용하면 광고 게재위치를 추가로 제어할 수 있습니다."
Google의 표현으로는 사기 방어가 아니라 게재위치 제어입니다. Google은 제외에 대한 ASN, ISP, VPN, 프록시, 데이터센터 설정도 문서화하지 않으며, 제외한다고 해서 이미 청구된 클릭의 금액을 돌려받지는 못합니다.
저희 쪽에도 한계가 있습니다. 저희 API는 여러분이 준 IP를 분류합니다. Google Ads 클릭이나 GCLID는 볼 수 없으며, 이는 여러분의 랜딩 페이지 로그에서만 얻을 수 있습니다. 프리픽스를 반환하지 않으므로 블록은 항상 RDAP에서 가져와야 합니다. 그리고 조회 결과는 변합니다. 10월 13일까지 저희 클릭 사기 가이드는 45.83.220.7을 단순한 호스팅 예시로 썼지만, 지금은 API가 Mullvad의 네트워크라고 명시합니다. 근거로 삼아 조치하는 모든 결과에는 날짜를 기록하십시오.
주소 유형별 대응은 다음과 같습니다.
| 주소 유형 | 대응 | 이유 |
|---|---|---|
| 자사 사무실, 경쟁사의 고정 사무실 대역, 로그에서 반복적으로 보이는 안정적인 호스팅 또는 Tor 블록 | 제외, 블록당 CIDR 항목 하나, 계정 수준에서 | 안정적이고 공유되지 않으며 항목 수가 적음 |
통신사 NAT(threat.is_cgnat: true), iCloud Private Relay(is_relay: true) | 절대 제외하지 않음 | 주소 하나에 실제 사용자가 많음 |
| VPN 출구, 일회성 호스팅 주소, 계속 바뀌는 모든 것 | 랜딩 시점에 scoring.recommended_action으로 점수 매기기 | 같은 운영자가 46점과 100점을 받았음 |
이번 주에 자체 제외 목록에서 할 점검 두 가지입니다.
- 줄이기. 현재 항목을 내보내 위 스크립트에 넣어 보십시오. 병합되는 항목은 슬롯을 비워 주므로, 새 항목을 추가하기 전에 남은 수를 세어 보십시오.
- 공유 주소 제거. 각 항목에서 주소 하나씩을 위험 점수 검사기에서 조회하십시오.
is_relay또는is_cgnat이 true로 나오는 항목은 삭제하십시오.
자주 묻는 질문
Google Ads에서 IP 주소를 몇 개까지 제외할 수 있나요?
캠페인당 최대 500개이며, Google의 API 레퍼런스는 계정 수준 제외에도 같은 500개 상한을 둡니다. 계정 목록이 더 큰 풀은 아닙니다.
Google Ads IP 제외에 CIDR이나 IPv6를 쓸 수 있나요?
Google Ads API를 통하면 가능합니다. IPv4 또는 IPv6 CIDR 블록 하나가 항목 하나입니다. Google의 도움말 페이지는 인터페이스용으로 단일 주소와 마지막 옥텟의 별표만 설명합니다.
실적 최대화(Performance Max) 캠페인에서 IP 주소를 제외할 수 있나요?
계정 수준에서만 가능합니다. 동영상, 호텔, 앱, 실적 최대화, 스마트 디스플레이 캠페인에서는 캠페인 수준 IP 제외를 사용할 수 없습니다.
제외한 IP 주소에서 왜 여전히 클릭이 발생하나요?
Google은 세 가지 이유를 듭니다. 일부 ISP가 사용자의 주소를 계속 바꾸고, 일부 Google 네트워크 사이트는 IP 정보를 제공하지 않으며, 자연 검색 클릭과 유료 클릭의 리퍼러가 같기 때문입니다.
IP 주소를 제외하면 이미 지불한 클릭이 환불되나요?
아닙니다. 제외는 그 시점부터 해당 주소에 광고가 노출되지 않게 할 뿐입니다. 무효 클릭에 대한 크레딧은 별도의 절차입니다.
이동통신사나 iCloud Private Relay IP를 제외해야 하나요?
아닙니다. 그런 주소 하나하나를 많은 실제 사용자가 함께 쓰므로, 슬롯을 쓰는 대신 클릭에 점수를 매기십시오.
GeoIPHub API를 만드는 팀
GeoIPHub IP 인텔리전스 API와 스캐너를 만드는 GeoIPHub 팀이 작성했습니다. 초안은 AI의 도움을 받아 준비하고 팀이 편집합니다. API 예시는 예시용으로 표시된 경우를 제외하고 라이브 API에 대한 실제 조회 결과입니다.
