欺诈防范Google Ads IP 排除上限：500 条限制、CIDR，以及它挡不住什么
Google Ads 的 IP 排除上限是每个广告系列 500 条、每个账号 500 条。本文基于我们实测的六次查询，说明 CIDR 如何让每个名额覆盖更多地址，以及哪些 IP 值得占用一个名额。
您手里有一份点击日志。少数几个地址反复出现，排除框只能容纳 500 条，您在想填满之后会怎样。搜索这个上限，几乎所有给出答案的页面都来自点击欺诈防护厂商，而几乎所有答案的结尾都一样：我们的工具会帮您轮换列表。
我们认为这个问题问错了。Google 自己的 API 文档以“IP 地址块”（IP blocks）为单位计算上限，所以一个条目可以覆盖整个地址段，真正有用的问题就变成了：哪些地址段值得占用一个名额。我们的立场很简单：排除列表用于处理稳定的干扰来源，例如您自己的办公室，或反复出现的某个托管地址块，而不是用来对付欺诈。Google 表示它已经在自己这一侧过滤无效点击，我们会在文末引用那个页面。
下面我们用 Google 的原话给出两个上限，演示如何在界面中输入地址段、如何通过 API 以 CIDR 形式提交，用我们的 API 查询六个真实地址来判断哪些值得占用名额，并列出任何排除都无法阻止的情况。如果想了解为每次点击评分而不是封禁的完整理由，请先阅读我们的点击欺诈指南。
Google Ads IP 排除上限：最多能排除多少个地址？
每个广告系列可以排除 500 个 IP 条目，每个账号也是 500 个。这两个数字分别出现在 Google 的不同页面上，这也是为什么很多文章把第二个数字写错了。
本文引用的每个 Google 页面，我们都在 2026 年 10 月 14 日 06:12 UTC 打开过。广告系列级上限写在 Google 的帮助页面排除 IP 地址中：
“每个广告系列最多可以排除 500 个 IP 地址。”
帮助页面没有给出账号级的数字。账号级上限写在 Google Ads API 参考文档的 CustomerNegativeCriterion 中，这个资源承载账号级排除。它的 ip_block 字段写着：“Immutable. IpBlock. You can exclude up to 500 IP addresses per account.”（不可变。IpBlock。每个账号最多可以排除 500 个 IP 地址。）一些排名靠前的页面漏掉了这一点。Lunio 关于 500 条上限的文章（我们在同一时间打开）写道：“500 条 IP 排除上限按广告系列计算，而不是按账号计算。”而 Google 的参考文档表明，账号级列表有自己的 500 条上限。
计数单位比数字本身更重要。Google 的 API 系统限制表格中这一行写的是“Excluded IP blocks per campaign”（每个广告系列排除的 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 给出的账号级操作步骤，出自同一帮助页面：
- 在您的 Google Ads 账号中，点击管理员图标。
- 点击账号设置。
- 前往“IP 排除”部分。
- 输入您不希望看到广告的 IP 地址。
- 点击保存。
针对单个广告系列：
- 在您的 Google Ads 账号中，点击广告系列图标。
- 点击版块菜单中的广告系列下拉菜单。
- 点击广告系列，然后点击设置。
- 选择您想排除 IP 地址的广告系列。
- 在“设置”页面上，点击其他设置。
- 展开“IP 排除”部分，输入地址并点击保存。
在任一级别删除条目都走同样的路径。Google 的说明是按照上述步骤，“移除您不想应用的任何 IP 地址排除”，然后点击保存。有一个陷阱：“您无法在各个广告系列中修改或移除账号级排除。”如果某个条目在广告系列里似乎删不掉，请到账号设置中查看。
合适的账号级条目包括您的办公室、您的代理商办公室，以及经确认反复产生点击的托管地址块。竞争对手固定的办公室地址段也适合占用一个广告系列级名额。如果您真正的目标是地域，Google 会把您引向别处：“如果您想阻止广告在某些地理位置展示，请尝试排除地理位置，而不是排除 IP 地址。”
哪些广告系列类型不能使用广告系列级 IP 排除？
视频、酒店、应用、效果最大化和智能展示广告系列不能使用广告系列级 IP 排除。Google 的帮助页面用一条注释说明了这一点：
“注意：视频广告系列、酒店广告系列、应用广告系列、效果最大化广告系列和智能展示广告系列不支持 IP 排除。”
账号级的覆盖范围更广。Google 表示您可以用它“在账号内的所有广告系列中排除特定 IP 地址看到您的广告，包括效果最大化、需求开发、搜索、购物、展示、Discover 和 YouTube”。所以效果最大化只能在账号级别使用 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.* 覆盖 256 个地址，与一个 /24 相同。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 的价值体现在名额计算上。以 194.83.41.0 到 194.83.47.255 这个地址段为例，这是一家英国代理商在 WebSuccess Insights 上使用的例子。我们用 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 | 65,536 个 /64 子网 | 1 |
Google 的 IPv6 示例是一个 /48，其中包含 65,536 个 /64 子网。单台设备所在的网络通常是一个 /64，而 ISP 通常给一个家庭分配 /56 或 /48，所以一个 /48 条目可以覆盖整个客户站点。我们在 IPv6 文章中解释了 /48 与 /64 各自覆盖的范围。
Google 还补充了一句：“IP 地址可能有不同的版本，因此请务必使用您想排除的 IP 地址的所有版本。”可以理解为：同时拥有 IPv4 和 IPv6 地址的办公室或服务器需要两个条目。
通过 Google Ads API 批量添加 IP 排除
通过 API，广告系列级排除是一个带 ip_block 的否定 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
八行输入变成了四个条目。我们还给它输入了 600 个来自 198.18.0.0/15、互不相邻的合成 /32，它保留了点击量最高的 500 个，并报告有 100 个超出上限。
这个脚本有意不做三件事：
- 它从不扩大一个地址的范围。
collapse_addresses只合并相邻或重叠的地址块。把一个地址扩大成它所在的 /24，是您在 RDAP 查询之后做出的决定，不应由代码去猜。 - 它不关心界面语法。 对 API 来说，/31 或 /48 都没问题。在界面中，您需要把 /31 输入为两个地址，而 Google 没有记载那里可用的 IPv6 地址段写法。
- 它不过滤共享地址。 只有在按照后面几节的规则剔除中继和运营商 NAT 地址之后，才运行它。
它也从不调用我们的 API。如果您加入一个查询步骤，那就是每个地址一次 GET 请求，IP 放在路径中，密钥放在 x-api-key 请求头中，如 API 参考文档所示。没有批量接口。如果使用 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 编辑器的2.11 版说明中有一个标题为“账号级展示位置和 IP 排除”的部分，但我们没有测试过编辑器，所以不提供编辑器的操作步骤。
为什么 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 的计数包括相互重叠的更具体前缀，以及两周窗口内出现过的任何前缀，所以应将其视为条目数的上界，而不是唯一的地址空间。这些数字每天都在变化。即便如此，单是 Amazon 所需的条目数就是您两份列表总容量的许多倍。
所以托管方面的问题不是“我能排除云吗？”您做不到。问题是“哪些托管地址块在我自己的日志里反复出现？”我们另文解释了什么样的地址算数据中心 IP。我们的 API 依据 853 个人工整理的托管 ASN 以及 10 家云服务商的官方地址段来标记托管流量，您可以在免费的数据中心 IP 检测工具中测试单个地址。
在基于这个标记编写规则之前，有一点需要注意。托管流量是 MRC 标准中的第一类常规无效流量（General Invalid Traffic），但同一标准将合法的 VPN 路由和虚拟机浏览排除在外，我们在 GIVT 与 SIVT：Google 的无效流量类别中有详细说明。仅凭托管这一点，评分在设计上就很低：下文的 45.33.32.156 返回 detection.is_hosting: true，评分为 10，allow。对于付费点击，托管流量是否应该看到您的广告，是由您来制定的规则，而不是由评分决定。
哪些地址值得占用您的 500 个名额之一
一个名额应该分配给一个稳定的、不与他人共享的、并且在您自己的点击日志中出现过的地址段。为了说明这是什么样子，我们在 10 月 14 日 06:12 UTC 用匿名的 GET https://api.geoiphub.com/v1/lookup/{ip} 查询了六个公开地址。六个都返回了 HTTP 200。它们都没有点击过任何人的广告，只是用来代表点击日志中会出现的几类地址。
我们的响应中没有前缀字段，所以我们在 06:14 UTC 通过 rdap.org（它重定向到了 ARIN 和 RIPE）从 RDAP 获取了每个地址的注册地址块。
| 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 名称来自我们的 VPN 托管网络表，置信度为 85，而不是来自 Mullvad 自己的服务器列表；我们在 10 月 13 日查看时，该列表并未包含这个地址。另外，104.28.46.99 位于 Cloudflare 注册的 /12 之内，但不在 Cloudflare 为自有网络公布的地址段之内，所以“排除 Cloudflare 的地址块”会误伤 Apple 中继用户，而不是 Cloudflare 的服务器。
一个地址的完整流程
从点击到条目，跟踪 185.220.101.1 的全过程。启用自动标记后，Google 会在您的着陆页网址上添加 GCLID，Google 示例中的写法是“www.example.com/?gclid=123xyz”。请在着陆页上把客户端 IP 与该 gclid 一起记录下来，因为正是这种配对把一个地址和一次付费点击关联起来。
然后查询这个地址。以下是我们 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 或服务商自己的地址段文件中获取，而不是从我们的响应中获取。
这些动作背后的评分区间是：allow 不超过 25，review 不超过 50，step_up 不超过 75，block 高于 75。我们在另一篇文章中解释了欺诈评分区间如何运作，您也可以在为某个地址占用名额之前，先用免费的 IP 欺诈评分检测工具查询它。
绝不要为共享地址占用名额：运营商 NAT 和 Private Relay
运营商 NAT 和 iCloud Private Relay 的地址同时承载着许多真实用户，排除其中一个，就会让所有这些人都看不到您的广告。任何评分或点击次数都改变不了这一点。
先说 Private Relay。每个出口地址都由许多 Apple 用户共享，我们的评分把中继的上限设为 60，所以 Private Relay 的 IP 永远不会达到 block。陷阱就在上面的表格里。172.224.226.1 在 Apple 的中继列表上，却仍然返回 detection.is_hosting: true，因为它运行在 Akamai 的数据中心里。一条“排除所有托管地址块”的规则会把 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 地址的点击仍可能出现在您的网站日志中。”
它给出了三个原因：
- 轮换。 “部分互联网服务提供商会不断轮换用户的 IP 地址。”广告在一个地址上展示，点击却从另一个地址到达。
- 数据缺失。 “部分 Google 网络中的网站不提供 IP 信息，因此使用您已排除 IP 地址的用户可能会在这些网站上看到您的广告。我们无法保证某个特定 IP 地址不会产生点击。”
- 自然点击。 “Google 自然搜索结果中的点击和广告点击的引荐网址是相同的。由于 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 的帮助页面对界面操作只记载了单个地址和替换最后一段的星号写法。
效果最大化广告系列可以排除 IP 地址吗？
只能在账号级别排除。视频、酒店、应用、效果最大化和智能展示广告系列不支持广告系列级 IP 排除。
为什么已排除的 IP 地址仍然会产生点击？
Google 给出了三个原因：部分 ISP 会轮换用户的 IP 地址；部分 Google 网络中的网站不提供 IP 信息；自然搜索点击与付费点击的引荐来源相同。
排除一个 IP 地址会退还已经付费的点击吗？
不会。排除只会让您的广告从此不再向该地址展示。无效点击的抵扣是另一套独立流程。
应该排除移动运营商或 iCloud Private Relay 的 IP 吗？
不应该。这类地址每一个都由许多真实用户共享，因此应对点击进行评分，而不是为它浪费一个名额。
GeoIPHub API 背后的团队
由 GeoIPHub 团队撰写，即构建 GeoIPHub IP 情报 API 及其扫描器的团队。草稿在 AI 辅助下完成，并由团队编辑；除非标注为示例，API 示例均为针对线上 API 的真实查询。
