• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Question 404, WordPress static page with NGINX

Paulo_o

New Pleskian
Server operating system version
Ubuntu 18.04.6 LTS
Plesk version and microupdate number
Plesk Obsidian 18.0.52 (upgrade #3)
I’m using NGINX reverse proxy configuration and want to “redirect” all the 404 errors to a specific static page. So, the server should not load WordPress, avoid delays and additional unnecessary php-fpm cpu load.

I have tested several configurations on Plesk Obsidian “Additional nginx directives”. However, the server is ignoring all of them and always redirects to 404.php theme file.
 
I’m using NGINX reverse proxy configuration and want to “redirect” all the 404 errors to a specific static page. So, the server should not load WordPress, avoid delays and additional unnecessary php-fpm cpu load.

I have tested several configurations on Plesk Obsidian “Additional nginx directives”. However, the server is ignoring all of them and always redirects to 404.php theme file.

@Paulo_o

In essence, that is default WordPress behavior.

The 404 pages are MOSTLY generated by WordPress and, as a result, it is not possible to reroute these 404 pages via Nginx.

However, there are some situations in which non-existing pages or files are being requested and these requests are forwarded by Nginx to Apache.

These requests can be "blocked" on the Nginx level (in order to prevent that these requests reach Apache), but it is not really recommended.

In fact, the default Nginx configuration provided with Plesk does a nice job banning specific requests on the Nginx level that would otherwise be forwarded.


As for a more practical approach of your "issue", it is recommended that you first determine which requests result in a 404 generated by WordPress.

If you have some insight in those requests, then you are very likely to be able to alter the page structure of the specific WordPress instance.

After all, if all permalinks and redirects (in WordPress) are set properly, then the 404 pages would be reduced to an absolute minimum.

In most cases, one should be able to live with that absolute minimum of 404 pages.

Stated differently, try to have a look at the page structure of the WordPress instance ...... after that, you can still - if needed at all - do some work with Nginx.


Kind regards....
 
Hi @trialotto

Thank you very much for your useful comments.


The major issue I have found its related with too many accesses to images at /wp-content/uploads/ (I have near 500.000 images that may change daily, some are deleted causing 404's). On top of that, each image may have a specific link for several languages as per the translation system.

Currently, each access (mainly from good web crawlers) need to be processed by WordPress (e.g. 404.php). In some cases, this causes unusual high CPU usage. If we may provide a simple 404 static reply, the process its much faster and with very low CPU load.

There is no point of having a 404 page loading. On this case its pure resources waste.


In the meantime, I have made the following change:


PLESK NGINX - WP Toolkit

# WordPress permalink
# To remove this rule, add "wordpressPermalinkHandlingFeature = false" in the [ext-wp-toolkit] section of panel.ini
# then reconfigure the current domain
set $sef_entry_point /;
if ($uri ~* "^/") {
set $sef_entry_point "/index.php?$args";
}
location @wpt_permalinks_fallback {
try_files $uri $sef_entry_point;
}
error_page 404 = @wpt_permalinks_fallback;
error_page 405 = @wpt_permalinks_fallback;



After changing "wordpressPermalinkHandlingFeature = false" on the plesk panel.ini, all the existing 404 are no more loading WordPress. As a result of non-usage php-fpm, db, etc., I had about 20% to 40% CPU reduction.

The improvement seems mainly related with the following directive removal
error_page 404 = @wpt_permalinks_fallback;


I do not know in detail the purpose of this code from WP Toolkit.

According with tests performed until now, I did not find any errors for disabling this block of code and solved most part of the issue.

So, for the moment I have 2 main doubts:

1) What is the purpose of this NGINX code?
2) Is there a way to make something similar for the WordPress pages in /products/? Here we have also some 404's.

Kind Regards and thanks!
 
@Paulo_o

The Nginx code is required for specific permalink settings of WordPress to work - that is the brief and simple explanation : this code actually prevents 404's by instructing Nginx to forward "pretty permalink" requests - which are not actual URI - as URI to Apache that can be dealt with by WordPress.

It is hence not really recommended to remove the error_page directives from Nginx config - you applied a "very dirty workaround", which is not good.

That was question 1.


Question 2 can be answered by a more general solution (and not a dirty workaround) that applies to your general issue of non-existing files.

It does not matter whether you have an URI pointing to a non-existing product or a non-existing file (such as an image).

