Supabase /auth/v1/token接口遭请求泛滥，寻求解决方案

有没有人遇到过类似问题？ #

不少同行都碰到过这种情况——只要项目上线公网，就会有自动化脚本盯着Supabase的认证接口扫，尤其是你说的这种来自云主机IP段（比如Hostinger）的请求，大概率是在试探有没有泄露的刷新令牌，或者单纯想刷爆接口限制搞破坏。

这算不算攻击？ #

算，这是典型的自动化扫描/暴力试探攻击。对方批量调用/auth/v1/token?grant_type=refresh_token，要么是碰运气找可用的刷新令牌，要么是故意触发429错误影响你的正常服务，属于恶意请求行为。

怎么缓解和阻止？ #

第一步：先确认令牌有没有泄露 #

• 查遍你的前端代码、环境变量、第三方服务配置，确保SUPABASE_ANON_KEY和用户刷新令牌没硬编码到公开仓库（比如GitHub）里
• 去Supabase控制台的「认证 -> 令牌」页面，看看有没有异常活跃的会话，直接吊销可疑的令牌

第二步：用Supabase自带的限制功能 #

• 调速率限制：在「设置 -> API」里，把认证接口的速率限制往下调（默认是每IP每分钟100次），比如改成每IP每分钟20次，直接卡死批量请求的频率
• 加IP白名单：如果你的服务只有特定IP需要调用接口，就在「设置 -> API」里配置IP白名单，只放可信IP进来
• 开CAPTCHA：去「认证 -> 设置」开启hCaptcha或reCAPTCHA，要求刷新令牌请求必须过人机验证，直接拦死自动化脚本

第三步：手动拦可疑IP #

• 从Supabase日志里导出异常IP，然后在你的云防火墙（比如Cloudflare、自己服务器的防火墙）里把这个IP拉黑，甚至可以拉黑整个Hostinger的IP段
• 要是用了Supabase边缘函数，写个简单的中间件，检查请求的User-Agent和IP，符合特征的直接返回403

第四步：排查自家代码和第三方服务 #

• 检查前端的刷新令牌逻辑，有没有写漏导致无限循环调用接口的bug
• 核对所有第三方服务（比如支付、分析工具）的配置，确认它们没在乱调用你的认证接口

调试的最佳方式 #

• 开Supabase的详细认证日志：在「设置 -> 日志」里把认证日志级别调到DEBUG，记录完整请求参数，看看有没有重复的令牌或者异常的请求规律
• 在你的前后端加临时日志，记录合法用户的刷新请求，对比异常请求的特征（比如User-Agent、IP）
• 用curl模拟异常请求，测试你的限制措施有没有生效：

  curl -X POST 'https://你的项目ID.supabase.co/auth/v1/token?grant_type=refresh_token' \
    -H 'Content-Type: application/json' \
    -d '{"refresh_token": "测试令牌"}' \
    -A 'node'
  

内容的提问来源于stack exchange，提问作者Pratik Luitel