499 код ошибки http

When managing and maintaining a website, there are a handful of HTTP status codes to be aware of. Some, such as the HTTP 499 error, can cause a timeout that interrupts your workflow. Therefore, you’ll need to ensure that your site is configured properly to avoid this issue.

Whether you’re seeing the HTTP 499 status code frequently or for the first time, it may indicate an issue with your website that needs to be addressed. The good news is that there are multiple steps you can take to resolve it.

Check Out Our Video Guide to Fixing the 499 Error

In this post, we’ll explain the HTTP 499 status code and what can cause the error. Then we’ll walk you through five potential solutions you can use to fix it. Let’s get started!

What the HTTP 499 Status Code Means

The HTTP 499 status code, also known as a “client closed request,” is a special case of the 502 Bad Gateway Error. It indicates that the client has closed the connection while the server is still processing the request.

HTTP 499 falls within the category of client-based errors. This means the issue is on the client side. Other common errors in this category include HTTP 400 Bad Request and HTTP 404 Not Found. With these errors, the problems are usually easy to define. However, HTTP 499 is more general.

The HTTP 499 error can happen on both Nginx and Apache servers. However, it is more common on Nginx servers because it was created by Nginx.

HTTP 499 is more common on Nginx because the server software handles client connections differently than Apache. With Nginx, each client connection is processed in a separate thread. Therefore, if one client connection takes a long time to process, it won’t slow down the other clients.

However, with Apache, all client connections are processed in the same thread. This can cause problems if one client connection takes a long time to process because it will slow down all other clients.

The HTTP 499 error can cause a timeout that interrupts your workflow- but with a little help from this guide, you can get right back on track 👩‍💻Click to Tweet

What Causes the HTTP 499 Error

Typically, the HTTP 499 error appears in Nginx logs. This can happen for several reasons, but most commonly, it’s due to either a browser timing out or a user canceling the request.

For example, a website may encounter an HTTP code 499 when it’s loaded with too much traffic. Alternatively, the error can happen when the request comes from algorithms that create issues within the site.

In some cases, this status code may also display when there is no response from the server, and the client has timed out waiting for a response. In these cases, it’s usually best to just try again later. However, if you are consistently getting this status code from a particular server, it may be worth investigating further to see if there is an overarching issue.

How To Fix the HTTP 499 Error (5 Potential Solutions)

Now that we understand more about the HTTP 499 error, let’s look at how to resolve it. Below are five potential solutions for the HTTP 499 status code!

1. Clear Your Browser Cache and Try Again

As we mentioned earlier, this error may be a temporary issue that can be resolved by simply trying to load the page again. It might be that your host or server is overloaded. Therefore, we recommend clearing your browser cache and trying again.

The process for clearing the cache will vary depending on your browser. If you’re using Google Chrome, you can navigate to the three vertical dots in the upper right-hand corner of the window, then go to More tools > Clear browsing data:

You’ll then be prompted to choose which data to clear from your browser cache:

When you’re done, reload your browser. You can also try using a different browser in the meantime. Then revisit your site to see whether the error message is still showing.

2. Disable Your Plugins and Extensions

Some users have reported that certain plugins cause the HTTP 499 status code error. Therefore, we recommend temporarily disabling your plugins to see if this resolves the issue.

You can do this by navigating to your Plugins screen in the WordPress dashboard, selecting all of them, then clicking on Deactivate > Apply from the bulk actions menu:

You can also connect to your site via a File Transfer Protocol (FTP) client or File Manager, then navigate to your plugins folder (wp_content > plugins). Right-click on the plugins folder and rename it to something such as “plugins_old.”

This will deactivate all of the plugins on your WordPress site. You can revisit your website to see whether the error message is still showing. If not, you can try activating your plugins one by one until you find the tool causing the issue.

3. Check Your Error Logs

When troubleshooting the HTTP 499 code, it’s essential to leverage your error logs. This approach will make it easier to narrow down the issue and determine whether it results from a specific plugin or tool.

If you’re not a Kinsta user, you can enable and view error logs by turning on WordPress debugging mode. However, if you’re a Kinsta user, you can quickly and easily see errors in the Log viewer from your MyKinsta dashboard:

You can also check your log files in Nginx (/var/log/nginx.error.log) and Apache (/var/log/apache2/error.log). Furthermore, Kinsta users can take advantage of our analytics tool to take a closer look at errors on your site. Then you can understand how often they’re occurring and whether the HTTP 499 error is an ongoing issue.

4. Use an Application Performance Monitoring (APM) Tool

When managing a website, it’s important to have reliable solutions for identifying and troubleshooting errors on your site. We recommend using an Application Performance Monitoring (APM) tool.

APM tools can help you narrow down which script or plugin may lead to various errors, such as HTTP 499. We include our Kinsta APM, as well as a variety of other DevKinsta tools, with all of our plans:

For example, your APM tool can help you collect valuable data and determine which applications are causing delays. Once enabled, you can use KinstaAPM to view the slowest transactions on your site, trace their timelines, and figure out the causes of issues. Our APM also provides insight into your PHP processes, MySQL queries, external HTTP requests, and more.

