429: Too Many Requests

[marlboro]

Hi, I have been trying for the better part of a week to diagnose why my Laravel 5.7 based API has suddenly started having issues with throttling (429: Too Many Requests). I have (for years) logged every request via a custom middleware and I don't see nearly enough requests to constitute any throttling. To confirm this I have run Wireshark on both the affected client and the web server during the affected periods. This confirmed that maybe 20 requests happened before my service started responding with the 429: Too Many Requests. I'm lost as to how to proceed with troubleshooting.

Environment:
IIS 10, PHP 7.1.26, Laravel 5.7.25.

Kernel.php

        'api' => [
            'throttle:120,1',
            'bindings',
             \App\Library\Cobalt\Http\Middleware\LogMiddleware::class,
        ],

Thanks in advance.

[staudenmeir]

Have you added logging to the ThrottleRequests middleware?

[marlboro]

No, but that is a great idea for a next step. I will update when I know more.

[Helveg]

@marlboro if you posted your question elsewhere, could you link it? I'm having similar issues.

[marlboro]

@Helveg No, but it's a bug or configuration issue with either PHP or Laravel. Originally this particular API was only called by one device and there were no issues. We added a second device and suddenly the 429's started. I would have expected each device (unique IP's) to get N requests before they got throttled. That is not the case or I would not be having issues.

I ended up just increasing the throttle value large enough to make it stop issuing 429's. It's hacky, and I hate it, but I had no other choice. Post a link if you get help somewhere else.

[r9software]

I got the same issue, my throttle was set to 270, and it is still happening, I believe it should be an issue with laravel, because there is no way for me to have 270 calls to my api from one device of testing in 1 minute

[playerrtwo]

I'm currently converting my web app UI to an SPA and running into the same issue. I get the error sporadically when I'm sure I'm nowhere near the limit.

[kristijorgji]

This can happen if you have frontend bugs, happened to me as well during infinite reload and SPA was making AJAX calls all the time. Check and fix your JS as well

[EvilLooney]

Just posting this if anyone else was getting the same error.

I was using Memcached as my cache store and after debugging through telnet, I found that it was never expiring my keys. I had to manually restart the service to fix the problem.

Homestead with memcached version 1.5.6.

[cmple]

@EvilLooney Your comment seems the most reasonable!
I'm also having this issue with Laravel 8 and PHP8.1 with Memcached on alpine docker.
Were you able to resolve this issue on your without having to restart the caching service?
Thanks!

[bissolli]

Did anyone find out the problem? We're facing same issues here.

[davidkryzaniak]

Same issue. Laravel 5.7, IIS10, PHP 7.3.

[Helveg]

It's a sporadic recurring issue, all or most of us reporting the issue face it in controlled testing environments as well where we're sure to be nowhere near the limit. @driesvints can we get some feedback, troubleshooting tips or a timeline on this?

Is there maybe a way that we can log every time a supposed request gets us closer to the throttle limit to debug it?

[Helveg]

Also a firefighting tip: you can clear the throttle if it hits your production environment with:

php artisan cache:clear

[mutiaramahee]

Woah, worked. Thanks

[vicandam]

work for me thanks.

[antoniosthanasisgit]

ty!

[denaachmad27]

Worked.. Thanks !

[winner00kambale]

thanks a lot

[davidkryzaniak]

@Helveg Yes, logging can be done on the client. Look in the headers of the response. It should look something like this:

DK@DK:~$ curl -I -X POST http://localhost/fake/path
HTTP/1.1 400 Bad Request
Date: Tue, 01 Oct 2019 20:29:45 GMT
Server: Apache/2.4.39 (Fedora) OpenSSL/1.1.1b
X-Powered-By: PHP/7.2.19
Cache-Control: no-cache, private
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 59
Connection: close
Transfer-Encoding: chunked
Content-Type: application/json

You're looking for X-RateLimit-Limit and X-RateLimit-Remaining

The issue I was having was in the Kernel. Inside of $middlewareGroups under api, 'throttle:120,1' was not being respected. As seen in the headers above, it was always set to 60. Here's what I needed to do to fix it:

/* ... */

protected $middlewareGroups = [
    'web' => [
        /* .. */
    ],

    'throttle' => ['throttle:99,1'], //No idea why, but this works!

    'api' => [
        'throttle:5000,1', //These values did not change the throttle limit.
        'bindings',
    ],
];

/* ... */

I found this by adding some dump()'s here: https://github.com/laravel/framework/blob/5.7/src/Illuminate/Routing/MiddlewareNameResolver.php#L29

[pellexa]

'throttle' => ['throttle:99,1'], //No idea why, but this works!

This works because the throttle middleware is registered here for the /token route.

[kelvinthiongo]

You just saved my multimillion dollars project.

[billanguyen1990]

i like it,

[ajaykumar890]

thanks for this wonderful answer

[dangminhtruong]

@kelvinthiongo He saved my unicorn startup 😄

[prabodhana]

Also a firefighting tip: you can clear the throttle if it hits your production environment with:

php artisan cache:clear

worked thanks

[jehnsen]

but you don't wanna run "php artisan cache:clear" command in prod right?

[akshayagarwal]

I had to remove the throttling from the api middleware in app\Http\Kernel.php. Just delete the following line in app\Http\Kernel.php

'throttle:60,1',

[Helveg]

That's not very good advice: the throttle is there for good reasons. You're now vulnerable to being spammed with requests such as login requests. Never advice to completely disable security measures even if they aren't functioning properly

[akshayagarwal]

That's not very good advice: the throttle is there for good reasons. You're now vulnerable to being spammed with requests such as login requests. Never advice to completely disable security measures even if they aren't functioning properly

I do agree that any good system architecture should incorporate the necessary security measures. However, these measures should be supplemented with a good understanding of the internals. My response was in the context of the specific OP query assuming they know what they are doing, and not a general system architecture advice.

Also, most apps would use the web middleware for website functions such as Login. Laravel 6.x does not enforce any throttling for this middleware out-of-the box so it would be vulnerable to spamming, unless the developer knows what they are building and incorporates the necessary guards.

Your thoughts are absolutely valid and I appreciate you providing the helpful perspective here. I just wanted to make sure that people who find the solution helpful would know what they are working with.

Cheers!

[Isurumayanga97]

how to increase request limit in laravel.

[AsifMian]

in app\Http\Kernel.php

'api' => [

        'throttle:2,1', //means 2 requests per minute we can increase it to as we want like 200000
       
    ],

[sloan58]

FWIW - I was causing this issue with the "infinite loop" situation with useEffect() in React. I added the empty array to stop triggering repeated requests.

[Rizzeol]

Hi @sloan58 Can you explain what exactly you did? php artisan cache:clear didn't worked for me. I think it is because of useEffect() in my react app.

Thanks in advance. :)

