必须在服务端实现IP限频，前端无法可靠获取真实客户端IP；后端需基于X-Forwarded-For等可信请求头提取并清洗IP，用Redis滑动窗口（ZSET+Lua）统计60秒内请求次数，超阈值返回429，且须叠加submit_token与幂等键等多重防护。
同一IP限频必须在服务端实现
HTML表单本身不感知IP，form标签和前端JS无法可靠获取真实客户端IP（尤其经过CDN、代理或NAT后），更无法统计或拦截。所谓“限制同一IP提交次数”，完全是后端职责，前端最多配合传递标识（如session ID、token）或展示友好提示。
后端如何做IP级限频（以常见场景为例）
核心是：在接收POST请求的入口处，基于请求头中可信的IP字段（如X-Forwarded-For最右非私有IP，或X-Real-IP），结合时间窗口计数。不能只依赖RemoteAddr，它在反向代理下通常是127.0.0.1或内网地址。
- 用Redis做滑动窗口计数：
INCRkey为ip_limit:{client_ip}:{action_type}，配EXPIRE60秒；超阈值（如5次/分钟）直接返回429 Too Many Requests - 注意清洗IP：剔除
127.0.0.1、::1、私有网段（10.0.0.0/8,172.16.0.0/12,192.168.0.0/16），否则本地开发或内网测试会误杀 - 别把IP当唯一身份：NAT环境下千人共一IP，过度限制会伤及正常用户；应作为辅助手段，与
submit_token、用户登录态、设备指纹等叠加使用
前端要不要传IP？传了也没用
前端用fetch或XMLHttpRequest无法读取真实IP，navigator.connection或WebRTC泄露IP属于隐私违规且不可靠。试图用JS拼接location.href或User-Agent伪造IP字段，后端必须忽略——所有客户端传来的IP都不可信。唯一该前端做的，是提交失败时根据HTTP状态码（如429）提示用户“操作太频繁，请稍后再试”，而不是刷新页面重试。
容易被忽略的关键点
IP限频不是开箱即用的安全补丁。它对动态IP用户（如移动网络）、校园网出口、企业防火墙后用户极不友好；若没配好代理头解析逻辑，可能把整个公司IP封掉；若没结合业务ID（如“注册表单”“评论接口”）做分维度限频，一个恶意用户刷评论就能卡死别人的注册流程。真正健壮的防重，永远是submit_token + 用户态幂等键 + 数据库唯一约束三层兜底，IP限频只是最外层沙袋。
立即学习“前端免费学习笔记（深入）”；