The non-existing product page or image result in a 404 generated by WordPress, due to the fact that the URI is not existing.


Thanks to the non-existing URI, one gets "redirected" to the Nginx location block with the name @wpt_permalinks_fallback .......

............ and there is the issue : in that location block, it is specified that Nginx should attempt to resolve the request with (in chronological order)

1 - $uri : the URI, if it can be matched by Nginx,

2 - $sef_entry_point : a value equal to "/" by default and to "/index.php?$args" if the URI starts with / but cannot be matched by Nginx,

and, as a result, pretty permalink requests are "redirected" to "/index.php?$args".


In your case, it is not about pretty permalink requests, but all about requests that cannot be matched by Nginx thanks to non-existing files or images.

Stated differently, you are redirected to "/index.php?$args" ........ and that creates 404s.

For that reason, the removal of the 404 error_page directive did provide you with some advantages - but it is not a solid solution.


In essence, you could try to alter the Nginx code in such a way that you do not end up at "/index.php?$args".

There are two methods that you can test :

a - remove all code and replace by one simple line containing :

error_page 404 /

and this will redirect to the home page, (OR)

b - only remove the code

if ($uri ~* "^/") {
set $sef_entry_point "/index.php?$args";
}

and this will also redirect to the home page, but Nginx still tries to match $uri, (OR)

c - change the line

try_files $uri $sef_entry_point;

to

try_files $uri / $sef_entry_point;

and hence force Nginx to try $uri first and, if not matched, to try the home page on "/" second and, if not matched, to try $sef_entry_point as the last resort.


Please note that I did not do any testing, but it could work.

As a final remark, it should be duly noted that any update would overwrite your customizations to the Nginx config.

That is not really a problem, first try out whether solution a or b works for you!


I hope the above helps a bit.....


Kind regards.....

PS If you want to create a redirect with a 301 status code, then you could try the following solution too :

location @alt_fallback {
return 301 /;
}
error_page 404 = @alt_fallback;
error_page 405 = @alt_fallback;
 
I have made a few more tests based on your comments.

a) With the original block "# WordPress permalink", removed and including only the line

error_page 404 /;

on the "Additional nginx directives".

All the 404s goes to 404.php WordPress theme error page. So, I'm getting junk requests that get processed by PHP-FPM and DB.

This includes the most critical calls to non existing pictures at /wp-content/uploads/ . Thus, I start to have high cpu usage again and overall server performance decreases.

b) Here I'm getting a similar result.
 
@Paulo_o

I am not sure why you should get those errors again, since Nginx should be redirected to the home page.

Could you check the permalink settings in WordPress?

It can be the case that you have wrong settings ........

........ in general, it is always good to have a "custom structure" with setting /%category%/%postname%/ in WordPress.


Please note that all information - screenshots included - is required to help you with these "issues"..... I cannot make guesses about settings.

Kind regards....
 
Hi @trialotto

The permalink settings in WordPress are defined for a long time, and seems correct.

Anyway, as per your comments, I have decided to keep the original wp-toolkit configuration from "WordPress permalink".
Also there are some very specific cases where we got errors without such lines.

So, just added at "Additional nginx directives"

location ~* ^/wp-content/uploads/.*\.(jpg|jpeg|png|gif) {
try_files $uri =404;
error_page 404 =404 /404.html;
}

This directive manage the main issue regarding some "junk requests" and all seems working fine now.

Many thanks for your valuable help.
 
@Paulo_o

Some general comments with respect to your solution.

First, the line

error_page 404 =404 /404.html;

should not be necessary - try to remove it.

Second, the location block and the regexp match

^/wp-content/uploads/.*\.(jpg|jpeg|png|gif)

can interfere with the default Nginx configuration that is provided by Nginx.

In essence, there is a workaround stacked upon a workaround in order to combat an issue inherent to Plesk - this is never a good idea.

Did you remove the original "fix" for the pretty permalink issue?

Kind regards....
 
Removing the line error_page 404 =404 /404.html; as a result a redirect to 404.php.

Regarding the regex ^/wp-content/uploads/.*\.(jpg|jpeg|png|gif), is there an alternative? Should not interfere with the default Nginx configuration unless there is other location blocks in Nginx configuration that conflict with this one.
I did not found any issue, but never knows...

Yes, I have removed the "fix". Meaning the "wordpressPermalinkHandlingFeature = true" as per original plesk configuration.
 
Back
Top