Cookie验证无法可靠拦截爬虫，因多数爬虫不支持或忽略Cookie；需结合Referer/U-A检查、JS挑战、频率限制等构成多层防护。
PHP不能单靠Cookie验证可靠拦截爬虫，因为绝大多数爬虫（尤其是简单HTTP爬虫）不支持Cookie或会主动忽略。但可以结合Cookie与其它机制形成基础防护层，对低级爬虫有一定效果。
Cookie验证的基本逻辑
核心思路是：用户首次访问时生成一个服务端可校验的Cookie，后续请求必须携带该Cookie且通过验证才放行。关键点在于Cookie值不能简单随机，需包含服务端可控的签名或时效信息。
- 用 setcookie() 设置带 HttpOnly、Secure（HTTPS下）、SameSite=Strict 的 Cookie，降低被JS篡改或跨站窃取风险
- Cookie值建议为加密字符串，例如：base64_encode(serialize(['token' => $random, 'ts' => time(), 'sig' => hash_hmac('sha256', "$random|$time", $secret)]))
- 每次请求时读取 Cookie，反解并验证时间戳（如10分钟内有效）、签名是否匹配，任一失败即拒绝响应
单独用Cookie验证为何效果有限
很多爬虫（如 curl、requests 默认行为、Scrapy 简单配置）根本不会自动处理 Set-Cookie 和后续携带；即使模拟浏览器，也只需一次解析+重放即可绕过。所以它本质是“防君子不防小人”。
- 无头浏览器（Puppeteer、Playwright）能完整执行 JS 并管理 Cookie，轻松绕过
- 高级爬虫可提取登录流程中的 Cookie 生成逻辑，批量伪造合法凭证
- 静态页面爬取（如只抓首页HTML）往往连首次请求都不需要，直接 GET 就拿到内容
更实用的组合策略（推荐）
将 Cookie 验证作为多层防护中的一环，配合其他低成本手段提升门槛：
立即学习“PHP免费学习笔记（深入）”；
- Referer + User-Agent 检查：拒绝空 Referer 或明显非浏览器 UA（如 python-requests、curl）的请求，注意移动端和搜索引擎需白名单
- JavaScript 挑战前置：首页返回含简单 JS 计算的 HTML（如执行 Math.pow(2,10)），结果拼入后续请求参数或 Cookie，服务端校验
- 请求频率限制：用 Redis 记录 IP 的请求数（如 /api/ 接口 60秒内≤5次），超限返回 429 或跳转验证码页
- 关键接口 Token 化：不依赖 Cookie，而是每个页面动态注入一次性 Token（如 form hidden 字段或 API 请求头 X-Token），后端比对并立即失效
代码片段示意（简化版）
以下仅为验证逻辑示意，生产环境需加异常处理、日志和防时序攻击：
// 生成并设置验证 Cookie
$token = bin2hex(random_bytes(16));
$ts = time();
$sig = hash_hmac('sha256', "$token|$ts", $_ENV['COOKIE_SECRET']);
$payload = base64_encode(json_encode(compact('token', 'ts', 'sig')));
setcookie('v', $payload, [
'expires' => time() + 600,
'path' => '/',
'domain' => '',
'secure' => true,
'httponly' => true,
'samesite' => 'Strict'
]);
<p>// 请求入口处验证
if (empty($_COOKIE['v'])) {
http_response_code(403);
exit('Access denied');
}
$data = json_decode(base64_decode($_COOKIE['v']), true);
if (!$data || !isset($data['token'], $data['ts'], $data['sig']) ||
time() - $data['ts'] > 600 ||
!hash_equals(hash_hmac('sha256', "{$data['token']}|{$data['ts']}", $_ENV['COOKIE_SECRET']), $data['sig'])) {
http_response_code(403);
exit('Invalid or expired token');
}</p> 
