1. 关注点
DeepSeek API 涨价。
自然反应：官方 API 贵，能不能直接转发 Web 端接口做替代？
查了一下。
Web2API 这类项目已有不少，把 Web 页面背后的接口封装成 API。但大多被公开标记为 "已被风控"，存活周期短。
但在相关讨论帖里注意到一个细节：DeepSeek Web 端在请求前置环节用了 PoW（工作量证明）。
用途：拦截非浏览器环境的自动化请求。
这个机制引起了兴趣。下文记录初步实现与实测。
2. PoW 是什么
PoW 的基本逻辑：服务端下发一道计算题，客户端必须算出答案才能继续请求。
在 CC 防御场景下的关键属性：非对称计算代价。
- 服务端：生成随机数 + 验证结果。耗时微秒级。
- 客户端：暴力枚举找到满足条件的字符串。耗时秒级。
攻击者的成本主要是请求次数。引入 PoW 后，每次有效请求都附加 CPU 算力消耗。攻击成本线性上升。
实际测试中，这个方案能快速过滤掉不携带计算模块的低成本脚本。
3. 一个 PHP 文件的 Demo 实现
用单个 PHP 文件模拟服务端下发挑战 + 客户端计算。
<?php
$salt = 'fixed_salt_123';
$expire = time() + 60;
$difficulty = 4;
$target = str_repeat('0', $difficulty);
$nonce = 0;
$found = false;
$maxAttempts = 2000000;
while ($nonce < $maxAttempts) {
$hash = hash('sha256', $salt . $expire . $nonce);
if (strpos($hash, $target) === 0) {
$found = true;
break;
}
$nonce++;
}
if ($found) {
echo "找到有效 Nonce: " . $nonce . "\n";
echo "对应哈希: " . $hash . "\n";
$verifyHash = hash('sha256', $salt . $expire . $nonce);
if (strpos($verifyHash, $target) === 0) {
echo "服务端验证通过，放行请求。\n";
} else {
echo "验证失败。\n";
}
} else {
echo "未找到有效 Nonce，尝试次数超限。\n";
}
?>
CLI 模式运行，验证算法逻辑。实际部署时计算在浏览器端，验证在服务端。
4. Demo 实现解释
https://bjun.tech/demo/pow_cc/index.php
拆解如下：
- 难度系数 = 4。哈希值十六进制必须以
0000 开头。客户端平均需尝试 16^4 = 65536 次。
- 盐值（Salt）：防止预计算彩虹表。
- 有效期（Expire）：限制 Nonce 有效时间窗口，防止过期结果被重放。
- 客户端枚举：从 0 递增，每步计算一次 SHA-256，比对目标前缀。
- 服务端验证：收到 Nonce 后，用相同参数重算一次哈希。比对一次即确认客户端是否付出了算力。
核心结论：服务端把计算压力转移给客户端，验证逻辑足够轻量，不构成新瓶颈。
5. 局限与进一步思考
5.1 SHA-256 的局限
SHA-256 是纯数学运算，依赖 CPU 整数指令。天然适合 GPU 并行加速。
实测：普通显卡的搜索速度是 CPU 的数十倍。攻击者持显卡集群时，4 位前缀难度可瞬间爆破。若提高到 6–7 位，普通用户浏览器会卡顿数秒甚至数十秒。
结论：SHA-256 在对抗专业攻击者时存在结构性缺陷。
5.2 PoW 机制的固有问题（与哈希算法无关）
- 移动端功耗敏感。PoW 计算增加电量消耗和发热。
- 延迟叠加。每次请求增加额外 RTT，弱网环境体验下降。
- 无法防御慢速攻击。PoW 只拦截高频请求，对占用连接不放的慢速攻击无效。
5.3 后续方向
两个方向：
- 横向替换算法。用 Scrypt 或 Argon2id 替代 SHA-256。这类算法强制占用大量内存，GPU 并行优势被内存带宽限制削弱，缩小攻击者与普通用户的算力差距。
- 纵向引入状态。服务端引入 Redis，记录已使用 Nonce 防止重放，难度改为动态值（根据负载和客户端性能自适应）。