A 500 Internal Server Error is one of the most common issues website owners and administrators encounter. It signals that something went wrong on the server—but offers no precise diagnostics. This article explains what typically triggers a 500 error and how you can resolve it.

Possible causes of a 500 error​

A 500 error can arise for many reasons. The most frequent are:

1. Server-side resource issues

Often error 500 can be caused by technical problems on the server, such as lack of resources (RAM, CPU time).

2. Errors in the website code

Scripts or website code may contain errors that cause a crash. This can be due to incorrect requests, errors in configuration files, or problems with the interaction of site components.

3. Problems with the .htaccess file

The .htaccess file is used to configure the web server and may contain errors that will result in a 500 error. For example, incorrect redirect rules or incorrect parameters can cause a crash.

4. Recent updates

Errors can occur after updates to the website or server applications where changes were not handled correctly.

How to fix a 500 error​

1. Check the web-server logs

To determine the cause of a 500 error, the first step is to check the server logs. These logs typically contain information about the failure — whether it's a code error, misconfiguration, or a server-level issue. However, it's important to understand that web server logs (such as those from Nginx or Apache) often only record the occurrence of the error and the response code, not the root cause. This is especially true for Nginx, which usually acts as a proxy and simply forwards the error from the backend application.

Depending on the web server being used, logs may be located in the following directories:

Apache:

• Ubuntu/Debian: /var/log/apache2/error.log

• CentOS/AlmaLinux/Rocky Linux: /var/log/httpd/error.log

Nginx:

• /var/log/nginx/error.log

If your server is managed through a control panel such as FASTPANEL, viewing logs becomes even easier. To do this:

• Log in to the control panel.

• Open the site card and locate the “Logs” section.

• The “Frontend Error Log” tab contains Nginx web-server errors, while the “Backend Error Log” tab contains Apache errors.

Keep in mind that many CMSs and frameworks (WordPress, Laravel, Joomla, etc.) maintain their own error logs. These logs often provide more precise information about the cause of a 500 error. Consult your platform’s documentation to find where these logs are stored.

Logs will very likely give you detailed insight into what went wrong. If the 500 error is triggered by misconfiguration or code issues, you can see the files—or even the exact lines—that cause the failure.

2. Enable PHP-side error logging

To obtain more detailed diagnostics, enable logging directly in PHP—especially useful when the error originates in code and does not appear in web-server logs.

To do this, set the following values in the php.ini file:

display_errors = Off

log_errors = On

error_log = /var/log/php_errors.log

Here:

• display_errors — suppresses error output in the browser

• log_errors — writes errors to a log file

• error_log — path to the log file (PHP must have write permissions)

Typical  php.ini locations:

• Debian/Ubuntu: /etc/php/*/apache2/php.ini or /etc/php/*/cli/php.ini

• CentOS/AlmaLinux: /etc/php.ini

Or locate it via:

php -i | grep "php.ini"

In FASTPANEL: open the site card → “PHP Settings”, search for variables such as display_errors, change their values, and click "Save". 

3. Check the .htaccess file

If the error appeared after editing .htaccess, revert the file to its previous state.

If you are not sure what exactly has changed, temporarily rename .htaccess (for example, to .htaccess.bak) - if the error disappears, then the problem is in this file.

In this case, try to restore the .htaccess file from a backup if available, or use the default .htaccess file for your CMS, which you can get from here.

4. Verify file permissions and ownership

Improper permissions can trigger a 500. Ensure the site root and all sub-files have correct rights and owner:

ls -laR /path/to/your/site/root

Recommended permissions:

• For directories: 755 — read, write, and execute for the owner; read and execute for everyone else.

• For files: 644 — read and write for the owner; read-only for everyone else.

Ownership:

Files and folders should belong to the web-server user (e.g.,www-data or apache).

If necessary, you can adjust permissions and ownership by using the following commands:

• Change to your site’s root directory:

cd /path/to/root/directory/site

• Set the correct ownership and permissions:

sudo chown -R yoursiteuser:yoursiteuser . && sudo chmod 644 . -R && sudo chmod +X . -R

Please replace yoursiteuser with the actual user and group that own your site.

5. Disable plugins and themes.

For CMS-driven sites such as WordPress, a 500 error often arises from plugin or theme conflicts. Disable all plugins and switch to a default theme to see whether this resolves the issue.

3. Make sure the server has sufficient free resources for your sites.

• Check that you have enough free disk space:

sudo df -h

• Check that the server has not run out of inodes:

sudo df -ih

• Check that the server has enough RAM:

sudo free -mh

• Check current CPU load:

sudo ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head

• Alternatively, open the process monitor with the command:

sudo top

