Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

wreckless's avatar

cURL errors 35 and 6 after upgrade to Laravel 9

Hey All,

I upgraded from Laravel 8 to Laravel 9 over the weekend, and since then my load-balanced queue (horizon) servers have intermittently become unresponsive, and logs show a bunch of cURL errors. The two main errors I'm seeing are:

cURL error 35: OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to xxxx.myshopify.com:443 (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://xxxx.myshopify.com/admin/api/2022-07/graphql.json {"exception":"[object] (GuzzleHttp\\Exception\\ConnectException(code: 0): cURL error 35: OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to xxxx.myshopify.com:443 (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://xxxx.myshopify.com/admin/api/2022-07/graphql.json at /home/forge/mysite/releases/20230523030942/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:210)

cURL error 6: Could not resolve host: xxxx.myshopify.com (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://xxxx.myshopify.com/admin/api/2022-07/graphql.json {"exception":"[object] (GuzzleHttp\\Exception\\ConnectException(code: 0): cURL error 6: Could not resolve host: xxxx.myshopify.com (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://xxxx.myshopify.com/admin/api/2022-07/graphql.json at /home/forge/mysite/releases/20230523030942/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:210)

Other than the code and framework update, there have been no changes to my servers (5 of them, all Ubuntu 20, php 8.1) of any kind. I initially suspected that maybe an older cURL or OpenSSL version was the culprit, so I upgraded those, but still had the problem. I then spun up a new server via Forge with the latest everything (Ubuntu 22, php 8.2) and still got the error, though it was slightly different, presumably due to a different OpenSSL version (v3) on the new server. The error is:

cURL error 35: error:0A000410:SSL routines::sslv3 alert handshake failure (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://xxxx.myshopify.com/admin/api/2022-07/graphql.json {"exception":"[object] (GuzzleHttp\\Exception\\ConnectException(code: 0): cURL error 35: error:0A000410:SSL routines::sslv3 alert handshake failure (see https://curl.haxx.se/libcurl/c/libcurl-errors.html) for https://xxxx.myshopify.com/admin/api/2022-07/graphql.json at /home/forge/mysite/releases/20230523175258/vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php:210)

As another point of reference, though its hard to verify, it does seem like this happens when a large volume of jobs are being processed.

Do you think this has something to do with server config, even though even the new server is having the same issue? Or is this a Laravel or Guzzle/CurlFactory thing? I suppose the issue could also be with DNS?? I'm totally at a loss here, so any thoughts or assistance is greatly appreciated! Cheers!

0 likes
11 replies
LaryAI's avatar
LaryAI
AI
2 years ago
Level 58

The cURL errors 35 and 6 are related to SSL connection issues. The error message suggests that there might be a problem with the SSL certificate or the DNS resolution. Here are a few things that you can try to resolve the issue:

  1. Check if the SSL certificate is valid and not expired. You can use an online SSL checker tool to verify the SSL certificate.

  2. Check if the DNS resolution is working correctly. You can use the nslookup command to check if the domain name is resolving to the correct IP address.

  3. Try disabling SSL verification temporarily to see if that resolves the issue. You can do this by setting the verify option to false in the Guzzle client configuration. Here's an example:

    $client = new \GuzzleHttp\Client([
    'verify' => false,
]);

    Note that disabling SSL verification is not recommended in production environments.

  4. Try upgrading the cURL and OpenSSL libraries to the latest version.

  5. Check if there are any firewall rules or network restrictions that might be blocking the connection.

  6. Try increasing the cURL timeout value to see if that helps. You can do this by setting the timeout option in the Guzzle client configuration. Here's an example:

    $client = new \GuzzleHttp\Client([
    'timeout' => 60,
]);

    This will set the cURL timeout to 60 seconds.

If none of the above solutions work, you might want to consider contacting your hosting provider or the Shopify support team for further assistance.

kayex's avatar

Any luck yet with this? I'm seeing similar issues with recent updates.

wreckless's avatar

I haven't figured anything out yet. Per the suggestion of Lary AI, I did set my Guzzle client's verify config option to false, but that didn't work either.

@kayex, when you say that you're seeing similar issues with recent updates, what exactly are you referring to? Is this happening to you also after an upgrade from Laravel 8 to 9? Or do you mean with Shopify, which is where I'm getting these errors? Or are you referring to updates of something else? I'd love to find any similarities to attempt to pin point the source. As it stands, I'm still no closer to figuring out who/what the culprit is here, let alone solving the issue.

kayex's avatar

@wreckless Did a Laravel 8 to 10 update. Happening with connections to a Soketi server for me.

wreckless's avatar

@kayex Thanks, and interesting. That adds at least one more data point on the side of "something changed in Laravel to trigger this". How frequently does it happen to you? Is it all the time, or just intermittently? Does your app ever make a large number of calls at once, or process a large number of jobs at once? If so, do those mass calls/jobs correlate to when you see the cURL errors? This seems to be my case.

I found this SO post that may be related: https://stackoverflow.com/questions/70669106/nginx-curl-error-getaddrinfo-thread-failed-to-start

While its not the exact scenario, the OP is using Laravel, and it seems to be caused by hitting server limits. I'm going to continue to pull on this thread. Let me know if your scenarios line up with this train of thought or not, please! Cheers.

wreckless's avatar

I think I've narrowed the issue down to running RateLimited middleware on my jobs. Here's an example of what I'm doing:

public function middleware()
    {
        $rateLimitedMiddleware = (new RateLimited())
            ->allow(40)
            ->everySeconds(20)
            ->releaseAfterSeconds(22)
            ->key('userjobthrottle-' . $this->userId);

        return [$rateLimitedMiddleware];
    }

All of the jobs that this applies to make an HTTP call to an external endpoint using GuzzleHttp/Client. If there are 500 jobs (for a specific user), this would result in 500 being added to the queue, ~40 processed (within 20 seconds), then the rest are pulled from the queue. Then, after 22 seconds, the remaining ~460 are put back on the queue and the next ~40 are processed.

Why is this causing Guzzle to throw cURL errors like it can't resolve the target website? Are connections to redis while managing the throttled jobs being exhausted somehow, such that some underlying service (host name resolution?) can't function any more?

In the end, I need to ensure that no more than 2 calls per second are made to the external endpoint. Is there a better way to do this?

wreckless's avatar
wreckless
OP
2 years ago
Best Answer
Level 1

This may have been contributing to reaching whatever limits were in place, but after more testing I found that this particular code was not the root cause. I'm still not sure what the exact root cause is. But, I've now deployed servers with upgraded OS (Ubuntu 18.04 -> 22.04), upgraded PHP (8.1 -> 8.2), and, generally, upgraded software from the original servers and the problem has gone away. So, the issue seems to be with Laravel and/or Guzzle and whatever server software versions or configuration differences existed in the originally-launched Forge servers vs the newly launched Forge servers. I would be good to know the exact cause of the issue, but, at least the issue has now been resolved. For anyone else experiencing cURL error 6 errors after upgrading Laravel, try updating your servers as well.

georaldc's avatar

Could be guzzle related. I manage an app that doesn't use Laravel, but uses the Flysystem package to work with Google Cloud Storage. We were using an old version of Guzzle (6.3.3) for the longest time and that worked fine. When I updated Guzzle to the latest supported version (7.8.0), I started seeing really intermittent curl 35 "TCP connection reset by peer" errors from code making calls to Google Cloud Storage through Flysystem. Our code was using Google's included retry algorithm, which would only retry Server 5xx error codes, so curl/connection errors were being left alone. I still haven't figured out what could have changed (other than the user agent changing between guzzle versions, which we were not modifying) but the errors immediately started occurring right after the guzzle upgrade.

georaldc's avatar

Another difference I just realized is a change that occurred in Guzzle fairly recently

https://github.com/guzzle/guzzle/pull/3075

Where they changed the default curl connect timeout config value from 150 seconds to 300 seconds (interestingly, both behaviors were never even made obvious when looking at the official docs, which today still states that the default "connect_timeout" value is 0 seconds, or to wait indefinitely). I don't know much about networking internals, but this probably might be related since now, curl will wait twice as long for a connection to succeed, making it possible for a new set of side effects to occur with different curl error codes (such as the other end cutting the connection?)

JohnWickX's avatar

Hi, I'm having the exact same problem as you. My current version is:

CentOS Linux release 7.6
PHP 7.4.30
Laravel Framework 8.83
OpenSSL 1.0.2k-fips
curl 7.29.0

My application has a lot of api to requests, and I have added verify => false to the Guzzle requests, but I still find a lot of cURL error 35: OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to api.example.com:443 in the LOG file.

This error occurs randomly.

I tried adding

‘curl’ => [
                    CURLOPT_SSLVERSION => CURL_SSLVERSION_TLSv1_2,
                ]

and forcing IPv4 have no effect.

Seeing that your solution is to upgrade to use a new environment, I decided to give it a try.

Please or to participate in this conversation.