409 ошибка nginx

When you attempt to view a website, you may see an error message that prevents you from accessing the page. If the server notices a conflict between the HTTP request and the resource, it will display a “409 Conflict” error.

Although this scenario can be frustrating, you can easily fix the 409 error. On the client side, you can fix typos in the requested URL, clear your browser cache, and uninstall browser extensions. Alternatively, you can solve this conflict as a website administrator by uninstalling core software and plugins or reviewing your server configuration.

In this post, we’ll give you an overview of the 409 error and its causes. Then, we’ll show you how to check your website for this issue and fix it if necessary. Let’s get started!

Check Out Our Video Guide to Fixing the “409 Conflict” Error

What Is the “409 Conflict” Error?

After making an HTTP request (such as loading a page), you may see an error message informing you that the request couldn’t be completed. In most cases, your browser will tell you what went wrong.

For example, a 400 Bad Request error will occur after a client-side error, like incorrect request syntax, corrupted browser cache, or large file sizes:

Screenshot of the 400 Bad Request error

400 Bad Request error

However, there are many other HTTP status codes. They belong to five different classes:

  • 100s: Informational status codes that indicate continuing requests.
  • 200s: Success codes for well-functioning requests.
  • 300s: Redirection messages explaining a redirect to another resource.
  • 400s: Error codes for client-side problems.
  • 500s: Error codes for server-side issues.

If you see a “409 Conflict” error, this is a 400 HTTP status code. In short, the request wasn’t completed because of a conflict with the resource’s current state.

Although this issue might seem complicated, you can usually resolve the conflict and try the request again. Fortunately, unlike server-side errors, the “409 Conflict” error code has some simple solutions.

Don’t worry- fixing the 409 error is easier than it may seem! 🚀 Keep reading to see exactly how to get it sorted… 💪Click to Tweet

What Causes the “409 Conflict” Error?

As its name suggests, the “409 Conflict” error results from some conflict in the HTTP request. It may happen because the requested resource is not in its expected state. Alternatively, the request itself could create a conflict if completed.

A 409 error usually occurs in response to a PUT request. This request updates the target resource. You can use a PUT request to make a new resource or replace an existing one.

However, if there are conflicting values in the PUT payload, they can cause a 409 error. For example, if you mistype certain fields, the server can notice these inconsistencies and reject the request.

You might also see a 409 response if you try to upload a file to your site that’s older than the existing one. Doing this will create a version control conflict that can result in a 409 error.

How To Locate the “409 Conflict” Error

To identify any 409 errors on your website, you can evaluate your HTTP requests and start troubleshooting them. This process will depend on the web hosting company for your site.

With a Kinsta hosting plan, you can manage your site logs in the MyKinsta dashboard. First, log in to your account and select the Sites tab. Then, choose the website you want to evaluate:

Choose sites in MyKinsta

MyKinsta Sites

This will open a page with basic information about your website. On the left-hand side, click on the Logs option:

Click on the Logs tab in MyKinsta

MyKinsta logs

After opening the Log viewer, you can see a record of specific errors on your website. If you don’t see a 409 error here, switch to access.log, which contains all of the requests processed by DevKinsta:

See records in Log Viewer

See records in Log Viewer

Here is the basic information you’ll see in each request:

  • Date and time
  • Request (method and URI)
  • HTTP error code or “200 OK” for successful requests
  • Bytes sent
  • HTTP referer
  • User-agent
  • HTTP X Forwarded for

You can look through the list of server requests to find any 409 HTTP status codes. Be sure to look for PUT requests since these can also contribute to conflict errors.

If needed, you can use the search bar to filter your results. Once you locate a “409 Conflict” error, you can proceed with the following solutions.

How To Fix the “409 Conflict” Error (5 Methods)

Even after you experience a 409 error, there are a few ways to resolve it. If you’re unsure what’s causing the issue, you may have to try a combination of different methods. Here are five of the most common fixes!

1. Check the Requested URL

As we mentioned earlier, the “409 Conflict” error can arise from incorrect information in a PUT request. When updating a resource, you’ll want to make sure that you entered its destination correctly.

Before you try more complex solutions, it’s a good idea to review the requested URL. If you manually entered this information, you may have accidentally made a typo that caused an error in the request.

If you made a mistake in this data, you can correct it and try the request again. Sometimes, this will enable you to continue with the request without causing a 409 error.

