【踩坑记】免费 IP 归属地接口被限流后，我们自建了一个多源聚合查询服务

admin

先说结论：一个"说好免费给你用"的 IP 归属地接口，某天开始偷偷限流；更坑的是客户端把"查询失败"当结果永久缓存了，于是工具里「IP 归属地」那一列整列变 -，而且再也回不来。最后我们干脆自建了一个查询服务。这篇把过程和一些经验记下来，也许对遇到同类问题的朋友有用。

背景三点（先交代清楚）

1. 接口原本用在哪：批量管理工具里所有要"把 IP 翻成归属地"的地方——防火墙模块（封禁列表/攻击来源 IP）、登录日志、路由追踪，四处共用同一个归属地查询缓存；接口一挂，四处同时哑。
2. 限流怎么暴露的：静默。界面上不弹错，只是「归属地」列悄悄整列变 -；只有直接请求接口才看到 HTTP 429 请求过于频繁。真正放大问题的，是「失败被当结果永久缓存」这一层。
3. 自建方案怎么选的：先否掉"把离线库塞进客户端"（体积大/更新难/多端维护），再定为"服务端一个 HTTP 查询接口 + 多源聚合 + RIR 对账 + 人工修正表 + 洗库链"。

一、现象与真凶

某天开始，工具里「IP 归属地」整列显示 -，几天都不恢复。排查下来：

· 直连那个第三方接口，返回 HTTP 429 {"code":429,"msg":"请求过于频繁"}——它按来源 IP 限流，突发额度只有个位数/窗口，换个 User-Agent 也绕不过。
· 真正坑的不是限流本身，是客户端逻辑：查询失败被当成"结果"永久写进了本地缓存，一旦命中就不再去查——被限流那一刻查过的那些 IP，永远是 -。
· 更糟的是，封禁列表/登录日志/路由追踪四处共用同一份缓存——一坏全坏。

一点小教训：失败绝不能和"确实查不到"混在一起缓存，而且缓存应该分来源、能独立失效。否则一个外部接口抖一下，你整个界面就废了。

二、为什么不把离线库塞进客户端

直接的办法是塞个离线 IP 库进客户端。但库文件体积不小、更新麻烦，而且我们这边工具/Windows agent/Linux 脚本好几端都要各自维护一份。于是反过来做：自建一个查询服务。客户端只认一个 HTTP 接口，库放在服务端，以后更新只动服务端一处。

三、多源聚合：单源都不靠谱

做起来才发现，单个数据源都有各自的短板，正确做法是分场景取信 + 权威兜底：

· 国内：ip2region（省市）+ 纯真 qqwry（国内+运营商）+ 国内运营商权威网段（电信/联通/移动/教育网等约 5400 段），运营商字段以权威段为准。
· 国外：MaxMind GeoLite2-City（国家/ASN）。

一个挺反直觉的发现：官方 MaxMind 对中国境内几乎不给省市（只到国家，覆盖约 20%）。以前很多"能查到国内省市"的库，其实是某种中文重打包版。所以分工必须写死——国内省市：纯真 > geoip2 > ip2region；国外：ip2region > geoip2。

还有一点：多源"聚合"不等于简单"投票"。必须写死每类字段的优先次序，再留一张人工修正表，优先级最高。



四、拿 RIR 注册库当"标准答案"做对账

怎么知道每个源到底几分准？我们用五家 RIR 的 delegated 注册库当国家判定的权威基准，抽 20 万个 IP 做了对比，与 RIR 一致率：

· ip2region：91.6%
· 纯真 qqwry：90.1%
· MaxMind GeoLite2：95.0%
· 三源合并后：95.0%

国内（CN）样本里，ip2region 和纯真的省市一致率只有 88.6%——单看一个库"好像挺准"，交叉一验就露馅了。

五、多源会一起错：修正表 + 待核对队列

有些情况三个库会一起错，投票也救不回来。典型是：一台登记在 A 国、实际跑在 B 国的机器（跨境/hosting）。这种只能靠人工修正表（按网段覆盖）。另外，只要出现"多源国家判定不一致"，就自动进一个待核对队列，由人在后台采纳或忽略——把"不确定"显性化，而不是硬编一个答案糊弄过去。

六、洗库链

我们单独放了一台机器干"洗库"：每天定时拉全源 + 跑抽样对账，再把最新的库同步回服务机、重启服务。全自动，基本不用人管。

七、几条可复用的经验

1. 免费接口 = 不可控，被限流只是时间问题——关键路径别单点依赖外部免费服务。
2. 查询失败绝不能当结果缓存；要退避重试，且"失败"和"确实查不到"要分开。
3. 多处共用一个缓存——一坏全坏；缓存要分来源、能独立失效。
4. 多源"聚合" ≠ "投票"；要分场景取信 + 权威兜底 + 人工修正三层。
5. 用权威基准（RIR）做量化对账，才知道每个源到底几分准。

以上是我们踩过的一串坑，记录下来给同路人参考。如果你也在做 IP 归属地/多源数据聚合，欢迎在评论区聊聊你踩过的坑。