网站 IP 定位风控怎么做：访客归属地、异常访问和接口封装

很多网站第一次接 IP 归属地，目标往往很简单：在评论区显示用户来自哪里，或者在后台统计访问地域。这个需求本身没有问题，但如果只停留在展示层，就低估了 IP 定位在业务系统里的价值。真正有用的 IP 定位，应该进入请求上下文，给风控、运营、客服、内容策略和安全审计提供统一输入。

举个常见场景：一个 SaaS 后台账号长期在杭州办公网络登录，某天凌晨突然从境外云主机出口发起密码修改；一个电商注册页在 10 分钟内收到大量来自同一运营商出口的手机号注册请求；一个内容平台需要在发帖、评论、举报和后台审核里保留发布时属地。这些问题单靠 IP 定位都不能直接定性，但没有 IP 归属地，风控系统会少掉一类非常基础的环境信号。

因此，本文讨论的不是“如何查到某个 IP 在哪里”这么简单，而是网站和业务系统如何把 IP 定位接成一套可复用的工程能力：在哪里取 IP，如何避免伪造头，怎么缓存，怎么形成 geo_context，哪些场景可以用，哪些场景不能滥用，以及第三方接口应该放在整体架构的哪个位置。

先把边界说清楚：IP 定位不是精准定位

IP 归属地通常适合做国家、省份、城市、运营商、网络类型这类粗粒度判断，不应该被当成 GPS、门店定位或用户真实住址。移动网络、企业代理、家庭宽带出口、云服务器、VPN、CDN、运营商 NAT 都可能让 IP 归属地和用户实际位置存在偏差。如果业务把“城市不一致”直接等同于“异常用户”，误杀会非常高。

更稳妥的理解方式是：IP 归属地是风控特征，不是最终裁判。它可以参与评分、提示、限流、二次验证和人工复核，但不建议单独作为封禁、拒付、拒绝登录的唯一依据。尤其是 B2B、远程办公、跨境用户和移动端场景，IP 地域漂移非常常见，策略必须给正常变化留出空间。

网站 IP 风控的合理目标是什么

第一类目标是访问环境识别。系统需要知道请求来自哪个国家、省市、运营商，是否来自云机房、代理出口或高风险网络段。这个信息主要给登录保护、注册防刷、接口限流和后台安全审计使用。

第二类目标是业务上下文补全。评论区属地展示、订单风控、客服排障、活动页地域分流、内容合规策略，都需要一个标准化的地域字段。这个字段最好在请求入口就生成，而不是每个业务服务临时去查。

第三类目标是运营分析。运营同学关心的是访问来源地区、异常流量分布、重点城市转化差异、某些区域是否出现集中投诉。IP 定位如果只在前端展示，不落库、不聚合，就很难支持这些分析。

第一步不是调接口，而是正确拿到客户端 IP

很多风控系统出问题，不是 IP 定位接口不准，而是系统一开始拿到的就不是用户真实出口 IP。经过 CDN、WAF、反向代理和负载均衡之后，后端看到的 remote_addr 可能只是上一层代理地址。此时如果直接拿 remote_addr 去查归属地，得到的通常是机房或代理节点位置，风控规则会被污染。

常见做法是只信任来自自家 CDN、WAF、网关和负载均衡的转发头。例如在可信代理链路内解析 X-Forwarded-For、X-Real-IP、CF-Connecting-IP 等字段；如果请求不是来自可信代理，就不要随便相信客户端自己带的 X-Forwarded-For，因为它可以伪造。取 IP 这一步建议封装成统一组件，所有业务服务只消费标准结果。

function getClientIp(req, trustedProxyIps) {
  const remoteIp = req.socket && req.socket.remoteAddress;
  const isTrustedProxy = trustedProxyIps.includes(remoteIp);

  if (!isTrustedProxy) {
    return remoteIp;
  }

  const forwarded = req.headers['x-forwarded-for'];
  if (forwarded) {
    const list = String(forwarded)
      .split(',')
      .map((item) => item.trim())
      .filter(Boolean);
    return list[0] || remoteIp;
  }

  return req.headers['x-real-ip'] || remoteIp;
}

第二步是把结果标准化成 geo_context

不要让每个业务系统直接依赖第三方接口的原始返回。比较稳妥的方式，是在内部定义一个统一的 geo_context，例如 country、province、city、isp、ip_version、source、confidence、queried_at、cache_hit。业务系统只看内部字段，底层接口来源可以后续切换。

这样做有两个好处。第一，风控规则不会被供应商字段名绑死。第二，当接口异常、缓存命中、离线库兜底或返回空字段时，系统仍然能用统一方式记录状态。风控最怕的是静默失败：接口超时了没人知道，字段为空却被当成正常城市，最后规则误判。

CREATE TABLE request_geo_context (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  request_id VARCHAR(64) NOT NULL,
  user_id BIGINT NULL,
  client_ip VARCHAR(64) NOT NULL,
  country VARCHAR(64) NULL,
  province VARCHAR(64) NULL,
  city VARCHAR(64) NULL,
  isp VARCHAR(64) NULL,
  source VARCHAR(32) NOT NULL,
  cache_hit TINYINT DEFAULT 0,
  created_at DATETIME NOT NULL,
  INDEX idx_user_time (user_id, created_at),
  INDEX idx_ip_time (client_ip, created_at),
  INDEX idx_city_time (city, created_at)
);