[sloan58]

Hi @Rizzeol,

Sure thing! There's a second parameter you can pass to useEffect to specify the data you want to watch so that useEffect fires when that data changes. If you pass an empty array (don't watch anything), it won't keep re-rendering when the component updates.

useEffect(() => {
    doSomethingOnce();
}, []);

[oussematn]

i do not recommend removing throttling, it's a huge security risk,like DOD and DDOS attacks

[fightborn]

You can, and should rate limit using the webserver, not using PHP itself. It's one of the worst decisions ever. You won't avoid DDOS using Laravel's rate limiting, it still needs to accept the request, check if it's over the limit and then send the output. You effectively did nothing to prevent DDOS.

The only sane decision is to approach the rate limiting without involving PHP as you want the request to be denied before it even makes PHP do any processing at all.

Throttling via nginx is trivial, easy to understand and best part: actually works.

[paras-malhotra]

Nginx throttling is good for sure, but that doesn't mean Laravel throttling is bad. There are different use cases for both. For instance, you may be able to throttle by IP address with Nginx, but throttling by username or a combination of username/IP or say user ID would be a better case for Laravel.

Also, DDOS attacks are distributed. Even Nginx can't save you from DDOS. There are other strategies for those kinds of attacks.

[hardikpoojara]

Hello,

