99 IP99
私有化部署

Pulse 私有化

我方把全量风险情报交到贵方机器上，贵方自己 selfhost、自己查。 接口与公网 API 完全一致，但查询全程在贵方内网完成—— 连「贵方查过哪些 IP」我方都不知道。

另一个产品是 潮汐 Tide（接入流量，找出正在发生的攻击）· 看两者对比

它解决的问题

贵方已经想清楚要在风控链路的哪一步查 IP——登录、注册、下单、提现。 唯一的障碍是那个 IP 不能发出去。

可能是合规不允许，也可能是更实际的顾虑：走公网 API 时，我方看得见贵方查了哪些 IP、什么时候查、多频繁。查询本身就是数据—— 它会暴露贵方的用户构成、风控节奏，以及正在调查什么。私有化把这条也切断。

传统 IP 库给的是标签；我们给的是一个会过期的判断

同一个 IP，三天前是代理，今天还是吗？传统情报库的答案是「是」——标签一旦打上就长期有效。我们的答案取决于证据距今多久：过了该风险类型的时效窗，分数直接归零，不是缓降。

下图曲线取自产品实际在用的定标表，不是示意。纵轴是分数，横轴是证据距今时长（对数刻度）。

证据新鲜度衰减 横轴是证据距今多久（对数刻度），纵轴是分数。秒拨在 6 小时、代理在 24 小时、VPN 在 7 天处直接归零；作为对照，传统静态标签保持恒定高分不随时间变化。 0 25 50 75 100 1 小时 6 小时 24 小时 7 天 传统静态标签：一次标记，长期有效 秒拨 · 6 小时归零 代理 · 24 小时归零 VPN · 7 天归零 分数

所以 0 分的意思是「没有可核验的证据」，不是「安全」

这个区别很要紧：把 0 分当成「已排除」，等于把我方的观测盲区当成贵方的安全区。 我方能给的判断只覆盖「有有效证据的那部分流量」——实测在客户真实流量上， 有记录的 IP 占 18%–69%（随流量构成差异很大），其中当下仍能出分的占 35%–46%。

传统静态标签没有这个问题，因为它从不承认自己过期—— 代价是三个月前的一次标记，今天仍在给贵方的用户打高分。哪种更危险，取决于贵方是怕漏还是怕误伤； 我方选择把时效讲明白，让贵方自己定阈值。

查询本身就是数据

走公网 API 时，我方看得见贵方查了哪些 IP、什么时候查、多频繁。那不是「元数据」——它直接暴露贵方的用户构成、风控节奏，以及正在调查什么。

私有化之后，查询只在贵方内网内完成；我方与贵方之间只剩一条方向相反的连接：我方向贵方推情报。

走公网 API 与私有化的数据流向对比 走公网 API 时，每次查询都到达我方，我方因此拥有你查过哪些 IP、何时查、多频繁的记录。私有化后查询只在你的内网内完成，我方只向你推送对所有客户一样的全量情报包，不携带你关心哪些 IP 的信息。 走公网 API 贵方风控系统 每次查询 我方服务 我方这边因此有了： 查过哪些 IP · 何时 · 多频繁 私有化 贵方内网 贵方风控系统 查询 贵方的实例 我方服务 全量情报包 对所有客户一样 查询不出内网 —— 我方没有这条请求，自然也没有这份记录

它包含什么

不是「让贵方通过一条专线来查我方」，而是把整份情报交给贵方，贵方自己 selfhost。 查询打在贵方自己的实例上，我方这边不产生任何记录。

全量情报，交到贵方机器上

不是抽样、不是按需回源。当前实测 2,216 万条风险画像、 约 3.76 GB，整份落在贵方的存储里，之后按增量持续更新。

查询记录不存在于我方

GET /pulse/v1/ip/{ip} 打在贵方自己的实例上。 我方没有这条请求，自然也就没有「贵方查过哪些 IP、什么时候查、查得多频繁」这份记录。

可以完全不连公网

内网环境走离线介质导入：tide-adm mirror-sync -import。 情报包与许可绑定，整包校验通过才写库，中途失败拿同一个包重来即可。 全程贵方机器不需要有出网能力。

接口与公网 Pulse 一致

返回字段与公网 ip99.com/pulse/v1/ip/{ip} 同一套（分数、建议、证据、评分时刻）， 本地实例额外给出完整证据字段与资源池句柄。已经接了公网 Pulse 的把域名换掉即可； 接的是老版 /v1/ip 画像接口的，两者返回结构不同，请按随包接口文档接一次。 另有 /pulse/v1/replay/{ip} 按贵方给的时间戳出分， 用来复盘「当时如果接了会不会拦住」。

三件我方要主动说清楚的事

一、连公网同步时，我方仍然看不到贵方查了什么。 唯一的对外连接是贵方来拉情报包，而那个包是全量的、对所有客户一样， 不携带任何「贵方关心哪些 IP」的信息。选离线介质则连这条连接也没有。

二、情报会过期，而且是静默的。 评分随证据与评分时刻的距离衰减。实测同一批 192 个 IP，镜像停更四天后从全部 ≥50 分变成全部 0 分——服务一切正常、查询照常返回， 只是检出率归零。所以 healthz 会直接给出最新证据距今多久， 控制台顶部也会写明。请按这个字段告警，不要只看服务活着没有。

三、我方不交付上游归属。 风险画像给全量，但「这条证据来自哪家供应商」是我方的商业信息， 交付里只给匿名簇句柄。贵方拿到的是「这些 IP 属于同一个资源池」， 不是那个资源池叫什么名字。

部署流程

比 Tide 简单得多：不需要接入流量，装完配好镜像同步就能查。

  1. 装上并起服务

    解包、填一份配置（许可名、Redis 地址）、装 systemd 单元、探活。 与 Tide 同一套二进制和同一份部署指南。

  2. 导入情报镜像

    有公网：装定时同步单元，之后按增量自动更新。
    无公网：离线介质导入 tide-adm mirror-sync -import。 包与许可绑定，整包校验通过才写库，中途失败拿同一个包重来即可。

  3. 把地址改过来

    已经接了公网 Pulse 接口的话，把 ip99.com 换成本地实例即可，字段一致。 接的是 /v1/ip 画像接口的，返回结构不同；没接过的，都按随包的接口文档接一次。

  4. 把镜像新鲜度接进监控

    healthz 给出最新证据距今多久，/metrics 也暴露同一个值。 请按这个字段告警，不要只看服务活着没有—— 镜像停更时服务完全正常，只是检出率在降。

参考规格

规格由情报规模决定，不随贵方的查询量走。

情报条数2,216 万条（实测全量）
镜像内存3.76 GB（192 字节/条），建议备 5–6 GB
吞吐约 850 QPS/核，P99 27 ms
对外连接仅情报同步一条；选离线介质则为零

联系销售 · 获取报价

单独定价，价格取决于部署规模与接入范围，所以不在页面上标价—— 留下需求，我方按贵方的实际情况给一份报价与部署方案。

填写需求，获取报价
产品交付形态、系统要求与验收标准均随交付包提供。 如需先了解技术细节，可在申请时注明，我们会在沟通时提供部署指南与验收标准全文。