If you have run out of disk space or inodes, you can identify which files and directories consume the most space by following the instructions in the relevant article.

If RAM or CPU load is excessively high, the causes may vary. Start your investigation by blocking search-engine bots, as they are frequently the source of elevated load. 

7. Verify that the DBMS is healthy.

Most often this will be MySQL; below are several quick steps to check whether your databases are OK. 

• Confirm that the MySQL service is running:

sudo systemctl status mysql

• Check the MySQL error log:

sudo grep -i error /var/log/mysql/error.log

• Check all databases for errors:

mysqlcheck -A -c

If errors are found, first be absolutely sure you have backups of the affected databases. If needed, create a dump with:

mysqldump -u [user] -p [database_name] > /path/to/file/dump.sql

• Replace [user] with the MySQL username.

• Replace [database_name] with the name of the database you want to export.

• /path/to/dump.sql  is the path where the dump file will be saved.

After that, run the error correction procedure with mysqlcheck:

mysqlcheck -A --auto-repair -c

8. Contact your hosting provider.

If you are unable to identify the problem, it may be worth contacting your hosting provider's support. It can help identify problems on the server that are not visible at the user level. You can learn about how to choose the right hosting provider in this article.

Conclusion​

Error 500 is not a verdict for your website. With the help of basic diagnostic tools, you can quickly find out the cause and fix the problem. If you are not confident in your abilities, you can always turn to specialists. It is important to remember that error 500 found and fixed in time will help you avoid more serious problems in the future.

Error 404 Not Found on the site running on Joomla means that the requested page can not be found. Visitors often get to it from search engines, outdated links, or even from the menu of the site itself. The reasons can range from a deleted article to routing issues.

In this article, we will explain why error 404 appears in Joomla and how to quickly eliminate it.

What 404 means in Joomla​

A 404 error is the standard response from the server when it cannot find the requested page. In Joomla, this usually happens because:

• The content item has been deleted or unpublished.

• The menu structure is broken.

• The component responsible for rendering the page is not working.

Primary causes of a 404 error in Joomla​

1. Content deleted or unpublished

If an article, category, or component is removed but a menu or module still links to it, Joomla returns a 404.

2. Menu item points to a non-existent target

Even if the article exists, a menu item linked to a missing category or incorrect route will trigger the error.

3. SEF (search-engine-friendly) URL problems

Joomla’s SEF links depend on component routes. After a site migration, enabling SEO, or changing aliases, “broken” links can appear.

4. Errors during site migration

Moving to a new domain or host can change the URL structure and make some pages inaccessible.

5. Component missing in the URL

For example, a link like index.php?option=com_k2&view=item&id=1 will fail if the K2 component is not installed.

How to fix a 404 in Joomla​

1. Check the menu item

Go to Menu → Main Menu and verify that the item points to an existing article, category, or component. Re-create the menu item if needed.

2. Regenerate SEF URLs

• In the admin panel, open Global Configuration → Site → SEO Settings.

• Confirm that SEF URLs and URL rewriting are enabled.

• Clear the cache: System → Clear Cache.

• If you use an extension like sh404SEF or JoomSEF, update or reset its SEF table.

3. Check .htaccess

To enable SEF (Search Engine Friendly) URLs, URL rewriting must be active. Make sure the .htaccess file is present in your site's root directory and that it includes the following directives to enable mod_rewrite:

RewriteEngine On

RewriteBase /

For more information about the default .htaccess structure in Joomla, check out this article.

4. Enable error reporting

For debugging, turn on error output:

• Go to System → General Settings → Server.

• Set Error Messages: Maximum.

Joomla will then show a more detailed message that will help you find the cause of the error.

5. Look at the error log

Most hosters provide an Apache error log. Look for lines with a 404 status code to identify problematic URLs.

If you use FASTPANEL: open the site card → Logs → check Backend access log and Frontend access log tabs to see which address triggered the 404 and the request origin. This helps trace broken links.

6. Configure redirects

If the page was deleted, but you want to keep traffic from external links, create a redirect. In Joomla it is done through the component “Redirects”:

• Navigate to Components → Redirects.

• Enable it in Options if disabled.

• Add the old URL and the new path (without the domain).

How to prevent 404 errors in the future​

• Do not delete content without adding a redirect.

• Audit menus after moving or unpublishing items.

• Use the Redirects component or .htaccess to manage redirections.

• Monitor 404 errors via Google Search Console.

Conclusion​

Error 404 in Joomla - a common phenomenon, but quite solvable. In most cases, it can be eliminated in 5-10 minutes by checking the menu, SEF settings, and site structure. Adding a reliable redirect system eliminates the risk of traffic loss on remote pages.

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.