Does Laravel's HTTP Client maintain DNS cache across PHP-FPM process lifecycles?

Direct Answer

No. Laravel's HTTP Client does not maintain a DNS cache across PHP-FPM worker lifecycles. Each call through the Http facade typically creates a new Guzzle client and a new cURL easy handle. libcurl's internal DNS cache is scoped to that individual handle, not to the PHP process, and it is discarded when the handle closes. Because PHP-FPM workers can process many Laravel request cycles, it is natural to expect persistence, but neither Laravel, Guzzle, nor the default cURL handler carries DNS results from one Http::get() call to the next.

Confirmed Facts vs. Likely Explanation

Confirmed: Guzzle's default cURL handler does not enable cURL share handles or any cross-request DNS sharing. Unless you manually reuse a cURL handle or configure a shared DNS cache, every outgoing request performs a fresh system resolver lookup. The connect_timeout option governs connection attempts, not DNS TTL, and Laravel offers no native abstraction for DNS cache management.

Likely explanation: If you observe apparent DNS persistence in a long-running PHP-FPM worker, the caching is almost certainly happening below the application layer—in the operating system's resolver. Components such as systemd-resolved, nscd, dnsmasq, or glibc's internal caching can mask the absence of application-level caching. These OS-level caches have their own TTLs and invalidation rules that are independent of PHP-FPM's pm.max_requests worker recycling.

Practical Verification

To confirm the behavior in your environment, issue two consecutive HTTP requests to the same host from within a single PHP-FPM worker and observe resolver traffic:

1. Run a small PHP script under strace that calls Http::get() twice against the same hostname.
2. Filter the trace for getaddrinfo calls or DNS packets on port 53.
3. If lookups repeat for each call, no application-level DNS cache is present.
4. Optionally, inspect the Guzzle handler stack to verify that no CURLSH share handle or custom DNS middleware is configured.

Missing Diagnostic Detail

One detail would change the recommendation: whether your deployment uses a local caching resolver such as systemd-resolved or dnsmasq, or relies solely on glibc's resolver. If a local caching resolver is active, OS-level caching may reduce the practical impact of repeated lookups. If not, every Http call will trigger a fresh network DNS query, and you may need to address caching at the infrastructure level rather than in application code.