评分方法
更新于 2026-10-21 · ipok.io
IPOK 的风险值（0–100，越大表示本站观测到的 IP 层不利证据越强）由多家数据源的数值评分加权汇总，再叠加站内硬信号与环境下限。本页公开完整的站内聚合、下限和分档算法；第三方数据源自己的内部算法不由 IPOK 控制。
归属地主源为 ip-api，不可用时依次回退到 IPinfo Lite、ipapi.is。IPinfo Lite 仅提供国家与 ASN 资料，不产生风险判定、不进入评分或共识投票；城市、经纬度等详细字段可能缺省。
一、多源加权平均
每个能给出数值风险评分的数据源按下表权重做加权平均；休眠、请求失败或没有数值评分的源不进入平均。内部聚合在没有数值来源时使用基础值 10，再取基础值与命中下限的最大值，四舍五入并限制在 0–100；这个内部值不是可直接显示的结论。缺少当前证据，或聚合含过期 / 时间不明的风险贡献时，页面显示“证据不足”并隐藏总分。历史观测仍保留，不能解释为当前安全或当前命中。
| 数据源 | 权重 | 说明 |
|---|---|---|
| Scamalytics | 0.90 | 专业欺诈评分，覆盖代理/VPN/数据中心 |
| IPQS | 0.70 | 欺诈评分（需 API Key；当前额度休眠） |
| proxycheck | 0.85 | 代理 / VPN 检测（受共享缓存新鲜度约束） |
| AbuseIPDB | 0.80 | 社区滥用举报库 + 白名单标记 |
| IPOK-DB | 0.80 | 六张信誉/中继子表：Tor、X4BNet VPN、DROP、OpenProxyDB Wikipedia 封禁标签、IPsum、Apple relay。另有七家云地址表仅作归属背景；新鲜且覆盖该地址族的子表才产生当前标记 |
| ipapi.is | 0.70 | 校准过的滥用评分 + 网络溯源 |
| IPHub | 0.70 | 专做代理 / VPN / Tor / 机房检测；只取它的显式判定，不用宽口径的 block 值 |
| vpnapi.io | 0.70 | VPN / 代理 / Tor 显式判定；relay（iCloud 私密转发）单列不当代理 |
| StopForumSpam | 0.65 | 论坛 / 注册垃圾源库（免费，与 AbuseIPDB 互补） |
| ip-api | 0.50 | 仅布尔推导，精度有限，权重最低 |
产物构建于 2026-10-21。下表分别展示各源成功抓取时间和地址族覆盖；构建日期不会替抓取失败的来源刷新时间。
当前快照覆盖与抓取日期
| 输入表 | IPv4 | IPv6 |
|---|---|---|
| Tor exit list | 新鲜 · 559 段 · 抓取 2026-10-21 | 该来源不覆盖此地址族 |
| X4BNet/lists_vpn | 新鲜 · 6794 段 · 抓取 2026-10-21 | 该来源不覆盖此地址族 |
| Spamhaus DROP | 新鲜 · 1445 段 · 抓取 2026-10-21 · 到期 2026-10-21 17:14 UTC | 该来源不覆盖此地址族 |
| OpenProxyDB | 新鲜 · 8201 段 · 抓取 2026-10-21 | 该来源不覆盖此地址族 |
| IPsum (level 3) | 新鲜 · 13179 段 · 抓取 2026-10-21 | 该来源不覆盖此地址族 |
| iCloud Private Relay egress ranges | 新鲜 · 1011 段 · 抓取 2026-10-21 | 新鲜 · 5903 段 · 抓取 2026-10-21 |
| AWS ip-ranges | 新鲜 · 937 段 · 抓取 2026-10-21 | 新鲜 · 2149 段 · 抓取 2026-10-21 |
| Google Cloud IP ranges | 新鲜 · 168 段 · 抓取 2026-10-21 | 新鲜 · 17 段 · 抓取 2026-10-21 |
| Cloudflare proxy IP ranges | 新鲜 · 14 段 · 抓取 2026-10-21 | 新鲜 · 7 段 · 抓取 2026-10-21 |
| Oracle Cloud public IP ranges | 新鲜 · 478 段 · 抓取 2026-10-21 | 该来源不覆盖此地址族 |
| Azure Service Tags (AzureCloud) | 新鲜 · 500 段 · 抓取 2026-10-21 | 该来源不覆盖此地址族 |
| DigitalOcean geofeed | 新鲜 · 102 段 · 抓取 2026-10-21 | 新鲜 · 39 段 · 抓取 2026-10-21 |
| Akamai/Linode geofeed | 新鲜 · 95 段 · 抓取 2026-10-21 | 新鲜 · 22 段 · 抓取 2026-10-21 |
Apple relay、AWS、Google Cloud、Cloudflare、DigitalOcean 与 Linode 只有在 IPv6 数据成功摄取后才具备对应覆盖。Tor、当前 VPN/DROP/proxy/IPsum 端点、OCI 与 AzureCloud 在这里不提供 IPv6 覆盖。地址族缺失或数据过期不能解释为安全。
Cloudflare 地址表命中表示属于其公布的 Anycast 网络地址范围，不能证明具体代理产品、WARP 出口或物理位置。WARP 防火墙文档列的是入口段，不是出口地址表。
二、硬信号下限
某些信号一旦命中，无论加权平均多低，最终分都不会低于对应下限（取加权平均与所有命中下限的最大值）。因此，具备评分资格的机房 IP 不会因多数源给低分而进入低于 15 分的“低风险迹象”档。
| 信号 | 下限 | 说明 |
|---|---|---|
| Tor 出口节点 | 90 | IP 层强匿名信号；许多服务通常限制 Tor，但本站不据此预测具体平台结果 |
| 命中垃圾 / 滥用黑名单 | 70 | 本次实际完成的 DNSBL 查询中任一命中，即构成直接 IP 层证据 |
| 确认代理 / VPN | 65 | 机房 IP 需至少 2 个非 ip-api 可用源投出 proxy/VPN 票；非机房需至少 2 个；已知匿名服务 ASN 可单独成立 |
| 近期滥用记录 | 55 | 举报 / 滥用评分达阈值 |
| 同段被标记 ≥25% | 40 | 仅统计非 blanket 的 /24 段级标记；比例达到 25% 且低于 50% 时作为环境下限 |
| 同段被标记 ≥50% | 50 | 仅统计非 blanket 的 /24 段级标记；比例达到 50% 时作为环境下限 |
| 数据中心 / 机房 | 35 | 机房是「用途」非欺诈，下限调低，把真风险让给代理/滥用 |
三项边界规则：任一可用源明确给出可信白名单时，只抑制「机房」环境下限；若同一来源同时给出白名单与滥用标记，则忽略该来源自相矛盾的滥用票，但不会覆盖其他来源的独立滥用证据；若整个 /24 只是被一条宽 CIDR blanket 一次性覆盖，则不再叠加同段连坐下限，避免重复计算同一条段级证据。其余直接信号仍照常参与。另有一条中继规则：命中苹果公布的 iCloud 私密转发出口段时，我们不再按「机房用途」抬下限，本站自建离线库也不再投 VPN 票（实测这些出口段 100% 被第三方 VPN 名单收录，若不区分，每个开着私密转发的用户都会被记一张 VPN 票）；但**若外部源仍判代理 / VPN，65 下限照常成立**——风险分保留这些 IP 层代理标签，不预测特定平台是否接受这个出口。我们的处置是把它标明成「iCloud 私密转发」，而不是替外部源改判。
票数门槛每周自校准
上面那条「确认代理 / VPN」要几票，不是一个定死的常数：每周从本站公开的匿名投票聚合里重算一次。做法是取 proxycheck 单独报了代理的样本，看 IPHub 与 vpnapi.io 这两家不同厂商（不保证底层数据独立）是否也报——不拿本站自己的最终判定当标尺，那一票本来就决定了判定，用它校准自己是循环论证。证实率 ≥70% 维持单票，<40% 收紧到两票，落在中间则维持原值不动（住宅桶这一档另需同段真人存在规则先落地）。三道护栏写死在代码里：门槛只能取住宅 1–2 票 / 机房 2–3 票、证实与否决之和不足 500 条就不动该参数、每次最多变动一格。每次变动都在这里和 /api/data/calibration 公开，参数不会悄悄漂移。
住宅桶 2 票 · 机房桶 2 票 · 校准于 2026-10-12 · 样本 155,491 次观测（30 天窗口） · 最近变动：住宅桶 1 → 2
证据分层（只标注，不计分）
上面那张权重表把所有源放在同一个尺度上比，但它们的证据来路差别极大：有的名单是网络运营方自己公布的自家出口，有的是第三方报告或封禁列表标签，有的是按服务商整个 ASN 涂满的。我们把每个源、以及自建离线库里的每一张子表，归到下面三层，并在 /data/sources 的源表里逐行标出来。
- 第一方自报第一方自报：由运行这张网络、这项服务的一方自己公布的出口地址表。要判断「这条地址是不是它家的」，没有比发布方更近的信源。
- 来源报告来源报告：第三方给出的观测、社区举报、封禁列表标签或明确判定字段。它们可能针对单 IP，也可能针对网段；不代表本站实时测过这个地址，也不保证来源之间独立或结论仍然有效。
- 推断推断：从这条地址所在的网段、ASN 或用途分类推出来的——按服务商整段涂抹的 VPN 表、hosting / datacenter 这类「非住宅」分类、只由几个布尔值合成的代理标。段级的话可能是对的，落到单个地址上未必成立。
| 数据源 | 层级 | 归层依据 |
|---|---|---|
| ip-api | 推断 | lib/sources/ipapi.ts 只读 data.proxy / data.hosting / data.mobile 三个布尔，背后没有任何探测证据。research/proxycheck-weight-review-20260922.md 用 15 天线上数据量过：仅 ip-api 标记的 1,704 条样本最终判可疑 8.5%，对 7.9% 的基线只有 1.1× 提升，统计上约等于没信息。aggregate.ts 的 dedicatedAnonVotes 本来就把它排除在专源票之外。 |
| IPQS | 推断 | 标 inferred 是因为**我们没有证据**，不是因为判它弱。IPQS 在 sourceStats.ts 的 DORMANT_SOURCES 里：无 API key、零次调用，lib/sources/ipqs.ts 里那套 d.proxy / d.vpn / d.tor / d.recent_abuse 显式布尔从没在本站取到过一次真实响应。字段形状与 measured 那几家相同，但没核过就不给更高层级——待核，接上 key 看到实际响应后重判。 |
| Scamalytics | 来源报告 | lib/sources/scamalytics.ts 取 scamalytics_score 与 scamalytics_proxy.is_vpn——厂商给出的显式 VPN 判定与欺诈评分。代码注释记着 v3 根本没有 is_proxy / is_tor，并刻意不从 is_datacenter 合成 proxy（否则普通机房会被误标代理）。同一响应里的 is_datacenter 是用途分类，单列为 inferred（见 SIGNAL_TIERS）。 |
| proxycheck | 来源报告 | lib/sources/proxycheck.ts 取 entry.proxy === 「yes」与 entry.type（VPN / Tor / Compromised Server …）——厂商的显式代理判定，不是从别的字段推出来的。⚠️ measured 讲的是证据来路，不是准确率：同一份复核里它单独标记机房 IP 共 8,370 次，84% 因票数不够被否，它的 0.85 权重也没有因此改动。 |
| AbuseIPDB | 来源报告 | lib/sources/abuseipdb.ts 的 abuser 标要 abuseConfidenceScore ≥ 25 **且**（totalReports ≥ 3 或 numDistinctUsers ≥ 2）——真人站长提交的滥用举报，门槛把单人乱举报滤掉了。同一响应里由 usageType 字符串推出来的 hosting、以及厂商维护的 isWhitelisted，是另外的层级（见 SIGNAL_TIERS）。 |
| ipapi.is | 来源报告 | lib/sources/ipapiis.ts 只取 is_tor 与校准过的 abuser_score（按括号里的 Very Low…Very High 标签映射，≥55 才置 abuser），并在注释里写明**拒读** is_vpn / is_proxy——它们噪声大，曾把 8.8.8.8 标成 vpn。同一个源里的 is_datacenter 是段级用途分类，单列为 inferred。 |
| StopForumSpam | 来源报告 | lib/sources/stopforumspam.ts 的 abuser 标要 appears === 1 **且** frequency ≥ 3——论坛注册环节由站长逐条提交的垃圾源举报，且与 AbuseIPDB 用同一条 ≥3 次门槛，不是单次偶发。 |
| IPOK-DB | 来源报告 | lib/lookup.ts 把六张信誉/中继子表合成一个 IPOK-DB SourceResult，另外七家云地址表只用于归属背景；它们不是十三个独立风险来源。Tor / relay 是第一方列表，OpenProxyDB 是 Wikipedia 封禁标签，IPsum 汇总多份名单，DROP 是网段级记录，X4BNet 是段级推断。每一项还取决于当前地址族覆盖与数据新鲜度；整体标为来源报告不等于全库经过实时实测。 |
| IPHub | 来源报告 | lib/sources/iphub.ts 只把 proxyType.proxy / .tor / .hosting / .relay 这几个**显式**判定写进 flags，注释里明确不拿宽口径的 block 当代理票（8.8.8.8 的 block 就是 1，blockReason 是 Hosting, proxy or bad IP）。⚠️ block 并非完全没用到：iphubRisk() 仍拿它给风险分（block===2→45、block===1→35），那部分属推断，见 SIGNAL_TIERS。 |
| vpnapi.io | 来源报告 | lib/sources/vpnapi.ts 只读 security.vpn / .proxy / .tor 三个显式布尔进 flags；security.relay 单列、不当代理票。它不给 hosting / datacenter 判定，所以不参与机房分桶——这个源里没有段级推断混进来。 |
IPOK-DB 的六张信誉/中继子表
离线产物有六张信誉/中继子表和七家云厂商地址表，共13份输入。七张云表只提供网络归属背景，不是十三个独立风险源；名单重叠也不证明上游信息相互独立。
| 子表 | 层级 | 归层依据 |
|---|---|---|
| tor | 第一方自报 | FEEDS.tor 使用 Tor Project 的 torbulkexitlist。它支持当前来源的 IPv4 出口记录；Onionoo 的 IPv6 or_addresses 是入口监听地址，不能冒充 IPv6 出口。只在已覆盖且新鲜时输出当前 Tor 标记。 |
| relay | 第一方自报 | FEEDS.relay 使用 Apple 发布的 egress-ip-ranges.csv。新鲜命中表明地址在公布的私密转发出口段内；lookupOffline 据此纠正本库自己的 VPN / cloud 分类，不替其他来源撤销判定，也不证明某个用户安全。IPv6 只在产物实际收录且日期有效时可用。 |
| proxy | 来源报告 | OpenProxyDB 从 Wikipedia 的本地和全局封禁列表提取代理相关标签。scripts/iplists-core.mjs 只保留单个 IPv4、proxy=true 且不含 cdn/webhost/rangeblock 的记录；排除宽网段行不等于逐个验证代理连通性。它是来源报告的历史标签，不是本站本次实测。 |
| ipsum | 来源报告 | FEEDS.ipsum 读取 levels/3.txt，表示该 IP 至少被三份上游名单收录。名单可能共享上游，因此重叠不证明独立举报或独立观测，也不能据此断言该主机当前正在攻击。运行时按这张聚合表的一项来源记录处理。 |
| abuse | 来源报告 | FEEDS.abuse 使用 Spamhaus DROP 的被劫持或用于专业垃圾/网络犯罪活动的网段记录。它针对网段，不代表本站实测该地址本次连接；过期快照命中只作历史说明，不产生当前标记。 |
| vpn | 推断 | FEEDS.vpn 使用 X4BNet 的 output/vpn/ipv4.txt，按已知 VPN 网络和服务商资料形成段级名单，不逐 IP 验证连接。它不是仓库的 legacy ipv4.txt 机房总表；新鲜的 Apple relay 命中优先于本库 VPN 标签。 |
分层目前只用于标注与展示：权重、硬信号下限、票数门槛都没有按层调整，加不加这套标注，判定结果逐字节相同。要不要让第一方自报的一条顶过推断的三条，得先有校准回路的读数（见上一节），在那之前按层调权重等于用同一批没有真值的数据既定层级又定权重。
三、垃圾 / 滥用黑名单（DNSBL）
计划经 Cloudflare DoH 查询 5 个邮件 / 滥用黑名单：SpamCop、UCEPROTECT、Barracuda、S5H、Anonmails；实际完成数以结果页为准。部分查询失败会明确警告，全失败则不产出黑名单结论，均不会被当成「未命中」。在实际完成的查询中任一命中即触发上面的黑名单下限。仅支持 IPv4。
四、风险分档
| 分档 | 区间 | 含义 |
|---|---|---|
| 证据不足 | — | 不展示总分；请核对观测时间与缺失来源，未知不等于安全 |
| 低风险迹象 | < 15 | 本次返回数据中的 IP 层不利证据很弱 |
| 较低风险迹象 | 15 – < 50 | 本次返回数据中的 IP 层不利证据较弱 |
| 警惕 | 50 – < 70 | 本次返回数据中的 IP 层不利证据中等或较强 |
| 高风险 | ≥ 70 | 本次返回数据中的 IP 层不利证据很强 |
五、登记归属与定位一致性
RIR / RDAP 提供登记信息，地理库提供定位估计。两者一致只表示国家字段一致，不能证明原生、住宅或未经过转发；不一致也不能单独证明广播或代理。Anycast 可在多地公告同一地址，因此不能从一个坐标推定物理出口。资料缺失时标为未知，也不据此承诺平台通过或封禁结果。
IPOK 是 AbuseIPDB 的已验证站长；徽章显示的是本账号自己的举报数——IPOK 只查询，从不举报访客 IP。