Error 404 Not Found is one of the most common problems WordPress site owners face. This message appears when the server cannot find the page requested by the user. The reason could be due to link settings, deleted content, or even the theme of the site.

If not handled properly, the error can affect visitor behavior and search rankings. In this article, briefly and to the point, we will tell you why a 404 error appears in WordPress and how to fix it.

What the 404 error means in WordPress​

When someone visits your site, WordPress tries to match the URL with records in the database. If the page is not found, a 404 error is displayed. This is not a server failure; the site continues to work, but the specific page is missing.

Why does 404 occur in WordPress​

1. Permalink structure is broken

One of the most common reasons. For example, you changed the URL structure in Settings → Permalinks, but WordPress did not update the .htaccess file. In this case, all pages except the homepage will return a 404 error. To fix this, you can manually update the .htaccess file or re-save the permalink settings in the WordPress admin panel - this will force WordPress to regenerate the .htaccess file with the correct rules.

2. Page or post deleted

If you have deleted a post or page, but the links to it remain (for example, in the menu, in search, or on other sites), visitors will be taken to a 404 page.

3. .htaccess file corrupted

This file is responsible for URL routing. If it is accidentally deleted or damaged, WordPress cannot process addresses correctly.

4. Theme or plugin issues

Sometimes, a 404 error appears after installing or updating a plugin, especially if it works with URLs, routes, custom post types, etc. There can also be errors in the theme’s functions.php file.

How to fix a 404 error in WordPress​

✅ 1. Regenerate permalinks

Go to Admin → Settings → Permalinks → simply click “Save Changes”. Even if you don’t change anything, WordPress will rebuild the structure and update .htaccess.

✅ 2. Check the .htaccess file

Connect to the site via FTP or through the file manager in the control panel. Find the .htaccess file in the WordPress root. Its basic content:

# BEGIN WordPress

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

# END WordPress

If it is missing, create it and paste this code manually. Make sure the file has 644 permissions. For more information about the default .htaccess structure in WordPress, check out this article.

✅ 3. Disable suspicious plugins

If the error appeared after installing a plugin, temporarily disable it. If a custom post type is used (for example, WooCommerce products or a portfolio), make sure the plugin correctly registers routes.

✅ 4. Try a default theme

Sometimes, a 404 error is caused by errors in a custom theme. Switch to a default WordPress theme (for example, Twenty Twenty-Four) and check whether the error disappears.

✅ 5. Enable error logging

For debugging purposes, you can enable WordPress error output. Add the following lines to wp-config.php:

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', true );

After that, errors will be saved to the /wp-content/debug.log.

✅ 6. Check server logs

If you use FASTPANEL, open the site card → “Logs” section → check the “Backend access log” and “Frontend access log” tabs. There, you can see which address caused the 404 error and where the request came from. This helps find “broken” links.

How to prevent 404s in the future​

• Do not change the link structure unless necessary.

• Use the Redirection plugin to set up 301 redirects.

• After deleting pages, update the menus and links.

• Periodically check 404 errors in Google Search Console.

Conclusion​

A 404 error in WordPress is unpleasant but solvable. Most often, simply saving the link structure or editing .htaccess helps. And if the problem lies deeper, the server log or debug file will help you locate it quickly.

By fixing 404s, you not only improve the site experience but also help its search promotion.

The .htaccess file is a configuration file used on Apache web servers to manage website settings without access to the server’s main configuration. With it, you can enable redirects, restrict access, configure SEO-friendly URLs, set up caching, and much more—directly from the root of your site or any of its directories.

Many CMSs automatically create this file on installation or include a sample in the distribution.

If you're working with hosting, especially on Apache, it's important to know what the default .htaccess looks like for different CMSs. This helps you:

• Check that everything is correct after installation;

• Restore the file if it was accidentally deleted;

• Understand what rules the system uses “out of the box”.

Where .htaccess is located​

The .htaccess file is usually found in the site’s root folder, for example:

/var/www/site.com/public_html/.htaccess

If the file is missing (e.g., it was accidentally deleted), you can create it manually with the name .htaccess (name begins with a dot, no extension).

Open the file with a text editor (e.g., Notepad++ or VS Code).

Below is a collection of standard .htaccess files used by default in popular CMSs. These examples can come in handy if you accidentally deleted or corrupted the original .htaccess file and need to restore it for your site to work properly.

Wordpress​

The default .htaccess for WordPress enables “clean” URLs and includes basic redirect rules:

# BEGIN WordPress

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule . /index.php [L]

</IfModule>

# END WordPress

If a multisite with subdomains is used (e.g., site1.example.com, site2.example.com):

# BEGIN WordPress Multisite

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

  

# Redirect for multisite (subdomains)

RewriteCond %{REQUEST_FILENAME} -f [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^ - [L]

RewriteRule ^(wp-(content|admin|includes).*) $1 [L]

RewriteRule ^(.*\.php)$ $1 [L]

RewriteRule . index.php [L]

</IfModule>

# END WordPress Multisite

If a multisite with subdirectories is used (e.g., example.com/site1, example.com/site2):

# BEGIN WordPress Multisite

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteBase /

RewriteRule ^index\.php$ - [L]

  

# Redirect for multisite (subdirectories)

RewriteCond %{REQUEST_FILENAME} -f [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^ - [L]

RewriteRule . index.php [L]

</IfModule>

# END WordPress Multisite

Joomla 2.5-3​

Joomla uses .htaccess for basic protection and SEF configuration:

##

# @package Joomla

# @copyright Copyright (C) 2005 - 2012 Open Source Matters. All rights reserved.

# @license GNU General Public License version 2 or later; see LICENSE.txt

##



##

# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!

#

# The line just below this section: 'Options +FollowSymLinks' may cause problems

# with some server configurations. It is required for use of mod_rewrite, but may already

# be set by your server administrator in a way that dissallows changing it in

# your .htaccess file. If using it causes your server to error out, comment it out (add # to

# beginning of line), reload your site in your browser and test your sef url's. If they work,

# it has been set by your server administrator and you do not need it set here.

##



## Can be commented out if causes errors, see notes above.

Options +FollowSymLinks



## Mod_rewrite in use.



RewriteEngine On



## Begin - Rewrite rules to block out some common exploits.

# If you experience problems on your site block out the operations listed below

# This attempts to block the most common type of exploit `attempts` to Joomla!

#

# Block out any script trying to base64_encode data within the URL.

RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]

# Block out any script that includes a <script> tag in URL.

RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]

# Block out any script trying to set a PHP GLOBALS variable via URL.

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