You can also try simply refreshing the page. Sometimes, old errors can disappear given enough time. Plus, the website owner could have already resolved the issue.

2. Clear Your Browser Cache

When you first view a website, your browser stores that page’s data in a cache. This way, you can easily reaccess those resources. Once you visit the site a second time, your browser will pull the cached data instead of requesting the resources from the server.

After you’ve recently fixed an error in your request, like a mistyped URL, you may still see the 409 error. Although the issue could already be resolved, the error message might still display because of your browser cache. In this case, you can clear your cache to remove the HTTP status code.

The method you use to do this will depend on your browser type. For Google Chrome users, you can start by clicking the three-dot icon in the top-right corner of the page. Then select More Tools > Clear Browsing Data:

Clear browsing data in Chrome

Clear browsing data in Chrome

In the new pop-up, select Cached images and files. If needed, you can also clear your browsing history, cookies, and other site data. Then, click on Clear data:

Clearing cached images and files in Google Chrome

Clearing cached images and files in Google Chrome

Although this will clear most of your cache, your browser will likely keep additional data that most users don’t want to be deleted. However, if you want to remove your full cache, navigate to the Advanced tab:

Chrome advanced cache data popup

Chrome advanced cache data

Here, you can select the data you want to delete from your cache. You can choose from these options:

  • Browsing history
  • Download history
  • Cookies and other site data
  • Cached images and files
  • Passwords and other sign-in data
  • Autofill form data
  • Site settings
  • Hosted app data

Once you specify the information to remove, click on Clear data. Now you can try the request again to see if the 409 error has been resolved!

3. Roll Back Recent Updates

Sometimes, HTTP error codes can be caused by conflicting software. To troubleshoot a “409 Conflict” error, consider downgrading your WordPress website. This downgrade can help you evaluate whether the core software conflicted with other tools on your site.

However, you’ll need to back up your website before starting this process. If not, you risk losing important changes you made with this new software update. After troubleshooting the issue, you can quickly restore your site to its former state.

Since Kinsta performs daily automatic backups, you can downgrade WordPress by restoring a previous backup. To do this, click on the Backups tab in your MyKinsta dashboard:

Backups in MyKinsta

MyKinsta backups

Then, select the backup you want to restore. Click on Restore to and choose whether to implement these changes in your staging environment or live site:

Restore backup in MyKinsta

Restore backup in MyKinsta

Finally, confirm the restoration by entering the given text:

Confirm backup restoration in MyKinsta

Confirm backup restoration

If you updated your website long ago, you’ll likely need to use another method of downgrading your site. Since Kinsta only saves your daily backups for 14 days, you may not be able to restore an older version.

As an alternative, you can install the WP Downgrade plugin. This tool will enable you to easily reinstall an older version of WordPress:

WP Downgrade plugin

WP Downgrade

First, install and activate the plugin. Then go to Settings > WP Downgrade:

Screenshot of WP Downgrade settings

WP Downgrade settings

Enter the exact number for the previous WordPress version to downgrade your software. When you’re finished, save your changes.

You may want to consider rolling back your computer update as well. For Windows users, you can do this in the update history settings. You can also downgrade a Mac computer by reverting to a Time Machine backup.

4. Uninstall Plugins and Extensions

If you don’t want to downgrade your website completely, you can deactivate your plugins and third-party tools. By removing this software, you’ll likely eliminate any conflicts.

To deactivate your plugins, go to the Plugins page on your WordPress dashboard. Then, select all of your plugins:

Select all plugins in WordPress

Select all plugins in WordPress

Click on the Bulk actions menu and select the Deactivate option. To finalize these changes, hit Apply:

Deactivate plugins in WordPress

Deactivate plugins in WordPress

Now you can try the request to see if you receive the 409 error. If the request is successful, you’ll know there was a conflict with one of your plugins.

To identify which plugin is causing the issue, activate each plugin one at a time. After each activation, check to see if the error happens again.

Once you locate the problematic plugin, you can delete it. If it performs a necessary task on your website, consider browsing the WordPress Plugin Directory for an alternative. Usually, you can find a different tool with similar functionality.

Alternatively, there could be an issue on the client-side of the request. To solve a 409 error, you can disable your browser extensions. On Chrome, go to More Tools > Extensions:

Chrome extensions

Chrome extensions

This will open a list of your enabled extensions. To disable them, make sure the switch next to each one is turned off:

