---
title: "为什么要做一个独立的人机验证服务"
date: 2026-06-14
category: "后端开发"
---

# 为什么要做一个独立的人机验证服务

博客的注册和登录需要人机验证。最开始的方案是用现成服务，接入只要半天，但用了一个月就换成了自建。

## 换掉的两个理由

一是校验链路。每次验证都要回调第三方服务器，它抖一下，我的登录就跟着失败。有读者反馈验证码转圈转不出来，查了半天问题在我控制不了的那一跳上。

二是规则。同一个 IP 短时间试错多少次要升级难度、失败几次要封禁，这些阈值全在别人后台里，我只能看着。

## 自建的骨架

服务单独跑在一个子域名上，和博客主站完全隔离。组成是四块：

会话初始化发 token 和盐值，前端采集行为数据，服务端校验一次核销，最后是按来源自适应的难度。

```php
$token = bin2hex(random_bytes(24));
$salt  = bin2hex(random_bytes(8));
$difficulty = $fails >= 3 ? 6 : 4;
```

失败次数多的来源，计算成本翻倍；正常用户几乎无感。

# 简要说明

基于php构建的拥有主流水平的人机验证（Captcha -Completely Automated Public Turing test to tell Computers and Humans Apart）系统，拥有以下功能：

1：动态混淆机制，JS会定时重新生成并进行混淆，难以根据代码进行破解

2：POW机制：动态变化POW难度，更高的绕过成本

> PoW 验证是什么

> PoW（Proof-of-Work）验证码通过让客户端执行一定量的计算任务来证明其不是大规模自动化脚本。
> 核心特点：

> * **计算成本高（客户端）**：需暴力搜索 nonce。
> * **验证成本低（服务端）**：只需一次哈希计算即可验证。
> * **不可预测**：无法提前预计算或使用公式跳过计算。

3：对于脚本不友好的挑战：

![人机验证demo图片](https://i.imgs.ovh/2026/10/25/17dea6d1a3c7b73d4928d03953fdf89b.png)

对真人友好，易于辨认，但脚本验证成本较高

4：动态限流：动态调整验证流量，且可疑用户与普通用户使用隔离流量池，防止脚本影响普通用户体验

体验链接：[在线演示 · Dino Captcha](https://cdn.dinonode.org/captcha/demo.html)