laravel socialite not working on live server, only works on local machine

Question

I have recently moved my application into a live server.
The problem is laravel socialite stopped working, below is the explanation:
I click on google login and after choosing email, on callback this happens:
InvalidStateException on Abstract.php on line 200.
To fixed this issue i used stateless() and now the new error is :
Client error: `POST https://www.googleapis.com/oauth2/v4/token` resulted in a `400 Bad Request` response: { "error": "invalid_request", "error_description": "Missing required parameter: code" }

Here is the list of things i have already tried:
1- In Google website, I updated google api url and callback url to new live domain addresses: http://www.domain-name.com and http://www.domain-name.com/login/google/callback

2- I have modified config/session.php file like this:
'domain' => env('SESSION_DOMAIN', 'www.domain-name.com'),

3- My storage folder is already have permission like this:
drwxrwxr-x 5 root www-data 4096 Jun 24 18:30 storage

4- I changed vendor\laravel\socialite\src\Two\GoogleProvider.php file and removed 'profile' and now it looks like this:

protected $scopes = [
'openid',
'email',
];

5- I used php artisan cache:clear , composer dump-autoload, and cleared browser cache data many times.

6- I tried $userSocial = Socialite::with('google')->user(); instead of $userSocial = Socialite::driver('google')->user(); , and i still get InvalidStateException on Abstract.php on line 200. only when i change to $userSocial = Socialite::driver('google')->stateless()->user(); the error changes to what i said at the beginning of the question.

my config/services.php file is like this:

'google' => [
    'client_id' => 'my-correct-client-id-from-google',
    'client_secret' => 'my-correct-client-secret-from-google',
    'redirect' => 'http://www.domain-name.com/login/google/callback',
],

I have been trying to fix this for 2 days now. any help would be appreciated.

Answer 1

after many hours wasted. finally found the answer:
it was nginx:
so i ran sudo nano /etc/nginx/sites-available/default

and fixed this line:

try_files $uri $uri/ /index.php?query_string; // wrong 

to

try_files $uri $uri/ /index.php?$query_string; // fixed