HTTP 408 Request Timeout Error: What It Is and How to Fix It in 2026

Last Updated: July 2026

TL;DR: The HTTP 408 Request Timeout error means the server closed a connection because the client took too long to send its request. Most fixes involve adjusting PHP, Apache, or Nginx timeout values, auditing slow network connections, or checking for large form or file submissions that stall mid-transfer.

Nothing frustrates a site visitor more than a blank error screen. The HTTP 408 Request Timeout error is one of those errors that can appear without warning on any WordPress site, under any host, often at the worst possible moment: during a checkout, a contact form submission, or an admin upload. Understanding exactly what triggers a 408 and how to fix it on your server gives you a clear path from error to resolution in minutes, not hours.

This guide covers what the 408 status code actually means, how it differs from similar timeout errors such as 504 and 524, what causes it on WordPress sites specifically, and seven concrete fixes complete with configuration snippets for Apache, Nginx, and PHP.

What Is the HTTP 408 Request Timeout Error?

Try GigaPress AI Free →

The HTTP 408 status code is defined in RFC 7231 as a server-side signal that the server decided to close an idle connection. Unlike most error codes where something broke, a 408 is the server’s polite way of saying: “You connected, but you did not send me a complete request within my allowed window, so I am closing this connection now.”

The timeline looks like this:

1. A client (browser, API caller, form submission) opens a TCP connection to the server.
2. The server starts a timer the moment it receives that connection.
3. If the client does not finish sending the full HTTP request before the timer expires, the server sends back a 408 and closes the connection.
4. The client may reconnect automatically, which is why you sometimes see a brief flash of the error before the page loads on retry.

It is worth noting that a 408 is a 4xx client-side error class, meaning the HTTP standard places responsibility on the client side of the connection. In practice, however, the root cause is often the server’s timeout threshold being too short for the type of request the site handles.

408 vs 504 vs 524: How to Tell Them Apart in 2026

Timeout errors often look similar on screen. The differences matter because they point to completely different parts of the stack.

Error Code	Who Times Out	Direction	Best For
408	Origin server	Client is too slow sending the request	Slow client connections, large uploads stalling
504	Proxy or gateway	Upstream server is too slow responding	Overloaded origin, slow PHP execution
524	Cloudflare edge	Cloudflare reached its limit waiting for origin	Sites behind Cloudflare with slow origin servers

If you are seeing a 504, see the guide on How to Fix the 504 Gateway Timeout Error in WordPress for that specific fix path. For 503 errors caused by server overload, the HTTP 503 Service Unavailable guide covers those scenarios in detail.

Common Causes of the HTTP 408 Request Timeout Error

Understanding why a 408 occurs helps you pick the right fix. These are the most frequent culprits on WordPress sites:

1. Slow or Unstable Client Connection

If a visitor is on a slow mobile connection, congested public Wi-Fi, or a throttled ISP connection, their browser may not finish transmitting POST data (from forms or file uploads) before the server’s keep-alive timeout fires. The server sees an incomplete request and responds with 408.

2. Server Keep-Alive Timeout Set Too Short

Apache and Nginx both have a keep-alive timeout: the number of seconds a persistent connection is held open waiting for a new or continued request. On shared hosting environments, this value is often set very low (5 to 15 seconds) to conserve resources. That works for simple page loads but fails for users sending large payloads.

3. Large Form or File Upload Submissions

WooCommerce checkout forms with many fields, WordPress media uploads, and contact forms with attachment support all require more time to transmit. A form with a 10 MB PDF attachment on a 1 Mbps connection takes over 80 seconds to upload. Most default server timeouts are shorter than that.

4. Server Congestion

Under heavy load, servers process queued connections more slowly. A client that opened a connection and is waiting for the server to be ready to receive data can be timed out before it ever gets to send. This is common during traffic spikes or on under-resourced shared hosting plans.

5. Reverse Proxy or CDN Misconfiguration

If you are running Nginx as a reverse proxy in front of Apache (a common managed hosting setup), timeout values need to be configured at both layers. A mismatch means one layer gives up before the other is ready, generating 408 responses that look intermittent and are hard to reproduce.

6. PHP Script Delays Before Header Output

A WordPress plugin that runs a slow database query or external API call before outputting any response headers can leave the client connection in a limbo state. In some stack configurations, this registers as a 408 rather than a 504 because the initial HTTP handshake stalls before the request is fully received.

7. Network Latency Between Client and Server

Geographic distance between the visitor and the server, high packet loss rates, or routing issues add latency to every byte transmitted. Users far from your server’s data center are statistically more likely to hit 408 errors, which is a strong argument for using a CDN and choosing a server region close to your primary audience.

7 Fixes for the HTTP 408 Request Timeout Error on WordPress

Work through these fixes in order. Fixes 1 through 3 cover the most common causes and require no server access. Fixes 4 through 7 require access to your server configuration files or hosting control panel.

Fix 1: Reload the Page and Test Your Connection

Before diving into server configuration, rule out a transient client-side issue. The HTTP spec explicitly states that a client may repeat the same request after receiving a 408 without modification. A simple browser reload resolves the error in many cases, especially on mobile connections.

Test steps:

• Hard reload: Ctrl+Shift+R (Windows) or Cmd+Shift+R (Mac).
• Switch from Wi-Fi to a wired connection, or switch mobile data networks.
• Open the URL in a different browser or a private/incognito window.
• Use a free tool such as Down For Everyone Or Just Me (downforeveryoneorjustme.com) to confirm the site is reachable from other locations.

If the error is consistent and reproducible on multiple connections and devices, the problem is server-side. Move to the next fixes.

Fix 2: Increase PHP Timeout Values

PHP has its own execution time limit that can cause a request to stall before the server closes the connection. On WordPress sites, this limit is set in php.ini or via wp-config.php.

Add or update these values in your php.ini file (PHP 8.3 syntax):

; Increase maximum execution time to 300 seconds
max_execution_time = 300

; Increase maximum input time (for file uploads and form data)
max_input_time = 300

; Set default socket timeout for external HTTP requests
default_socket_timeout = 300

If you do not have access to php.ini, add this to your theme’s functions.php or a site-specific plugin:

<?php
// Increase PHP execution time limit for WordPress
@ini_set( 'max_execution_time', 300 );
@ini_set( 'max_input_time', 300 );

Alternatively, add this to your .htaccess file if your host allows PHP directives there:

php_value max_execution_time 300
php_value max_input_time 300

Fix 3: Increase Apache Timeout and Keep-Alive Settings

If your server runs Apache (the most common setup on shared and managed WordPress hosting), the Timeout and KeepAliveTimeout directives control how long Apache waits on a client request. You can set these in your main Apache config (httpd.conf or apache2.conf) or in an .htaccess file.

In httpd.conf or a VirtualHost block:

# How long Apache waits for a complete request from the client
Timeout 300

# How long Apache keeps a connection open waiting for another request
KeepAliveTimeout 30

# Enable keep-alive connections
KeepAlive On

# Maximum number of requests per keep-alive connection
MaxKeepAliveRequests 100

In .htaccess (if your host allows these directives):

# Set Apache timeout via .htaccess
<IfModule mod_reqtimeout.c>
    RequestReadTimeout header=30-60,MinRate=500 body=60,MinRate=500
</IfModule>

The mod_reqtimeout module is the most targeted fix for 408 errors specifically. The values above give the client 30 to 60 seconds to send headers (with a minimum data rate of 500 bytes per second) and 60 seconds for the request body. Adjust MinRate down if you serve users on slow connections.

Fix 4: Update Nginx Timeout Configuration

If your site uses Nginx (either as the primary web server or as a reverse proxy), update the following directives in your nginx.conf or site-specific server block:

http {
    # Time to wait for client to send the request body
    client_body_timeout   120s;

    # Time to wait for client to send the request header
    client_header_timeout 120s;

    # Timeout between successive read operations from the client
    keepalive_timeout     75s;

    # Maximum time between two successive writes to the client
    send_timeout          120s;

    # For reverse proxy setups: time waiting for upstream response
    proxy_read_timeout    300s;
    proxy_connect_timeout 300s;
    proxy_send_timeout    300s;
}

After editing, always test your configuration before reloading:

nginx -t && systemctl reload nginx

Fix 5: Increase WordPress Upload and Post Size Limits

Large file uploads stall mid-transfer and trigger 408 errors when the server closes the incomplete connection. WordPress respects PHP’s upload limits, so raise these in php.ini:

; Maximum size of an uploaded file
upload_max_filesize = 64M

; Maximum size of POST data
post_max_size = 64M

; Memory limit should be at least post_max_size
memory_limit = 256M

You can also set these via .htaccess on Apache servers:

php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value memory_limit 256M

If you are seeing image upload errors alongside 408s, the guide on How to Fix the Image Upload HTTP Error in WordPress covers the full set of upload-related issues, including permission and memory errors.

Fix 6: Disable and Test Plugins That Make External Requests

Some WordPress plugins make synchronous external HTTP requests during page load or form processing. If the external API they call is slow or unavailable, the plugin stalls the request pipeline long enough for the server’s connection timeout to fire.

To isolate a plugin as the cause:

1. Deactivate all plugins from the WordPress admin (Plugins > Installed Plugins > select all > Bulk Actions > Deactivate).
2. Reproduce the action that triggered the 408.
3. If the error is gone, reactivate plugins one at a time, testing after each one.
4. When the 408 returns, you have found the offending plugin.