# Block out any script trying to modify a _REQUEST variable via URL.

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

# Return 403 Forbidden header and show the content of the root homepage

RewriteRule .* index.php [F]

#

## End - Rewrite rules to block out some common exploits.



## Begin - Custom redirects

#

# If you need to redirect some pages, or set a canonical non-www to

# www redirect (or vice versa), place that code here. Ensure those

# redirects use the correct RewriteRule syntax and the [R=301,L] flags.

#

## End - Custom redirects



##

# Uncomment following line if your webserver's URL

# is not directly related to physical file paths.

# Update Your Joomla! Directory (just / for root).

##



# RewriteBase /



## Begin - Joomla! core SEF Section.

#

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

#

# If the requested path and file is not /index.php and the request

# has not already been internally rewritten to the index.php script

RewriteCond %{REQUEST_URI} !^/index\.php

# and the request is for something within the component folder,

# or for the site root, or for an extensionless URL, or the

# requested URL ends with one of the listed extensions

RewriteCond %{REQUEST_URI} /component/|(/[^.]*|\.(php|html?|feed|pdf|vcf|raw))$ [NC]

# and the requested path and file doesn't directly match a physical file

RewriteCond %{REQUEST_FILENAME} !-f

# and the requested path and file doesn't directly match a physical folder

RewriteCond %{REQUEST_FILENAME} !-d

# internally rewrite the request to the index.php script

RewriteRule .* index.php [L]

#

## End - Joomla! core SEF Section.

Joomla 4-5​

In Joomla 4 more attention is paid to security and caching:

##

# @package    Joomla

# @copyright  (C) 2005 Open Source Matters, Inc. <https://www.joomla.org>

# @license    GNU General Public License version 2 or later; see LICENSE.txt

##

  

##

# READ THIS COMPLETELY IF YOU CHOOSE TO USE THIS FILE!

#

# The line 'Options +FollowSymLinks' may cause problems with some server configurations.

# It is required for the use of Apache mod_rewrite, but it may have already been set by

# your server administrator in a way that disallows changing it in this .htaccess file.

# If using it causes your site to produce an error, comment it out (add # to the

# beginning of the line), reload your site in your browser and test your sef urls. If

# they work, then it has been set by your server administrator and you do not need to

# set it here.

##

  

## MISSING CSS OR JAVASCRIPT ERRORS

#

# If your site looks strange after enabling this file, then your server is probably already

# gzipping css and js files and you should comment out the GZIP section of this file.

##

  

## OPENLITESPEED

#

# If you are using an OpenLiteSpeed web server then any changes made to this file will

# not take effect until you have restarted the web server.

##

  

## Can be commented out if causes errors, see notes above.

Options +FollowSymlinks

Options -Indexes

  

## No directory listings

<IfModule mod_autoindex.c>

IndexIgnore *

</IfModule>

  

## Suppress mime type detection in browsers for unknown types

<IfModule mod_headers.c>

Header always set X-Content-Type-Options "nosniff"

</IfModule>

  

## Protect against certain cross-origin requests. More information can be found here:

## https://developer.mozilla.org/en-US/docs/Web/HTTP/Cross-Origin_Resource_Policy_(CORP)

## https://web.dev/why-coop-coep/

#<IfModule mod_headers.c>

# Header always set Cross-Origin-Resource-Policy "same-origin"

# Header always set Cross-Origin-Embedder-Policy "require-corp"

#</IfModule>

  

## Disable inline JavaScript when directly opening SVG files or embedding them with the object-tag

<FilesMatch "\.svg$">

  <IfModule mod_headers.c>

    Header always set Content-Security-Policy "script-src 'none'"

  </IfModule>

</FilesMatch>

  

## These directives are only enabled if the Apache mod_rewrite module is enabled

<IfModule mod_rewrite.c>

RewriteEngine On

  

## Begin - Rewrite rules to block out some common exploits.

# If you experience problems on your site then comment out the operations listed

# below by adding a # to the beginning of the line.

# This attempts to block the most common type of exploit `attempts` on Joomla!

#

# Block any script trying to base64_encode data within the URL.

RewriteCond %{QUERY_STRING} base64_encode[^(]*\([^)]*\) [OR]

# Block any script that includes a <script> tag in URL.

RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]

# Block any script trying to set a PHP GLOBALS variable via URL.

RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]

# Block any script trying to modify a _REQUEST variable via URL.

RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})

# Return 403 Forbidden header and show the content of the root home page

RewriteRule .* index.php [F]

#

## End - Rewrite rules to block out some common exploits.

  

## Begin - Custom redirects

#

# If you need to redirect some pages, or set a canonical non-www to

# www redirect (or vice versa), place that code here. Ensure those

# redirects use the correct RewriteRule syntax and the [R=301,L] flags.

#

## End - Custom redirects

  

##

# Uncomment the following line if your webserver's URL

# is not directly related to physical file paths.

# Update Your Joomla! Directory (just / for root).

##

  

# RewriteBase /

  

## Begin - Joomla! core SEF Section.

#

# PHP FastCGI fix for HTTP Authorization, required for the API application

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

# -- SEF URLs for the API application

# If the requested path starts with /api, the file is not /api/index.php

# and the request has not already been internally rewritten to the

# api/index.php script

RewriteCond %{REQUEST_URI} ^/api/

RewriteCond %{REQUEST_URI} !^/api/index\.php

# and the requested path and file doesn't directly match a physical file

RewriteCond %{REQUEST_FILENAME} !-f

# and the requested path and file doesn't directly match a physical folder

RewriteCond %{REQUEST_FILENAME} !-d

# internally rewrite the request to the /api/index.php script

RewriteRule .* api/index.php [L]

# -- SEF URLs for the public frontend application

# If the requested path and file is not /index.php and the request

# has not already been internally rewritten to the index.php script

RewriteCond %{REQUEST_URI} !^/index\.php

# and the requested path and file doesn't directly match a physical file

RewriteCond %{REQUEST_FILENAME} !-f

# and the requested path and file doesn't directly match a physical folder

RewriteCond %{REQUEST_FILENAME} !-d

# internally rewrite the request to the index.php script

RewriteRule .* index.php [L]

#

## End - Joomla! core SEF Section.

</IfModule>

  

## These directives are only enabled if the Apache mod_rewrite module is disabled

<IfModule !mod_rewrite.c>

<IfModule mod_alias.c>

# When Apache mod_rewrite is not available, we instruct a temporary redirect

# of the start page to the front controller explicitly so that the website

# and the generated links can still be used.

