Nginx ошибка 408

Feb 8, 2018 11:00:50 AM |
408 Request Timeout: What It Is and How to Fix It

The 408 Request Timeout is an HTTP response status code indicating that the server did not receive a complete request from the client within the server’s allotted timeout period.

The 408 Request Timeout is an HTTP response status code indicating that the server did not receive a complete request from the client within the server’s allotted timeout period. The 408 Request Timeout error code appears similar to the 504 Gateway Timeout error we explored in a previous article, which indicates that that a server acting as a gateway or proxy timed out. However, the 408 Request Timeout error isn’t a message from a gateway or proxy server somewhere in the node chain, but is a direct message from the active server the client has connected to (like a the web server)

It can be difficult to find the cause of unexpected HTTP response codes and the 408 Request Timeout error code is no exception. With a potential pool of over 50 status codes used to represent the complex relationship between the client, a web application, a web server, and (possibly) multiple third-party web services, determining the cause of a particular status code can be challenging, even under the best of circumstances.

In this article we’ll explore the 408 Request Timeout in greater depth by looking at what might cause this message to appear, including a few tips you can use to diagnose and debug the appearance of this error within your own application. We’ll even look at a number of the most popular content management systems (CMSs) for potential problem areas that could cause your own website to be unexpectedly generating 408 Request Timeout errors. Let’s dive right in!

Server- or Client-Side?

All HTTP response status codes within the 4xx category are considered client error responses. Errors in the 4xx category contrast with those from the 5xx category, such as the aforementioned 504 Gateway Timeout we examined earlier, which are considered server error responses. That said, the appearance of a 4xx error doesn’t necessarily mean the issue is on the client side (the «client», in this case, is typically the web browser or device being used to access the application). Oftentimes, if you’re trying to diagnose an issue within your own application, you can immediately ignore most client-side code and components, such as HTML, cascading style sheets (CSS), client-side JavaScript, and so forth. This doesn’t apply solely to web sites, either. Smart phone applications often implement modern looking user interfaces that are actually powered by normal web applications behind the scenes.

On the other hand, the server could be the root cause of a 408 Request Timeout error. In some cases, the server may be misconfigured and may be handling requests improperly, which can result in 408 code responses and other troublesome traffic routing issues. We’ll explore some of these scenarios (and potential solutions) down below, but be aware that, even though the 408 Request Timeout is considered a client error response, it doesn’t necessarily mean we can rule out either the client nor the server as the culprit in this scenario. In these situations, the server is still the network object that is producing the 408 Request Timeout and returning it as the HTTP response code to the client, but it could be that the client is causing the issue in some way.

Start With a Thorough Application Backup

As usual, it is better to have played it safe at the start than to screw something up and come to regret it later on down the road. As such, it is critical that you perform a full backup of your application, database, and all other components of your website or application before attempting any fixes or changes to the system. Even better, if you have the capability, create a complete copy of the application and stick the copy on a secondary staging server that is either inactive, or publicly inaccessible. This will give you a clean testing ground on which to test all potential fixes needed to resolve the issue, without threatening the security or sanctity of your live application.

Diagnosing a 408 Request Timeout

A 408 Request Timeout response code indicates that the server did not receive a complete request from the client within a specific period of time tracked by the server (i.e. the timeout period). As specified in the RFC7235 HTTP/1.1 Semantics and Content standards document server should include the special Connection header with the close directive as part of its response (e.g. Connection: close), which informs the client that the connection should be closed. Put simply, a 408 code informs the client that the server has decided to close the connection rather than continue waiting for the transaction to complete. Upon receiving the Connection: close header the client can opt to repeat the original request using a new connection.

Most modern browsers implement HTTP preconnection mechanisms, which provides the user agent (i.e. browser) to speed up overall web surfing experiences by essentially predicting what resources — and therefore connections — the client may be using in the immediate future. The full scope of how browsers use these mechanisms is well beyond the scope of this article, but you can check out the W3C Resource Hints documentation for more details.

Troubleshooting on the Client-Side

Since the 408 Request Timeout is a client error response code, it’s best to start by troubleshooting any potential client-side issues that could be causing this error. Here are a handful of tips to try on the browser or device that is giving you problems.

Check the Requested URL

The most common cause of a 408 Request Timeout is simply inputting an incorrect URL. Many servers are tightly secured, so as to disallow unexpected requests to resources that a client/user agent should not have access to. It may be that the requested URL is slightly incorrect, which is causing the user agent to request an unintended resource, which may be routed through a proxy server that requires authentication. For example, a request to the URI https://airbrake.io/login might route requests through a separate proxy server used to handle user authentication. If the original request did not contain appropriate credentials, the result could be a 408 Request Timeout error response. It’s always a good idea to double-check the exact URL that is returning the 408 Request Timeout error to make sure it is intended resource.

Debugging Common Platforms

If you’re running common software packages on the server that is responding with the 408 Request Timeout, you may want to start by looking into the stability and functionality of those platforms first. The most common content management systems — like WordPress, Joomla!, and Drupal — are all typically well-tested out of the box, but once you start making modifications to the underlying extensions or PHP code (the language in which nearly all modern content management systems are written in), it’s all too easy to cause an unforeseen issue that results in a 408 Request Timeout.

There are a few tips below aimed at helping you troubleshoot some of these popular software platforms.

Rollback Recent Upgrades

If you recently updated the content management system itself just before the 408 Request Timeout appeared, you may want to consider rolling back to the previous version you had installed when things were working fine. Similarly, any extensions or modules that you may have recently upgraded can also cause server-side issues, so reverting to previous versions of those may also help. For assistance with this task, simply Google «downgrade [PLATFORM_NAME]» and follow along. In some cases, however, certain CMSs don’t really provide a version downgrade capability, which indicates that they consider the base application, along with each new version released, to be extremely stable and bug-free. This is typically the case for the more popular platforms, so don’t be afraid if you can’t find an easy way to revert the platform to an older version.

