简介基于PHP开发的IP探针工具面向网站开发者、运维人员及对访客位置查询感兴趣的IT从业者。程序部署后可自动捕获访问者IP地址结合内置地理数据库完成定位并生成可分享的探针链接对方点击即可获知其大致所在区域适用于访客统计、安全跟踪、位置验证等场景。压缩包共一百五十六个文件以四十个PHP功能脚本为核心辅以二十三个JavaScript交互文件、五个CSS样式文件、两个SQL数据库初始化脚本另有七十五个GIF动图用于界面演示整体包体仅七百一十五KB轻量易部署。目前已有四千六百六十一人学习下载社区验证可用。解压后目录结构清晰包含完整源码、配置说明、数据库脚本以及前端静态资源支持二次开发与自定义界面可帮助读者快速搭建属于自己的IP查询与定位服务平台。1. 一个IP探针该回答哪三个问题查询、定位与归属一个IP探针做得顺手不顺手第一分钟就能看出来丢一个IP过去探针链接把归属地、运营商、经纬度、更新时间原样吐回来状态码清晰缺参数和非法地址都有独立返回做得不顺手的返回一坨字段还得人眼猜含义。这篇笔记就按IP探针、IP查询、定位三个动作往下拆讲清楚数据从哪来、链接怎么设计、最小服务怎么写以及定位精度到底能信多少。适合准备做登录风控、访问地域统计或者只是想给内部加一个IP工具箱的开发者。文中代码是一个可落地的简化版直接照着改就能放到自己的服务里。2. IP探针的数据源与链接设计选型先定代码才会少返工2.1 三种数据来源怎么选离线库、查询API与自建交换做IP查询第一个问题不是写代码而是数据从哪来。市面上能落地的方案大致三种离线IP库、查询API、自建数据交换。三者不是同一层的东西选错后面全得返工。离线IP库是一份按IP段组织的文本或数据库文件常见格式是“起始IP 结束IP 国家 省份 城市 运营商 纬度 经度”社区和商业机构都有维护。它的优点是没有配额局域网内部随便查响应时间完全由自己控制缺点是更新需要自己盯文件里偶尔混入编码不一致的脏数据精度也取决于发布方。对日均查询量不大、预算有限的团队这是最稳的起步方案。查询API则是把IP发到一个远程地址对方把归属和定位信息以JSON返回。字段往往更全有的还能给风险标记、邮编和时区接入成本低不用维护本地库。代价是按量计费有QPS配额而且每次查询都是一次外网往返内网服务直接依赖它的可用性。适合业务刚起步、不想花精力维护数据文件的场景但要给自己留好降级方案。自建数据交换听起来最“硬核”实际是三者里唯一不推荐个人去碰的。它需要对接多家数据源做实时的BGP路由与地址分配信息整理网络设备、清洗脚本、质量监控一样都不能少只有体量到一定程度的平台才划算。个人开发者如果选这条路线大概率把时间耗在数据处理而不是业务上。选型我一般按三个问题卡日均调用量是几百还是几百万业务能不能容忍一次外网依赖故障定位要城市级还是区县级调用量小、不能容忍外网依赖就离线库字段要求多、愿意接受配额就API两个都不满足先做缓存和分级处理而不是急着换数据源。方案精度级别成本并发限制主要维护成本离线IP库城市级为主一次性获取成本无定期更新数据文件查询API城市级到区县级按查询次数计费有QPS配额接口降级与监控自建数据交换取决于数据源采集和存储成本很高无链路与数据源维护2.2 探针链接的URL长什么样路径传参与查询传参的选择探针链接就是IP探针服务对外暴露的URL。设计上有两种风格路径式例如http://host/api/v1/ip/192.0.2.1查询参数式例如http://host/api/v1/ip?ip192.0.2.1。路径式符合“IP是资源”的语义对HTTP缓存比较友好但携带额外参数时不方便扩展查询参数式更像一个工具接口加format、callback之类的参数很容易也便于在日志里直接看到完整查询条件。我自己的习惯是对外只暴露查询参数式统一为http://host/api/v1/ip?ip目标IPformatjson|text。原因很简单后续要加批量查询参数式只需把ip改成逗号分隔要做JSONP加一个callback参数就行。路径式在这一点上改起来牵扯路由规则动静更大。有一点算我个人的偏见尽量别给探针链接做短链接。短链转发层会掩盖真实接口地址出了问题排查跨度大而且IP查询本身就是程序调用的活不是给人手输的短链带来的便利远小于它引入的定位难度。探针链接还要考虑访问入口的归属。常见做法是把它挂在网关后面网关做鉴权、限流、缓存内部再转发给真正的查询服务。这样探针链接对外是一个地址对内可以随时换数据源而不用动调用方。2.3 响应协议先定好状态码、经纬度、更新时间的字段约定接口联调返工最频繁的地方就是字段口径没定清楚。IP探针的响应协议我建议在写代码前先把这些约定死。状态码用数字不要用布尔值。0表示成功1表示缺参数2表示IP格式非法3表示查无记录。这样调用方可以直接用整数开关而不是在前端解析字符串提示语。经纬度统一用十进制WGS84缺省时置null不要为了“好看”给0.0(0,0)在真实地图上是有明确含义的会让前端打点打到奇怪的海域。更新时间统一ISO8601的UTC格式响应里至少带一个数据版本或updated_at当两次查询结果不一致时这是对账的依据。字段命名也尽量一次到位。顶层字段用country、region、city、isp、lat、lon别用address、pos这种含糊名。country存国家名称还是国家码要明确我倾向于两个都给country放名称country_code放两字码。运营商名称一定是数据源给的原文不要自己翻译或缩写否则后面做统计时你会发现同样一个运营商在库里出现了七八个变体。3. 用Python把IP探针服务跑起来建库、查询、拼链接3.1 建一张IP段表整数区间存储与复合索引拿到离线IP库后别急着查先把文本数据转成一个规整的数据库表。存储上最通用的是整数区间把IP字符串转成整数用start_ip和end_ip两个整数表示一个段查询就是一次区间包含判断。这样做的好处是哪怕库文件里有“1.2.3.4 - 1.2.3.10”这种不规整的写法导入时也能统一处理。建表SQL可以这样写CREATE TABLE IF NOT EXISTS ip_segments_v4 ( start_ip INTEGER NOT NULL, end_ip INTEGER NOT NULL, country TEXT, region TEXT, city TEXT, isp TEXT, lat REAL, lon REAL, updated_at TEXT ); CREATE INDEX IF NOT EXISTS idx_v4_start_end ON ip_segments_v4(start_ip, end_ip);坐标和运营商字段在SQLite里用REAL和TEXT就够了。索引一定要建在(start_ip, end_ip)上没有这个索引查询量一上来就退化成全表扫描。导入时用ipaddress.ip_address(ip_str)把字符串转成整数IPv6单独建一张ip_segments_v6表逻辑完全相同只是整数取值范围更大。表建好之后查询逻辑就是一个参数化SQL避免直接拼接字符串import sqlite3 def lookup(ip_int, db_pathip_data.db): conn sqlite3.connect(db_path) cur conn.cursor() cur.execute( SELECT country, region, city, isp, lat, lon, updated_at FROM ip_segments_v4 WHERE start_ip ? AND end_ip ? ORDER BY (end_ip - start_ip) ASC LIMIT 1, (ip_int, ip_int), ) row cur.fetchone() conn.close() return row这里ORDER BY (end_ip - start_ip)是处理段重叠的关键。有些IP库在更新时会把新旧段同时保留重叠状态下按段长度升序优先命中最短的段等于自动选择更新更精确的那一层。段长度算出来是负数的情况不用考虑因为start_ip ? AND end_ip ?已经把段长度约束在非负区间。3.2 查询接口与探针链接拼装从curl到前端fetch服务层用一个轻量Web框架把查询包成HTTP接口。我这里以Flask为例结构很简单一个路由接收参数调lookup()再按约定返回JSON。from flask import Flask, request, jsonify import ipaddress app Flask(__name__) app.route(/api/v1/ip) def ip_probe(): ip_str request.args.get(ip, ).strip() if not ip_str: return jsonify({status: 1, message: missing ip}), 400 try: ip_int int(ipaddress.ip_address(ip_str)) except ValueError: return jsonify({status: 2, message: invalid ip}), 400 row lookup(ip_int) if row is None: return jsonify({status: 3, message: not found, ip: ip_str}) country, region, city, isp, lat, lon, updated_at row return jsonify({ status: 0, ip: ip_str, country: country, region: region, city: city, isp: isp, lat: lat, lon: lon, updated_at: updated_at, }) if __name__ __main__: app.run(host0.0.0.0, port8000)ipaddress.ip_address()会在内部判断IPv4和IPv6真实项目中IPv6走单独的查询表这里先不展开。request.args.get(ip, ).strip()去掉首尾空格避免前端把换行符带进来导致转换失败。返回status1和status2时带上HTTP 400让网关层的限流和监控能直接按状态码识别异常请求。服务跑起来后探针链接的拼装就是标准的查询参数拼接。命令行验证我用curlcurl -G http://127.0.0.1:8000/api/v1/ip \ --data-urlencode ip192.0.2.1 \ --data-urlencode formatjson--data-urlencode会做URL编码防止IP字符串里混入不可见字符。前端调用时直接用fetch(/api/v1/ip?ip encodeURIComponent(ip))不需要另外引SDK。探针链接至此就跑通了一个URL带ip参数返回ISO风格的JSON。3.3 返回字段怎么给前端地图打点与风控的取数差异同样一份返回不同使用方取字段的侧重点完全不一样。地图打点要的是经纬度但城市级坐标不能无限放大前端拿到lat和lon只用来定位到城市范围不应该画到街区精度。地域统计看country、region、city海外用户经常只有国家码有值统计脚本要提前接受字段缺失。业务场景重点关注字段注意点地图展示lat, lon城市级坐标不要做连续精细轨迹登录风控isp, updated_at, statusIDC段要降权处理地域统计country, region, city海外记录可能只有国家日志装饰ip, isp优先展示原始IP字符串风控场景还建议把isp和status一起透传。status0只代表“查到了一条记录”不代表“定位可信”真正判断时要结合ISP名称里的关键字做降权比如匹配到IDC、数据中心、云计算字样就说明这是机房出口而非个人宽带。探针链接如果要做批量查询参数ip用逗号分隔后端ip_str.split(,)之后循环查再按每个IP的status单独返回。批量场景下响应里一定要带上每个查询对应的ip字段否则前端无法对齐结果。4. IP定位的精度边界经纬度能信几成城市级兜底怎么补4.1 注册地、观测地与业务地IP定位的三种口径IP定位的“不准”很多时候不是数据源错而是口径混了。同一个IP至少有三层含义注册地是IP地址被分配时登记的机构地址观测地是这次流量从哪个物理出口出去业务地是用户自己填写的收货地址或办公地址。三者可以相差千里。一个在北方的用户访问海外服务中间流量经过某数据中心的出口节点IP库查出来的是数据中心所在城市而不是用户所在城市。这不是库的错误是观测口径本身偏差。做定位功能前先问团队你们要的是注册地、观测地还是用户声明地三者混用越往后越说不清。数据源本身的更新滞后也是偏差源头。IP段在运营商之间转让、BGP路由变更反映到IP库需要时间有些库半年不更查出来的城市还停留在上一轮归属。所以定位功能上线前先看一眼updated_at如果库文件超过三个月没更新别急着做区县级展示。4.2 坐标兜底与城市级判定把可疑经纬度修到可用经纬度字段是最容易“假得难看”的地方。有些库的经纬度是IP段中心点位置落在荒郊野岭有些库把0.0当缺省值。直接透传给前端地图上就是一片漂移点。我一般会在导入阶段算一份“城市兜底坐标”查询时发现当前段坐标可疑就用兜底替代。import statistics def build_city_fallback(db_pathip_data.db): conn sqlite3.connect(db_path) rows conn.execute( SELECT city, lat, lon FROM ip_segments_v4 WHERE lat IS NOT NULL AND lon IS NOT NULL ).fetchall() conn.close() groups {} for city, lat, lon in rows: if city is None or (abs(lat) 0.01 and abs(lon) 0.01): continue groups.setdefault(city, []).append((lat, lon)) fallback {} for city, coords in groups.items(): fallback[city] ( statistics.median([c[0] for c in coords]), statistics.median([c[1] for c in coords]), ) return fallback这个逻辑的核心是用中位数而不是平均数单个段坐标飘得再远也不会把城市中心拉走。查询时先判断原始坐标是否为None、是否接近(0, 0)再决定要不要用兜底。城市级判定和坐标是两个维度坐标兜底管展示城市字段管统计。业务上如果只要“用户在哪座城市”直接信任city字段并归一化掉“XX市”和“XX”这种格式差异比纠结经纬度更有价值。4.3 什么时候该退让IDC、移动网络与动态IP的置信度定位的置信度应该跟着IP类型走而不是对所有IP一视同仁。IDC和云计算出口的IP查出来的是机房位置访问者可以来自任何地方这类结果展示给运维看没问题但拿去风控就容易误伤。移动网络是另一个典型场景一个省级出口池可能承载全省流量IP库最多给到省细分到市就开始猜。遇到ISP字段里带“移动”或“联通”关键字的我一般主动降级到省级展示不强行精确。动态IP则是“过期”最快的数据。普通宽带的IP会周期性重拨变化今天落在A市明天落在相邻的B市这属于正常现象不是数据源坏了。给存储层做“IP到城市”的强绑定关系时一定要带上时间戳超过一个租约周期就失效。定位的边界清楚之后探针能回答的问题也就清楚了它告诉你是哪个机构持有这个段、出口大概在哪里至于屏幕前坐着谁那是另一个层级的事。5. IP探针落地避坑同一IP两次不一致、乱码与接口被刷5.1 返回乱码与中文变问号编码不一致的排查路径现象探针返回的JSON里中文城市名变成\uXXXX转义或者直接显示问号。前端拿到数据后地图标注全是乱码。原因离线IP库的文本文件编码不统一。同一个文件里可能混着UTF-8和GBK有些还带BOM头Python默认用UTF-8读文件时就会把GBK字节读出乱码。我踩过一次之后养成一个习惯凡是新拿到的库文件第一件事不是导入而是用file命令看编码再决定用什么方式读。解决读取时用encodingutf-8-sig同时对所有入库字符串做一次str.encode(utf-8).decode(utf-8)的强制校验解析失败的记录直接丢弃并单独输出到日志。宁可少导几条脏数据也不能让脏数据污染整张表。5.2 同一个IP两次查询结果不同库版本与出口变化谁说了算现象同一IP上午查是A市下午查是B市调用方来问是不是探针坏了。原因两类情况。一类是离线库更新换版新旧数据在重叠区间里结果不同另一类是出口节点的BGP路由变化让同一个IP在两次查询时命中了不同的物理出口。严格说后者不算数据错误而是网络现实。解决探针每次响应都带updated_at和数据版本号调用方看到结果变化先查版本。同时在服务层加一层结果缓存缓存有效期内的第一次查询结果直接固定避免同一次业务会话里前后不一致。库版本切换时提前清理缓存而不是等数据文件替换完还在用旧缓存。5.3 高并发下探针响应劣化缺索引与无缓存的双重问题现象接口平时几毫秒返回流量压上来之后变成几百毫秒数据库CPU先跑满。原因最常见的是IP段表没建索引查询退化成全表扫描另一个是每个请求都去读库明明同一批IP被反复查。这两件事叠加并发稍微上来就直接劣化。解决建(start_ip, end_ip)复合索引这是最省事的一步。然后加一层TTL内存缓存热点IP在缓存期内直接返回不用每次都走SQL。索引建没建压测数字能差几十倍这是血泪经验。5.4 探针链接被刷与滥用鉴权限流的三种做法现象日志里出现大量陌生IP对探针发起查询频率远超业务正常水平带宽和数据库同时告警。原因探针链接裸奔没有鉴权任何限制。IP库不花钱的还好最多占点带宽用按量计费的API被刷一晚就是一笔不小的成本。解决至少做三层。第一层在网关加访问Key调用方必须带固定请求头或签名第二层按调用方IP限流超过每秒配额直接返回429第三层把探针链接只暴露给内网或经过统一API网关不直接对公网开放。日志里发现异常频率的调用方先封IP再排查原因。6. 缓存、回归与一分钟自检让IP探针长期可维护查询接口第一版跑通后我会把三件事补上内存缓存、样本回归、定时自检。缓存放在服务入口TTL设300秒保证数据源更新后最多延迟5分钟生效也让重复查询不再打穿数据库。回归校验是最容易被省掉、但长期价值最高的一步。维护一个样本文件里面放若干条已知IP和它们期望的归属地每次数据源更新后跑一遍看哪些结论变了。import json import sys import urllib.request PROBE_URL http://127.0.0.1:8000/api/v1/ip with open(probe_cases.json, encodingutf-8) as f: cases json.load(f) failed 0 for case in cases: url PROBE_URL ?ip case[ip] with urllib.request.urlopen(url, timeout3) as resp: data json.loads(resp.read()) if case.get(city) and data.get(city) ! case[city]: failed 1 print(fFAIL {case[ip]}: city {data.get(city)} ! {case[city]}) elif case.get(region) and data.get(region) ! case[region]: failed 1 print(fFAIL {case[ip]}: region {data.get(region)} ! {case[region]}) print(ftotal {len(cases)}, failed {failed}) sys.exit(1 if failed else 0)样本文件里维护二十来条记录就够了覆盖本网段、IDC段、海外段和私网段。私网地址可以预期返回“查无记录”如果哪次改成命中了一个奇怪的城市说明库里的保留段出了脏数据。断言只到城市级不去卡经纬度因为坐标是段中心点卡太死只会制造噪音。把自检脚本挂成定时任务每天跑一次数据源更新后第一时间看出偏差而不是等调用方来投诉才发现。我自己在模拟项目X里一直是这么做的新库文件导入后先跑一轮回归再切换流量确保探针长期可维护。希望帮到你。本文还有配套的精品资源点击获取
