Laragon with Guzzle not closing http connections cleanly

[whitsey]

I am at a loss. Code that used to work fine on pre-existing environments now wont work on laragon and my research has lead me down the path that it is the laragon environment that doesn't cleanly close connections and I dont know how that could be possible.
I have a loop which takes data and pushes it to a http endpoint.
However, when looping to the 2nd dataset, it just hangs because the initial connection is waiting to "close" and never closes (until I kill the web server) and it never processes the 2nd batch

Hoping someone can tell me if this is in fact a problem with my laragon environment
Laragon 2025 v8.2.3
PHP 8.3.16
Nginx 1.27.3
Guzzle 6.5.5
cURL 8.7.0‑DEV

Here is my code:

foreach ($dealer as $dealer_id) {

	$stockFeedId = $this->customer->createStockFeed( $dealerId );
	
	if ( $stockFeedId )
	{
		$postResult = $this->customer->postStockFeed( $stockFeedId, $dealerId, $this->attachment );
	}	
}


function getHttpClient()
	{
		if (!$this->httpClient) {
			$this->httpClient = new Client([
				'base_uri' => $this->settings["server"],
				'verify' => false, // Dont validate the SSL in testing (self-signed SSL will throw error)
				'headers'  => [
					'Content-Type' => 'application/json',
					'apikey'       => $this->settings['api_key']
				]
			]);
		}

		return $this->httpClient;
	}
	
	function createStockFeed($dealerId) {
		
		$client = $this->getHttpClient();
		$referenceId = $dealerId . date('YmdHis');

		try 
		{
			
error_log(ENDPOINT["CREATE"]);
error_log(">> About to call Guzzle post for dealer $dealerId");

			$response = $client->post( ENDPOINT["CREATE"], [
				'json' => [
					'region' => 'au',
					'reference_id' => $referenceId
				],
				'curl' => [
					CURLOPT_VERBOSE => true,
					CURLOPT_STDERR => fopen('guzzle-curl.log', 'a'),
					CURLOPT_FORBID_REUSE => true,
					CURLOPT_FRESH_CONNECT => true
				],
			]);
error_log("<< Guzzle post returned for dealer $dealerId");
			$data = json_decode($response->getBody(), true);

error_log("Check if we have retrieved a valid stock id");

			if (isset($data['stock_feed_id'])) 
			{
				error_log( "Stock Feed ID Created: " . $data['stock_feed_id']. " (with referenceId: $referenceId)" );
				return $data['stock_feed_id'];
			} 
			else 
			{
				error_log( "Error: stock_feed_id not found in response: ".print_r($data,true) );
				return false;
			}
			
			error_log("Check if we have retrieved a valid stock id");
		} 
		catch (RequestException $e) 
		{
			error_log( "Error creating stock feed: " . ($e->hasResponse() ? $e->getResponse()->getBody()->getContents() : $e->getMessage()) );
			var_dump($client);
			return false;
		}
	}

error_log:

[27-Jan-2026 16:33:28 Australia/Victoria] /mock.api.php
[27-Jan-2026 16:33:28 Australia/Victoria] >> About to call Guzzle post for dealer xxx
[27-Jan-2026 05:33:28 UTC] Array
(
    [Content-Length] => 55
    [Content-Type] => application/json
    [User-Agent] => GuzzleHttp/6.5.5 curl/8.7.0-DEV PHP/8.3.16
    [Apikey] => XXX
    [Host] => absee.local
)
[27-Jan-2026 16:33:28 Australia/Victoria] Error creating stock feed: {"error":"Invalid API key"}
[27-Jan-2026 16:33:28 Australia/Victoria] Done processing email#1
[27-Jan-2026 16:33:29 Australia/Victoria] /mock.api.php
[27-Jan-2026 16:33:29 Australia/Victoria] >> About to call Guzzle post for dealer xxx
[27-Jan-2026 16:37:02 Australia/Victoria] Error creating stock feed: cURL error 56: Recv failure: Connection was reset (see https://curl.haxx.se/libcurl/c/libcurl-errors.html)

log.txt:

2026-01-27T05:33:28+00:00 - Start API
2026-01-27T05:33:28+00:00 - End API

guzzle-curl.log:

* Host localhost:443 was resolved.
* IPv6: (none)
* IPv4: 127.0.0.1
*   Trying 127.0.0.1:443...
* Connected to localhost (127.0.0.1) port 443
* ALPN: curl offers http/1.1
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: C=SG; ST=Singapore; L=Singapore; O=Laragon; OU=Server; CN=laragon
*  start date: Oct 22 00:38:37 2025 GMT
*  expire date: Oct 22 00:38:37 2026 GMT
*  issuer: C=SG; ST=Singapore; L=Singapore; O=Laragon; OU=Server; CN=laragon
*  SSL certificate verify result: self-signed certificate (18), continuing anyway.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* using HTTP/1.x
> POST /mock.api.php HTTP/1.1
Host: localhost
apikey: XXX
User-Agent: GuzzleHttp/6.5.5 curl/8.7.0-DEV PHP/8.3.16
Content-Type: application/json
Content-Length: 55

* upload completely sent off: 55 bytes
< HTTP/1.1 200 OK
< Server: nginx/1.27.3
< Date: Tue, 27 Jan 2026 05:37:22 GMT
< Content-Type: application/json
< Content-Length: 149
< Connection: keep-alive
< X-Powered-By: PHP/8.3.16
< 
* Closing connection

[leokhoa]

@whitsey : We are looking into this issue now and will follow up with you.

In the meantime can you please check with?:

1. Nginx with PHP Non Thread Safe (nts) version.
2. Apache with PHP Thread Safe (ts) and Non Thread Safe (nts) version

[whitsey]

Nginx with php-8.3.16-Win32-vs16-x64
(nts)

[leokhoa]

@whitsey : We can't reproduce the issue. It could be related to the data. Can you keep testing with Apache, both PHP TS and NTS?

[whitsey]

Sorry, I was using php-8.3.16-Win32-vs16-x64 [TS], I changed to PHP 8.1.30 [NTS] but same issue.
notably, I set a timeout which forced disconnection - it looks like it connects every second loop perfectly but fails every other alternate attempt

I've posted into stack with guzzle tag - maybe someone will know something
https://stackoverflow.com/questions/79878360/cant-get-guzzle-to-disconnect-cleanly

[leokhoa]

@whitsey: What you posted on Stackoverflow is great. I've been able to consistently replicate the issue with Nginx across several setups.
Interestingly, the exact same code runs without any problems under Apache (both Thread-Safe and Non-Thread-Safe builds on PHP 8.1/8.2/8.3/8.4/8.5). That's why you don't have the problem in your previous environment because you used Apache. In the meantime, please use Apache. I am keep investigating and working on a fix/workaround to help you to solve the issue with Nginx. I'll post an update here as soon as I have progress.

[leokhoa]

@whitsey : Thanks for your patience.

I have made some improvements to Nginx and tested things pretty thoroughly to fix your issue. I also ran a lot of tests to make sure it's working reliably now.

It looks like the main problem was that the default number of PHP processes was too low. That can cause timeouts when the app calls itself over HTTP (via Guzzle). I couldn't reproduce it at first because I was testing via CLI.

What's improved:

• Auto-detect if PHP CGI port 9003 is already in use and switch to another port
• Detect when PHP processes are set too low and enforce a minimum of 4
• Let you configure the number of PHP processes via the Upstream setting (Just click the Reload button to see the effect).

# Increase PHP processes by setting Upstream in (Menu > Laragon > laragon.ini) under [nginx] section
# Upstream=10

Let me know if you still run into any issues.
Please download the hotfix here (Laragon v8.5.1 20260205):
https://github.com/leokhoa/laragon/blob/master/laragon.exe

[whitsey]

Worked! I added Upstream=10 to the existing laragon.ini and it worked for 10 loops then locked.
I then replaced the laragon.exe and ran it and it completed all connections successfully in a timely fashion.
Thanks for your persistence.

[AWqxKAWERbXo]

@whitsey also, it's highly recommended to use an up to date version of Guzzle.

Your version is known for security issues and there are even newer version in the 6.x branch.

The current version is 7.10

[leokhoa]

That's awesome! Really happy to hear that. Thanks for the update, and Alex's advice is valuable, as security issues always catch up with you eventually. You may need to upgrade to PHP 8.5, too if performance is your concern. I performed many tests to make sure works great with the latest Guzzle and all PHP versions 8.1-8.5, both TS and NTS.