I tried to comment
//'throttle' => \Illuminate\Routing\Middleware\ThrottleRequests::class,
and
'api' => [ //'throttle:60:1', \Illuminate\Routing\Middleware\SubstituteBindings::class, ],

It worked for me. Sorry for the typo

[ErickOrtegaG]

Hi everyone, so, is there a proper way to fix this issue without disabling throttle if I'm using Sanctum for my API authentication and Fortify for my web authentication?

[tonipepperoni]

My guess is that you're using a login proxy to passport so server is requesting tokens rather than the user. You should disable the throttling specifically for localhost (ips from server).

[xbrln]

Am using Laravel 8 for my API and I have a couple of clients accessing my API. Recently I started to get 429 HTTP response after I added some new clients.

What I found out is that, by default rate limit is not IP specific, so when I added more clients (each client has its own IP) I started to get 429. I modified rate limit to use IP and this solved the issue for me.

This is how I did that.

File path app/Providers/RouteServiceProvider.php
Before (IP agnostic rate limiting)

RateLimiter::for('api-rate-limit', function (Request $request) {
    return Limit::perMinute(120);
});

After (IP aware rate limiting)

RateLimiter::for('api-rate-limit', function (Request $request) {
    return Limit::perMinute(120)->by($request->ip());
});

More information on how to do this with Laravel 8 can be found here. And also there is a nice explanation about it in Laracasts. It is also possible to set up rate limiting per route, (for example api/images) instead of a route group like api/.

Also to keep in mind is that this is Laravel 8 way of rate limiting. For versions below 8, rate limiting is done differently. But I assume it is possible to rate limit per IP and per route in versions below 8.

Also I think, in general, it is worthwhile to try out IP specific and/or route specific rate limit instead of removing rate limit completely or increasing rate limit to a very high value.

[nagra]

Since you can get people on the same IP, you can also change it to use the Bearer token of the user.
This is how twitter API does it.

[ShekhSaifuddin007]

In laravel version above 7.x php artisan optimize:clear will help you

[salanta-net]

if someone is using Fortify there is a 'limiters' of five request per minute. Just comment the 'login' it!

/*
|--------------------------------------------------------------------------
| Rate Limiting
|--------------------------------------------------------------------------
|
| By default, Fortify will throttle logins to five requests per minute for
| every email and IP address combination. However, if you would like to
| specify a custom rate limiter to call then you may specify it here.
|
*/

'limiters' => [

// 'login' => 'login',
'two-factor' => 'two-factor',
],

[antoniosthanasisgit]

 protected $middlewareGroups = [
        'web' => [
            \App\Http\Middleware\EncryptCookies::class,
            \Illuminate\Cookie\Middleware\AddQueuedCookiesToResponse::class,
            \Illuminate\Session\Middleware\StartSession::class,
            // \Illuminate\Session\Middleware\AuthenticateSession::class,
            \Illuminate\View\Middleware\ShareErrorsFromSession::class,
            \App\Http\Middleware\VerifyCsrfToken::class,
            \Illuminate\Routing\Middleware\SubstituteBindings::class,
        ],

        'api' => [
            // \Laravel\Sanctum\Http\Middleware\EnsureFrontendRequestsAreStateful::class,
            'throttle:200,1',
            \Illuminate\Routing\Middleware\SubstituteBindings::class,
        ],
    ];

[i-bajrai]

I experiences this because it was IP address driven and perhaps the users internet provider reused the IP addresses of their customers making anonymous users appears to be the same person, hitting too many times.

Has anyone else experienced this?

I want to suggest it might be cloudflare related but I think the code accounts for the use of cloudflare's request headers.

[cmple]

@marlboro were you able to resolve this issue? If so, how?
Thanks man!

[jorgeart81]

Definig Rate Lminters

`use Illuminate\Cache\RateLimiting\Limit;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\RateLimiter;

/**

• Configure the rate limiters for the application.
• @return void
  */
  protected function configureRateLimiting()
  {
  RateLimiter::for('global', function (Request $request) {
  return Limit::perMinute(1000);
  });
  }`

[janzcio]

@marlboro I have experienced this kind of issue and made me panic. My solution is to change the CACHE_DRIVER to array in your .env file.
CACHE_DRIVER=array