RedirectMatch 302 ^/$ /index.php/

# RedirectTemp cannot be used instead

</IfModule>

</IfModule>

  

## GZIP

## These directives are only enabled if the Apache mod_headers module is enabled.

## This section will check if a .gz file exists and if so will stream it

##     directly or fallback to gzip any asset on the fly

## If your site starts to look strange after enabling this file, and you see

##     ERR_CONTENT_DECODING_FAILED in your browser console network tab,

##     then your server is already gzipping css and js files and you don't need this

##     block enabled in your .htaccess

<IfModule mod_headers.c>

# Serve gzip compressed CSS files if they exist

# and the client accepts gzip.

RewriteCond "%{HTTP:Accept-encoding}" "gzip"

RewriteCond "%{REQUEST_FILENAME}\.gz" -s

RewriteRule "^(.*)\.css" "$1\.css\.gz" [QSA]

  

# Serve gzip compressed JS files if they exist

# and the client accepts gzip.

RewriteCond "%{HTTP:Accept-encoding}" "gzip"

RewriteCond "%{REQUEST_FILENAME}\.gz" -s

RewriteRule "^(.*)\.js" "$1\.js\.gz" [QSA]

  

# Serve correct content types, and prevent mod_deflate double gzip.

RewriteRule "\.css\.gz$" "-" [T=text/css,E=no-gzip:1]

RewriteRule "\.js\.gz$" "-" [T=text/javascript,E=no-gzip:1]

  

<FilesMatch "(\.js\.gz|\.css\.gz)$">

# Serve correct encoding type.

Header set Content-Encoding gzip

  

# Force proxies to cache gzipped &

# non-gzipped css/js files separately.

Header append Vary Accept-Encoding

</FilesMatch>

</IfModule>

Drupal 7​

The .htaccess in Drupal 7 includes basic security and optimization settings. Typical content:

# Use the following to prevent server signatures and directory browsing

ServerSignature Off

Options -Indexes

  

# Protect sensitive files

<FilesMatch "\.(htaccess|htpasswd)">

  Order Allow,Deny

  Deny from all

</FilesMatch>

  

# Protect files from being accessed directly

<FilesMatch "\.(txt|md|yml|json|xml)$">

  Order Allow,Deny

  Deny from all

</FilesMatch>

  

# Set a default timezone for PHP

SetEnv TZ Europe/Amsterdam

  

# Enable compression for better performance

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript text/javascript application/javascript

  

# Cache settings for better performance

<IfModule mod_headers.c>

  Header set Cache-Control "public, max-age=3600"

</IfModule>

Drupal 8​

For Drupal 8, .htaccess already includes additional improvements and supports new features. For example, there is HTTP/2 support, improved security, customization to handle clean URLs and caching.

# Prevent server signature and directory browsing

ServerSignature Off

Options -Indexes

  

# Protect sensitive files

<FilesMatch "\.(htaccess|htpasswd|ini|log|conf)$">

  Order Allow,Deny

  Deny from all

</FilesMatch>

  

# Clean URLs support

RewriteEngine on

RewriteBase /

  

# Support for HTTP/2

<IfModule http2_module>

  Protocols h2 http/1.1

</IfModule>

  

# Cache control for assets

<IfModule mod_headers.c>

  Header set Cache-Control "public, max-age=86400, s-maxage=86400, must-revalidate"

</IfModule>

  

# Enable compression

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript application/javascript text/javascript

  

# Redirect trailing slashes for clean URLs

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_URI} /+$

RewriteRule ^(.*)/$ /$1 [R=301,L]

Drupal 9​

For Drupal 9 the .htaccess includes further enhancements for working with newer web technologies such as HTTP/2 support and stricter security measures.

# Prevent directory browsing and server signatures

ServerSignature Off

Options -Indexes

  

# Protect sensitive files

<FilesMatch "\.(htaccess|htpasswd|ini|log|conf)$">

  Order Allow,Deny

  Deny from all

</FilesMatch>

  

# Enable clean URLs (this is essential for Drupal to work properly)

RewriteEngine on

RewriteBase /

  

# Support for HTTP/2 and modern caching

<IfModule mod_http2.c>

  Protocols h2 http/1.1

</IfModule>

  

<IfModule mod_headers.c>

  Header set Cache-Control "public, max-age=86400, s-maxage=86400, must-revalidate"

</IfModule>

  

# Enable Gzip compression

AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript text/javascript application/javascript

  

# Clean URLs support for Drupal

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_URI} /+$

RewriteRule ^(.*)/$ /$1 [R=301,L]

OpenCart​

Options +FollowSymlinks

RewriteEngine On

RewriteBase /

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^([^?]*) index.php?_route_=$1 [L,QSA]

Magento (2.x)​

Magento has a complex .htaccess that includes rules for compression, caching, and security. Example for Magento 2:

<IfModule mod_php5.c>

php_flag memory_limit 756M

php_flag max_execution_time 18000

</IfModule>

  

<IfModule mod_rewrite.c>

Options +FollowSymLinks

RewriteEngine on

  

RewriteCond %{REQUEST_URI} !^/pub/

RewriteRule ^(.*)$ pub/$1 [L]

</IfModule>

PrestaShop (1.7.x)​

PrestaShop automatically generates the .htaccess file during installation or when you change SEO-friendly URL settings.

# ~~start~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again

# .htaccess automatically generated by PrestaShop e-commerce open-source solution

# http://www.prestashop.com - http://www.prestashop.com/forums

  

<IfModule mod_rewrite.c>

<IfModule mod_env.c>

     SetEnv HTTP_MOD_REWRITE On

</IfModule>

  

RewriteEngine on

  

# Domain: www.example.com

RewriteRule . - [E=REWRITEBASE:/]

  

# API

RewriteRule ^api$ api/ [L]

RewriteRule ^api/(.*)$ %{ENV:REWRITEBASE}webservice/dispatcher.php?url=$1 [QSA,L]

  

# Images