第三步才是接入 IP 定位接口，并设计缓存

IP 归属地数据不适合每次请求都实时查。高频访问场景下，应该把定位查询放在网关、中间层或异步任务里，并加缓存。常见缓存键是 client_ip，缓存时间可以按业务风险调整：普通页面访问缓存 1 到 24 小时都可以，登录、支付、后台敏感操作可以设置更短 TTL 或强制刷新。

缓存不是为了省一点接口费这么简单。它还能降低接口波动对业务链路的影响。风控系统不应该因为一个外部接口短暂超时，就阻塞所有登录请求。更合理的是：接口正常时写入最新 geo_context；接口失败时使用短期缓存或降级为空上下文，同时把异常写入监控。

风控规则应该做评分，不要做单点拦截

一个可落地的 IP 风控规则，通常不是“境外 IP 直接拦截”这么粗。更常见的是把 IP 地域变化、设备变化、登录时间、失败次数、账号历史、手机号归属地、操作敏感度组合成分数。低风险直接放行，中风险触发短信或邮箱二次验证，高风险进入人工复核或短期限流。

例如后台管理员从陌生城市登录，不一定要直接拒绝，但可以要求二次验证；普通用户从新城市浏览商品，大多数情况不需要干预；同一 IP 段短时间注册大量账号，则应进入注册防刷规则。IP 定位只有和具体动作结合，才会变成有效风控，而不是制造误判的静态标签。

function scoreIpRisk(ctx) {
  let score = 0;

  if (ctx.isNewCountry) score += 40;
  if (ctx.isNewProvince) score += 15;
  if (ctx.isCloudProviderIp) score += 25;
  if (ctx.failedLoginCountLastHour >= 5) score += 30;
  if (ctx.deviceChanged) score += 20;
  if (ctx.operation === 'change_password') score += 20;

  if (score >= 80) return 'review_or_block';
  if (score >= 50) return 'step_up_verify';
  if (score >= 30) return 'rate_limit';
  return 'allow';
}

哪些场景适合用 IP 定位

登录保护适合用 IP 定位。它可以帮助识别异地登录、异常时段登录、云机房登录和高风险国家地区访问。但动作建议以二次验证、登录提醒和安全审计为主，不要轻易一刀切拒绝。

注册防刷适合用 IP 定位。注册接口可以结合 IP 段、运营商、城市、手机号归属地、设备指纹和验证码失败次数做频控。这里 IP 定位不是为了判断用户真实身份，而是为了识别批量化请求模式。

内容平台适合用 IP 定位。发帖、评论、举报、审核记录都可以保留发布时属地，用于内容治理和透明展示。但属地展示要注意产品文案，避免让用户误以为系统能拿到精确位置。

运营报表也适合用 IP 定位。网站可以按城市、运营商、访问来源和异常流量分布看转化差异，帮助判断投流质量、攻击来源和重点区域表现。

接口选型：官方、离线库和第三方 API 怎么取舍

IP 定位不像快递那样有大量官方承运商接口，但仍然存在几类方案：自建离线库、采购专业数据、使用云厂商或第三方 API。离线库查询快、成本可控，但要处理授权、更新、准确率回归和多节点分发。专业数据源字段丰富，适合更高预算和更强精度要求的场景。第三方 API 则适合直接接入生产业务，用标准接口减少数据更新和供应商维护成本。

如果业务系统需要快速把 IP 归属地接进登录、注册、内容属地和运营报表，我倾向直接使用标准化第三方 API，把精力放在内部工程封装上：取 IP、查归属地、标准化 geo_context、缓存、风控评分、日志审计、调用监控和成本治理。华霆数联的全球 IP 定位服务可以作为这类标准 RESTful API 接入方案之一，适合放在生产系统的入口上下文层，支撑登录保护、注册防刷、内容属地展示和运营分析这类高频场景。

上线前一定要做的检查

第一，确认所有入口都使用同一个 IP 提取规则，尤其是网页、App、管理后台、开放 API 和回调接口。第二，确认代理头只在可信代理链路内使用。第三，确认接口超时不会阻塞核心链路。第四，确认缓存和降级策略有监控。第五，确认风控动作可以解释、可回溯、可人工干预。

最终判断这套系统是否有价值，不是看页面上有没有显示属地，而是看它是否降低了异常注册、盗号风险、客服排障成本和运营盲区。IP 定位是一个很小的接口，但如果放在正确的位置，它会成为网站风控和业务上下文里非常稳定的一块基础设施。

工具对接实操：从选型到上线

curl -X POST "https://ai.huating-ai.cn/api/758" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "ip": "203.0.113.10"
}'

const API_KEY = process.env.HUATING_API_KEY;
const API_URL = "https://ai.huating-ai.cn/api/758";

if (!API_KEY) {
  throw new Error("请先设置环境变量 HUATING_API_KEY");
}

async function queryIpLocation(ip) {
  const payload = {
    ip
  };

  const res = await fetch(API_URL, {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify(payload)
  });

  if (!res.ok) {
    throw new Error(`HTTP ${res.status}`);
  }

  const data = await res.json();
  if (data.code && data.code !== 200) {
    throw new Error(data.message || "API 调用失败");
  }

  return data.data || data;
}

queryIpLocation("203.0.113.10").then(console.log).catch(console.error);