开放数据
七个 IP 信誉源在哪些地方一致，在哪些地方打架
IPOK 线上查询的滚动聚合计数：各信誉源的覆盖率、标记率、两两分歧率，以及留一法一致率——把被测源从参照里拿掉，不再拿含它自己一票的最终判定当尺子。机房 IP 与住宅 IP 分开统计，因为共识规则对两者本来就用不同阈值。只公开脱敏计数，不含任何 IP，附 JSON 与 CSV 下载。
生成于 2026-10-13T00:43:24.822Z · 缓存 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.4% | 37.9% | 37.9% | 87.2% | 56.5% | 67.7% | 66.9% | 62,158 |
| IPQS休眠 · 无 key | 推断 | 0.0% | — | — | — | — | — | — | 0 |
| Scamalytics | 实测 | 6.2% | 1.5% | 1.5% | 100.0% | 3.8% | 67.5% | 58.9% | 3,912 |
| proxycheck | 实测 | 98.9% | 65.3% | 65.3% | 65.9% | 94.1% | 51.1% | 72.7% | 62,471 |
| AbuseIPDB | 实测 | 98.9% | 8.1% | 0.0% | 96.2% | 15.6% | 62.3% | 55.8% | 62,452 |
| ipapi.is | 实测 | 68.0% | 40.6% | 0.0% | 85.1% | 43.7% | 53.5% | 70.7% | 42,947 |
| StopForumSpam | 实测 | 100.0% | 6.3% | 0.0% | 96.1% | 11.7% | 61.1% | 54.5% | 63,134 |
| IPOK-DB | 实测 | 88.7% | 5.8% | 5.2% | 89.2% | 7.8% | 57.5% | 51.1% | 55,987 |
| IPHub | 实测 | 40.4% | 0.2% | 0.1% | 100.0% | 0.2% | 30.2% | 23.0% | 25,518 |
| vpnapi.io | 实测 | 47.5% | 59.7% | 59.7% | 91.7% | 62.9% | 50.7% | 73.4% | 29,983 |
| 数据源 | 证据层级 | 覆盖率 | 标记率 | 直报 proxy/vpn | 被佐证率 | 捕获率 | 留一法一致率 | 与最终判定一致（含自指） | 有结论次数 |
|---|---|---|---|---|---|---|---|---|---|
| ip-api | 推断 | 98.3% | 2.9% | 2.9% | 37.0% | 36.3% | 96.9% | 86.8% | 96,678 |
| IPQS休眠 · 无 key | 推断 | 0.0% | — | — | — | — | — | — | 0 |
| Scamalytics | 实测 | 2.1% | 0.0% | 0.0% | — | 0.0% | 97.4% | 82.4% | 2,110 |
| proxycheck | 实测 | 98.2% | 4.5% | 4.5% | 20.8% | 56.1% | 95.5% | 91.3% | 96,580 |
| AbuseIPDB | 实测 | 98.1% | 0.9% | 0.0% | 22.0% | 5.9% | 98.4% | 88.2% | 96,429 |
| ipapi.is | 实测 | 9.3% | 6.8% | 0.0% | 57.1% | 4.0% | 88.9% | 65.9% | 9,157 |
| StopForumSpam | 实测 | 100.0% | 0.2% | 0.0% | 36.0% | 3.5% | 98.9% | 87.5% | 98,283 |
| IPOK-DB | 实测 | 88.8% | 0.4% | 0.3% | 57.2% | 2.5% | 98.8% | 86.2% | 87,320 |
| IPHub | 实测 | 6.4% | 0.3% | 0.3% | — | 2.8% | 90.1% | 51.0% | 6,303 |
| vpnapi.io | 实测 | 6.9% | 4.9% | 4.9% | 86.0% | 7.3% | 89.7% | 57.3% | 6,822 |
- 第一方自报第一方自报：由运行这张网络、这项服务的一方自己公布的出口地址表。要判断「这条地址是不是它家的」，没有比发布方更近的信源。
- 实测实测 / 举报：有人真的去连过这个地址，或真的有人举报过它——逐个探测到的开放代理、多家互相独立的黑名单同时收录、社区提交的滥用举报，以及商业源明确给出的代理 / VPN / Tor 判定字段。可能过期、可能误报，但讲的是这台主机本身。
- 推断推断：从这条地址所在的网段、ASN 或用途分类推出来的——按服务商整段涂抹的 VPN 表、hosting / datacenter 这类「非住宅」分类、只由几个布尔值合成的代理标。段级的话可能是对的，落到单个地址上未必成立。
层级说的是「这条结论怎么来的」，不是「它准不准」，计分环节一个字都没读它。IPOK-DB 是这张表里最别扭的一行：这里是一行，底下却是六张表、横跨三层——Tor 自己公布的出口表和苹果自己公布的中继段在最上面，X4BNet 按服务商整段涂抹的 VPN 表在最下面。逐表分层写在方法页。
两两分歧率
对每一对源，只数两边都给出了结论的那些查询，再看其中「恰好一边打了标记」的占比。数字高只说明两者看的证据不同，不说明哪一边错了。同一个 IP 在不同厂商那里读数不同，原因就在这里。
| 源 A | 源 B | 机房分歧率 | 机房共同样本 | 住宅分歧率 | 住宅共同样本 |
|---|---|---|---|---|---|
| proxycheck | IPHub | 77.4% | 25,510 | 42.9% | 6,303 |
| proxycheck | IPOK-DB | 60.7% | 55,394 | 5.0% | 85,868 |
| proxycheck | StopForumSpam | 59.9% | 62,466 | 4.6% | 96,562 |
| proxycheck | AbuseIPDB | 58.3% | 62,441 | 5.0% | 96,417 |
| StopForumSpam | vpnapi.io | 57.9% | 29,980 | 4.9% | 6,821 |
| ipapi.is | vpnapi.io | 57.6% | 29,898 | 12.4% | 6,793 |
| IPHub | vpnapi.io | 57.5% | 25,501 | 4.5% | 6,296 |
| IPOK-DB | vpnapi.io | 56.7% | 27,022 | 5.7% | 6,691 |
| AbuseIPDB | vpnapi.io | 55.8% | 29,978 | 6.5% | 6,822 |
| Scamalytics | vpnapi.io | 53.9% | 2,620 | 3.4% | 1,329 |
| ip-api | vpnapi.io | 51.1% | 29,490 | 16.7% | 6,737 |
| proxycheck | ipapi.is | 50.5% | 42,932 | 32.9% | 9,157 |
| ip-api | IPHub | 50.3% | 25,079 | 15.0% | 6,226 |
| ipapi.is | IPOK-DB | 44.7% | 38,573 | 8.2% | 8,994 |
| ipapi.is | IPHub | 43.7% | 25,470 | 8.1% | 6,283 |
| Scamalytics | proxycheck | 42.9% | 3,911 | 6.4% | 2,110 |
| ip-api | proxycheck | 42.6% | 61,497 | 5.5% | 95,000 |
| ipapi.is | StopForumSpam | 38.4% | 42,943 | 7.3% | 9,154 |
| ip-api | IPOK-DB | 38.0% | 55,136 | 3.2% | 85,819 |
| ip-api | ipapi.is | 37.2% | 42,345 | 20.8% | 9,040 |
| AbuseIPDB | ipapi.is | 36.7% | 42,926 | 8.4% | 9,155 |
| ip-api | StopForumSpam | 34.1% | 62,153 | 2.9% | 96,659 |
| ip-api | AbuseIPDB | 31.9% | 61,478 | 3.3% | 94,855 |
| proxycheck | vpnapi.io | 31.4% | 29,975 | 38.1% | 6,822 |
| ip-api | Scamalytics | 30.4% | 3,867 | 6.9% | 2,078 |
| Scamalytics | ipapi.is | 24.1% | 3,869 | 3.3% | 2,027 |
| AbuseIPDB | IPOK-DB | 12.5% | 55,385 | 1.3% | 85,727 |
| AbuseIPDB | IPHub | 11.0% | 25,515 | 2.1% | 6,303 |
| StopForumSpam | IPOK-DB | 10.3% | 55,982 | 0.5% | 87,302 |
| AbuseIPDB | StopForumSpam | 9.8% | 62,447 | 0.9% | 96,412 |
| Scamalytics | AbuseIPDB | 7.5% | 3,911 | 1.9% | 2,109 |
| StopForumSpam | IPHub | 7.2% | 25,515 | 0.3% | 6,302 |
| IPOK-DB | IPHub | 5.7% | 25,518 | 1.1% | 6,303 |
| Scamalytics | StopForumSpam | 5.6% | 3,911 | 0.9% | 2,108 |
| Scamalytics | IPOK-DB | 4.4% | 3,806 | 0.7% | 2,066 |
| Scamalytics | IPHub | 2.8% | 2,536 | 1.0% | 1,256 |
| 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-13, 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-13},
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 的人工核对快照（而不是流量聚合），见 六源投票实测。
这些数字说不了什么
- ·这不是站点流量。声称自己是浏览器、却带着真浏览器不会有的头组合的请求，我们在计数点之前就拒掉了（边缘一道，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。