RewriteRule ^([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$1$2$3.jpg [L]

RewriteRule ^([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$1$2$3$4.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$1$2$3$4$5.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg [L]

RewriteRule ^c/([0-9]+)(\-[\.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2$3.jpg [L]

RewriteRule ^c/([a-zA-Z_-]+)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2.jpg [L]

  

# AlphaImageLoader for IE and fancybox

RewriteRule ^images_ie/?([^/]+)\.(jpe?g|png|gif)$ js/jquery/plugins/fancybox/images/$1.$2 [L]

  

# Dispatcher

RewriteCond %{REQUEST_FILENAME} -s [OR]

RewriteCond %{REQUEST_FILENAME} -l [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^.*$ - [NC,L]

RewriteRule ^.*$ %{ENV:REWRITEBASE}index.php [NC,L]

</IfModule>

  

<IfModule mod_headers.c>

<FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|svg)$">

     Header set Access-Control-Allow-Origin "*"

</FilesMatch>

</IfModule>

  

<IfModule mod_expires.c>

ExpiresActive On

ExpiresByType image/gif "access plus 1 month"

ExpiresByType image/jpeg "access plus 1 month"

ExpiresByType image/png "access plus 1 month"

ExpiresByType text/css "access plus 1 week"

ExpiresByType text/javascript "access plus 1 week"

ExpiresByType application/javascript "access plus 1 week"

ExpiresByType application/x-javascript "access plus 1 week"

ExpiresByType image/x-icon "access plus 1 year"

ExpiresByType image/svg+xml "access plus 1 year"

ExpiresByType image/vnd.microsoft.icon "access plus 1 year"

ExpiresByType application/font-woff "access plus 1 year"

ExpiresByType application/x-font-woff "access plus 1 year"

ExpiresByType font/woff2 "access plus 1 year"

ExpiresByType application/vnd.ms-fontobject "access plus 1 year"

ExpiresByType font/opentype "access plus 1 year"

ExpiresByType font/ttf "access plus 1 year"

ExpiresByType font/otf "access plus 1 year"

ExpiresByType application/x-font-ttf "access plus 1 year"

ExpiresByType application/x-font-otf "access plus 1 year"

</IfModule>

  

<IfModule mod_headers.c>

Header unset Etag

</IfModule>

FileETag none

  

<IfModule mod_deflate.c>

<IfModule mod_filter.c>

     AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/x-javascript font/ttf application/x-font-ttf font/otf application/x-font-otf font/opentype image/svg+xml

</IfModule>

</IfModule>

  

# If rewrite mod isn't enabled

ErrorDocument 404 /index.php?controller=404

  

# ~~start~~ Do not remove this comment, Prestashop will keep automatically the code outside this comment when .htaccess will be generated again

# .htaccess automatically generated by PrestaShop e-commerce open-source solution

# http://www.prestashop.com - http://www.prestashop.com/forums

  

<IfModule mod_rewrite.c>

<IfModule mod_env.c>

     SetEnv HTTP_MOD_REWRITE On

</IfModule>

  

RewriteEngine on

  

# Domain: www.example.com

RewriteRule . - [E=REWRITEBASE:/]

  

# API

RewriteRule ^api$ api/ [L]

RewriteRule ^api/(.*)$ %{ENV:REWRITEBASE}webservice/dispatcher.php?url=$1 [QSA,L]

  

# Images

RewriteRule ^([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$1$2$3.jpg [L]

RewriteRule ^([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$1$2$3$4.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$1$2$3$4$5.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$1$2$3$4$5$6.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$1$2$3$4$5$6$7.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$1$2$3$4$5$6$7$8.jpg [L]

RewriteRule ^([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])([0-9])(\-[_a-zA-Z0-9-]*)?(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/p/$1/$2/$3/$4/$5/$6/$7/$1$2$3$4$5$6$7$8$9.jpg [L]

RewriteRule ^c/([0-9]+)(\-[\.*_a-zA-Z0-9-]*)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2$3.jpg [L]

RewriteRule ^c/([a-zA-Z_-]+)(-[0-9]+)?/.+\.jpg$ %{ENV:REWRITEBASE}img/c/$1$2.jpg [L]

  

# AlphaImageLoader for IE and fancybox

RewriteRule ^images_ie/?([^/]+)\.(jpe?g|png|gif)$ js/jquery/plugins/fancybox/images/$1.$2 [L]

  

# Dispatcher

RewriteCond %{REQUEST_FILENAME} -s [OR]

RewriteCond %{REQUEST_FILENAME} -l [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^.*$ - [NC,L]

RewriteRule ^.*$ %{ENV:REWRITEBASE}index.php [NC,L]

</IfModule>

  

<IfModule mod_headers.c>

<FilesMatch "\.(ttf|ttc|otf|eot|woff|woff2|svg)$">

     Header set Access-Control-Allow-Origin "*"

</FilesMatch>

</IfModule>

  

<IfModule mod_expires.c>

ExpiresActive On

ExpiresByType image/gif "access plus 1 month"

ExpiresByType image/jpeg "access plus 1 month"

ExpiresByType image/png "access plus 1 month"

ExpiresByType text/css "access plus 1 week"

ExpiresByType text/javascript "access plus 1 week"

ExpiresByType application/javascript "access plus 1 week"

ExpiresByType application/x-javascript "access plus 1 week"

ExpiresByType image/x-icon "access plus 1 year"

ExpiresByType image/svg+xml "access plus 1 year"

ExpiresByType image/vnd.microsoft.icon "access plus 1 year"

ExpiresByType application/font-woff "access plus 1 year"

ExpiresByType application/x-font-woff "access plus 1 year"

ExpiresByType font/woff2 "access plus 1 year"

ExpiresByType application/vnd.ms-fontobject "access plus 1 year"

ExpiresByType font/opentype "access plus 1 year"

ExpiresByType font/ttf "access plus 1 year"

ExpiresByType font/otf "access plus 1 year"

ExpiresByType application/x-font-ttf "access plus 1 year"

ExpiresByType application/x-font-otf "access plus 1 year"

</IfModule>

  

<IfModule mod_headers.c>

Header unset Etag

</IfModule>

FileETag none

  

<IfModule mod_deflate.c>

<IfModule mod_filter.c>

     AddOutputFilterByType DEFLATE text/html text/css text/javascript application/javascript application/x-javascript font/ttf application/x-font-ttf font/otf application/x-font-otf font/opentype image/svg+xml

</IfModule>

</IfModule>

  

# If rewrite mod isn't enabled

ErrorDocument 404 /index.php?controller=404

Shopify, Squarespace, Adobe Commerce, and other cloud platforms​

Shopify, Squarespace, and Adobe Commerce (formerly Magento Commerce) are cloud-based platforms that do not provide direct access to the .htaccess file. All configuration is done through the administrative panel.

Other examples of such services include Wix, Weebly, BigCommerce, and Jimdo. These platforms allow users to configure and optimize their websites through visual interfaces, without the need to manually edit server configuration files.

Need help restoring your .htaccess file?​

If you're not sure which CMS your website is using or how to safely restore a broken .htaccess file, we're here to help.

Our technical support is completely free for all Kodu.cloud clients and available 24/7/365. Simply create a support ticket, and our team will assist you in a minutes.

For more details about what’s included, see our support policy.

Looking for the best hosting control panel? Both FASTPANEL and CyberPanel are popular among system administrators, but FASTPANEL leads in key areas such as usability, performance, compatibility and security.

FASTPANEL - a control panel designed for simplicity, stability, and flexibility​

FASTPANEL is a modern web panel for server and website management. It is lightweight, architecturally stable and comes with powerful built-in tools. The focus is on maximizing ease of administration while minimizing server load.

Unlike CyberPanel, which is tied to OpenLiteSpeed and has a number of limitations, FASTPANEL delivers a stable, compatible environment for most popular CMSs and PHP applications and, in reverse-proxy mode, reliably handles any non-PHP backend.

✅ 1. Versatility & compatibility​

• Broad OS support: Debian 9–12, Ubuntu 18.04–24.04, CentOS 7, AlmaLinux 8, RockyLinux 8
• Fast installation: 3–7 minutes, no reboot required, launched with a single command
• Works on nearly any VPS or dedicated server with no tweaks or hacks

⚡ 2. Minimal server load​

• Uses only ≈ 100 MB of disk space and ≈ 170 MB of RAM after installation.
• FASTPANEL - Ideal for resource-constrained or budget VPSs.
• By comparison: CyberPanel consumes almost 5× more disk space and 1.5× more RAM

🔧 3. Classic, flexible web-server stack​

Nginx (frontend) + Apache (backend) with PHP-FPM provides:

• High-speed static file delivery
• Stable PHP performance
• Easy .htaccess / mod_rewrite configuration
• Supports PHP 5.3 to 8.4, with the ability to assign different PHP versions to different sites.

🛠️ 4. Rich feature set out of the box​

• Advanced file manager - fast, modern UI

• Built-in web terminal for accessing the CLI directly from the panel

• Database management via built-in phpMyAdmin/phpPgAdmin

• Mail server with full webmail (Exim + Dovecot + RoundCube)

• Backups:

  ◦ Free differential backups

  ◦ Cloud storage: Dropbox, Google Drive, FTP, SCP

  ◦ Integration with FASTBACKUP

🔒 5. Security hardened by default​

• Web firewall
• Malware scanner
• 2FA (Two-Factor Authentication)
• Site isolation at the system level - each site runs under a separate user account.
• Ability to grant developer/webmaster access for one site without risking the rest.

🌍 6. Clean, intuitive interface​

• Modern UI with logical structure
• Suitable for both beginners and experienced administrators
• 18 languages available (English, German, Spanish, Portuguese, etc.)

📊 7. Monitoring & integrations​

• Supports integration with AWStats and Prometheus (Prometheus requires Extended license)
• Visual graphs for load, resource usage, and logs

🤝 8. Reliable support & up-to-date docs​

• 24/7 support for panel-related issues (free of charge).
• Support for general server administration questions (paid).
• Average response time - less than 5 minutes.
• Detailed documentation with intuitive navigation, unlike the bulky manuals of CyberPanel.

💰 9. Transparent, flexible pricing​

• Free license with full core functionality

• Extended license:

  ◦ € 4.20 / month

  ◦ € 46.20 / year

  ◦ € 99 lifetime

• No extra fees for essentials such as the file manager or WP Manager (unlike CyberPanel)

✅ Why choose FASTPANEL​

• Simplicity & stability
• Feature-rich without hidden costs
• Low system requirements
• Fast, responsive support & strong security
• Excellent real-world performance

Key differences between FASTPANEL and CyberPanel​

Boost efficiency - No hidden costs, no unnecessary complexity​

FASTPANEL is a professional server administration toolkit that combines ease of use, stability and performance. One installation provides everything you need - no hidden restrictions, no forced subscriptions.

For all kodu.cloud customers when renting any server (dedicated or VPS) the extended FASTPANEL license is provided free of charge with no restrictions.

👉 Choose your VPS or dedicated server and get started today. No subscriptions — just performance.

When it comes to choosing a hosting provider for renting dedicated servers or a cheaper VPS, it is crucial to consider several key factors. In this material, we will break down exactly what you should focus on when making your decision to ensure you receive a high-quality and reliable service.

1. SLA (Service Level Agreement)​

SLA - is an agreement that guarantees certain levels of availability and performance from the hosting provider. When renting dedicated servers and VPS, always make sure that the SLA specifies:

• Guaranteed uptime - an ideal indicator for selecting a hosting service with minimal downtime.
• Support response time - it’s important that the provider responds quickly to issues in the event of any malfunctions.
• The amount of resources provided - including computing power, memory, disk space, etc.

Agreed SLA terms and conditions ensure that you receive quality service with minimal disruption, which is critical to the stability of your online business.

2. Data Center: location and security​

The data center is the foundation of hosting, as its infrastructure determines not only the stability of server operations but also the security of your data.

• Data center location. Choose a provider with a data center that is physically close to your main market. This can improve access speed and reduce latency.
• Security Level. Ensure that the data center is equipped with state-of-the-art security systems, including DDoS protection systems, backup power, cooling systems, and physical protection.

When choosing a hosting provider for dedicated server and VPS rental, pay special attention to the reputation and certifications of the data center, which confirm its reliability and compliance with international standards.

3. 24/7 Support - key to uninterrupted operation​

Prompt and professional support is an important component of quality hosting. The provider should offer:

• Round-the-clock technical support. The faster problems are resolved, the less time is lost in troubleshooting.
• Various communication channels: chat, phone, email. This allows you to quickly select the most convenient way to contact support, depending on the situation.
• Support for various technologies. It is especially important that support can help with installing and configuring specific applications or technologies (for instance, setting up VPS, working with web servers, databases, etc.).

The quality of the support team affects not only ease of use but also the speed of restoring server operation if something goes wrong.

4. Affordable Plans and Scalability​

When choosing a hosting provider for renting dedicated servers and VPS, it’s important to consider not only your current needs but also the potential for future expansion. Some hosting providers offer flexible plans that can easily adapt to the growing demands of a business. Pay attention to:

• Price categories: cheap VPS or dedicated server rentals with corresponding capacities - look for a balance between price and quality.
• Scalability: the ability to quickly increase resources (memory, CPU, disk space) without significant downtime.

Choosing a cheap VPS or dedicated server rental depends on the specific needs of the business, and it is important that the provider offers the best terms in terms of price and functionality.

Conclusion​

When choosing a hosting provider for renting dedicated servers or VPS, it’s important to consider several factors: SLA, data center security, and the quality of technical support. These aspects determine the stability of your site or application. Don’t forget to also pay attention to the pricing plans and scalability, so your hosting can grow with your business.

By selecting a hosting provider with all these factors in mind, you will ensure the reliability and security of your online business for many years to come.

Looking for quality and affordable hosting? Check out our tariffs and choose the best solution for renting dedicated servers and VPS with guaranteed support and high SLA.

Introduction​

When a business or project needs reliable hosting, the question arises: should you opt for a VPS or immediately rent a dedicated server? It's easy to make a mistake here - you'll either overpay or face a lack of resources. In this article, we’ll examine which tasks a cheap VPS is suited for, and when you really can’t do without bare-metal.

What are VPS and dedicated server?​

• VPS (Virtual Private Server) is a portion of a physical server with allocated resources. It operates like a full-fledged server but shares the “hardware” with other users.
• A dedicated server is an entire physical machine whose resources are yours alone.

Now let's understand when a VPS is enough and when it's time to move to a dedicated server.

When a VPS is the ideal choice​

1. Small and medium projects​

If your site or application does not generate huge loads, a VPS is an excellent choice. It’s cheaper and offers enough resources for most tasks.

2. Development and testing​

A VPS is perfect for development, testing, and experimentation. You can quickly deploy a server, roll back changes, and install any operating system.

3. Startups and growing projects​

If your project has not yet reached peak load, it’s better to start with a VPS. As the load grows, you can migrate to a more powerful plan or a dedicated server.

4. VPN/ Proxy​

Such services do not require super-powerful resources, so VPS will cope with them without any problems.

When a dedicated server Is necessary​

1. High-load projects​

If your website, CRM, or database serves thousands of users per minute, a VPS may not cope. A dedicated server ensures stability and power.

2. Online stores, financial platforms, and SaaS​

If you have an online store, a financial platform, or a SaaS project, reduced speed = lost profits. A dedicated server guarantees maximum performance.

3. Projects requiring high security​

For handling personal data, payment information, and corporate data, a dedicated server is often required, providing more guarantees of isolation and security.

4. Game servers and streaming​

If you plan to run game servers (such as Minecraft, Valheim, or any other game you like) or stream video, you might need a dedicated graphics card, faster storage, and a stable connection with higher bandwidth. A VPS may not be able to handle these demands.

Conclusion: what to choose?​

VPS – if you need a balance of price and resources: websites, blogs, small services, testing.

Dedicated server – if power and stability are critical: heavy-load projects, large databases, serious SaaS products.

If you’re unsure what to choose, you can always start with a VPS and move to a dedicated server when the load increases. The main thing is to pick a reliable hosting provider that ensures uninterrupted server operation.

Looking for a reliable VPS or dedicated server at a great price? Choose kodu.cloud – powerful plans, 24/7 support with a responsive team always ready to assist with any server-related issues, and rock-solid performance throughout your lease!

If your browser reports DNS_PROBE_FINISHED_NXDOMAIN, it means that it cannot determine the IP address of the requested site. This can happen for a variety of reasons:

• The domain name is not present in DNS servers or its registration has expired.
• The server responsible for the domain zone is unavailable.
• DNS is configured incorrectly on the device.
• Interference from a VPN, antivirus, or firewall.
• Issues with the internet service provider.

The accompanying error message may look slightly different in different browsers:

• Google Chrome: «This site can’t be reached».
• Mozilla Firefox: «Hmm. We’re having trouble finding that site».
• Microsoft Edge: «Hmm… can’t reach this page».
• Safari: «Safari Can’t Find the Server».

How to identify the cause of the error?​

1. Check the domain status​

First, make sure the entered address is correct. If everything is correct, check the domain registration using ICANN Lookup. Enter the URL and see if the domain is active.

2. Check availability via proxy​

Try accessing the site using a proxy, VPN, or another network (for example, your mobile provider). If the site opens in this scenario, then the issue is most likely related to the settings on your device or network.

How to fix DNS_PROBE_FINISHED_NXDOMAIN​

Clearing the DNS cache​

Sometimes the browser or system saves outdated DNS records. Clearing the cache helps refresh them.

• Windows:

1. Open Command Prompt as administrator: Start → type cmd in the search bar and press Enter.
2. Run the command:

ipconfig /flushdns

3.  Restart your browser.

• macOS:

1. Open Terminal: on the keyboard, press cmd + space, type Terminal, and press Enter.
2. Enter:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

3. Press Enter.

• Google Chrome:

1. In the browser’s address bar, enter:

chrome://net-internals/#dns

2. Click Clear host cache.

Updating the IP address​

If clearing the cache did not help, try obtaining a new IP address.

• Windows:

ipconfig /release
ipconfig /renew
netsh int ip set dns
netsh winsock reset

 Restart your system.

• macOS:

1. Go to System Preferences → Network.
2. Open the connection → Advanced → TCP/IP.
3. Click Renew DHCP Lease.

Using alternative DNS servers​

The issue might be related to your provider’s DNS servers. Try using Google DNS (8.8.8.8, 8.8.4.4) or Cloudflare DNS (1.1.1.1, 1.0.0.1).

• Windows:

1. Open Control Panel → Network and Internet → Network and Sharing Center.
2. Select the active connection → Properties.
3. In the Internet Protocol Version 4 (TCP/IPv4) section, specify:

• Primary DNS: 8.8.8.8

• Secondary DNS: 8.8.4.4

• macOS:

1. Open System Preferences.
2. Go to Network.
3. Select the active connection (for example, Wi-Fi or Ethernet) in the left column.
4. Click the Advanced button.
5. Go to the DNS tab.
6. In the DNS Servers section, click the + button and add the following DNS servers:

• 8.8.8.8 (Google DNS)
• 8.8.4.4 (Google DNS)

 or

• 1.1.1.1 (Cloudflare DNS)
• 1.0.0.1 (Cloudflare DNS)

7. Click OK, then Apply.

Restarting the DNS Client Service (Windows)​

1. Open Command Prompt as administrator.
2. Type:

net stop dnscache
net start dnscache

 Checking the hosts file​

The hosts file may contain incorrect entries that block access to the site.

• Windows:

1. Open Notepad as administrator.
2. Open the file  (File  →  Open):

C:\Windows\System32\drivers\etc\hosts 

3. Удалите строки, содержащие проблемный домен.

• macOS:

1. Open the hosts file in a text editor:

sudo nano /etc/hosts

2. Delete the lines that contain the problematic domain.
3. Save the file using the keyboard shortcut Ctrl + O, and then exit the editor using Ctrl + X. 

Resetting chrome flags​

Hidden browser settings might have changed.

1. Enter in the address bar:

chrome://flags/

2. Click Reset all to default.

Disabling antivirus and VPN​

Some antivirus programs or VPN services may block DNS queries. Temporarily disable them and check if the site is now accessible.

Checking CDN settings​

If the site uses Cloudflare or another CDN, try temporarily disabling proxying for that domain in your CDN control panel.

Restarting the router​

Sometimes the issue is related to the router. Try the following:

1. Turn it off for 5 minutes.
2. Turn it on and check the connection.

Conclusion​

The DNS_PROBE_FINISHED_NXDOMAIN error is related to DNS issues. You can resolve it by clearing the cache, changing DNS servers, checking the domain, or adjusting system settings. If nothing helps, contact your internet service provider.

Introduction​

If you have ever configured a mail server or encountered reverse DNS checks for other reasons, you have likely heard about PTR records. But what exactly are they? Why can you often not set up a PTR record yourself? Let’s figure it out!

What is a PTR record?​

A PTR (Pointer) record is a type of DNS record used for reverse mapping of IP addresses to domain names. Unlike standard A records (which map a domain to an IP), PTR records let you determine which domain a particular IP address belongs to.

How does a PTR record work?​

When a server receives an incoming connection, it can request a reverse DNS (rDNS) lookup for the sender’s IP address. If a PTR record is configured, it will return the corresponding domain name. This is important for:

• Setting up mail servers (SMTP servers often require PTR records for proper email delivery and to avoid spam issues);
• Identifying IP addresses in logs and enhancing security;
• Ensuring correct operation of certain services that depend on rDNS.

Why can’t I set up a PTR record on my own?​

Many users with access to manage DNS records expect they can create a PTR record just like an A or CNAME record. However, here’s the main issue: PTR records are not configured in your DNS hosting; they are set up by the IP address provider (ISP, data center, or hosting provider).

Key reasons:​

1. Control of IP addresses – PTR records belong to the owner of the IP pool. If you have a dedicated server or VPS, your hosting provider owns the IP address and must configure the record.
2. Lack of rDNS management – Even if you have DNS management access, the reverse DNS zone (in-addr.arpa) is controlled by the owner of the IP address block.
3. Provider requirements – Some hosting providers only allow you to configure PTR through support tickets, not via a control panel.
4. Dynamic IP addresses – If your IP address is dynamic (for example, with a home internet connection), your ISP will not let you set a personalized PTR record.

How to configure a PTR record?​

1. Contact your provider​

To create or change a PTR record, you need to contact the hosting provider or ISP that allocated your IP address. This is usually done by opening a support ticket.

2. Specify the required domain​

Typically, the provider will require the PTR record to point to a real domain, which is already set up and resolvable via an A record.

3. Verify the configuration​

After changing the PTR record, it’s worth checking its functionality using the following commands:

Windows:

nslookup 123.123.123.123

Linux and MacOS:

dig -x 123.123.123.123

Conclusion​

A PTR record is an important part of DNS, especially for mail servers. However, you cannot set up this record without the involvement of the IP address owner. If you need to create a PTR record, contact your hosting provider to discuss the possibility of configuring it. Doing so will help you avoid email delivery problems and increase trust in your server.

Want to redirect users and search engines to a new website address? 301 redirect is your best friend! It helps you maintain SEO rankings and avoid 404 errors. In this article, we will show you how to set up 301 redirect in .htaccess and Nginx quickly and easily.

What is a 301 redirect and why do you need it?​

A 301 redirect is a permanent redirect from one URL to another. It is used to:

• Preserve a site’s search engine rankings after changing its address.
• Combine multiple URLs into one.
• Avoid traffic loss and 404 errors.

How to Set Up a 301 Redirect in .htaccess (Apache)​

1. Find or сreate the .htaccess

The .htaccess file is located in the root (primary working) directory of your site. If it doesn’t exist, create a new one.

2. Add the following code for redirection

• For a single URL:

Redirect 301 /old-page https://yoursite.com/new-page

• To redirect an entire website:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^oldsite\.com$ [NC]

RewriteRule ^(.*)$ https://newsite.com/$1 [L,R=301]

Replace oldsite.com and newsite.com with your site’s old and new domains respectively. 

3. Save the file

The changes will take effect immediately.

How to set up a 301 redirect in Nginx​

1. Open the nginx configuration file for your site

Connect to your server via SSH and open the necessary file in the nano text editor:

sudo nano /etc/nginx/sites-available/your-site.com.conf

Replace yoursite.com with your site’s domain. 

If you can’t find such a file, you can locate the configuration file with the following command:

sudo grep -irl name /etc/nginx

2. Add redirect rules to the server block

• For a single URL:

server {

listen 80;

server_name oldsite.com;

return 301 https://newsite.com/new-page;

}

• To redirect an entire site:

server {

listen 80;

server_name oldsite.com;

return 301 https://newsite.com$request_uri;

}

3. Save and apply the changes

Save the file using the shortcut "Ctrl + O" and exit nano with "Ctrl + X". Then apply the changes with:

sudo systemctl reload nginx

How to check if the redirect is working​

After configuring, make sure your 301 redirect is active:

• Open the old url in a browser.

Go to the old URL in your browser and make sure you are redirected to the new address.

• Use an online redirect checker, for example, Redirect Checker.

Modern HTTP/2 and HTTP/3 protocols can significantly speed up site loading, improve user experience and increase search engine rankings. But not everything is so simple: they have both advantages and disadvantages. Let's understand what these protocols are, their pros and cons, and how to enable them on your server.

What are HTTP/2 and HTTP/3?​

HTTP/2 is an updated version of the HTTP/1.1 protocol that allows multiple website resources to be loaded in parallel rather than one by one. This speeds up response times and reduces server load.

HTTP/3 is an even more advanced version that uses the QUIC protocol on top of UDP. It creates more stable connections, especially in poor network conditions.

Advantages​

1. HTTP/2

• Parallel (multiplexed) loading of site resources.
• Reduced latency through header compression.
• Traffic savings.

2. HTTP/3

• Quick connection establishment with minimal delay.
• Resilience to packet loss (especially important for mobile internet).
• Excellent performance on unstable networks.

By enabling these protocols, you will speed up your site, make it more user-friendly, and gain an SEO advantage.

Disadvantages​

1. Compatibility

• HTTP/2 and HTTP/3 are not supported by older browsers and devices. For example, certain Internet Explorer versions and older Android devices cannot take advantage of these protocols.
• HTTP/3 depends on UDP, which can be blocked by some firewalls and network filters.

2. Configuration complexity

• Incorrect configuration of HTTP/2 can worsen performance (for example, if stream prioritization is not used).
• HTTP/3 requires an up-to-date version of Nginx, OpenSSL, and QUIC support, which can be challenging on older servers.

3. Resource consumption

• HTTP/3 is more demanding on server resources, particularly with a large number of connections.

4. Dependence on HTTPS

• HTTP/2 only works over HTTPS, which increases the complexity and cost of certificate setup and maintenance.

 5. HTTP/1.1 and performance with HTTP/2/3

• HTTP/2 and HTTP/3 do not exclude support for HTTP/1.1. This may slightly reduce performance, but it does not cause critical issues, since HTTP/1.1 is used only for clients that do not support more modern protocols.

How to Enable HTTP/2 and HTTP/3 in Nginx​

1. Checking compatibility

Connect to your server via SSH.

Check the current Nginx version:

sudo nginx -v

For HTTP/3, version 1.25.0 or higher is required.

Check the current OpenSSL version:

openssl version

To work with HTTP/3, you need OpenSSL version 3.0.0 or higher, as earlier versions do not support QUIC.

Additionally, before making changes to the nginx configuration, make sure there are no errors:

nginx -t

If everything is fine (you can ignore “warn” messages), you will see:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

2.  Configure HTTP/2

Open your site’s configuration file in a text editor:

sudo nano /etc/nginx/sites-available/your-site.conf

Add the directive http2 to the listen 443 ssl line and add the line http2 on inside the server block, so it looks something like this:

server {

listen 443 ssl http2;

server_name example.com;

  

ssl_certificate /path/to/fullchain.pem;

ssl_certificate_key /path/to/privkey.pem;

  

http2 on;


rest of your config file

}

Restart the web server to apply the changes:

systemctl restart nginx

3. Configure HTTP/3

Similarly to the previous step, open your site’s configuration file and modify it to look like this:

server {

listen 443 ssl http2;

listen 443 quic reuseport;

server_name example.com;

  

ssl_certificate /path/to/fullchain.pem;

ssl_certificate_key /path/to/privkey.pem;

  

http2 on;

  

ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;

add_header Alt-Svc 'h3=":443"; ma=86400';


rest of your config file

}

Here:

• listen 443 quic reuseport; — enables HTTP/3 (QUIC) on port 443 and improves performance under high connection loads. 
• ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3; — specifies TLS versions for encryption. For better security, it’s recommended to use only TLSv1.2 and TLSv1.3.
• add_header Alt-Svc 'h3=":443"; ma=86400'; — this header tells browsers that the server supports HTTP/3 and stores this information for 24 hours. 

Then run an additional compatibility check for your nginx version with these directives, as well as a syntax check:

nginx -t

If everything is fine (you can ignore “warn” messages), you will see:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Restart Nginx to apply the changes:

systemctl restart nginx

Conclusion​

HTTP/2 and HTTP/3 are a step into the future, speeding up site load times, improving SEO and making your resource more usable. However, it is important to consider compatibility, resource consumption and configuration complexity.

If most of your users are on modern browsers, start by enabling HTTP/2. Then move on to HTTP/3 if you’re ready to update your server software and are confident in your infrastructure’s compatibility.

If you prefer not to configure these protocols manually, you can choose a server with the free FASTPANEL, where enabling HTTP/2 and HTTP/3 for your site is simple and convenient.

When renting a server, the choice of storage system directly affects the performance of your projects, storage reliability, and rental cost. It is important to understand the difference between HDD, SSD and NVMe to make the best choice for your needs.

HDD: durability and stability​

Hard disk drives (HDD) are traditional storage devices that have served data centers for years, storing large volumes of data. They aren’t as fast as SSDs, but they provide long service life under moderate load.

HDD typically have a lifespan of around 20,000–25,000 hours. In practice, many HDD in data centers operate for about 3–5 years, depending on usage intensity.

HDD are highly sensitive to power outages because they use moving parts (e.g., read/write heads), which can lead to data damage. In the event of an abrupt shutdown, the risk of data loss is higher compared to SSD.

Advantages of HDD:​

• Durability: They operate for a long time under moderate load.
• Cost: Cheaper than SSDs and NVMe, especially when calculated per TB of data.
• Large storage capacity: Ideal for storing huge volumes of data at lower access speeds.

SSD: faster, but with limited lifespan​

Solid-state drives (SSD) are fast and reliable devices for servers where speed is critical. However, SSD have a more limited write cycle lifespan. For SATA SSD, the endurance is about 300–500 full write cycles, which, under moderate usage, could theoretically last up to five years. Yet, if your workloads involve a lot of write operations—common for many websites—the lifetime of SSD can be significantly reduced.

SSD are more resistant to sudden power loss because they have no moving parts. However, intensive writes can quickly consume the drive’s write endurance, particularly in cheaper models.

Advantages of SSD:​

• High speed: Excellent for servers where performance is crucial.
• Resistance to power outages: More resilient to hardware damage during abrupt shutdowns.

NVMe: maximum speed, but shorter lifespan​

NVMe (Non-Volatile Memory Express) диски drives are a modern alternative to SATA SSDs, offering even higher performance. They provide significantly faster read and write speeds, which is ideal for servers handling large amounts of data or performing computationally intensive tasks.

However, NVMe drives tend to have a shorter lifespan than SATA SSDs. Due to their high write speeds, these drives can wear out faster under constant load.

Like SSD, NVMe drives are less prone to damage during abrupt shutdowns. However, they are still not as long-lasting as HDD due to the intense operational loads.

Advantages of NVMe:​

• Maximum speed: Ideal for servers that process large data volumes. 
• High performance: Suitable for tasks with heavy workloads.

Which storage type should you choose?​

• If durability and cost matter more to you, and you don’t plan on heavy write operations, HDD is a great choice. It’s cheaper and will provide stable operation for years.
• If you need fast data processing under moderate load, go for an SSD. It offers good speed and wears out less quickly compared to NVMe.
• NVMe is suitable for servers with extremely high speed requirements, but keep in mind its shorter lifespan and higher price. 

Your choice of storage depends on your specific tasks: if longevity and affordability are the priority, choose HDD. If you need high performance, SSD or NVMe will be the optimal solution.

Additionally, we offer servers tailored to your needs and budget, providing the perfect fit for any requirement.