Uninstall New Extensions, Modules, or Plugins

Depending on the particular content management system your application is using, the exact name of these components will be different, but they serve the same purpose across every system: improving the capabilities and features of the platform beyond what it’s normally capable of out of the box. But be warned: such extensions can, more or less, take full control of the system and make virtually any changes, whether it be to the PHP code, HTML, CSS, JavaScript, or database. As such, it may be wise to uninstall any new extensions that may have been recently added. Again, Google the extension name for the official documentation and assistance with this process.

Check for Unexpected Database Changes

It’s worth noting that, even if you uninstall an extension through the CMS dashboard, this doesn’t guarantee that changes made by the extension have been fully reverted. This is particularly true for many WordPress extensions, which are given carte blanche within the application, including full access rights to the database. Unless the extension author explicitly codes such things in, there are scenarios where an extension may modify database records that don’t «belong» to the extension itself, but are instead created and managed by other extensions (or even the base CMS itself). In those scenarios, the extension may not know how to revert alterations to database records, so it will ignore such things during uninstallation. Diagnosing such problems can be tricky, but I’ve personally encountered such scenarios multiple times, so your best course of action, assuming you’re reasonably convinced an extension is the likely culprit for the 408 Request Timeout, is to open the database and manually look through tables and records that were likely modified by the extension.

Above all, don’t be afraid to Google your issue. Try searching for specific terms related to your issue, such as the name of your application’s CMS, along with the 408 Request Timeout. Chances are you’ll find someone who has experienced the same issue.

Troubleshooting on the Server-Side

If you aren’t running a CMS application — or even if you are, but you’re confident the 408 Request Timeout isn’t related to that — here are some additional tips to help you troubleshoot what might be causing the issue on the server-side of things.

Confirm Your Server Configuration

Your application is likely running on a server that is using one of the two most popular web server softwares, Apache or nginx. At the time of publication, both of these web servers make up 84% of the world’s web server software! Thus, one of the first steps you can take to determine what might be causing these 408 Request Timeout response codes is to check the configuration files for your web server software for unintentional redirect or request handling instructions.

To determine which web server your application is using you’ll want to look for a key file. If your web server is Apache then look for an .htaccess file within the root directory of your website file system. For example, if your application is on a shared host you’ll likely have a username associated with the hosting account. In such a case, the application root directory is typically found at the path of /home/<username>/public_html/, so the .htaccess file would be at /home/<username>/public_html/.htaccess.

If you located the .htaccess file then open it in a text editor and look for lines that use KeepAliveTimeout or RequestReadTimeout directives. KeepAliveTimeout is part of the core module, while RequestReadTimeout is from the reqtimeout module in Apache. Covering exactly how these directives work is well beyond the scope of this article, however, the basic concept is that these timeout directives inform the server to allow for incoming client requests to take only a certain amount of time before they are considered failed and closed via a 408 response.

For example, here we’re using the RequestReadTimeout directive to set header and body timeouts of 15 and 30 seconds:

RequestReadTimeout header=15 body=30

