PHP API Request Times Out Even Though Endpoint Works

Question

```php

```
I am trying to make a PHP request to an external API, but the request periodically times out even though the API endpoint itself appears to be online and responding normally when I test it directly.

The problem does not happen on every request. Some requests complete in less than a second, while others wait until the timeout limit is reached.

I am trying to determine whether this is more likely to be caused by my PHP configuration, the remote API, DNS/network latency, or the way I am handling the request.

Current PHP code
```php

Miles Rivera · Accepted Answer

To isolate the cause of the intermittent 28‑error you can add a few diagnostics and then decide whether a retry policy is appropriate.

1. Collect timing data for each request 
```php
 $ch = curl_init($url);
 curl_setopt_array($ch, [
 CURLOPT_RETURNTRANSFER => true,
 CURLOPT_CONNECTTIMEOUT => 10,
 CURLOPT_TIMEOUT => 30,
 CURLOPT_FOLLOWLOCATION => true,
 CURLOPT_HTTPHEADER => ['Accept: application/json'],
 ]);

$response = curl_exec($ch);

if ($response === false) {
 $error = curl_error($ch);
 $info = curl_getinfo($ch);
 error_log("cURL error: $error");
 error_log("Connect time: {$info['connect_time']}s, Total time: {$info['total_time']}s");
 } else {
 // normal handling
 }
 curl_close($ch);
```
 * connect_time shows DNS + TCP handshake. 
 * total_time is the full round‑trip. 
 * pretransfer_time can reveal TLS negotiation delays.

Store these values in a log or a database column so you can spot patterns (e.g., spikes after a certain hour).

2. Check DNS resolution separately 
```bash
 dig api.example.com +time=5
```
 If the lookup sometimes takes >5 s, the DNS server is the culprit. Switch to a more reliable resolver (e.g., 8.8.8.8) or enable CURLOPT_DNS_CACHE_TIMEOUT.

3. Verify the remote server’s health 
 * Use a monitoring tool (e.g., curl -w "%{http_code} %{time_total}n" -o /dev/null -s https://api.example.com/products) to see if the endpoint itself sometimes returns 5xx or 429. 
 * Look at the API provider’s status page or rate‑limit headers (X-RateLimit-Remaining, Retry-After).

4. Inspect server‑side limits 
 * PHP‑FPM workers: pm.max_children, pm.max_requests. 
 * Web‑server timeouts: ProxyTimeout (Apache) or proxy_read_timeout (NGINX). 
 * Firewall rules: iptables -L -n or cloud provider outbound rules.

5. Implement a safe retry strategy 
 * Only retry on idempotent verbs (GET, HEAD). 
 * Use exponential back‑off with jitter: 
```php
 $maxRetries = 3;
 $delay = 1; // seconds

for ($i = 0; $i < $maxRetries; $i++) {
 $response = curl_exec($ch);
 if ($response !== false) break;

$code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
 if ($code == 429 || $code == 503) {
 // Respect Retry-After if present
 $retryAfter = curl_getinfo($ch, CURLINFO_HEADER_OUT);
 // parse header if needed
 }

sleep($delay + rand(0, 1)); // jitter
 $delay *= 2; // exponential
 }
```
 * Log each retry attempt and the reason for failure. 
 * Do not retry on client errors (4xx other than 429) or on network failures that are not transient.

6. Avoid duplicate side‑effects 
 * For non‑idempotent operations (POST, PUT, DELETE) either do not retry or use a unique request ID that the API can recognize to deduplicate.

7. Optional: use curl_multi 
 If you need to send many requests concurrently, curl_multi can keep connections alive and reduce DNS lookups, but it adds complexity.

Summary

1. Log connect_time, total_time, and error codes. 
2. Verify DNS and remote server health. 
3. Check PHP‑FPM and web‑server timeouts. 
4. If retries are needed, limit them to idempotent calls, use exponential back‑off, and respect rate‑limit headers.

These steps should help you pinpoint whether the problem is local, network‑wide, or on the API side, and give you a controlled way to handle transient failures.

Da Code Master · Answer

The fact that some requests finish in under a second while others hit the 30-second timeout suggests an intermittent connection or response issue, but I wouldn't rule out PHP or the hosting environment without checking the timing data first.

**cURL error 28 doesn't necessarily mean the API is down.** It means the operation exceeded its configured timeout. Even if the API works when tested directly, the PHP server could be experiencing DNS delays, connection problems, TLS negotiation issues, or delays waiting for a response.

I'd start by adding detailed cURL timing diagnostics immediately after curl_exec():
```php
$response = curl_exec($ch);

$info = curl_getinfo($ch);

$diagnostics = [
 'dns_time' => $info['namelookup_time'],
 'connect_time' => $info['connect_time'],
 'tls_time' => $info['appconnect_time'] ?? null,
 'first_byte_time' => $info['starttransfer_time'],
 'total_time' => $info['total_time'],
 'http_code' => $info['http_code'],
 'primary_ip' => $info['primary_ip'] ?? null,
 'curl_errno' => curl_errno($ch),
 'curl_error' => curl_error($ch)
];

error_log(json_encode($diagnostics));
```
The important part is comparing successful requests against failed ones.

- If DNS lookup times are unusually high, investigate DNS resolution.
- If connection establishment is slow, check outbound firewall rules, routing, IPv4/IPv6 connectivity, and hosting network restrictions.
- If the connection completes quickly but the first response byte is delayed, investigate API-side processing, rate limits, or upstream services.
- If the timing looks normal until a particular point, compare the affected requests and any redirects.

I'd also test the same endpoint directly **from the server running PHP**, rather than relying solely on a browser or another computer. That can help identify differences between the two environments.

**Regarding retries:** Yes, retries are useful for transient failures, but they should be controlled.

For safe, read-only requests, I'd generally start with a maximum of two retries, exponential backoff, and a little random jitter. Respect the API's Retry-After header when applicable.

Be careful with POST or other requests that modify data. A timeout doesn't guarantee the remote API failed to process the original request. Retrying could create duplicates unless the API supports idempotency keys or another deduplication mechanism.

I also wouldn't increase CURLOPT_TIMEOUT beyond 30 seconds until the actual bottleneck is identified. A longer timeout can simply make failures take longer.

My recommendation: Start by capturing cURL timing data for both successful and failed requests. That should narrow down whether you're dealing with DNS, connection establishment, or a remote response delay.

One question: When the timeout happens, does it affect requests to other external APIs from the same PHP server, or only this particular endpoint? That would be useful information for isolating the problem.

The diagnostic approach is supported by the official PHP cURL documentation: https://www.php.net/manual/en/function.curl-getinfo.php and the official cURL retry guidance: https://everything.curl.dev/usingcurl/downloads/retry.html

PHP API Request Times Out Even Though Endpoint Works

2 Answers