Manage Chrome extensions

Manage Chrome extensions

You can also delete the extensions completely. This should eliminate any software conflicts. However, you should only do this with unnecessary tools.

5. Review Your Server Configuration

As a last resort, you can check your server configuration for errors. In MyKinsta, you can use the built-in Application Performance Monitoring (APM). With this APM tool, you can identify any long external requests, unoptimized plugin code, and slow database queries:

Kinsta APM homepage

Kinsta APM

To open the Kinsta APM, sign in to MyKinsta. Next, head to Sites > Kinsta APM:

MyKinsta APM

MyKinsta APM

Then, you’ll have to enable performance monitoring for a certain period. At the top of the page, click on Enable:

Enable Kinsta APM

Enable Kinsta APM

In the pop-up window, select the amount of time you want Kinsta to evaluate. You can enable a monitoring time window between 2 hours and 24 hours:

APM monitoring time

APM monitoring time

After you enable performance monitoring, you can use your results to troubleshoot the 409 error. You’ll be able to view all your requests and analyze your server’s response time:

APM monitoring results

APM monitoring results

Alternatively, you can use the Query Monitor plugin. This free tool enables you to see the performance level of your database queries, scripts, hooks and actions, block editor blocks, and more:

Query Monitor plugin

Query Monitor plugin

First, install and activate Query Monitor. Then, click on the new tab at the top of your WordPress dashboard:

Query Monitor tab

Query Monitor tab

Here, you can view reports for your site’s queries, requests, scripts, and other data. Under HTTP API Calls, you can see a list of any request errors:

Query Monitor results

Query Monitor results

With either of these tools, you can easily find 409 errors and discover the root cause of the issue. Then you don’t have to waste time troubleshooting other areas of your website.

There are several options to fix this error- and they’re all covered in this helpful guide 🚀Click to Tweet

Summary

When a conflict occurs during a request, you’ll likely see a 409 error. In this case, the server can’t send the relevant information because of a problem with the state of the requested resource. After identifying the conflicting requested values, you can try the request again.

To review, here’s how you can fix the “409 Conflict” error in WordPress:

  1. Check the requested URL.
  2. Clear your browser cache.
  3. Roll back recent updates.
  4. Uninstall plugins and extensions.
  5. Review your server configuration.

With Kinsta web hosting, we provide all the tools you need to troubleshoot performance errors as soon as they occur. Using our APM, you can review your external requests and fix conflicts to keep your website functioning properly!

Trying to configure nginx for proxy HTTP CRUD requests to fastcgi

nginx config:

server {
    listen   80;
    server_name api.example.dev;

    dav_methods  PUT DELETE;

    dav_access group:rw all:r;
    create_full_put_path on;

    index index_dev.php;
    set $root_path '/var/www/api/public';
    root $root_path;
    try_files $uri $uri/ @rewrite;

    location @rewrite {
        rewrite ^/(.*)$ /index_dev.php?_url=/$1;
    }

    location ~ \.php {
        fastcgi_pass unix:/var/run/php-fpm.api.sock;
        fastcgi_index /index_dev.php;
        include /etc/nginx/fastcgi_params;
        fastcgi_split_path_info       ^(.+\.php)(/.+)$;
        fastcgi_param PATH_INFO       $fastcgi_path_info;
        fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HOST $host;
        fastcgi_param DESTINATION $http_destination;
        fastcgi_param OVERWRITE $http_overwrite;
        fastcgi_param APPLICATION_ENV dev;
    }
}

On PHP side i’ve got phalcon php-framework.
Witch works fine with simple GET/POST requests. And routers from framework can handle PUT, DELETE methods. But when i try to make simple PUT method request nginx return me 409 Conflict error with that configuration above.

I can’t find any suggestions for that case and how to pass web_dav methods to php from nginx.

Thanks.

asked Jul 12, 2013 at 8:36

lazycommit's user avatar

This answer is in the context of plain nginx WebDav, but may be useful to your PHP situation as well. I’ve found that you’ll get a 409 if you try to specify a destination parent folder instead of the complete destination including the filename. Example:

Setup:

$ echo "test" >> ~/test.txt
$ cat ~/test.txt
test

Bad test:

$ curl -X PUT -d `cat ~/test.txt` http://localhost:8080/
<html>
<head><title>409 Conflict</title></head>
<body bgcolor="white">
<center><h1>409 Conflict</h1></center>
<hr><center>nginx/1.5.0</center>
</body>
</html>