Look for any strange timeout directives in the .htaccess file that don’t seem to belong, then try temporarily commenting them out (using the # character prefix) and restarting your web server to see if this resolves the issue.

On the other hand, if your server is running on nginx, you’ll need to look for a completely different configuration file. By default this file is named nginx.conf and is located in one of a few common directories: /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx. Once located, open nginx.conf in a text editor and look for client_body_timeout, client_header_timeout, or keepalive_timeout directives, which are all part of the http_core Nginx module. For example, here is a simple block directive (i.e. a named set of directives) that configures a virtual server for airbrake.io and sets the client header and body timeouts to 15 and 30 seconds, respectively:

server {

    listen 80;

    listen 443 ssl;

    server_name airbrake.io;
 client_header_timeout 15s;
 client_body_timeout 30s;
 keepalive_timeout 60s;
 }
 

Have a look through your nginx.conf file for any abnormal _timeout directives and comment out any abnormalities before restarting the server to see if the issue was resolved.

Configuration options for each different type of web server can vary dramatically, so we’ll just list a few popular ones to give you some resources to look through, depending on what type of server your application is running on:

• Apache
• Nginx
• IIS
• Node.js
• Apache Tomcat

Look Through the Logs

Nearly every web application will keep some form of server-side logs. Application logs are typically the history of what the application did, such as which pages were requested, which servers it connected to, which database results it provides, and so forth. Server logs are related to the actual hardware that is running the application, and will often provide details about the health and status of all connected services, or even just the server itself. Google «logs [PLATFORM_NAME]» if you’re using a CMS, or «logs [PROGRAMMING_LANGUAGE]» and «logs [OPERATING_SYSTEM]» if you’re running a custom application, to get more information on finding the logs in question.

Debug Your Application Code or Scripts

If all else fails, it may be that a problem in some custom code within your application is causing the issue. Try to diagnose where the issue may be coming from through manually debugging your application, along with parsing through application and server logs. Ideally, make a copy of the entire application to a local development machine and perform a step-by-step debug process, which will allow you to recreate the exact scenario in which the 408 Request Timeout occurred and view the application code at the moment something goes wrong.

No matter the cause — and even if you managed to fix this particular error this time around — the appearance of an issue like the 408 Request Timeout within your own application is a good indication you may want to implement an error management tool, which will help you automatically detect errors and will alert you the instant they occur. Airbrake’s error monitoring software provides real-time error monitoring and automatic exception reporting for all your development projects. Airbrake’s state of the art web dashboard ensures you receive round-the-clock status updates on your application’s health and error rates. No matter what you’re working on, Airbrake easily integrates with all the most popular languages and frameworks. Plus, Airbrake makes it easy to customize exception parameters, while giving you complete control of the active error filter system, so you only gather the errors that matter most.

Check out Airbrake’s error monitoring software today and see for yourself why so many of the world’s best engineering teams use Airbrake to revolutionize their exception handling practices!

Encountering HTTP status code errors can be frustrating and stressful. This is especially true when you don’t know what the message means or what’s causing it. One of the errors you might be dealing with is HTTP 408 Request Timeout.

Fortunately, you can take a handful of steps to troubleshoot and resolve this issue. You’ll simply need a basic understanding of what could be causing the HTTP 408 error, then implement solutions to fix it.

In this post, we’ll explain the HTTP 408 status code and some common causes of the error. Then we’ll walk you through eight potential solutions for resolving it. Let’s jump in!

Check Out Our Video Guide to Fixing the HTTP 408 Error

What the HTTP 408 Status Code Is

HTTP status codes indicate the status of a client’s request. They can also redirect clients to different resources, depending on their requests.

The most common HTTP status code is 404, which indicates that the requested resource could not be found. Other common status codes include 200 (OK), 400 (Bad Request), and 500 (Internal Server Error).

Status codes are divided into five categories:

1. Informational: The server is still processing the request.
2. Successful: The request was completed successfully.
3. Redirects: The client should be redirected to a different resource.
4. Client Errors: There was an error with the request.
5. Server Errors: There was an error with the server.

HTTP 408 falls into the category of client errors. The status code communicates that the server did not receive a timely response from the client and that the server timed out waiting for the request. This can happen if the client takes too long to send the request or the server is too busy to process it.

The HTTP 408 error is similar to the 504 Gateway Timeout status code. However, the former doesn’t come from a gateway or proxy server. Instead, it comes directly from the web server the client is connected to.

Encountering HTTP status code errors can be frustrating and stressful. 😰 This guide can help. 🛠Click to Tweet

Common Causes of the HTTP 408 Request Timeout Error

There are a handful of potential reasons behind the HTTP 408 request timeout error. These causes include:

• Network latency
• Clients timing out
• Servers being too busy to handle the request

The 408 Request Timeout error means the request you sent to the website server took longer than the server was prepared to wait. It can happen due to heavy traffic on the internet or a slow connection on your side.

The problem with this status code is that it can occur for both client-side and server-side-related reasons. In other words, although the 408 error is categorized as a client error, this doesn’t necessarily mean the issue stems from the browser or device. It’s possible that the server is misconfigured or isn’t handling requests correctly.

How To Fix the HTTP 408 Error (8 Solutions)

Now that we understand more about the HTTP 408 status code, let’s discuss how you can resolve it. Below are eight potential solutions you can use, separated into two categories: client-side and server-side.

Client-Side

Below are some client-side solutions you can use to resolve the HTTP 408 error!

1. Back Up Your Site

The first thing you should do before troubleshooting the HTTP 408 error is back up your website. Then, if anything goes wrong while trying to fix the issue, you will have a full, updated version of your files and database to restore.

There are several methods you can use to back up your site. One is the manual approach. This method involves using a Secure File Transfer Protocol (SFTP) client, such as FileZilla. After receiving your SFTP credentials from your host and connecting to the server, you can download your files from the root directory (public_html folder).

Next, you’ll need to download your database via phpMyAdmin. If you’re a Kinsta user, you can access this through MyKinsta > Sites > Info:

Then select Open phpMyAdmin to launch the database manager. Select your site’s database from the menu:

Next, click on Export at the top of the screen. Make sure to select SQL under Format, then click on Go. Your database file should begin downloading.

You can also use a backup plugin such as UpdraftPlus. After installing and activating the plugin, navigate to Settings > UpdraftPlus Backups in your WordPress dashboard, then click on Backup Now:

A third option is to back up your site through your web host. At Kinsta, you can view your existing backups by logging into MyKinsta and then navigating to the Backups tab:

You can create up to five manual backups, which are automatically stored for two weeks. We also offer DevKinsta, a free local WordPress development tool you can use for staging and backing up your site to a local environment.

You can do this by going to DevKinsta and selecting the Import from Kinsta option. You may need to verify your hosting credentials. Once you choose your site, DevKinsta handles the rest.

2. Check the URL

One of the reasons you may be seeing the HTTP 408 status code error is that you simply typed the wrong URL into the browser. Therefore, you should now double-check the URL to ensure you didn’t make any typos.

Pay close attention to the domain name, especially if there are slashes or hyphens. Try re-entering the URL and then reloading the page. If the timeout request error is still present, you can move on to the next solution.

3. Review Recent Database Changes

If you’ve made any recent changes to your database, they may be causing the HTTP 408 error. You’ll need to revert any changes you’ve made to fix the issue.

Recently installed extensions or updates to your database may have altered database records that are causing problems. To see if this is the case, we recommend opening your database (phpMyAdmin) and manually going through to check any tables or records that have been recently modified. If you find any, revert them to their original states.

4. Uninstall Extensions and Plugins

Adding extensions and plugins to your site can cause various incompatibility issues and errors, including the HTTP 408 status code. One of the easiest ways to see whether this is the case is to deactivate all of the plugins on your site.

If you have access to your WordPress dashboard, you can do this by navigating to Plugins from the admin area, selecting all of the installed plugins, then selecting Deactivate from the Bulk actions dropdown menu. Now click on Apply:

If you don’t have access to your dashboard, you can bulk deactivate your extensions by connecting to your site via SFTP, then renaming the plugins folder to something like “plugins_old”.

Revisit your site. You can assume a plugin was to blame if you no longer see the error message.

You’ll need to reactivate each plugin one by one, checking the site in between. Once you see the error message again, you’ll have to uninstall that extension and find a replacement (or contact the developer for more information).

5. Roll Back Recent Changes

If you’ve recently made any changes to your WordPress site, such as installing a new plugin or updating the WordPress software, you might be seeing the HTTP 408 error. New tools can sometimes lead to configuration problems. You can roll back recent changes by restoring your site to a previous version.

If you’re a Kinsta user, open your MyKinsta dashboard, then navigate to Sites and select your site. Next, click on Backups.

From the list of backups, find the version you want to restore, click on Restore to, then select Staging or Live:

Next, you can confirm the backup restoration and click on Restore backup. Once the backup is complete, you can check to see whether the error message is still displaying.

Server-Side

If none of the above solutions worked, the HTTP 408 error might be caused by a server-side issue. Let’s look at potential solutions you can use to resolve it.

6. Check Server Config Files

One of the ways you can determine the cause of the HTTP 408 error is to check your server configuration files via SFTP. The process for doing so will depend on your server software.

Chances are that your server is either running on Apache or Nginx. If you’re a Kinsta user, we use Nginx.

If you’re using Apache, you can look for the .htaccess file within your site’s root directory. When you locate the file, open it and look for the following lines:

• KeepAliveTimeout
• RequestReadTimeout

If you find these directives, you can comment them out by using the # symbol prefix before the line. Then you can save the file and reload the page in your browser.

If you’re a Kinsta user, you can check your .htaccess file by opening your MyKinsta dashboard and navigating to your website under Sites. Locate the SFTP/SSH section to get your credentials, then use them to connect to your site via an FTP client.

Next, navigate to the public_html folder, then locate and open the .htaccess file:

Look for either of the directives listed above. If you see any of these rules, comment them out and save your changes.

7. Review Application Logs

Your server-side logs can be invaluable for providing information about your applications, including what they did, the pages requested, the servers connected to, and more. If you’re a Kinsta user, you can check your error logs using the log viewer in MyKinsta.

If you’re not using a Kinsta hosting plan or your host doesn’t provide a logging tool, you can insert the following code into your wp-config.php file:

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', true );

define( 'WP_DEBUG_DISPLAY', false );

This will enable WordPress debugging mode.

From MyKinsta, navigate to Sites > Logs:

Here, you’ll find the Log viewer that displays your error logs. You can click on access.log from the dropdown menu. This is where you can find all the HTTP requests from your website. You can also look for any HTTP 408 requests using the search bar.

If you locate any errors, you can use the information to pinpoint which web page is causing the issue. This can help you narrow down the source of the problem.

8. Debug Apps or Scripts

At this point, if you’re still seeing the HTTP 408 error, it’s time to debug your site. There are a handful of options you can use for this process.

One is to use a plugin such as Query Monitor:

This free plugin debugs your website’s performance and development. It enables you to check database queries, scripts, timing, and more.

Another option is using an Application Performance Monitoring (APM) tool. This software helps you monitor and optimize the performance of your website or application.

Using an APM tool can help you debug your site by giving insight into its performance and the location of any bottlenecks. This information can help you identify and fix any issues causing your website to run slowly or have other performance problems.

You can use our Kinsta APM Tool. It’s a custom-designed performance monitoring tool for WordPress sites that helps you identify performance issues. It’s also free for all sites hosted with us.

You can access the Kinsta AMP via your MyKinsta dashboard by navigating to Sites > Kinsta APM:

Once you enable the APM, you can use a variety of tools and features. These include diagnosing performance issues and monitoring results.

 It’s easier than you may think to fix this pesky issue. 😌 Here’s how to get started… ✅Click to Tweet

Summary

HTTP status codes can provide a wide range of information about client and server requests. However, some of these messages indicate problems, such as the HTTP 408 Request Timeout error.

As we discussed in this post, the source of the issue may be either client- or server-side. To troubleshoot and resolve the status code error, you should review and roll back recent changes, check your server configuration file and application logs, and debug your apps and scripts.

Do you want to switch to hosting that provides easy access to software for identifying, testing, and fixing issues on your site? Check out our Kinsta hosting plans to learn more about our APM and development tools!

I’m working on a server that is receiving requests from IoT devices. They perform a HEAD request on boot. Unfortunately, it seems there’s something wrong with the headers.

NGINX access log

[11/Sep/2018:13:41:11 +0000] "HEAD / HTTP/1.1" 408 0 "-" "-" --- "-" "-"

The log format is as follows

log_format custom '[$time_local] "$request" $status $body_bytes_sent '
                  '"$http_referer" "$http_user_agent" ---'
                  '"$content_type" "$content_length"';

NGINX error log

2018/09/11 13:40:11 [debug] 31368#31368: *1 accept: SRCIP:33930 fd:32
2018/09/11 13:40:11 [debug] 31368#31368: *1 event timer add: 32: 60000:1536673271229
2018/09/11 13:40:11 [debug] 31368#31368: *1 reusable connection: 1
2018/09/11 13:40:11 [debug] 31368#31368: *1 epoll add event: fd:32 op:1 ev:80002001
2018/09/11 13:40:11 [debug] 31368#31368: *1 post event 000056011DBAA2C0
2018/09/11 13:40:11 [debug] 31368#31368: *1 delete posted event 000056011DBAA2C0
2018/09/11 13:40:11 [debug] 31368#31368: *1 http wait request handler
2018/09/11 13:40:11 [debug] 31368#31368: *1 malloc: 000056011DAAB650:1024
2018/09/11 13:40:11 [debug] 31368#31368: *1 recv: fd:32 71 of 1024
2018/09/11 13:40:11 [debug] 31368#31368: *1 reusable connection: 0
2018/09/11 13:40:11 [debug] 31368#31368: *1 posix_memalign: 000056011DB0DCD0:4096 @16
2018/09/11 13:40:11 [debug] 31368#31368: *1 http process request line
2018/09/11 13:40:11 [debug] 31368#31368: *1 http request line: "HEAD / HTTP/1.1"
2018/09/11 13:40:11 [debug] 31368#31368: *1 http uri: "/"
2018/09/11 13:40:11 [debug] 31368#31368: *1 http args: ""
2018/09/11 13:40:11 [debug] 31368#31368: *1 http exten: ""
2018/09/11 13:40:11 [debug] 31368#31368: *1 posix_memalign: 000056011DB690C0:4096 @16
2018/09/11 13:40:11 [debug] 31368#31368: *1 http process request header line
2018/09/11 13:40:11 [debug] 31368#31368: *1 http header: "Host: MYHOST"
2018/09/11 13:40:11 [debug] 31368#31368: *1 recv: fd:32 -1 of 953
2018/09/11 13:40:11 [debug] 31368#31368: *1 recv() not ready (11: Resource temporarily unavailable)
2018/09/11 13:41:11 [debug] 31368#31368: *1 event timer del: 32: 1536673271229
2018/09/11 13:41:11 [debug] 31368#31368: *1 http process request header line
2018/09/11 13:41:11 [info] 31368#31368: *1 client timed out (110: Connection timed out) while reading client request headers, client: SRCIP, server: MYHOST, request: "HEAD / HTTP/1.1", host: "MYHOST"
2018/09/11 13:41:11 [debug] 31368#31368: *1 http request count:1 blk:0
2018/09/11 13:41:11 [debug] 31368#31368: *1 http close request
2018/09/11 13:41:11 [debug] 31368#31368: *1 http log handler
2018/09/11 13:41:11 [debug] 31368#31368: *1 free: 000056011DB0DCD0, unused: 707
2018/09/11 13:41:11 [debug] 31368#31368: *1 free: 000056011DB690C0, unused: 3104
2018/09/11 13:41:11 [debug] 31368#31368: *1 close http connection: 32
2018/09/11 13:41:11 [debug] 31368#31368: *1 reusable connection: 0
2018/09/11 13:41:11 [debug] 31368#31368: *1 free: 000056011DAAB650
2018/09/11 13:41:11 [debug] 31368#31368: *1 free: 000056011DAFF960, unused: 128

Tcpdump sudo tcpdump -n -S -s 0 -A 'src SRCIP and port 80' shows

13:55:32.846408 IP SRCIP.39761 > DSTIP.80: Flags [S], seq 1846787, win 2920, options [mss 1460], length 0
E..,....p. *E......h.Q.P........`..h\;........
13:55:33.153456 IP SRCIP.39761 > DSTIP.80: Flags [.], ack 3538300854, win 2920, length 0
E..(....p..^E......h.Q.P....../.P..hqK........
13:55:33.314206 IP SRCIP.39761 > DSTIP.80: Flags [P.], seq 1846788:1846859, ack 3538300854, win 2920, length 71: HTTP: HEAD / HTTP/1.1
E..o&...p..CE......h.Q.P....../.P..hg...HEAD / HTTP/1.1
Host: MYHOST
Content-Length:
13:56:33.363048 IP SRCIP.39761 > DSTIP.80: Flags [F.], seq 1846859, ack 3538300855, win 2919, length 0
E..(....p...E......h.Q.P...K../.P..gq.........

I cannot change the firmware in the devices so I’m looking for a workaround on the NGINX side. Please let me know if I can provide more info to help with the answer.

EDIT: I’m not adding the server config because I’ve tried too many and I’m not sure what to paste here.

EDIT 2: tcpdump at first logs

13:55:32.846408 IP SRCIP.39761 > DSTIP.80: Flags [S], seq 1846787, win 2920, options [mss 1460], length 0
E..,....p. *E......h.Q.P........`..h\;........
13:55:33.153456 IP SRCIP.39761 > DSTIP.80: Flags [.], ack 3538300854, win 2920, length 0
E..(....p..^E......h.Q.P....../.P..hqK........
13:55:33.314206 IP SRCIP.39761 > DSTIP.80: Flags [P.], seq 1846788:1846859, ack 3538300854, win 2920, length 71: HTTP: HEAD / HTTP/1.1
E..o&...p..CE......h.Q.P....../.P..hg...HEAD / HTTP/1.1
Host: MYHOST
Content-Length:

And then the rest after some time. I assume it’s after NGINX times out.

EDIT 3: I finally understand what’s going on. This has been really confusing because there’s one Apache server in production with which the devices work properly. While trying to switch to NGINX things stopped working.

As I’ve said above, the IoT devices on boot are performing a HEAD request. They expect a response with a Date: header so that they can parse it.

Currently, the device are working fine with Apache because when a timeout is triggered while waiting for headers from the client, Apache returns a 408 response to the client, including the Date: header.

This directive can set various timeouts for receiving the request headers and the request body from the client. If the client fails to send headers or body within the configured time, a 408 REQUEST TIME OUT error is sent.
(https://httpd.apache.org/docs/2.4/mod/mod_reqtimeout.html)

On the other hand, NGINX when a when a timeout is triggered while waiting for headers from the client, just closes the connection without returning anything to the client. Even if it logs 408 in the access log.

Defines a timeout for reading client request header. If a client does not transmit the entire header within this time, the request is terminated with the 408 (Request Time-out) error.
(http://nginx.org/en/docs/http/ngx_http_core_module.html#client_header_timeout)

There’s been a discussion on this behaviour already https://trac.nginx.org/nginx/ticket/1005.

In other words, the HEAD request from the IoT devices has always being wrong. It just works with Apache because a 408 response with Date: is sent back whenever a timeout while waiting for headers is triggered.

As I said above, unfortunately there’s no way for me to change how the devices work. Thus, I need to workaround in NGINX. The only way I found is to change the source and compile myself.

This is what I came up with by copy / pasting from the internet. Unfortunately, I haven’t had time to understand the code and prolly won’t ever. It would be really great if somebody helped me understanding how bad that code is and what’s a better way of writing it.

The version of NGINX is 1.14.0.

diff --git a/src/http/ngx_http_request.c b/src/http/ngx_http_request.c
index 2db7a62..086701b 100644
--- a/src/http/ngx_http_request.c
+++ b/src/http/ngx_http_request.c
@@ -1236,7 +1236,7 @@ ngx_http_process_request_headers(ngx_event_t *rev)
     if (rev->timedout) {
         ngx_log_error(NGX_LOG_INFO, c->log, NGX_ETIMEDOUT, "client timed out");
         c->timedout = 1;
-        ngx_http_close_request(r, NGX_HTTP_REQUEST_TIME_OUT);
+        ngx_http_finalize_request(r, ngx_http_special_response_handler(r, NGX_HTTP_REQUEST_TIME_OUT));
         return;
     }

To validate the code is working I used Telnet:

This is what NGINX normally would do

Request

$ telnet HOST 80
Trying IP...
Connected to HOST.
Escape character is '^]'.
HEAD / HTTP/1.1
Content-Length:

Response

Connection closed by foreign host.

This is what NGINX does with the modified code

Request

$ telnet HOST 80
Trying IP...
Connected to HOST.
Escape character is '^]'.
HEAD / HTTP/1.1
Content-Length:

Response

HTTP/1.1 408 Request Time-out
Server: nginx
Date: Tue, 25 Sep 2018 08:18:41 GMT
Content-Type: text/html
Content-Length: 176
Connection: close

Notice that I could use another header in place of Content-Length: (e.g. Accept: and the result would be the same). If you are trying to reproduce just remember to press enter once (and only once) after the empty header (in the example Content-Length:).

When you visit websites on the internet, you access them through your web browser. The basis for this transmission, which is handled by default through TCP, is the stateless protocol HTTP (“Hypertext Transfer Protocol”), which describes the initial exchange of messages between web server and browser. According to the classic client-server principle, the browser issues an HTTP request, after which the server sends back a response which includes a status code.

While you don’t notice most of this communication as a user, the situation is usually different when it comes to HTTP error codes: if a problem occurs during the exchange, the browser often presents corresponding code in the 4xx and 5xx series, which stand for various client or server-side error sources. For example, the HTTP 408 message tells you that the client request timed out. How, exactly, this timeout occurs and how you can solve the problem will be explained in this guide.

What does the http 408 error code mean?

The HTTP error code 408 – like all members of the 4xx error series – is one of the messages that indicate a client-side problem. When you go into the background of this error message in more detail, however, it becomes clear that it does not necessarily have to be a browser malfunction: Error 408 is linked to “Request Timeout” information, which simply means that the request sent from the client to the web server took more time than the web server allows for. As a result, the browser receives the HTTP 408 message instead of the actual response. Of course, this may be due to problems with your internet connection, but it cannot be ruled out that the timeout is the result of an overload or incorrect configuration of the web server.

An overview of possible reasons for “408: Request Timeout” error messages

Although there are over 50 different  HTTP status codes, more than half of which are error messages, these messages often only prove to be a rough guideline for the following problem solution. This also applies to error code 408, which basically just says that too much time has passed in a prescribed time interval after establishing at TCP/IP connection without data transferring through the connection. However, there are several possible causes for this delay, and for the subsequent error messages, for example:

• Bandwidth problems and disconnections: HTTP 408 messages often result from problems with your internet connection. For example, the bandwidth may be so low that the HTTP request fails due to the defined time interval. It is also possible that the internet connection to the server was temporarily interrupted after the TCP/IP connection was established, so the request data might not have been completely sent.
   
• Trying to access incorrect or inaccessible URLs: Not every website URL is available to visitors without encryption. If you inadvertently try to access a page that you have no authorization for, or you try to access an HTTPS page that doesn’t have an SSL/TLS activated, a 408 timeout could certainly occur. In addition, many URLs have restrictions regarding the permitted HTTP request methods (GET, POST, HEAD, PUT, and so on), so the timeout can also be the result of an incorrectly applied method. In both cases, however, there are also standard messages that indicate the problem (“403: Forbidden“ for unauthorized access attempts and “405: Method Not Allowed” for unavailable HTTP methods).
   
• Incorrect web server configuration: Regardless of the web server software used, the website runner specifies how many seconds an HTTP request should be rejected in the respective configuration file. There are separate values for the header and the body of the HTTP messages. If the server chooses too short a time interval for processing one or both package components, this may well be the reason for the 408 error on user pages.
   
• Plugins, extensions, modules, etc.: A problem that can be both a client-side and a server-side problem is the use of faulty or outdated extensions. Therefore, both the browser plugins used by the website visitor and the CMS modules used by the operator could be responsible for the HTTP timeout and cause the HTTP 408 error.

HTTP-408: how to solve the http timeout problem as a browser user

If you are confronted with a “408: Request Timeout” message when visiting a website, you are naturally interested in the quickest possible solution to the problem. However, you cannot always fix the problem on your own. If the error is exclusively on the client side, chances are good that you can correct the 408 error using one of the following approaches.

Solution 1: check URL

Before you go on more intensive troubleshooting, your very first look should be at the URL you entered. The URL you have chosen might no longer be accessible to you. This happens in particular if you try to access the targeted website using old bookmarks. If the website in question has made changes to permissions or permitted request methods in the interim, or has switched to HTTPS, it is very likely that the saved link will no longer lead to the website, but instead the HTTP-408 or comparable error messages. So make sure that the URL you entered is correct and up to date to avoid this error source.

Solution 2: check internet connection and restart router

Problems with an internet connection are always a nerve-racking affair. Sometimes, the connection no longer works at all, so access to the web remains completely closed. While you will inevitably notice these complete failures, in most cases you won’t notice any temporary fluctuations or connection interruptions. So, the cause for slow loading times and error messages during loading – like the 408 error – should be quick to find on the visited website. For this reason, it is recommended that you check your own network connection by visiting other websites or performing a DSL speed test, for example.

If you find that there are technical difficulties with your access, you should reboot your router. If the connection problem persists, you should contact your internet provider.

To display this video, third-party cookies are required. You can access and change your cookie settings here.

Solution 3: disable browser extensions

With plugins, addons, or extensions, web browser functions can be extended with just a few clicks. However, the practical extensions do not always work as desired – in the worst case, they make the surfing experience worse and cause error messages like HTTP-408, often because the extensions are outdated and/or no longer compatible with the current browser version, since they are no longer actively developed. To test whether the timeout error is due to one or more included extensions, temporarily deactivate them completely. Once the problem is resolved, you can turn on the plugins one by one to find out which was responsible for the HTTP error message.

Solution 4: try to access the website at a later time

The “408: Request Timeout” error cannot always be corrected using the suggestions listed above – e.g. if it is due to prolonged problems with your network connection. In this case, it is advisable that you wait and try again at a later date. If the HTTP exchange still fails, it is highly likely that the cause of the error lies in the web server. If the responsible website has provided appropriate contact data, you can find out whether they are aware of the problem and when the page will be available as usual again.

To display this video, third-party cookies are required. You can access and change your cookie settings here.

How to fix HTTP Error 408 if you run a website

While the HTTP timeout problem is primarily annoying for visitors because the target page cannot be opened, its impact on website operators can be much bigger. If many users are confronted with the error message over a longer time, this not only has a negative effect on traffic, but also on the website’s reputation. In addition, there is also the threat of punishment by search engines if HTTP 408 errors occur more frequently of if a correction takes too long. If you are responsible for a website, you should take immediate action once you discover the issue.

Solution 1: check web server configuration

Incorrect settings are among the most common server-side HTTP error code causes (like “408: Request Timeout”). You should check the respective file first, either on Apache (httpd.conf; apache2.conf), NGINX (nginx.conf), or others. In Apache web server settings, for example, the directives “KeepAliveTimeout” and “RequestReadTimeout” deserve special attention. Both specify a time interval for incoming HTTP requests, which may be too low (15 or even 30 seconds is recommended). If your website runs on an NGINX server, the directives are “keepalive_timeout,” “client_body_timeout,” and “client_header_timeout.” Do not forget to save the changes to the respective configuration file before starting the web server to finally resolve the HTTP 408 problem.

Solution 2: inspect server logs and customize problematic pages

As mentioned above, HTTP error 408 only occurs on one page or individual pages on a website because those pages have configuration errors with their action rights and permitted HTTP methods. So if you discover a timeout problem, it is recommended to check which URL(s) are causing the HTTP error. To avoid having to access each page manually, just take a look at your web server’s error log file, where all the HTTP errors are automatically archived. Once you have identified the problematic pages, you can search for specific causes for the timeout and, if necessary, make changes to the access rights and methods.

Note

You can usually also view the web server error logs if you are hosting your website with a web hosting provider. To do this, log onto the respective customer account, which should include a section with server statistics including downloadable server logs. If you cannot find the corresponding menu item on your own, the FAQ area or provider’s service team should be able to help.

Solution 3: deactivate obsolete, faulty modules, templates, and plugins in the CMS

Content management systems are in high demand as a basis for websites. A major advantage of these platforms is their high degree of extensibility through modules, templates, and plugins, which provide additional functions, layouts, and designs. These extensions, like their client-side counterparts, can also be responsible for the 408 request timeout. In the abundance of additional modules and plugins, there are always representatives who promise a huge added value for their own product, but in the end they don’t work the way they should or stop being developed at a certain point. This is especially true for extensions from third-party vendors, where there may be problems with every new CMS version. The simple solution is to disable plugins (and modules if necessary).

Note

Even if all modules and plugins work properly, the extensions can cause errors like the HTTP-408 error: if you use too many extensions in your CMS, this can negatively affect the performance of your website. Make sure you switch off any unnecessary or no longer required additional functions and design components in time to be able to exclude these scenarios.

Solution 4: check and repair code

Of course, the error does not always have to be traced back to an external source, but can just as easily be hidden in your own code. If you are dealing with error code 408 and have not yet found a solution, either during the web server configuration file inspection or during the content management system check, it is advisable to look at the HTML framework, as well as the built-in CSS snippets and scripts (JavaScript, PHP, etc.). Do not hesitate to perform a complete debugging process with the appropriate software if the timeout problem cannot be solved any other way. This allows you to efficiently locate and repair faulty code.

To display this video, third-party cookies are required. You can access and change your cookie settings here.

Solution 5: increase server resources

The more HTTP requests reach the web server, the more resources it needs for processing. If the available computing power is not sufficient to handle the incoming traffic, error messages like “408: Request Timeout” are not uncommon. If your budget allows, you should consider increasing processor performance and memory.

Note

If your server’s performance is poor despite having sufficient resources, this may indicate technical problems with your hosting provider. Under these circumstances, you cannot correct an HTTP error 408 by posting additional service components. Your only option is to contact the provider directly to get detailed information for possible troubleshooting.

Related articles

Roland IJdemaShutterstock

HTTP Error “405 Method Not Allowed”: How to solve the problem

HTTP is indispensable as a mediator between the browser and web server: Both communicate with each other using the transmission protocol on the application layer by sending various types of messages. With an HTTP request, for example, the browser can request a resource or return its own data to the server. If one of these HTTP methods doesn’t work, error 405 (Method Not Allowed) occurs. But what…

HTTP Error “405 Method Not Allowed”: How to solve the problem

MichaelJayBerlinShutterstock

403 Forbidden: What does the http status code mean and how do you fix it?

Is your browser displaying an http error 403 instead of the web page you requested? This means that the web server has not granted you access to that page. The reason for this differs from case to case; sometimes the website operator as secured this area from being accessed but sometimes it’s simply a case of adjusting your browser settings. This article outlines the various causes of the http…

403 Forbidden: What does the http status code mean and how do you fix it?

Error 522 – ‘Connection timed out’: How to fix the error

52- HTTP error messages indicate a problem between the web server that is running a website and the Cloudflare CDN service. The 522 error is very common and is also known as the ‘Cloudflare error’. It is displayed in the visitor’s browser whenever the mandatory TCP handshake fails. This guide explains the reason for this error message and what solutions there are for site operators and visitors.

Error 522 – ‘Connection timed out’: How to fix the error

MichaelJayBerlinShutterstock

HTTP 400: Bad Request explained

Internet users are often confronted with error messages. HTTP status codes can be especially annoying, and even more so if you don’t understand what they mean. The message ‘HTTP 400 – Bad Request’ is a mystery for many internet users, but luckily it can be solved in most cases. We explain what the error message means and how to fix the error.

HTTP 400: Bad Request explained

DNS_PROBE_FINISHED_NXDOMAIN: The best solutions

If your browser shows an error message instead of the website you wanted to open, it can be hard to know exactly it means and what you can do. For example, the Chrome message “DNS_PROBE_FINISHED_NXDOMAIN” tells users that the domain address could not be resolved to the corresponding IP address. This article shows you what’s behind this connection problem.

DNS_PROBE_FINISHED_NXDOMAIN: The best solutions

Experiencing a 408 Request Timeout Error can be extremely frustrating. HTTP status code starting with 4XX is the client-side error code and 408 request timeout error is one of the client-side errors.

In this guide, we will learn how to fix a 408 request timeout error. Whether you’re a user or a developer, we’ll explore the causes behind this error and provide practical solutions.

From unraveling the technicalities to offering step-by-step troubleshooting, this guide equips you with the know-how to swiftly resolve the issue.

Before we dive into the solution let’s understand what this error actually means and how it differs from the 504 bad gateway timeout error.

What does 408 Request Timeout mean?

A 408 Request Timeout error is an HTTP status code that is returned at the client side when a server takes a longer time to process any particular request than the allocated timeout. When this happens, the server terminates the connection and thus returns 408 Request Timeout error.

It is also possible that the server could be misconfigured and result in improper request handling which may also return a 408 Request Timeout error.

408 Request Timeout Indication

• 408 Request Timeout is displayed
• It crashes the active browser window
• The browser may respond to the request slowly

Different Ways to See a 408 Request Timeout Error

There are several different ways that you might see a 408 Request Timeout error. These errors may appear differently on different web servers or hosting. Although they show different error messages, each one means the same.

• “408 Request Time-out”
• “408: Request Timeout”
• “Request Timeout”
• “The Request Has Timed Out”
• “HTTP Error 408 – Request Timeout”

How is a 408 Request Timeout error different from a 504 Gateway Timeout error?

You may have come across a similar error i.e. 504 Gateway Timeout error. Since these two errors are quite similar, you might be wondering how it is different from one another.

The 504 Gateway Timeout error occurs while acting as a gateway or proxy. On the other hand, a 408 error is returned when a request to load the web page takes longer than the server was prepared to wait.

Learn how to fix the 504 Gateway Timeout error.

How to Fix a 408 Request Timeout Error

In certain cases, it can be difficult to immediately determine the source of an HTTP error. Although 4xx errors are known to be client-side errors, this doesn’t mean that the server should be completely ruled out as the culprit. Below are a few things you can check, both on the client and server side in order to try and resolve a 408 error.

Fix a 408 Request Timeout error at client-side

Reload the Web Page

There are instances when this error occurs temporarily on the client side because of the browser. You can try to reload the web page or even reopen the browser to see if the error gets resolved.

Double check URL

Depending upon the configuration of your web server, the requested URL might throw a 408 request timeout error. Suppose, you are requesting a URL that requires certain permissions or credentials to get access, this might trigger a 408 error.

Check your internet connection

If there is any issue with your internet connection or it is running slow then the request made can take too long to complete. As a result, the server’s timeout exceeds and becomes idle which results in a 408 request timeout error.

Fix a 408 Request Timeout error on server-side

Check your web server’s timeout settings

Most web servers like Apache and Nginx allow website developers to set certain timeout values in the configuration file which enables you to control the time required for certain requests.

So if you are receiving the 408 timeout error, the configured timeout value might be too low. You increase the timeout value and restart the server to see if the issue is resolved.

Apache

If you’re using the Apache web server, you need to check both the .htaccess file and the Apache server config file. Inside these files look for the KeepAliveTimeout or RequestReadTimeout directives. If either of these directives is defined, increase its value and reload the webserver.

If you don’t find these directives inside the configuration file, you can add them along with their values and test a few requests by reloading the web server.

NGINX

If you’re using Nginx as a web server, open the nginx.conf file and check for directives like client_body_timeout, client_header_timeoutand keepalive_timeout and then increase their values.

If you don’t find these directives, add them inside the http or server block along with their values.

You can test a few requests by increasing their values and reloading the web server.

Check the logs

While investigating any kind of server error, it’s a good idea to check the error logs. It provides you with a whole lot of information about the error.

Additional Ways to Fix a 408 Request Timeout Error

Other Fixes

• How to Fix 403 Forbidden Error in NGINX Ubuntu
• Fix 413 Request Entity Too Large Error on Nginx & Apache
• Fix 502 Bad Gateway Nginx Error in Ubuntu – 4 Simple Steps
• PHP5-FPM 502 Bad Gateway Error (connect() to unix:/var/run/php5-fpm.sock failed (2: No such file or directory)
• Fix 504 Gateway Timeout Nginx Error – 5 Simple Steps

Conclusion

A 408 Request Timeout error is fairly common and can be fixed quite easily most of the time. It simply passes the message to the client side that the request timed out for the website and that the server has terminated the connection.

I hope that you’ll find the solution for addressing the 408 Request Timeout Error highly beneficial. We encourage you to share your thoughts and feedback in the comment section below.

Your insights are greatly valued and can contribute to refining the troubleshooting process even further.

Thank you for engaging with us!