这个页面显示本站给你当前 IP 打的信誉分，以及分数是怎么算出来的。它同时是本站防滥用机制的说明——申请 @haotianblog.com 邮箱时用的就是这套评分，分数越高，人机验证的哈希题越难。
要先做一次人机验证才能查询。不加这道门，这个页面就成了免费的 IP 信誉查询接口：任何人都能拿代理池挨个试，找出本站认为”干净”的地址。让每次查询付出一秒 CPU，拦不住一个好奇的读者，但拦得住这种批量枚举。
这个分数不是什么
它不调用任何外部信誉 API，不用第三方黑名单，也不按国家/地区加权。全部信号都来自本站自己能观察到的东西。
国家维度是刻意排除的：它与”读者住在哪”的相关性远强于与”是不是滥用”的相关性，而本站有中英双语读者分布在很多地区。按地区加价会稳定地惩罚一批正常读者，换不来对应的防护收益。
另外，分数只决定价格，不决定通过与否。没有任何一档分数会被直接拒绝——分数高只是哈希题更难。这是有意的：本地信号必然会误判，而误判的代价应该是”慢几秒”，不是”办不成事”。
五个信号
| 信号 | 分值 | 为什么 |
|---|---|---|
| 反向 DNS 指向主机商/云 | +30 | 家庭宽带几乎不会解析到 amazonaws、digitalocean 这类名字，而自动化脚本几乎总跑在上面 |
| 没有反向 DNS 记录 | +5 | 多数住宅 ISP 会发布 PTR 记录，但缺失太常见，只能算很弱的信号 |
| 近期验证失败 | +10/次，上限 30 | 反复失败通常意味着在试探规则，而不是在正常使用 |
| 短时间内重复通过验证 | 超过 2 次后 +8/次，上限 25 | 通过几次是正常的；一小时内通过十几次是在刷 |
| 账号年龄 | 不足 1 天 +15，不足 7 天 +8 | 新账号没有积累任何”烧掉会心疼”的历史 |
| User-Agent 缺失或是自动化工具 | +20 | curl、python-requests 这类标识不伪装时，说明请求方也没打算伪装 |
分数封顶 100，映射到 17–21 bit 的难度区间。17 bit 期望约 13 万次哈希（浏览器里约 0.4 秒），21 bit 约 210 万次（约 6 秒）。每多一个 bit，工作量翻倍。
隐私边界
本站不存储你的 IP 原文。计数器用的是 IP 的 HMAC（以站点密钥加盐）作为键，所以即使拿到数据库也无法反推出地址列表。反向 DNS 结果缓存一天，同样按哈希键存。
页面上显示的 IP 是你自己的地址——你本来就知道它，显示它不构成新的信息泄露，但能让你核对本站看到的地址是否正确（比如经过代理时）。
为什么用工作量证明而不是图形验证码
图形验证码把判断外包给第三方，往页面塞一个阻塞脚本，而且几分钱就能被打码平台批量解决。工作量证明不试图分辨人和机器——它让每次尝试都付出真实的 CPU 时间。一次请求对读者是察觉不到的一秒；一万次请求对滥用者是每台机器数小时的算力。
需要说清楚它的局限：PoW 挡不住有耐心的单个攻击者，它只改变经济账。所以邮箱申请没有只靠它——还要求已登录、邮箱已验证、每账号一个。PoW 是纵深防御的一层，不是唯一那道门。
可能的失败情况
- 浏览器不支持 Web Worker 或 TextEncoder：验证按钮会一直停在失败状态。这套代码不依赖任何新特性，但极老的浏览器仍可能不行。
- 验证过期：题目签发后 10 分钟内有效，超时需重新点一次。
- 一题一用：查询成功后需要重新验证才能再查。这是防重放，不是故障。
- 移动设备较慢：手机 CPU 大约是桌面的三分之一到一半，高分区间可能要十几秒。
相关文章
- 高熵流量防御与混淆填充：另一类”改变攻击经济账而不是试图完全阻断”的思路。
- AI 安全威胁建模：怎么把”谁会攻击、代价多大”写成可检验的模型。
- 实用功能：站点内其他浏览器端工具。