5. Contact Your Web Host and Request a Timeout Increase

As we’ve discussed, sometimes HTTP 499 errors can occur when a request is canceled because it’s taking too long. Some hosting providers use a ”kill script”.

In short, a kill script forces a request to be terminated after a certain amount of time. This script is often used in shared hosting environments to prevent long requests from impacting other sites.

If you’re a Kinsta user, this isn’t something you need to worry about. Each site hosted on our platform runs on an isolated software container that includes all resources and software. Everything is completely private, and none of your resources are shared, so we don’t run kill scripts.

However, when it comes to the HTTP 499 error, it’s important to note that the “client” may be a proxy, such as a Content Delivery Network (CDN) or load balancer. A load balancing service can act as a client to the Nginx server and proxy data between your server and users. This can cause a timeout that cancels the request to the Nginx server.

PHP timeouts happen if a process runs longer than the maximum execution time (max_execution_time) or max_input_time specified in your server’s PHP configuration. You may encounter timeouts if you have a busy website or scripts that need longer execution times. Therefore, it might be necessary to extend your timeout value.

Let’s say you have a request that is expected to take 20 seconds to complete. If you have an application with a timeout value of 10 seconds, the application will probably time out before completing the request. You’ll likely see the HTTP 499 status code in such an instance.

Therefore, it’s wise to check with your host about the values set on your server. At Kinsta, the default max_execution_time and max_input_time values are set to 300 seconds (5 minutes). The maximum PHP timeout values vary depending on your plan.

If necessary, you can reach out to your hosting provider to request a timeout increase. As a Kinsta user, you can open a ticket with our support team.

With help from this guide, you can ensure your site is properly configured to avoid seeing this error in the future. ✅ Here’s how… 🚀Click to Tweet

Summary

There are a wide variety of HTTP status codes to be aware of as a website owner. Some of the trickiest are client-based errors, such as the HTTP 499 code. The good news is that you can take a handful of steps to resolve this issue.

In this post, we discussed five potential solutions you can use to fix the HTTP 499 status code error. All of them are viable options; if one doesn’t work, another one should.

Do you want to troubleshoot and resolve issues in WordPress as painlessly as possible? Check out Kinsta hosting plans to learn how our APM tool and other solutions can streamline your website maintenance and management!

In my case, I was impatient and ended up misinterpreting the log.

In fact, the real problem was the communication between nginx and uwsgi, and not between the browser and nginx. If I had loaded the site in my browser and had waited long enough I would have gotten a «504 — Bad Gateway». But it took so long, that I kept trying stuff, and then refresh in the browser. So I never waited long enough to see the 504 error. When refreshing in the browser, that is when the previous request is closed, and Nginx writes that in the log as 499.

Elaboration

Here I will assume that the reader knows as little as I did when I started playing around.

My setup was a reverse proxy, the nginx server, and an application server, the uWSGI server behind it. All requests from the client would go to the nginx server, then forwarded to the uWSGI server, and then response was sent the same way back. I think this is how everyone uses nginx/uwsgi and are supposed to use it.

My nginx worked as it should, but something was wrong with the uwsgi server. There are two ways (maybe more) in which the uwsgi server can fail to respond to the nginx server.

1) uWSGI says, «I’m processing, just wait and you will soon get a response». nginx has a certain period of time, that it is willing to wait, fx 20 seconds. After that, it will respond to the client, with a 504 error.

2) uWSGI is dead, or uWSGi dies while nginx is waiting for it. nginx sees that right away and in that case, it returns a 499 error.

I was testing my setup by making requests in the client (browser). In the browser nothing happened, it just kept hanging. After maybe 10 seconds (less than the timeout) I concluded that something was not right (which was true), and closed the uWSGI server from the command line. Then I would go to the uWSGI settings, try something new, and then restart the uWSGI server. The moment I closed the uWSGI server, the nginx server would return a 499 error.

So I kept debugging with the 499 erroe, which means googling for the 499 error. But if I had waited long enough, I would have gotten the 504 error. If I had gotten the 504 error, I would have been able to understand the problem better, and then be able to debug.

So the conclusion is, that the problem was with uWGSI, which kept hanging («Wait a little longer, just a little longer, then I will have an answer for you…»).

How I fixed that problem, I don’t remember. I guess it could be caused by a lot of things.

HTTP response status code 499 is an unofficial client error that is specific to both ArcGIS with 499 Token Required and nginx with 499 Client Closed Request.

Usage specific to ArcGIS

When the 499 Token Required status code is received, the server is expecting a token to accompany the HTTP request but it was not submitted. To solve this error, the HTTP request needs to be resubmitted with a valid token.

Usage specific to nginx

When the 499 Client Closed Request status code is generated, it means that the client has closed the HTTP Connection in advance of the server completing the task. As such, the final response cannot be sent and this status code is only available in the nginx logs.

Takeaway

The 499 Token Required / Client Closed Request status code is specific to ArcGIS, where the HTTP request required a token that was not included, and nginx, where the client closed the HTTP request prematurely.

