开放数据
七个 IP 信誉源在哪些地方一致，在哪些地方打架
IPOK 线上查询的滚动聚合计数：各信誉源的覆盖率、标记率、两两分歧率，以及留一法一致率——把被测源从参照里拿掉，不再拿含它自己一票的最终判定当尺子。机房 IP 与住宅 IP 分开统计，因为共识规则对两者本来就用不同阈值。只公开脱敏计数，不含任何 IP，附 JSON 与 CSV 下载。
混合 API 查询样本：包含通过准入的页面、App、扩展与公开 API 请求。请求头不证明真人身份；历史计数未区分已验证用户与自动化，因此不能当作真人用户量或准确率。
生成于 2026-10-24T11:58:26.470Z · 缓存 30 分钟 · 分母不足 30 的比率不显示。
已知缺口 · 2026-09-22 → 2026-09-28（UTC）
IPHub 或 vpnapi.io 有应答的查询没有落库：统计表的列约束按 8 个源设计，装不下它们的签名，写入静默失败。
这段日期里显式查询、机房 IP、可疑 IP 被系统性少计：IPHub 与 vpnapi.io 覆盖率读作 0，ipapi.is、Scamalytics 的覆盖率与判可疑占比都比真实值低。丢掉的观测无法补回，跨窗口比较请剔除这几天。
覆盖率、标记率、一致率
覆盖率 = 该源在多少比例的查询里给出了结论。标记率 = 在它给出的结论中，带风险标记的占比。最后一列问的是更窄的问题：该源的标记与 IPOK 发布的分数（risk ≥ 50）方向是否一致。而那个分数是加权合成的、里面本来就有这个源自己的一票——所以这一列标着「含自指」：覆盖率接近满格的源，有一部分是在跟自己比。
它前面三列就是为了拆掉这个循环。对每个源，我们取它在同一次查询里的「其他源」——那次给出了结论的所有别家，再去掉 ip-api（它的 proxy 布尔值是推导出来的，本站的共识规则里也从不算独立一票）。被佐证率：该源打了标记的那些查询里，其他源至少也有一家打了标记的占比。捕获率：其他源至少 2 家打了标记、而该源也在场的那些查询里，它也打了标记的占比。留一法一致率：在它给出结论的查询里，它的标记与「其他源至少 2 家打了标记」这个朴素标签相同的占比。被测的源永远不在自己的参照里。但这三个数仍然不是准确率：其他源可以一起错，而只在部分流量上被调用的源，分母更小、构成也不一样。
| 数据源 | 证据层级 | 覆盖率 | 标记率 | 直报 proxy/vpn | 被佐证率 | 捕获率 | 留一法一致率 | 与最终判定一致（含自指） | 有结论次数 |
|---|---|---|---|---|---|---|---|---|---|
| ip-api | 推断 | 98.1% | 37.6% | 37.6% | 85.9% | 51.7% | 64.1% | 63.7% | 77,470 |
| IPQS休眠 · 无 key | 推断 | 0.0% | — | — | — | — | — | — | 0 |
| Scamalytics | 来源报告 | 6.5% | 1.6% | 1.6% | 100.0% | 4.2% | 64.2% | 58.6% | 5,093 |
| proxycheck | 来源报告 | 97.5% | 65.8% | 65.8% | 72.7% | 94.2% | 53.7% | 77.6% | 76,990 |
| AbuseIPDB | 来源报告 | 97.5% | 7.9% | 0.0% | 97.2% | 14.4% | 57.6% | 52.1% | 76,956 |
| ipapi.is | 来源报告 | 66.3% | 40.3% | 0.0% | 88.4% | 42.5% | 51.0% | 64.9% | 52,318 |
| StopForumSpam | 来源报告 | 100.0% | 6.0% | 0.0% | 95.8% | 10.7% | 56.9% | 51.4% | 78,940 |
| IPOK-DB | 来源报告 | 86.8% | 5.1% | 4.6% | 85.4% | 6.0% | 53.1% | 48.1% | 68,508 |
| IPHub | 来源报告 | 57.2% | 0.2% | 0.1% | 100.0% | 0.3% | 31.2% | 24.3% | 45,195 |
| vpnapi.io | 来源报告 | 66.2% | 59.9% | 59.9% | 89.9% | 62.8% | 50.5% | 72.4% | 52,253 |
| 数据源 | 证据层级 | 覆盖率 | 标记率 | 直报 proxy/vpn | 被佐证率 | 捕获率 | 留一法一致率 | 与最终判定一致（含自指） | 有结论次数 |
|---|---|---|---|---|---|---|---|---|---|
| ip-api | 推断 | 98.0% | 3.5% | 3.5% | 33.1% | 29.8% | 96.0% | 86.4% | 111,452 |
| IPQS休眠 · 无 key | 推断 | 0.0% | — | — | — | — | — | — | 0 |
| Scamalytics | 来源报告 | 2.4% | 0.0% | 0.0% | — | 0.0% | 98.4% | 84.9% | 2,753 |
| proxycheck | 来源报告 | 95.7% | 4.8% | 4.8% | 25.2% | 56.3% | 95.3% | 90.2% | 108,881 |
| AbuseIPDB | 来源报告 | 95.6% | 0.8% | 0.0% | 25.4% | 4.7% | 98.2% | 88.2% | 108,686 |
| ipapi.is | 来源报告 | 11.1% | 7.7% | 0.0% | 61.4% | 7.1% | 88.2% | 72.2% | 12,675 |
| StopForumSpam | 来源报告 | 100.0% | 0.2% | 0.0% | 22.5% | 1.3% | 98.7% | 87.7% | 113,689 |
| IPOK-DB | 来源报告 | 83.6% | 0.4% | 0.3% | 55.3% | 0.8% | 98.5% | 86.3% | 95,082 |
| IPHub | 来源报告 | 10.3% | 0.2% | 0.2% | — | 1.9% | 90.8% | 63.6% | 11,715 |
| vpnapi.io | 来源报告 | 11.1% | 5.0% | 5.0% | 71.6% | 5.8% | 89.7% | 67.4% | 12,653 |
- 第一方自报第一方自报：由运行这张网络、这项服务的一方自己公布的出口地址表。要判断「这条地址是不是它家的」，没有比发布方更近的信源。
- 来源报告来源报告：第三方给出的观测、社区举报、封禁列表标签或明确判定字段。它们可能针对单 IP，也可能针对网段；不代表本站实时测过这个地址，也不保证来源之间独立或结论仍然有效。
- 推断推断：从这条地址所在的网段、ASN 或用途分类推出来的——按服务商整段涂抹的 VPN 表、hosting / datacenter 这类「非住宅」分类、只由几个布尔值合成的代理标。段级的话可能是对的，落到单个地址上未必成立。
层级说的是「这条结论怎么来的」，不是「它准不准」，计分环节一个字都没读它。IPOK-DB 是这张表里最别扭的一行：这里是一行，底下却是六张表、横跨三层——Tor 自己公布的出口表和苹果自己公布的中继段在最上面，X4BNet 按服务商整段涂抹的 VPN 表在最下面。逐表分层写在方法页。
两两分歧率
对每一对源，只数两边都给出了结论的那些查询，再看其中「恰好一边打了标记」的占比。数字高只说明两者看的证据不同，不说明哪一边错了。同一个 IP 在不同厂商那里读数不同，原因就在这里。
| 源 A | 源 B | 机房分歧率 | 机房共同样本 | 住宅分歧率 | 住宅共同样本 |
|---|---|---|---|---|---|
| proxycheck | IPHub | 75.4% | 45,185 | 31.9% | 11,715 |
| proxycheck | IPOK-DB | 62.3% | 66,799 | 5.3% | 90,978 |
| proxycheck | StopForumSpam | 60.6% | 76,986 | 4.8% | 108,859 |
| proxycheck | AbuseIPDB | 58.8% | 76,942 | 5.2% | 108,657 |
| IPHub | vpnapi.io | 58.2% | 45,147 | 4.8% | 11,702 |
| StopForumSpam | vpnapi.io | 57.9% | 52,250 | 5.0% | 12,649 |
| ipapi.is | vpnapi.io | 57.5% | 52,145 | 12.3% | 12,593 |
| IPOK-DB | vpnapi.io | 57.3% | 45,758 | 5.6% | 11,449 |
| AbuseIPDB | vpnapi.io | 56.5% | 52,244 | 6.7% | 12,653 |
| Scamalytics | vpnapi.io | 56.1% | 5,040 | 2.0% | 2,667 |
| ip-api | vpnapi.io | 51.7% | 51,271 | 14.3% | 12,397 |
| ip-api | IPHub | 49.8% | 44,332 | 13.1% | 11,477 |
| proxycheck | ipapi.is | 49.1% | 52,300 | 29.5% | 12,667 |
| ipapi.is | IPOK-DB | 44.8% | 45,828 | 8.5% | 11,474 |
| ipapi.is | IPHub | 44.1% | 45,128 | 8.0% | 11,671 |
| ip-api | proxycheck | 43.8% | 75,524 | 6.1% | 106,752 |
| Scamalytics | proxycheck | 38.7% | 5,092 | 3.1% | 2,753 |
| ip-api | ipapi.is | 38.5% | 51,329 | 18.1% | 12,417 |
| ip-api | IPOK-DB | 38.3% | 67,248 | 3.9% | 93,080 |
| ipapi.is | StopForumSpam | 38.0% | 52,315 | 7.8% | 12,671 |
| ip-api | Scamalytics | 36.8% | 5,013 | 4.7% | 2,681 |
| AbuseIPDB | ipapi.is | 36.1% | 52,303 | 8.9% | 12,673 |
| ip-api | StopForumSpam | 34.1% | 77,466 | 3.5% | 111,426 |
| ip-api | AbuseIPDB | 32.0% | 75,489 | 3.6% | 106,565 |
| proxycheck | vpnapi.io | 31.7% | 52,241 | 28.9% | 12,647 |
| Scamalytics | ipapi.is | 21.1% | 5,047 | 2.6% | 2,671 |
| AbuseIPDB | IPOK-DB | 11.9% | 66,777 | 1.2% | 90,818 |
| AbuseIPDB | IPHub | 11.0% | 45,189 | 2.2% | 11,715 |
| StopForumSpam | IPOK-DB | 9.7% | 68,504 | 0.6% | 95,060 |
| AbuseIPDB | StopForumSpam | 9.0% | 76,952 | 0.9% | 108,664 |
| StopForumSpam | IPHub | 7.2% | 45,192 | 0.2% | 11,711 |
| Scamalytics | AbuseIPDB | 6.1% | 5,092 | 1.2% | 2,753 |
| IPOK-DB | IPHub | 5.4% | 43,451 | 1.0% | 10,743 |
| Scamalytics | StopForumSpam | 5.3% | 5,093 | 0.3% | 2,753 |
| Scamalytics | IPOK-DB | 4.5% | 4,766 | 0.0% | 2,487 |
| Scamalytics | IPHub | 2.7% | 4,891 | 0.5% | 2,577 |
| ip-api | IPQS | — | 0 | — | 0 |
| IPQS | Scamalytics | — | 0 | — | 0 |
| IPQS | proxycheck | — | 0 | — | 0 |
| IPQS | AbuseIPDB | — | 0 | — | 0 |
| IPQS | ipapi.is | — | 0 | — | 0 |
| IPQS | StopForumSpam | — | 0 | — | 0 |
| IPQS | IPOK-DB | — | 0 | — | 0 |
| IPQS | IPHub | — | 0 | — | 0 |
| IPQS | vpnapi.io | — | 0 | — | 0 |
有几个专源直报 proxy / VPN
共识规则只数专源的票（ip-api 除外，它的布尔值是推导出来的，不是实测）。机房 IP 要凑够 2 票 IPOK 才按代理处理，住宅 IP 1 票即可。下面是这个票数的实际分布，卡在门槛上的比例你自己看得到，不用听我们断言。
下载
两份文件与本页是同一批数字。CSV 给的是原始日签名计数而不是算好的比率，上面每一个百分比都能用它从零重算，不必相信我们的算术。
许可 CC BY 4.0。引用请署名 IPOK 并回链本页。
如何引用
版本号跟的是口径，不是数字。状态定义、分桶判据、出比率的门槛变了才会动它；数字本身随窗口每天滚动，不动版本号。版本号相同的两次取数才能放在一起比——请记下你取数的日期。
IPOK. (2026). IPOK IP Reputation Source Agreement Dataset (Version 1.3) [Data set]. Retrieved 2026-10-24, from https://ipok.io/en/data/sources
@misc{ipok-source-agreement,
title = {IPOK IP Reputation Source Agreement Dataset},
author = {{IPOK}},
year = {2026},
version = {1.3},
url = {https://ipok.io/en/data/sources},
urldate = {2026-10-24},
note = {Data set. Licensed CC BY 4.0}
}怎么统计的
- ·我们把每一次计入的查询压成一个 16 位签名：8 个源各占 2 位，取值是缺席 / 无标记 / 直报 proxy·vpn / 只报 Tor 或滥用历史。落库的一行是：UTC 日期、机房还是住宅、最终判定 0 或 1、这个签名、以及次数。
- ·机房与住宅的划分判据是「任一源报了 hosting」，与共识规则挑 2 票还是 1 票门槛时用的是同一个表达式。它和结果页上显示的 IP 类型标签不是一回事，后者还经过一层调和。
- ·最终判定取 1 的条件是发布出去的风险分达到 50，也就是全站「安全」与「警惕」两档的分界。
- ·行保留 60 天后惰性删除。没有逐查询记录可删，因为我们压根没写过。
- ·观测数不足 30 时我们打一个短横杠，不出比率。几十次查询算出来的百分比是噪声。
证据层级这一列是标注，不是算术。我们把来路差别极大的数据混在一张表里、让它们投同样的票：一张是网络运营方自己公布的出口表，一张是逐个地址探测出来的，还有一张是按服务商整个 ASN 涂满的。2026-09-22 为此付过一次代价——苹果公布的 105,727 个 iCloud 私密转发出口 IP，100% 落在 X4BNet 的 VPN 段里，在我们让苹果那份压过这份之前，每个开着私密转发的 Safari 用户都在被记一张 VPN 专源票。把层级标出来是修复的前一半；后一半是让不同层级带不同分量，那一半我们没做。加不加这一列，权重、硬信号下限、票数门槛逐字节相同。第一方的一句话该不该顶过三条推断，交给校准回路回答，而它要的读数 2026-10-06 之前拿不到。
这些数字所描述的打分规则写在 方法页。想看逐个可复现 IP 的人工核对快照（而不是流量聚合），见 六源投票实测。
这些数字说不了什么
- ·这不是站点流量，也不是已证明的真人样本。准入过滤会拒绝部分矛盾请求头，但 App、扩展和普通 API 仍可调用，请求头分类没有身份认证效力。历史行不能按证明状态重新拆分。
- ·第三方上游池已满时服务的那些查询，我们整条排除。那种状态下四个商业源是被我们自己的策略限制成只读缓存的，算进去等于把本站的配额政策报成人家的覆盖率问题。
- ·源用过期缓存作答时，仍算作「给出了结论」。所以覆盖率量的是「拿不拿得到答案」，不是「答案有多新」。
- ·有两个源我们本来就只在部分查询上调用：Scamalytics 只在有人主动查某个地址时调，ipapi.is 只在已有廉价嫌疑信号时才调。它们的覆盖率描述的是这套调用策略，不是厂商本身。
- ·IPQS 没有配置 API key，处于休眠状态。它那一行留着是为了位序连续，读数为零。
- ·与最终判定的一致率不度量「谁对」。某个地址在查询当时是否在跑代理，IPOK 没有真值可比，所以这两张表都别当成厂商准确率排名来读。
- ·留一法那三列拿掉的是「自己给自己打分」，不是「可能错」。吃同一批黑名单的几家源完全可能一起错在同一个方向；2 家这个门槛也是我们定的，不是量出来的。
- ·这三列奖励的还是「跟得紧」而不是「有增量」：一个只会复读别家结论的源在这里分数很好看，对判定却一点新东西都没加。ip-api 的位置还略有不同——它本来就不在任何一组「其他源」里，没有自己那一票要减，所以它是在比别人多一家的参照上被测的。
- ·被测的是哪些地址由流量决定。样本构成就是大家查了什么，本身偏向「已经有人起疑」的那部分地址。
签名位序对应的源名：ip-api、IPQS、Scamalytics、proxycheck、AbuseIPDB、ipapi.is、StopForumSpam、IPOK-DB、IPHub、vpnapi.io。