Production Debugging
Debugging WordPress HTTP API and cURL Timeouts
A layered method for diagnosing WordPress outbound request failures across application code, DNS, TLS, proxies, firewalls, and remote APIs.
Author: Fahad Bin Shakir · Published: · Updated: · 11 min read
Introduction
A WordPress message such as cURL error 28 describes a deadline, not a root cause. The request may be waiting on DNS, a TCP connection, TLS negotiation, the remote server, a proxy, or response transfer. Increasing the timeout can hide the distinction and make web requests occupy workers for longer.
The fastest path to a durable fix is to preserve the failing request's context, reproduce it from the same execution environment, and time each network phase.
Capture the request before changing it
Record the destination scheme, hostname, port, method, timeout, redirect policy, response size expectation, WordPress and PHP versions, and the plugin or job that issued the call. Remove credentials and personal data from logs. Determine whether the failure affects every destination, one vendor, IPv6 only, cron only, or interactive requests only.
Use WordPress HTTP API hooks or a small controlled diagnostic plugin to log start time, completion, error code, and sanitized destination. Do not enable verbose payload logging across the site. A narrow trace during a bounded window is safer and easier to interpret.
Reproduce from the same network namespace
A successful request from a laptop proves little about a production container or hosting account. Test DNS and HTTPS from the same server, container, user, and egress path as PHP. Compare command-line curl with a minimal PHP request and with wp_remote_get so you can locate the layer where behavior diverges.
If command-line curl succeeds but PHP fails, inspect PHP's CA bundle, proxy variables, disabled functions, cURL build, open_basedir, and runtime limits. If both fail, focus on DNS, routing, firewall, TLS, or the remote service before changing WordPress code.
Measure each connection phase
Use curl timing output or an equivalent trace to separate name lookup, connection, TLS handshake, first byte, and total time. Slow DNS suggests resolver or network problems. A fast connection followed by a long time to first byte points toward the remote service, rate limiting, or an upstream dependency.
Compare IPv4 and IPv6 deliberately. Broken IPv6 often appears as intermittent delay when the client attempts an unreachable address before falling back. Fix routing or DNS rather than permanently forcing IPv4 without understanding the environment.
curl --silent --show-error --output /dev/null \
--write-out 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
https://api.example.com/healthCheck TLS, redirects, and intermediaries
Validate the certificate chain, hostname, expiry, supported protocol, and server clock. Do not solve certificate errors by disabling verification. Inspect every redirect because a harmless-looking API URL can redirect to a blocked host, an authentication page, or an infinite loop.
Hosting firewalls, outbound allowlists, corporate proxies, WAF rules, and vendor IP restrictions can interrupt different phases. Use request IDs and timestamps when asking another operator for evidence. A screenshot of a timeout is less useful than the exact UTC window, source egress IP, target, and trace.
Fix request behavior at the application layer
Set a timeout based on the operation's user impact, not the vendor's worst case. Interactive page requests should not wait tens of seconds for optional data. Move slow work to a queue or scheduled task, cache successful responses with a justified lifetime, and present a graceful stale or unavailable state.
Retry only idempotent operations unless the remote API provides an idempotency key. Use exponential backoff with jitter and a strict attempt limit. A retry storm can turn a partial vendor slowdown into a complete outage for both sides.
Prove the correction
Repeat the original request under the same conditions and record phase timings. Monitor success rate, latency percentiles, worker occupancy, queue depth, and vendor response codes after release. Remove temporary verbose logging when the observation window closes.
Document the final cause in operational language: for example, an unreachable IPv6 route delayed each connection before fallback, or a plugin called a slow endpoint synchronously on every page. That explanation makes the next incident faster to recognize.
Deployment checklist
- Capture the sanitized destination, caller, timeout, and failure pattern.
- Reproduce from the same host and execution environment as PHP.
- Measure DNS, connect, TLS, first-byte, and total durations separately.
- Compare IPv4 and IPv6 and inspect the full redirect chain.
- Verify CA bundles, clocks, proxies, firewalls, and vendor allowlists.
- Keep slow optional work out of interactive requests.
- Bound retries and verify with production metrics.