IP做了限制，每天的发送数量也做了限制，还有什么办法啊
是不是验证码太简单的原因。
我觉得这个是有专门的软件刷的。但是现在不知道怎么办了
走同样的路，发现不同的人生
我觉得你的程序是不是有bug，首先要排查一下什么问题出在了哪里1.更换个更难分辨的英文数字混杂的验证码，图形验证码正确后才发短信，检测到验证码输入错误后立马刷新验证码2.后台统计一下各个ip段每天触发接口的数量是否和限制数一致3.也要限制每个手机号码每天的发送数量
验证码应该能防掉一大片了，难道别人花钱专门来图像识别
你司既然对同一IP某一时间段内发送的短信数量上限进行了限制，那么这已经是满足基本限制了。再加上验证码，基本没毛病了。
这边提个建议，你可以尝试将限制规则改为：对同一手机号码，在半小时内最多发送5条短信。当然，这个30分钟、5条灵活变动哦。
这种纯数字的验证码确实太过简单,我以前用python写过爬虫,能识别出这种验证码,建议加上英文字母.另外,想想是不是自己网站有漏洞,是否有方法可以绕开验证码直接访问短信接口.还可以通过根据对方的请求头信息来拒绝访问,例如当User-Agent不是来自浏览器的时候,不过大多数爬虫都能通过这个伪装成浏览器.
恶意刷的话，才几千条，不算多吧，感觉不是恶意刷的量级
不过验证码确实太简单了，而且全是数字。可是，换个复杂一点儿的验证码也没有太大的意义，现在识别验证码的软件正确率都很高。过于复杂的又影响用户体验。最可怕的是，他们可以选择人工识别验证码。。。就是写一个脚本，做个界面，只显示验证码和一个输入框，然后再添加一些方便快速输入的按键，人要做的就是识别验证码，其他的就是脚本去做了。
几千条应该不算很多。首先你是怎么得知被恶意刷的，网站是否有其他漏洞（这个可能性比较大）
不知道你这是什么系统，我们是这样：1：用户名和密码输入正确才会下发短信验证码2：同一用户，一天限制次数。超过之后是锁账号，还是不再校验短信验证码看业务要求。
总之，短信验证码是能不发就不发...
试试阿里的JAQ，风险识别，挡机器人专用的
首先当务之急是确定问题，你要确定是否是恶意刷还是程序错误还是正常情况。最好的判断方法是日志。
短息服务商那边应该有日志，如果没有，则需要你自己写一个日志。确定问你题性质才能有解决方案。
如果目标不重复，ip不重复，几千条也不能说是恶意的。
我觉得你的程序是不是有bug，首先要排查一下什么问题出在了哪里
1.更换个更难分辨的英文数字混杂的验证码，图形验证码正确后才发短信，检测到验证码输入错误后立马刷新验证码
2.后台统计一下各个ip段每天触发接口的数量是否和限制数一致
3.也要限制每个手机号码每天的发送数量
验证码应该能防掉一大片了，难道别人花钱专门来图像识别
你司既然对同一IP某一时间段内发送的短信数量上限进行了限制，那么这已经是满足基本限制了。再加上验证码，基本没毛病了。
这边提个建议，你可以尝试将限制规则改为：对同一手机号码，在半小时内最多发送5条短信。当然，这个30分钟、5条灵活变动哦。
这种纯数字的验证码确实太过简单,我以前用python写过爬虫,能识别出这种验证码,建议加上英文字母.
另外,想想是不是自己网站有漏洞,是否有方法可以绕开验证码直接访问短信接口.
还可以通过根据对方的请求头信息来拒绝访问,例如当User-Agent不是来自浏览器的时候,不过大多数爬虫都能通过这个伪装成浏览器.
恶意刷的话，才几千条，不算多吧，感觉不是恶意刷的量级
不过验证码确实太简单了，而且全是数字。可是，换个复杂一点儿的验证码也没有太大的意义，现在识别验证码的软件正确率都很高。过于复杂的又影响用户体验。最可怕的是，他们可以选择人工识别验证码。。。就是写一个脚本，做个界面，只显示验证码和一个输入框，然后再添加一些方便快速输入的按键，人要做的就是识别验证码，其他的就是脚本去做了。
几千条应该不算很多。
首先你是怎么得知被恶意刷的，网站是否有其他漏洞（这个可能性比较大）
不知道你这是什么系统，我们是这样：
1：用户名和密码输入正确才会下发短信验证码
2：同一用户，一天限制次数。超过之后是锁账号，还是不再校验短信验证码看业务要求。
总之，短信验证码是能不发就不发...
试试阿里的JAQ，风险识别，挡机器人专用的
首先当务之急是确定问题，你要确定是否是恶意刷还是程序错误还是正常情况。最好的判断方法是日志。
短息服务商那边应该有日志，如果没有，则需要你自己写一个日志。确定问你题性质才能有解决方案。
如果目标不重复，ip不重复，几千条也不能说是恶意的。