See also

• ArcGIS Survey123
• Esri Technical Support for ArcGIS error 499
• nginx HTTP return Codes

Understand the HTTP 499 Client Closed Request error: What are the causes and how to fix it.

Table of Contents

• What is the 499 Client Closed Request error?
• How to fix the 499 Client Closed Request error
  • 499 error when the website is behind a proxy
    • The right way to set the timeouts
  • 499 when your server closed the connection
    • How to fix the 499 error when your application dies
  • 499 when your server is under a DOS or DDOS attack
    • How to fix the 499 error when DOS/DDOS attacks:
• All HTTP Status Codes

What is the 499 Client Closed Request error?

The 499 HTTP is a non-standard status code introduced by Nginx when a client, for instance a browser, closes the connection while Nginx is processing the request.

There are various reasons why the client would not process the request and ended up with a 499 error code. In the following sections, we will help you identify the different causes and how to fix them in each case.

499 error when the website is behind a proxy

You may find 499 errors when you have a Load Balancing service between your users and your Nginx. A similar situation occurs when your Nginx site is served by a CDN or is behind a WAF (Web Application Firewall).

The 499 error happens when the front server attending your browser request is an Nginx server in reverse proxy mode, and it sends the request to your server site, but your site process exceeds the waiting time of the front server.

To fix this error, you can:

• Increase the processing capacity of your application server. By increasing the “processing power”, you will reduce the waiting time of the Nginx clients in front of your service.
• If you cannot increase the power of your application server, then increase the timeouts of your proxies (load balancer, CDN, firewall, …).

At Wetopi you can increase the size of your server with a single click.

★ Zero-config: configuration files for all server services are transparently adjusted to the power.

The right way to set the timeouts

If there are proxies on your setup such as a “Load balancer”, a Firewall, a CDN, etc, you should set the timeouts so that you timeout first your application server and then the other proxies to the user.

Example:

User → CDN → Nginx Load Balancer → Nginx application → Php_fpm

It’s recommended to set the timeouts like this:

• n seconds to Php_fpm timeout.
  Set the php.ini max_execution_time and
  the request_terminate_timeout in your php_fpm config file.

• n+1 seconds to Nginx application timeout.
  Set the fastcgi_read_timeout in your nginx config.

• n+2 seconds to timeout to Nginx Load Balancer
  In your location doing the proxy_pass set the timeouts of:
  proxy_connect_timeout
proxy_send_timeout
proxy_read_timeout
• n+3 seconds of timeout for your CDN. NOTE: If you can’t set the timeouts of your CDN, then find what is its timeout and adjust the others according to it.

It provides a correct chain of timeouts: Setting an incremental chain of timeouts lets you find who is reaching the timeout.

499 when your server closed the connection

This could be your case, If:

1. your site is running with an Nginx server and,
2. the request is passed to an application processor e.g. php_fpm, or
3. the request is passed to your API

This setup is configured using the nginx fastcgi_pass directive.

This 499 error code is produced when your server is too slow.

e.g. your WordPress page process takes too long or freezes

To correct this error, you can:

• Increase the processing capacity of your server. By increasing “processing power”, you will reduce the period Nginx waits.
• If you cannot increase your server power, increase Nginx timeouts with the directive: fastcgi_read_timeout.

How to fix the 499 error when your application dies

• First, tell the Nginx to wait longer. Increase the timeouts of your Nginx by modifying the fastcgi_read_timeout.
• If waiting longer does not solve the problem, increase the processing capacity of your server.
• If the 499 error occurs on a specific page or request, it could be a “hung” or “code freeze” in your application or content manager. If you use WordPress, check plugin compatibility. If database queries are made, check the good status of tables and indexes.

499 when your server is under a DOS or DDOS attack

There might be a case when someone attacks, and intentionally consumes the server resources. This makes the server unable to process the request and return the result on time.

To verify if this is your case: look at your analytics, and search for spikes in traffic with requests giving the 499 status code:

How to fix the 499 error when DOS/DDOS attacks:

In this case, the best solution is a combination of security measures:

• Prevention: avoid non-legit traffic. You can filter malicious traffic with a combination of public and private blacklists.
• Add infrastructure protection against DOS (Denial of Service) and DDOS (Distributed Denial of Service). Find a hosting provider with infrastructure ready to mitigate this kind of attack.
• Add a protection layer, a security proxy, in front of your server, or
• Add an external security service. A well-known one is Cloudflare. They put a distributed infrastructure in front of your server to fight against DDOS attacks.

At Wetopi, as WordPress specialists, we know how important it is to add strong measures of security.
We apply three techniques to filter traffic:

Shared security heuristic learning,
Blacklisting from external sources and
Mitigation of DDoS attacks.

We are techies passionate about WordPress. With wetopi, a Managed WordPress Hosting, we want to minimize the friction that every professional faces when working and hosting WordPress projects.

Not a wetopi user?

Free full performance servers for your development and test.
No credit card required.

All HTTP Status Codes