Good test:

$ curl -X PUT -d `cat ~/test.txt` http://localhost:8080/test.txt
$ curl -X GET http://localhost:8080/test.txt
test
$

answered Nov 8, 2013 at 0:32

CrazyPyro's user avatar

CrazyPyroCrazyPyro

3,2573 gold badges30 silver badges39 bronze badges

I am trying to install an NGINX web server which would accept HTTP PUT requests from external source. But every time when I try to put a file on my web server from the external IP I got Error 409 Conflict:

$ curl -X PUT http://192.168.178.100/hls/ -d index.m3u8
<html>
<head><title>409 Conflict</title></head>
<body bgcolor="white">
<center><h1>409 Conflict</h1></center>
<hr><center>nginx/1.10.0 (Ubuntu)</center>
</body>
</html>

My /etc/nginx/sites-available/default config is:

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    root /var/www/html;
    index index.html index.htm;

    server_name 192.168.178.100;
    location / {
        try_files $uri $uri/ =404;
    dav_methods PUT;
    }
}

Any ideas what could be wrong? When I upload the files manually I can read them from the http://192.168.178.100/hls/ and the web server is up and running.

And this is my error in the /var/log/nginx/error.log

cannot PUT to a collection, client: 192.168.178.50, server: 192.168.178.100, request: "PUT /hls/ HTTP/1.1", host: "192.168.178.100"

My system is Ubuntu 16.04 and I haven’t installed PHP and MariaDB on it because I don’t need them.

This should be an easy one!

You have likely created the /mnt/zfsstorage/externalHDD/folderx as root user, see the root root part. This corresponds to UID 0 and GID 0.

This folder has the same owner from the container side, at /data.

nginx is, however, running as user abc, group abc, with UID 1000 and GID 1000 as you specified with the PUID and PGID variables. nginx can’t access the /data folder.

Solution, hopefully. Stop the container. From the host, run something like chown -R 1000:1000 /mnt/zfsstorage/externalHDD/folderx. This will assign, from the host level, correct permissions to access the folder. Run the container again. It should work.

If you need to add files to /mnt/zfsstorage/externalHDD/folderx via other ways (that is, not through WebDAV), you need to re-assign permissions to the folder. Otherwise, it should keep working.

Let me know!

We are moving our forum in GitHub Discussions.
For questions about Phalcon v3/v4 you can visit
here
and for Phalcon v5
here.

  1. Home
  2. General
Created
Last Reply
Apr ’15
Replies
1
Views
2180
Votes
0

Hi,

I have a simple piece of code that works well on Apache, but does not return any body when using Nginx. It is a piece of code taken straight (mostly) from the official Phalcon documentation.

    $this->response->setStatusCode(409, 'Conflict')
                            ->setContentType('application/json', 'UTF-8')
                            ->setJsonContent(array('success' => false, 'error' => 'blabla'))
                            ->send();

    die();

Why is this happening? Is this a bug in Phalcon, or should we modify something in our Nginx server for this to work properly?

Thanks in advance!

Best regards,

If you do this in PHP, does it work?

header("409 Conflict");
header('Content-Type: application/json');
echo json_encode(array('success' => false, 'error' => 'blabla'));


edited Apr ’15

Yes it does, it’s the first thing I tested. Although the precise code I am using is:

http_response_code(409);
header('Content-type: application/json; charset=utf-8');
echo json_encode(array('success' => false, 'message' => 'Test http status code 409'));
die();

EDIT : we are using Phalcon 1.3.4 and nginx 1.6.2. Should we be using Phalcon 2.0.0 in production env? I see that it is marked as «stable» here https://phalcon.io/fr/download/windows

Ok it seems it is due to nginx not sending some headers (CORS related) when response is 4xx.

For other people in that situation, you have to use headers_more module and recompile nginx.

Sorry for the trouble! (the catch was that the standard code was working when doing same-domain GET request, whereas the Phalcon code was tested via a cross-domain Ajax API)

Понравилась статья? Поделить с друзьями:

Интересное по теме:

  • 408 ошибка стендофф
  • 4122 ошибка терминала сбербанка как исправить
  • 4121 ошибка сбербанк
  • 4076 ошибка тигуан
  • 4121 ошибка bmw

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии