凌晨两点多某数据录入系统的值班同事发来截图录入队列里突然多出四百多条记录提交时间集中在十几分钟内字段格式合规得过分连错别字都没有。人工复核发现这些记录来自同一个出口 IP 段分布在三个相隔上万公里的地区而账号注册时间全在当天下午。这不是第一次了。后来我们把整个录入链路重新梳理了一遍把 IP 地理位置数据嵌进风控和界面渲染两个环节问题才算压住。这篇内容聊的就是这件事IP 地理位置数据怎么用在站点的安全防护和内容自定义上以及像 ipdata 这类地理位置数据服务在真实系统里应该摆在什么位置。适合正在做后台系统、数据采集平台、跨境业务站点的开发者和产品同学看也适合已经把接口调通、但还没想清楚拿到这些字段之后到底干什么的人。全文不讲空概念只讲我们踩过的路。1. 标题里那个数据录入软件的真实诉求先把场景说清楚不然讨论地理位置数据很容易飘。所谓数据录入软件在多数团队里不是一个孤立的小工具而是一套带权限、带审核、带统计的后台系统录入员分区域作业审核员按批次处理运营看报表。这类系统天然对人从哪来敏感因为它的核心资产就是数据本身的干净程度。1.1 录入系统最怕的三类脏数据来源第一类是脚本灌入。有人写个循环把伪造或半伪造的记录批量塞进来目的是刷量、刷任务、套激励。这类请求的特征是节奏均匀、字段高度规整、出口 IP 集中。第二类是账号共享。一个录入账号被几个人甚至跨地区轮流使用工时统计全乱绩效算不准出问题还追不到人。这类行为在 IP 维度上表现为同一账号在极短时间内出现在地理上不可能同时到达的两个位置。第三类是区域越权。某些录入任务按市场划分A 区的录入员不该看到 B 区客户的信息。传统做法靠账号权限表管但权限表管不住人把自己的账号借出去。这三类问题有一个共同点它们都不是靠字段校验能解决的。字段可以伪造节奏可以模仿只有请求来自哪里这个信号相对难以低成本伪造。这就是地理位置数据在录入系统里最朴素的切入点。1.2 地理位置数据在链路上的四个落点我们把地理位置判断放在了四个位置每个位置的目标完全不同落点触发时机主要用途失败时的处理登录鉴权账号登录时判断是否为异常地域登录触发二次验证放行但标记风险分写入接口提交记录时机房出口 IP、跨区提交拦截进入人工审核队列界面渲染首屏输出时语言、时区、日期与数字格式、货币单位回落到站点默认区域报表统计离线批处理按来源地区聚合看异常分布归入未知来源桶四个落点对实时性的要求不一样。登录和写入是同步链路多几十毫秒用户能感知所以必须带缓存和超时兜底渲染是半同步可以接受一次带缓存的外呼报表是离线怎么查都行甚至可以批量补历史。提醒一句不要一上来就在所有落点都调实时接口。地理位置数据的价值密度在少数关键判断上铺得太开会把接口费用和延迟一起拉高收益却很有限。1.3 为什么不在前端做这件事有人会问浏览器里不是能拿到时区、语言吗前端算一下不就行了。不行原因有三个。一是前端拿到的都可以被改。时区、语言、navigator系列字段在调试工具里随便改拿它做安全判断等于没有判断。二是前端拿到的是设备偏好不是网络位置。用户在系统设置里把语言设成英文不代表他在英文市场用户挂着公司内网出口时区可能是总部时区。三是前端算出来的结论要传回服务端服务端还得再信一次中间多了一个可以被篡改的环节。地理位置判断必须落在服务端前端只负责根据服务端下发的区域标识切换文案和格式。这个分工要一开始就定死否则后面会陷入到底以谁为准的扯皮。2. IP 地理位置数据能给出什么以及给不了什么第二个要讲清楚的是能力边界。我见过不少团队把地理位置接口当成精准定位写进需求文档时写的是获取用户所在城市上线后发现城市命中率远低于预期然后开始怀疑服务商不行。问题往往不在服务商而在需求本身写错了。2.1 字段清单与各自的业务含义以 ipdata 这类服务为例一次查询通常能返回下列几组信息。我把它们按可信度和业务用途分开列字段分组典型内容可信度主要用途国家/地区两位国家码、国家名高合规提示、站点默认区域、语言兜底省/州、城市行政区名称与编码中报表聚合、区域任务分配经纬度浮点坐标低到中距离估算、地图展示时区IANA 时区名中高时间显示、营业时间判断网络属性ASN、运营商、连接类型高机房 IP 识别、风控打分类型标记是否为数据中心、是否为企业网络中高风控打分货币与语言货币码、语言码中界面本地化兜底注意最后两行的定位它们是兜底值不是权威值。用户所在国家的默认货币不等于用户想用的货币跨境业务尤其如此。我们最终的做法是地理位置给默认值用户设置覆盖默认值两者都记下来报表里能看出偏差率。真正高价值的其实是网络属性那一组。判断一个 IP 是不是数据中心出口比判断它在哪个城市有用得多。因为绝大多数批量灌数据的请求都来自机房而正常录入员的请求来自家庭宽带或移动网络。这个信号的区分度比经纬度高出几个量级。2.2 精度是分层的别用一个指标概括全部行业内常见的说法是国家级准确率很高城市级中等坐标级最低。这句话是对的但落到工程上要拆得更细国家级绝大多数场景可用。跨境判断、合规提示、语言兜底都可以基于它。省级可用性尚可适合做报表聚合不适合做是否越权的硬判断。城市级在人口密集、运营商基础设施建设完善的地区表现较好在网络结构分散的地区会明显下降。坐标级只能当参考。常见偏差来源包括运营商把整个省份的出口集中在省会、移动网络的出口池跨市共享、企业专线统一从总部出口。我们把城市字段用在两个地方报表的地理分布图和距离上一次登录位置超过 N 公里的软提示。绝不用它做封禁依据。2.3 三条必须写进设计文档的误差假设上线前我们把下面三条写进了技术方案后面每次争论都回来看这三条移动网络不可靠假设。移动网络的出口 IP 会在一个较大的池子里漂移同一个用户在通勤路上可能被判断在相邻两三个城市之间跳。任何基于城市的硬规则都必须对移动网络类型放宽阈值。企业出口集中假设。一个几十人的团队共用一条专线所有人在 IP 维度上长得一模一样。如果规则是同 IP 多账号判定为异常第一天就会把整个团队误伤。所以规则必须是同 IP 多账号 时间窗口 字段相似度的复合条件。IPv6 覆盖不全假设。IPv6 的地理数据覆盖度通常不如 IPv4某些段甚至只能给到国家。系统必须能接受只有国家、没有城市这种稀疏结果而不是当成错误处理。这三条假设后来救了我们两次。一次是移动录入员集体被误判一次是 IPv6 用户大面积城市未知。如果没有提前约定这两次都会被当成线上故障处理实际只是数据本身的特性。3. 站点防护把地理信号变成可执行的风控规则拿到字段只是开始真正难的是怎么用。我见过两种极端一种是拿到数据什么都不敢做怕误伤另一种是上来就写死规则country ! XX直接拒绝第二天客服被打爆。中间那条路是打分不是判断。3.1 从布尔判断到风险打分布尔判断的问题在于它只有一个比特的信息量无法表达有点可疑和非常可疑的区别。改成打分之后每条规则贡献一个分数总分超过阈值才触发动作动作本身也分等级记录、二次验证、进人工队列、临时限制。我们用的权重表大致如下分数是相对值不是绝对值各团队应该按自己的误判成本调信号分值说明出口 IP 被标记为数据中心30录入场景下这是最强的单一信号同一账号 24 小时内跨越多个国家25需要排除移动网络与企业专线同 IP 关联账号数超过 520单独看容易误伤配合其他信号IP 时区与浏览器时区相差超过 3 小时15常见于手工修改时区IP 国家与账号注册国家不一致10跨境办公很常见权重必须低提交频率处于历史高位区间15与 IP 无直接关系但需要一起看阈值我们设了两档低于 40 分只记录不打扰40 到 70 分之间触发二次验证短信或邮箱确认高于 70 分进人工审核队列同时对该账号的写入做限速。三个月跑下来人工审核队列里真正有问题的比例从最初的不到两成提升到了六成以上误伤投诉下降了绝大部分。3.2 五条可以直接抄的规则写法下面这几条是我们实际在用、并且调过参数的规则写法上尽量做到条件明确、可解释、能回滚规则一机房出口写入敏感表。如果请求的出口 IP 被标记为数据中心且目标接口属于核心数据表直接进人工队列不做拦截。理由是不拦截就不会误伤真实用户而人工队列的成本远低于数据被污染的成本。规则二不可能的地理跳跃。同一账号两次相邻请求地理位置距离超过 800 公里且时间间隔小于 2 小时标记为高风险。这里的 800 公里是拍出来的实测下来能过滤掉跨区共享账号的大部分情况同时不误伤同城和邻近城市通勤。规则三时区与地理位置错位。IP 所属时区与浏览器上报时区相差超过 3 小时记一次轻量风险分。这一条单独看不强但和账号注册不满 7 天叠加时命中率很高。规则四同 IP 并发写入。同一出口 IP 在 5 分钟内对同一张表写入超过 30 条触发限速返回可重试的状态码而不是拒绝。限速比封禁温和脚本会自己卡住真人几乎无感。规则五注册地与常用地分离。账号长期在 A 地区使用突然从 B 地区提交核心数据且 B 地区从无历史记录触发二次验证。这条规则需要维护一个常用地区的滚动统计实现上不复杂一张按账号聚合的日表就够。3.3 误判的成本必须有出口任何基于地理位置的风控都会误判区别只在于你有没有为误判准备出口。我们踩过的误判场景包括跨国公司员工出差、海外留学生暑期回国、运营商临时调整出口路由、用户自己开了加速类工具导致出口变化。对应的处理是所有触发风控的动作都必须给出可解释的提示和可自助解除的路径。二次验证是最低成本的方式人工审核要给出 24 小时内响应的承诺被限制的账号要有明确的申诉入口而不是只显示一个 403。有个细节值得单独提提示文案不要写检测到您所在地区异常这句话会让人一头雾水。写成您的账号近期在多个地区登录为保障数据安全请完成一次验证完成率会高很多。风控的成败有一半在文案上。4. 内容自定义让同一个页面在不同市场长出不同样子防护是防守面的用法自定义是进攻面的用法。同一套地理位置数据换个用法就能明显提升录入效率因为它减少的是每次都要手动改的摩擦。4.1 本地化不是翻译是格式对齐很多团队理解的本地化是把文案翻成另一种语言实际用起来最影响体验的往往是格式。我们按优先级排了一下效果从高到低日期与时间格式。2024/03/05和03/05/2024混在一起录入员每天都要多花几秒确认。统一按 IP 所属地区输出出错率下降非常明显。数字分隔符与小数点。逗号和小数点的用法在不同地区是反的录入金额字段时这是真实的错误来源。货币单位与符号位置。符号在前在后、要不要空格这些细节在跨境结算场景里会引发对账纠纷。计量单位。长度、重量、温度能换算的尽量换算不能换算的在字段旁边标注原单位。语言。放在最后不是因为它不重要而是因为它最容易被用户设置覆盖地理位置只是兜底。实现上我们把区域标识一个短字符串比如zh-CN、en-US作为唯一入参传给前端前端用标准的国际化库格式化绝不在业务代码里手写格式化逻辑。服务端只负责决定这个标识是什么以及用户手动选择时怎么覆盖。4.2 首屏渲染里做地理判断的代价最直接的做法是在服务端渲染首屏之前调一次地理位置接口拿到结果再输出。问题是这个调用是同步的接口慢 300 毫秒首屏就慢 300 毫秒用户感知非常明显。我们后来改成了三层策略第一层会话内固定。用户登录后第一次请求算出区域标识写进会话后续请求直接读不再调接口。这样绝大多数请求是零成本。第二层IP 段缓存。以/24IPv4或/48IPv6为粒度缓存查询结果TTL 设 24 小时。同一个办公网络里的几十个录入员共享一条缓存命中率很高。第三层异步预热。登录成功后异步触发一次查询把结果写入会话首屏不等它。如果首屏时缓存未命中先用浏览器的Accept-Language兜底渲染等异步结果回来再补一次局部刷新。三层叠加之后首屏因为地理位置判断增加的平均耗时降到了个位数毫秒。4.3 缓存与个性化的冲突怎么解这里有个经典矛盾内容个性化要求每个用户看到的可能不同CDN 缓存要求同一 URL 返回同一份内容。两者直接冲突处理不好会出现北京用户看到英文界面这种事故。我们试过Vary头效果不好因为Vary的维度是请求头而地理位置不是请求头边缘节点无法据此分桶。最终方案是用区域标识进缓存键把区域标识作为 URL 的一部分或者作为缓存键的一维让不同区域落到不同的缓存对象上。代价是缓存对象数量乘以区域数命中率会下降。所以区域粒度不能太细我们只用了大区级别几个合并后的区域而不是城市级别。语言、货币这些细节仍然在前端按用户设置覆盖两套机制并存。有个坑要提前说做缓存分桶之后务必在测试环境验证同一用户切换区域后是否拿到了正确的内容。我们曾经因为缓存键里漏了一个字段导致切换区域的用户在半小时内看到旧区域的内容排查了很久才定位到缓存层。5. 接入实现从一次调用到长期运行接口调通只要十分钟稳定运行一年是另一回事。这一节讲的是工程侧真正花时间的部分。5.1 请求层的超时、重试与并发地理位置查询是外部依赖必须假设它随时会慢、会挂、会返回格式不对的数据。我们的封装做了这几件事超时连接超时 100 毫秒读取超时 200 毫秒。超过就走降级绝不阻塞主流程。重试只对网络错误和 5xx 重试一次不重试 4xx。重试要带抖动避免同一时刻大量请求同时打过去。并发限制给这个依赖单独一个信号量限制最大并发防止它拖垮整个线程池。结果校验返回的字段做类型和范围校验国家码必须是两位字母经纬度必须在合法区间校验不过当失败处理。import time import random import requests GEO_TIMEOUT (0.1, 0.2) # 连接 100ms读取 200ms GEO_MAX_RETRY 1 def fetch_geo(ip: str, cache): hit cache.get(ip) if hit is not None: return hit last_err None for attempt in range(GEO_MAX_RETRY 1): try: resp requests.get( fhttps://api.ipdata.co/{ip}, params{api-key: GEO_KEY}, timeoutGEO_TIMEOUT, ) if resp.status_code 500: raise RuntimeError(fupstream {resp.status_code}) if resp.status_code ! 200: return None # 4xx 不重试直接降级 data resp.json() result { country: data.get(country_code), region: data.get(region), city: data.get(city), timezone: data.get(time_zone, {}).get(name), asn: data.get(asn, {}).get(asn), is_dc: bool(data.get(threat, {}).get(is_datacenter)), } if not _valid(result): return None cache.set(ip, result, ttl86400) return result except Exception as exc: last_err exc if attempt GEO_MAX_RETRY: time.sleep(random.uniform(0.02, 0.08)) # 抖动 return None上面这段是骨架真正上线还要加监控埋点调用耗时分布、失败率、降级触发次数。这三个指标任何一项异常都意味着你的风控和本地化正在退化成默认值。5.2 缓存层怎么选本地还是共享本地缓存进程内 LRU的特点是快、零网络开销缺点是每个实例各存一份命中率被实例数稀释而且实例重启后缓存全空。共享缓存集中式键值存储的特点是命中率高、结果一致缺点是多一次网络往返大概几毫秒。我们的选择是两级都用本地 LRU 挡在前面容量设几千条TTL 设 1 小时共享缓存放在后面TTL 设 24 小时。查询顺序是本地、共享、接口。这样常见 IP 几乎不产生外部调用同时保证不同实例看到的结果一致。需要提醒的是缓存粒度。我们最初按完整 IP 缓存结果发现同一办公网络的几十个 IP 各存一份浪费严重。改成按网段聚合后缓存对象数量下降了一个数量级而精度损失在业务上完全可接受——同一个/24网段落在同一个城市的概率非常高。5.3 降级拿不到数据时系统怎么办降级方案要在写代码之前定不能等出事再想。我们的规则是防护链路降级为只记录不判定。风险分缺少地理维度就按其他信号算宁可漏不可误伤。渲染链路降级为站点默认区域同时前端读Accept-Language做二次兜底。统计链路降级为归入未知桶离线任务在数据恢复后重新跑一遍补上。还有一条容易被忽略降级必须可观测。如果接口静默失败了三天业务方却完全不知道那和没做监控没区别。我们给降级次数设了告警阈值日降级率超过 1% 就发告警。6. 踩过才知道的六个坑这一节全是教训没有理论。每一条都对应一次真实的排查过程。6.1 取到的 IP 不是用户的 IP最早的实现里我们直接从请求对象读客户端地址上线后发现所有用户都被判断成同一个位置。原因很简单请求前面有转发层和 CDN 边缘节点代码读到的是边缘节点的地址。解决办法是按X-Forwarded-For从左到右找第一个可信的地址或者依赖边缘节点注入的专用头。关键是信任链要明确只有你自己控制的那几层注入的头才能信用户自己传进来的头一律不信。我们后来固定成从右往左跳过已知的可信层取第一个非可信地址这个逻辑写成了一个公共函数全站统一调用。排查那次问题的方法也值得记一下把判断结果和用户反馈的位置做对比发现全部集中在几个数据中心所在的城市基本就能确定是取错了 IP 而不是数据源不准。6.2 机房 IP 标记不等于恶意我们把数据中心 IP当作强信号用了两周然后收到一批投诉某公司的整个团队无法提交数据。查下来他们用的是云桌面办公出口 IP 天然就是机房地址。这件事的教训是网络类型标记描述的是网络不是人。它只能作为一个加分项不能作为独立的拦截条件。调整之后的规则变成了机房 IP 新账号 高频提交三者同时满足才触发限制误伤立刻消失。6.3 时区字段和地理位置字段会打架同一个 IP返回的国家可能是 A时区可能是 B。这在地理边界附近、或者运营商路由特殊配置的情况下很常见。我们最初的代码里两个字段被用在了不同的判断里导致同一个用户在两个功能里的行为不一致排查了半天才发现是数据本身内部不一致。处理原则是定一个主字段其他字段只做补充。我们定的是国家码为主时区只在渲染时间格式这一件事上使用不参与风控。凡是参与风控的字段都要在文档里标清楚优先级和冲突时的取舍。6.4 坐标不能直接算距离不可能的地理跳跃规则用的是距离而距离是从经纬度算的。最初我们用直线距离结果在跨越特定地理形态的场景里误差很大。后来改用了考虑地球曲率的公式Haversine再后来干脆把距离阈值放宽了一倍因为这条规则的目的不是精确测量而是粗筛。顺带说一句经纬度在城市级精度下的偏差可能有几十公里用它算出来的距离本身就不精确。所以阈值不要卡太死800 公里和 900 公里在实际效果上没什么区别。6.5 数据新鲜度会被忽略IP 归属会变运营商重组网段、企业更换专线、地址池重新分配这些都会让缓存里的旧数据失效。我们最初的缓存 TTL 设了 7 天结果某次运营商调整之后一批用户连续几天被判断在错误的位置。现在按用途分开设 TTL用于渲染的区域标识可以长一些24 小时到 7 天都行用于风控的网络类型标记短一些建议不超过 24 小时。如果数据源提供变更通知或者支持批量刷新那就更好定期把高频 IP 段的缓存主动失效一遍。6.6 合规提示不能靠猜有些市场对数据的存储位置、展示内容有明确要求。我们最初的实现里合规提示是按国家码硬编码的新增一个市场就要改一次代码而且很容易漏。后来改成配置驱动区域标识到提示内容的映射放在配置中心运营可以自己维护代码只负责查表。还有一个细节合规提示的展示时机。放在首屏会打断录入流程放在提交前又会显得突兀。我们的做法是放在进入某个特定功能区的时候一次性展示用户确认后记住选择不再重复弹。7. 一点点个人体会这套东西从最开始的调个接口试试到最后变成录入链路里绕不开的一环中间改了大概四五版。回头看真正有价值的经验不在于用了哪个数据源、字段有多全而在于三件事一是明确边界。地理位置数据回答的是这个请求大概从哪来不是这个人是谁。所有超出这个边界的期待最后都会变成线上问题。二是永远给误判留出口。风控规则写得再精细也会有真实用户被拦下来。有没有二次验证、有没有申诉入口、文案写得清不清楚这些非技术的部分决定了这套系统能不能长期跑下去。三是降级方案要比主流程先写。外部依赖不可用是常态不是异常。先想清楚拿不到数据时系统怎么活再想拿到数据时怎么用得更好顺序反了会返工。最后再分享一个我觉得挺实用的小做法给地理位置相关的判断都打上统一的日志标签字段包括原始 IP、解析结果、命中规则、最终得分、采取的动作。线上出现任何争议把这条日志捞出来就能复盘不用靠猜。这套日志后来还意外成了产品侧做区域分析的数据源算是顺手捡的。