Server/System Specifications

All our servers are running a highly customized 64-bit version of Debian GNU/Linux with the Apache web server. The server-side scripting languages supported on our hosting platform are PHP, Python, Perl, Ruby, and Tcl. Our database server solution is MySQL (both the MyISAM and InnoDB storage engines are supported). You can find more information on the versions of the installed server-side scripting languages and MySQL in the hosting Control Panel -> System Information section. Hosting accounts with a WebApps section in the hosting Control Panel can deploy projects using custom runtime environments (e.g., Node.js, Python WSGI applications, etc.). Examples can be found in the WebApps/Node.js category of our online documentation. If you do not see a WebApps section in the hosting Control Panel, contact your hosting provider for more information.

Our servers are running а highly customized 64-bit version of Debian GNU/Linux with the Apache web server, MySQL (MyISAM and InnoDB), PHP, Python, Perl, Ruby, and Tcl available. You can find the full list of software installed on the server in the hosting Control Panel -> System Information section. If you see a WebApps section in your hosting Control Panel, you can install runtime environments like Django, Node.js, Flask, Ghost, Ruby on Rails, and run MongoDB or PostgreSQL instances. In the WebApps/Node.js category of our online documentation, you can find step-by-step instructions on how to install some of these web applications. You can contact your hosting provider for more information if you would like to take advantage of the web application support on our servers, but you do not see the WebApps section in your hosting Control Panel.

Here you can find the most common reasons for a 500 server rrror: • Incorrect file/directory permissionsAlmost always Error 500 is caused by insufficient permissions of a file or directory. On our servers you should make sure your files and directores have world-writable permissions, so using permissiosn 644, 664, 755 for files. You can use the same permissions as well as 775 for directories. If you wish to have a script executed by your website visitors, it should have access permissions starting with 7 (-rwx) or with 5 (-r-x) like 0775 (-rwxrwxr-x), 0755 (-rwxr-xr-x), 0750 (-rwxr-x---), and 0700 (-rwx------). This will allow the script to get executed by your hosting account user and the Apache web server. If the file/directory is lacking these permissions, the script will return a 500 Internal Server Error. More details about permissions and what they actually mean are available in our File and folder permissions (CHMOD) article. • Invalid or wrong code in .htaccess filesInvalid or wrong code in your .htaccess files can cause 500 server errors. If you are trying to modify PHP settings with php_flag directives, this may result in a Internal Server Error. PHP runs does not run as an Apache module on our servers, it runs as CGI or FPM, so you cannot use php_flag directives. You can make changes to your PHP configuration using the hosting Control Panel > PHP Settings section or by using a .user.ini and php.ini files. For more details, you can check our Changing PHP settings  article. • Using Windows EOL (end-of-lines) charactersThis problem may occur if you are using a text editor like Notepad or Wordpad. When you add a new line with these programs, they may add EOL characters for Microsoft Windows, which are different than the EOL characters for Linux that runs on our servers. To resolve this problem, you can open view the files via the hosting Control Panel > File Manager section without modifying them and simply click on the "Save and Exit" button. The File Manager editor will remove the Windows EOL characters and replace them with UNIX EOL characters. Executing your script should no longer return Error 500. We would recommend that you use alternative text editors that are free of charge instead of Notepad and Wordpad. Here are two examples:- PSPad (www.pspad.com)- Notepad++ (http://notepad-plus.sourceforge.net/bg/site.htm) • Incorrect path to Perl, Ruby, or PythonIf you use a Perl, Ruby, or Python скрипт, make sure you use the correct path to its binary. You can find the correct path on the server for the binaries you wish to use on your account in the hosting Control Panel > System Information. File and folder permissions

The meanings of these error codes from the web server are: 401 Authorization RequiredThis error message indicates that a website visitor tried to access a password-protected page without authenticating (with a valid username and password). 403 ForbiddenThis error code means that access to the page the visitor is requesting is not allowed. This can be due to a special rule in the configuration of the web server, or due to the specific file system permissions of the file. An example rule in an .htaccess file that would cause this message is this: deny from 1.2.3.4 where 1.2.3.4 is the IP address of the visitor.This error can also be caused by the file lacking read permissions. In that case, the web server will not be able to read the file, and this error message would be displayed. 404 Not FoundThis simply means that the requested file is not there. 412 Precondition FailedThe error means that the request triggered a mod_security protection on our end. You can learn more on this matter in the Error "412 Precondition Failed" (mod_security2) article. 500 Internal Server ErrorThis can be the most confusing error message, because it can be caused by many things ranging from server and permission problems to application errors and script misconfiguration. More sample causes for the error can be found in our Error 500 (Internal Server Error) article. Information about the actual error message is recorded in the server's error log, which you can review via the Logs section in the Control Panel.

To deliver outstanding performance and uptime, our servers are built with the most reliable server components. Each shared hosting server is equipped with powerful multi-core Xeon processors, up to 1 TB of RAM, and multi-terabyte SSD RAID 6 storage arrays. We use RAID 6 because it offers the best combination of performance and reliability. Performance is the same as RAID 5, and stored data is protected even if two drives in the array fail simultaneously. All storage drives, power supply units, and cooling fans are hot-swappable, allowing replacements on the fly. This mitigates the impact of possible hardware failures to the absolute minimum. Redundant power on the premises, multiple backup generators, and a redundant network of multiple fiber trunks from multiple sources ensure the highest levels of connectivity and reliability.

Log files format Every line in the log files of the Apache web server on our servers has the following fields: HOSTNAME IP ADDRESS  -  HTTP USER TIME REQUEST STATUS CODE SIZE REFERER USER AGENT An explanation of every field is available in the table below: HOSTNAME The name of your (sub)domain where the request was sent to. IP ADDRESS The IP address that initiated the request. - Not readable by the server. HTTP USER Here you will find the username for HTTP authorization. TIME The time the request was handled - exact date, time, and time zone of the server. REQUEST Shows the method used for the request (e.g. GET or POST), followed by the requested full resource (e.g. the path to an image); the protocol used for the request will be listed last (e.g. "HTTP/1.1"). STATUS CODE The status code that the server sent to the visitor. All 2** codes indicate that the request was handled successfully. 3** status codes indicate a redirection, 4** status codes indicate an error caused by the visitor, and 5** status codes indicate a server error. Full list of the status codes is available in the HTTP specification (RFC 9110 Section 15). SIZE The size in bytes of the data sent from the server to the visitor. REFERER The page the visitor is coming from will be listed here if any data is listed in the REFERER header of the request. USER AGENT Information about the browser (User-Agent) of the visitor. All requests are saved to a log file within your hosting account once per hour. A separate log file is created for every hostname (e.g. your_domain.com.log), so the respective HOSTNAME field in the log file is excluded from the log file. For better readability, the HOSTNAME field is displayed in the examples listed below in this article. Examples The first example shows a request from a visitor that searched the words "test" and "example" in google.com and clicked on a link to "http://www.example.com/index.php" from the results page of google.com:www.example.com 64.14.68.138 - - [07/Jul/2019:08:38:50 -0400] "GET /index.php HTTP/1.1" 200 3242 "http://www.google.com/search?hl=en&q=test+example&btnG=Search" "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)"An explanation of every field is listed in the following table: HOSTNAME www.example.com The request was made to www.example.com. IP ADDRESS 64.14.68.138 The request was made from IP address 64.14.68.138. - - - HTTP USER - No username/password was used as the requested resource does not require authorization. TIME [07/Jul/2019:08:38:50 -0400] The request was handled at 8:38:50 GMT-4 on July 07, 2019. REQUEST "GET /index.php HTTP/1.1" The resource was requested with the GET method, the requested resource is "/index.php", and the protocol was "HTTP/1.1." STATUS CODE 200 The 200 status code indicates that the request was handled successfully. SIZE 3242 The requested content sent to the visitor was 3242 bytes. REFERER "http://www.google.com/search?hl=en&q=test+example&btnG=Search" The visitor came to the website "http://www.example.com/index.php" after searching for "test" and "example" on Google.com. USER AGENT "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)" The visitor used the Mozilla Firefox browser as per the "Firefox/3.0.11" string. For the second example, there is a subdomain named protected.example.com, and a redirection is configured for it to another address via the hosting Control Panel > Redirect URL section. In addition, the protected.example.com subdomain is password protected via the hosting Control Panel > Protection section > Web access protection subsection.A visitor opens the URL "http://protected.example.com" in their Internet Explorer browser. The visitor is presented with a prompt where they enter their alloweduser username and respective password for access to protected.example.com. After the successful authorization, the visitor is redirected to the URL configured via the hosting Control Panel > Redirect URL section. Only two lines will be listed in the Apache web server logs, and we will examine only the interesting fields for each request:protected.example.com 64.14.68.139 - - [07/Jul/2019:09:40:10 -0400] "GET / HTTP/1.1" 401 409 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)" HTTP USER - The username is not listed here as the server responds with the authorization prompt to this initial request. STATUS CODE 401 The server returns a 401 status code as the visitor has to authenticate with a valid username and password to access the protected.example.com subdomain. USER AGENT "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)" The visitor uses the Internet Explorer browser as per the "MSIE 7.0" string. The second string is for the password prompt: protected.example.com 64.14.68.139 - alloweduser [07/Jul/2019:09:40:32 -0400] "GET / HTTP/1.1" 302 237 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)" HTTP USER alloweduser The username provided in the authorization prompt is "alloweduser." STATUS CODE 302 The server returns a 302 status code as the visitor is redirected to another address after the successful authentication.

You can view the Apache access and error logs in near real time using the Logs -> Live HTTP Logs section of the hosting control panel. The logs might be provided with a slight delay. When you open the interface for the first time after logging in to the Control panel, live logs for your account are enabled within one minute. Live logs will be disabled six hours after you close the interface, and will be enabled again when you open the interface again.

The raw Apache access logs, as well as the FTP access logs for the account, are available in the /home/$USER/logs folder on the server. This folder is accessible through the File Manager of the hosting Control panel, and through FTP. To access the logs folder with the File Manager and download log files over HTTP, you need to: Open your hosting Control Panel, and go to the File Manager. Click on the .. link to go to the upper folder. You might have to click it a second time, to reach the /home/$USER/ folder. Click on the logs folder. You will see a directory structure with the available log files for your account, a subfolder for each separate month. You can locate the file(s) you need, and download it by clicking on it. To download log files over FTP, you need to log in to your account via FTP and change the working directory to /logs (make sure that you include the leading slash). You will find the logs in that directory. Note that you must use your main FTP user. We also provide log analysis tools that are readily available with your hosting account. You can access them on the Site Statistics page of the Control Panel. For information on viewing the error log, as well as the access log, of the web server in near real time, please refer to the Live HTTP Logs article.  The mail logs are not available for download; however, you can search for incoming and outgoing messages for your hosting account's mailboxes via the Online Manual -> Control Panel -> Logs section. More details on how to search for specific messages are available in our Searching for messages in the mail server logs article.

You can search the mail server logs on the Logs -> Mail logs section of the hosting Control Panel. The mail server logs contain information about all email messages delivered by our servers. There is more information about the format of the logs in our Mail Logs Format article.

Mod_gzip is a module for the Apache 1.3 web server. As we do not use Apache 1.3 on our servers, it is not available with our service. We are using Apache 2. In Apache 2, the functionality of mod_gzip is covered by the mod_deflate module. You can check this article for more information on using mod_deflate: Using mod_deflate.

Mod_deflate is a module for the Apache Web Server. Its purpose is to make a better use of the available bandwidth by compressing content delivered from the web server to the client's browser. The compression is automatic, and the only requirement is that the browser supports gzip compression. Nowadays, most of the browsers support gzip, and no additional software is required. How is the compression performed? The browser will announce if the compression method is supported when sending a request to the server for a specific file, for instance, http://www.example_domain.com/index.html. In case Apache is configured with mod_deflate, the content of index.html will be compressed and sent to the browser. The browser, on the other hand will decompress the gzip file and will display it to the client as a simple html file. The web visitor would not be aware of the above operations. How can I use mod_deflate? To set up mod_deflate, you have to create a .htaccess file (note the dot(".") at the beginning of the file) with the following code in it: <IfModule deflate_module>    AddOutputFilterByType DEFLATE text/css text/csv text/html text/plain text/richtext text/sgml text/tab-separated-values application/javascript application/x-javascript httpd/unix-directory    AddOutputFilter DEFLATE html htm shtml php php4 pl rb py cgi css js txt    BrowserMatch ^Mozilla/4 gzip-only-text/html    BrowserMatch ^Mozilla/4\.0[678] no-gzip    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html</IfModule>Then save the .htaccess file to the directory where you want mod_deflate enabled. Have in mind that .htaccess files work recursively, so it will have effect on all the subdirectories as well. The .htaccess file above will have mod_deflate enabled for all HTML, SSI, PHP, Perl, Ruby, Python, CGI, Cascading Style Sheets, JavaScript and text files.

Mod_speling is a module for the Apache Web Server. Its purpose is to attempt to correct mistaken URLs or various misspellings. It does that by ignoring capitalization. The Linux filesystem is case-sensitive by default, and mod_speling can help you overcome issues with the naming of your files. You may run into such issues when transferring your website over from a Windows-based server, or when publishing website content built on a Windows-based application.  How can I use mod_speling? To enable mod_speling, you have to create a .htaccess file (note the dot(".") at the beginning of the file) with the following code in it: <IfModule mod_speling.c>    CheckSpelling on    CheckCaseOnly on</IfModule> Then save the .htaccess file in the directory where you want mod_speling enabled. Have in mind that .htaccess files work recursively, so it will have effect on all the subdirectories as well.

Mod_brotli is a module for the Apache Web Server. It uses the brotli compression format to compress data sent from the server to the client over the network. The compression is automatic, and the only requirement is that the browser supports brotli compression. Modern browsers support brotli, and no additional software is required. How is the compression performed? The browser will announce if the compression method is supported when sending a request to the server for a specific file, such as http://www.example_domain.com/index.html. If Apache is configured with mod_brotli, the content of index.html will be compressed and sent to the browser. The browser, on the other hand, will decompress the file and will display it to the client as a simple HTML file. The web visitor would not be aware of the above operations. How can I use mod_brotli? To set up mod_brotli, you have to create a .htaccess file (note the dot (".") symbol at the beginning of the file) with the following code in it: <IfModule brotli_module>    AddOutputFilterByType BROTLI_COMPRESS text/css text/csv text/html text/plain text/richtext text/sgml text/tab-separated-values application/javascript application/x-javascript httpd/unix-directory</IfModule> Then save the .htaccess file in the directory where you want mod_brotli enabled. Have in mind that .htaccess files work recursively, so it will have effect on all the subdirectories as well. The .htaccess code above will enable mod_brotli for all HTML, SSI, PHP, Perl, Ruby, Python, CGI, Cascading Style Sheets, JavaScript, and text files.

What is an .htaccess file? .htaccess files allow you to alter the default Apache web server configuration settings. They work recursively, so any defined configuration changes will be applied to the current directory and its subdirectories. The name of the file begins with a dot (.) symbol, and you can easily create .htaccess files via the File Manager section of the hosting Control Panel. If you wish to edit an .htaccess file with a text editor of your choice, you can download the file via the hosting Control Panel > File Manager section or an FTP client. You can find step-by-step instructions on how to set up the most popular FTP clients in the Uploading files category from our online documentation. Some FTP clients do not show configuration/hidden files that start with a dot (.) symbol by default, so please refer to the official documentation of your FTP client of choice for instructions on how to show/display hidden files. Most common uses of .htaccess files In this article, you can find examples of the most common uses of .htaccess files listed below: Restricting access to a website: with password protection for everyone from specific IP addresses/networks for everyone except from specific IP addresses/networks from specific countries from all countries except specific countries from specific User-Agents (blocking bots/website crawlers) from specific referrers for a specific file for multiple files for a specific file extension in a specific time frame Redirecting visitors: to the HTTPS version of your website from the non-WWW version of your domain to the WWW version from the WWW version of your domain to the non-WWW version from the non-WWW version of your domain to the WWW version and forcing HTTPS from the WWW version of your domain to the non-WWW version and forcing HTTPS to a specific page to a temporary (maintenance) page to a subdirectory without showing it to visitors to a subdirectory and showing it to visitors to another website from one page to another one Forcing browsers to upgrade all HTTP requests to HTTPS Setting up HTTP Strict Transport Security (HSTS) Taking advantage of browser caching Enabling content compression Using custom error pages Changing the default browser behavior for specific file types Enabling directory listing Hiding specific files from directory listing Disabling directory listing Preventing hotlinking of your images Adding Content-Type headers Making URLs case-insensitive Removing file extensions from URLs Commenting specific directives Note: With the introduction of Apache version 2.4+ and its Core Authorization module (mod_authz_core), the old Order, Deny, and Allow directives were deprecated by new directives like Require. There are compatibility issues when using the new and old directives simultaneously, and since a lot of software applications rely on the old directives, the examples in this article are listed with the old (but still fully functional) Order, Deny, and Allow directives. How to protect a website with a password? You can enable password protection for your website or a directory quite easily via the hosting Control Panel > Protection section > Web access protection subsection. More details about this option are available in our Password protection article. Of course, you can enable this type of protection manually too: • For Basic authentication (your username and password will be sent from your browser to our servers unencrypted): Use an online .htpasswd generation tool to generate your authentication username and hashed password pair. Insert the string generated by the .htpasswd generation tool into an .htpasswd file in the root folder of your domain (~/www/www/.htpasswd). Add this code block in the .htaccess file of your domain to enable the authentication:AuthType BasicAuthUserFile "/home/USERNAME/www/www/.htpasswd"AuthName Limited!require valid-userNote: You will need to replace USERNAME with your hosting account username. • For Digest authentication (your username and password will be sent from your browser to our servers encrypted): Use an online .htpasswd generation tool that supports Digest authentication to generate your authentication username and hashed password pair. Insert the string generated by the .htpasswd generation tool inside an .htdigest file in the root folder of your domain (~/www/www/.htdigest). Add this code block in the .htaccess file of your domain to enable the authentication:AuthType DigestAuthDigestProvider fileAuthUserFile "/home/USERNAME/www/www/.htdigest"AuthName Limited!require valid-userNote: You will need to replace USERNAME with your hosting account username. How to fully disable public access to a website with an .htaccess file? To entirely prevent access to your website, you can add the following code block to an .htaccess file located in the root folder of your domain (~/www/www/.htaccess):Order Allow,DenyDeny from allIf there are no .htaccess files with Order/Deny/Allow directives in the subdirectories of your website, the first line should be sufficient to prevent all visitors from accessing your website as it sets the default access state for your website to Deny. Should you wish to allow your visitors to browse your website except for the contents of a specific subdirectory, add the code block listed above to an .htaccess file in that subdirectory. How to prevent access to a website from specific IP addresses, networks, or domains? The fastest way to prevent IP addresses or network from accessing your website is to block them via the hosting Control Panel > Protection section > Web access protection subsection. Details on how to use this option are available in our Block by IP article. An .htaccess file can be used to block specific IP addresses, networks, and even domains from accessing a website with the Deny directive. To block IP addresses (e.g. 1.2.3.4), networks (e.g. 5.6.7), domains (e.g. baddomain.com), or subdomains of another domain (e.g. anotherbaddomain.com) and prevent them from accessing your website, use this code block in an .htaccess file in the root directory of your website:Order Deny,AllowDeny from 1.2.3.4Deny from 5.6.7.Deny from baddomain.comDeny from .anotherbaddomain.comAllow from allNote: For the domain rule to work properly, the domain needs to have a valid rDNS record which matches the IP address. This is because the web server does a reverse DNS lookup on the IP address to find the associated hostname, and then does a forward lookup on the hostname to assure that it matches the original IP address. Only if the forward and reverse DNS are consistent and the hostname matches, will the rule work. In general, the last line can be skipped if you do not have other .htaccess files with defined Order/Deny/Allow directives. If you are not sure about this, we would recommend that you add it. How to allow access to a website only from specific IP addresses, networks, or domains? The process of allowing access to your website from IP addresses (e.g. 1.2.3.4), networks (e.g. 5.6.7), domains (e.g. baddomain.com), or subdomains (e.g. subdomain.anotherbaddomain.com) is similar to the access prevention listed above with some minor differences. To achieve this, add the following code block to the root .htaccess file of your website:Order Deny,AllowAllow from 1.2.3.4Allow from 5.6.7.Allow from baddomain.comAllow from .anotherbaddomain.comDeny from allNote: For the domain rule to work properly, the domain needs to have a valid rDNS record which matches the IP address. This is because the web server does a reverse DNS lookup on the IP address to find the associated hostname, and then does a forward lookup on the hostname to assure that it matches the original IP address. Only if the forward and reverse DNS are consistent and the hostname matches, will the rule work. If there are no .htaccess files in the subdirectories of your website with Order, Deny, or Allow directives, you can use this code block (changing the Order directive, and removing the Deny from all directive):Order Allow,DenyAllow from 1.2.3.4Allow from 5.6.7.Allow from baddomain.comAllow from .anotherbaddomain.com How to prevent access to a website from specific countries? The easiest way to achieve this is to use the hosting Control Panel > Protection section > Web access protection subsection. More information about this feature is available in our Block by IP article. You can prevent visitors from a specific country (e.g. Russia) from accessing a website by adding the following code block to your website:SetEnvIf MM_COUNTRY_CODE "^RU$" CountryMatchDeny from env=CountryMatchIf you want to block visitors from multiple countries (e.g. Russia and Antarctica), you can separate the two-letter country codes (ISO-3166-1 ALPHA-2) with a pipe symbol (|) in the .htaccess file as follows:SetEnvIf MM_COUNTRY_CODE "^RU|AQ$" CountryMatchDeny from env=CountryMatchor add a separate line for each country as shown below:SetEnvIf MM_COUNTRY_CODE "^RU$" CountryMatchSetEnvIf MM_COUNTRY_CODE "^AQ$" CountryMatchDeny from env=CountryMatchNote: If a website visitor uses VPN or proxy services, their IP address and country will change, so your country blocks may result in false positives - bad actors may be able to access the website, and regular visitors may be prevented from accessing the website. For this reason, we would recommend that you use the country blocking option with care. How to allow access to a website only from a specific country? If you wish to prevent access to a website from all countries except for one (e.g. United States), you can add the following code block to the main .htaccess file of your website:SetEnvIf MM_COUNTRY_CODE "^US$" CountryMatchAllow from env=CountryMatchDeny from allIf you want to allow access to your website from multiple countries (e.g. United States and Canada), you can separate the two-letter country codes (ISO-3166-1 ALPHA-2) with a pipe symbol (|) in the .htaccess file as follows:SetEnvIf MM_COUNTRY_CODE "^US|CA$" CountryMatchAllow from env=CountryMatchDeny from allor add a separate line for each country as shown below:SetEnvIf MM_COUNTRY_CODE "^US$" CountryMatchSetEnvIf MM_COUNTRY_CODE "^CA$" CountryMatchAllow from env=CountryMatchDeny from allNote: You should use the country blocking option carefully as it may not work correctly for website visitors that use VPN or proxy services. For example, if a website visitor from the US uses a VPN service with IP addresses from outside of the US, the visitor will be unable to see your website. How to prevent access to a website from specific browsers/User-Agents? If you notice suspicious visits on your website generated from a specific browser/User-Agent, you can prevent it from accessing the website by using an .htaccess file. This option is very useful for bots that do not obey the robots.txt file and aggressively crawl websites. The code block listed below will prevent visitors from accessing your website if their browser/User-Agent contains the "BadBot" string:SetEnvIfNoCase User-Agent "BadBot" bad_botDeny from env=bad_botWhen blocking visitors based on User-Agent, you should carefully define the match string ("BadBot" in the example above) to ensure that there are no false positives. If you are not sure how to define the User-Agent, you can contact us for assistance. Note: By default, we block access from browsers and bots that are known to be malicious or extremely aggressive. More details are available in our Error "412 Precondition Failed" (mod_security2) article. How to block visitors referred from specific websites? The hosting Control Panel > Protection section > Web access protection subsection allows you to easily block visitors coming from a specific website. You can learn more about this option in the Block referrers article. To block visitors with a specific referrer (e.g. visitors coming from the website of baddomain.com), you can add the following code block to the main .htaccess file of your website:RewriteEngine onRewriteCond %{HTTP_REFERER} ^https?://(www\.)?baddomain\.com [NC]RewriteRule .* - [F]If you wish to block access to your website for visitors coming multiple websites (e.g. baddomain.com and subdomains of anotherbaddomain.com), you can insert the following lines to your website's .htaccess file:RewriteEngine onRewriteCond %{HTTP_REFERER} ^https?://(www\.)?baddomain\.com [NC,OR]RewriteCond %{HTTP_REFERER} ^https?://([^.]+\.)*anotherbaddomain\.com [NC]RewriteRule .* - [F]If there are multiple RewriteCond directives listed one after the other, they all have to match for the RewriteRule directive to take place. For this reason, the OR flag is added to the first RewriteCond directive, so the RewriteRule directive will work if either of the RewriteCond directives matches. The NC flag indicates case insensitivity. How to disable access to a file? You can add an .htaccess file to the directory of a given file (e.g. private.txt) with the following code block to limit access to that file:<Files "private.txt">    Order Allow,Deny    Deny from All</Files>The Files directive describes which file the given code block will be applied to. You can modify the code block within the Files directive to set custom access to the specified file. Note: You can modify the lines within the Files directive to allow and/or prevent different IP addresses, networks, or domains from accessing the specific file. How to disable access to multiple files? If you wish to block public access to multiple files (e.g. private.txt and secret.doc), you can use the following FilesMatch directive in an .htaccess file located in the directory of the files:<FilesMatch "^(private\.txt|secret\.doc)$">    Order Allow,Deny    Deny from all</FilesMatch>You can achieve the same result by enabling regular expressions for the Files directive with the tilde (~) symbol as shown in the example below; however, it is still recommended that you use the FilesMatch directive:<Files ~ "^(private\.txt|secret\.doc)$">    Order Allow,Deny    Deny from All</Files>Note: You can modify the lines within the Files and FilesMatch directives to allow and/or prevent different IP addresses, networks, or domains from accessing the specific files. How to disable access to multiple files with the same extension? To block access to all files with the same extension (e.g. .txt), you can use the following code block in an .htaccess file:<FilesMatch "\.txt$">    Order Allow,Deny    Deny from All</FilesMatch>If you want to prevent access to multiple file extensions (e.g. .txt, .doc, .rtf, .log, .fla, and .psd files), you should add the following lines to an .htaccess file:<FilesMatch "\.(txt|doc|rtf|log|fla|psd)$">    Order Allow,Deny    Deny from all</FilesMatch>Note: You can modify the lines within the Files and FilesMatch directives to allow and/or prevent different IP addresses, networks, or domains from accessing the specific flies. How to block access to a website in a specific time frame? Using an .htaccess file, you can also restrict access to your website in specific time frames. For example, you can use this code in the .htaccess file of your website to disable public access between 7 PM and 7 AM, so your website will be available only between 7 AM and 7 PM:RewriteEngine OnRewriteCond %{TIME_HOUR} >19 [OR]RewriteCond %{TIME_HOUR} <07RewriteRule ^.*$ - [F,L]You can also disable access to a single file (e.g. contact.php) of your website for just an hour (e.g. starting from 1 PM):RewriteEngine OnRewriteCond %{TIME_HOUR} ^13$RewriteRule ^contact\.php$ - [F,L] How to redirect your website from HTTP to HTTPS? One of the easiest ways to force your website to use HTTPS instead of HTTP is via the hosting Control Panel. For WordPress, you can use the hosting Control Panel > WordPress Manager to update your SiteURL from HTTP to HTTPS as described in our Forcing HTTPS for WordPress article. For other applications, you can use the hosting Control Panel > SSL/HTTPS section > Force HTTPS subsection. To redirect all requests to your website from HTTP to HTTPS with an .htaccess file, you can use the following code block:RewriteEngine OnRewriteCond %{HTTPS} !onRewriteRule (.*) https://%{HTTP_HOST}/$1 [L,R=301]Note: The provided solution may not work for some software applications, so you should refer to the official documentation of the software application that you use for the best way to force the usage of HTTPS for your website. If you encounter mixed content warnings while browsing your website, you may have to force the web server to load all elements of your website via HTTPS. For more information, you can refer to the How to force browsers to load all content from HTTP to HTTPS? section of this article. How to redirect a website from the non-WWW version of your domain to the WWW version? To get your website working with the WWW prefix (e.g. www.your_domain.com and not your_domain.com), you can use the following code block in an .htaccess file:RewriteEngine OnRewriteCond %{HTTP_HOST} ^your_domain.com$RewriteRule ^(.*)$ http://www.your_domain.com/$1 [L,R=301]If you wish to test the redirect, you can use a 302 (temporary) redirect instead of a 301 (permanent) redirect to prevent possible browser caching issues. After you are sure the redirect is working correctly, you can change the redirect from 302 to 301. Note: For some software applications, the provided solution may cause issues, so you should refer to the official documentation of the application you use. If you use WordPress, you can use the hosting Control Panel > WordPress Manager to change the URL of your website as explained in our Changing the Site URL article. How to redirect a website from the WWW version of your domain to the non-WWW version? To redirect visitors to your website without the non-WWW prefix (e.g. your_domain.com instead of www.your_domain.com), you can use the code listed below in your .htaccess file located in the website's root directory:RewriteEngine OnRewriteCond %{HTTP_HOST} ^www.your_domain.com$RewriteRule ^(.*)$ http://your_domain.com/$1 [L,R=301]You should consider changing the redirect status code from 301 (permanent) to 302 (temporary) to test the redirect first. If everything is working as expected, you can set the redirect status code back to 301. Note: If you are using a software application, you should refer to its official documentation on how to change the URL of your website. If you are running WordPress on your website, the easiest way to change the URL of your website is via the hosting Control Panel > WordPress Manager by following the instructions listed in our Changing the Site URL article. How to redirect a website from the non-WWW version of your domain to the WWW version and forcing HTTPS? You can add the following lines of code to your website's .htaccess file if you wish to have your website always working with HTTPS and the WWW prefix (e.g. https://www.your_domain.com):RewriteEngine OnRewriteCond %{HTTP_HOST} ^your_domain.com$RewriteCond %{HTTPS} onRewriteRule ^(.*)$ https://www.your_domain.com/$1 [L,R=301]RewriteCond %{HTTPS} !onRewriteRule ^(.*)$ https://www.your_domain.com/$1 [L,R=301]We encourage you to replace the 301 with 302 redirects in the above code when testing as this should prevent browser caching of the redirects. Do not forget to set the redirects to 301 once you are satisfied with the result. Note: Some software applications may not work correctly with this redirection, so please refer to their official documentation for instructions on how to achieve the desired redirect. For WordPress, you can make the URL conversion from HTTP to HTTPS and from non-WWW to WWW at once by Changing the Site URL via the hosting Control Panel > WordPress Manager. If mixed content browser warnings are displayed in your website, you may have to explicitly configure the server to upgrade all requests from HTTP to HTTPS. For more information, you can refer to the How to force browsers to load all content from HTTP to HTTPS? section of this article. How to redirect a website from the WWW version of your domain to the non-WWW version and forcing HTTPS? If you would like to have your website always working over HTTPS without the WWW prefix (e.g. https://your_domain.com), you can use the following .htaccess code:RewriteEngine OnRewriteCond %{HTTP_HOST} ^www.your_domain.com$RewriteCond %{HTTPS} onRewriteRule ^(.*)$ https://your_domain.com/$1 [L,R=301]RewriteCond %{HTTPS} !onRewriteRule ^(.*)$ https://your_domain.com/$1 [L,R=301]The 301 redirect is permanent and will allow your browser to cache the redirect, so you may use a temporary 302 redirect if you wish to test the redirect and make changes to the code. Note: Redirect issues/loops can occur if you use the .htaccess code for some software applications. In such cases, you should refer to the official documentation of the software application installed on your website. If you are using WordPress, you can make the WWW to non-WWW and HTTP to HTTPS switch via the hosting Control Panel > WordPress Manager by Changing the Site URL of your WordPress installation. Should your website show mixed content warnings, you should consider checking the How to redirect your website from HTTP to HTTPS? section of this article for a solution. How to redirect a website to a specific page? You can redirect all visitors of your website to a specific page (e.g. temp.php) by adding the following code block to an .htaccess file in the root directory of your website:RewriteEngine OnRewriteCond %{REQUEST_FILENAME} !temp\.phpRewriteRule .* /temp.php [NC,L,R=301]Switching the redirect status code in the .htaccess file from 301 to 302 will allow you to test the redirection without having to worry about browser caching as the 302 redirections should not be cached by browsers. Do not forget to set the redirect status code back to 301 after the tests. How to redirect a website to a maintenance page? You can use the method listed above to display a temporary page to your website visitors. The only difference is that the redirect status code should be set to 302 or 307 which will indicate to browsers and search engines that the redirection is temporary. Here is some sample code that you can use to redirect everyone visiting your website to a temporary maintenance page (e.g. maintenance.html) that resides in your website's directory:RewriteEngine OnRewriteCond %{REQUEST_URI} !/maintenance.html$RewriteRule .* /maintenance.html [L,R=307]Note: Some software applications allow you to set a maintenance page via their administrative interface or by creating a file named ".maintenance" in the root directory of the application. If you use a software application, it is advisable that you check its documentation for instructions on enabling maintenance mode. How to get a website to work from a subdirectory without showing it to visitors? The easiest way to do get your website to load the files of a subdirectory (e.g. /new_subdirectory/) would be to change the document root of your website via the hosting Control Panel > Subdomains section as explained in our Document roots article. This way, your website files will be loaded from the specified subdirectory of your domain without it being shown in the URL of the website visitors. You can achieve the same result by using the code listed below in an .htaccess file in the root directory of your website:RewriteEngine OnRewriteCond %{ENV:REDIRECT_STATUS} ^$RewriteRule ^new_subdirectory($|/) - [L,R=404]RewriteRule !^new_subdirectory/ /new_subdirectory%{REQUEST_URI} [L] How to get a website to work from a subdirectory and show it to visitors? If you want to show your visitors that the website content has been moved to a subdirectory (e.g. your_domain.com/new_subdirectory/) and redirect them to the same page at the new location, you can do this with the following .htaccess file code block in the root directory of the website:RewriteEngine OnRewriteCond %{REQUEST_URI} !^/new_subdirectory/RewriteRule ^(.*)$ /new_subdirectory/$1 [NC,L,R=301]The above code block will redirect visitors from any page of the main domain (your_domain.com/page.html) to same page in the specified subdirectory (your_domain.com/new_subdirectory/page.html). If you simply wish to redirect all visitors to the index file of the new_subdirectory subdirectory, update the RewriteRule as follows:RewriteRule .* /new_subdirectory/ [NC,L,R=301]This way, visitors of your website will be redirected to the index file of the subdirectory (e.g. your_domain.com/new_subdirectory/). How to redirect a website to another website? To redirect a website to another website (e.g. another_domain.com), you can use the code block listed below in an .htaccess file located in the root directory of the website where the redirect will occur:RewriteEngine OnRewriteRule ^(.*)$ https://another_domain.com/$1 [L,R=301]This code will redirect visitors from any page of your website (e.g. your_domain.com/page.html) to the same page on the other website (e.g. another_domain.com/page.html). If you want to redirect all visitors without preserving the URL, use this .htaccess code block:RewriteEngine OnRewriteRule .* https://another_domain.com/ [L,R=301] How to redirect a page or directory to another one? The easiest way to perform this type of redirects is via the hosting Control Panel > Redirect URL section. If you wish to manually redirect a given page of your website to a new page of your or another website (e.g. old_page.html to new_page.html or old_file.html to http://another_domain.com/new_file.html), you can use the following code in an .htaccess file added to your website's root directory:Redirect 301 /old_page.html /new_page.htmlRedirect 301 /old_file.html http://another_domain.com/new_file.htmlThe same can rule can be used for directories (e.g. old_directory to new_directory or old_location to http://another_domain.com/new_location):Redirect 301 /old_directory /new_directoryRedirect 301 /old_location http://another_domain.com/new_locationWe would advise that you first set the redirects with a 302 (temporary) status code instead of 301 (permanent) as this will instruct browsers to not cache the redirection which will help ensure that your redirection is configured correctly. Once you are certain that the redirection is indeed configured correctly, you can set the redirect status code to 301. How to force browsers to load all content from HTTP to HTTPS? A browser will display a mixed content warning if you open a website via HTTPS, but some elements of the website (images, stylesheets, or other files) are actually loaded via HTTP. This poses a security issue as the connection is not fully encrypted. To resolve this problem, you should first check that you have forced HTTPS for your website. You can refer to the How to redirect your website from HTTP to HTTPS? section of this article for more information. If you still encounter the mixed content browser warning, it is possible that some remote elements are loaded via HTTP or some local elements are hard-coded to use HTTP. To fix this problem, you can force the web server to always request elements via HTTPS for the website by adding the following line to the .htaccess file of your website:Header always set Content-Security-Policy: upgrade-insecure-requests How to enable HSTS? HTTP Strict Transport Security (HSTS) is a simple policy which protects website visitors by ensuring that their browsers always connect to a website over HTTPS. HSTS removes the need to use common techniques for redirecting users from http:// to https:// URLs. Before you enable HSTS, you should first check that you have not forced HTTPS for your website via the hosting Control Panel > SSL/HTTPS section > Force HTTPS subsection. Forcing HTTPS this way may affect the proper operation of the HSTS-enabling lines in your .htaccess file. Also, make sure you have not forced a redirect from non-www to www via your hosting Control Panel > Domain Parking section > Domain Redirects tab. Furthermore, you should check your .htaccess file for other custom rewrite rules and remove them, if they are related to or in conflict with the HSTS directive. To summarize, the main requirements of HSTS are: 1) redirect from HTTP to HTTPS on the same host. i.e. http://example.com to https://example.com and http://www.example.com to https://www.example.com; 2) redirect to the canonical hostname (www or non-www) on HTTPS only. (i.e. after #1 above); 3) send the Strict-Transport-Security (STS) HTTP response header when on HTTPS only, including on the canonical redirect (#2 above). To enable HSTS for your website and set up a redirect from non-www to www at the same time, add the following lines to your .htaccess file (the order of the lines is important): RewriteEngine On# Set HSTS env var only if HTTPS RewriteCond %{HTTPS} onRewriteRule ^ - [E=HSTS:1] # Redirect HTTP to HTTPS on the same host RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] # Redirect non-www to www (HTTPS only) RewriteCond %{HTTP_HOST} !^www\.RewriteRule ^ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L] # Set HSTS header for 365 days including subdomains conditionally if request is over HTTPS only (based on HSTS env var) Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HSTS If you prefer using non-www URLs instead of www, you can add the following lines instead: RewriteEngine On# Set HSTS env var only if HTTPS RewriteCond %{HTTPS} onRewriteRule ^ - [E=HSTS:1] # Redirect HTTP to HTTPS on the same host RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L] # Redirect www to non-www (HTTPS only) RewriteCond %{HTTP_HOST} ^www\.RewriteRule ^ https://your-domain-name.com%{REQUEST_URI} [R=301,L]# Set HSTS header for 365 days including subdomains conditionally if request is over HTTPS only (based on HSTS env var) Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HSTS When redirecting from www to non-www URLs, make sure to replace your-domain-name.com with your actual domain name. HSTS is a nice addition to loading all website elements via HTTPS, as described in the How to force browsers to load all content from HTTP to HTTPS? section of this article. How to take advantage of browser caching? One of the best ways to reduce the loading time and traffic usage of your website is to help browsers identify what information can be cached and for how long. You can use the following code block in an .htaccess file inside your website to instruct browsers to cache images, stylesheets, and JavaScript files.ExpiresActive OnExpiresByType application/javascript "access 1 month"ExpiresByType application/pdf "access 1 month"ExpiresByType application/x-javascript "access 1 month"ExpiresByType application/x-shockwave-flash "access 1 month"ExpiresByType image/gif "access 1 year"ExpiresByType image/jpeg "access 1 year"ExpiresByType image/jpg "access 1 year"ExpiresByType image/png "access 1 year"ExpiresByType image/x-icon "access 1 year"ExpiresByType text/css "access 1 month"ExpiresDefault "access 2 days" How to enable content compression? Another great way to reduce the loading time of your website and your traffic usage is to enable compression support for your website. When compression is enabled and a visitor opens your website, the web server will send a request to the browser of the visitor to check if compression is supported. If it is supported, the web server will compress all data that is defined for compression and send the compressed data to the visitor's browser. The browser will decompress the data, and the original content file will be loaded. This happens automatically and will be invisible to the visitor. The visitor will only benefit from faster loading time and reduced data usage. Most modern browsers have full support for Brotli, Deflate, and GZIP compression. On our servers Brotli (mod_brotli) and Deflate (mod_deflate) compressions are supported, and GZIP compression (mod_gzip) is covered by the Deflate compression (mod_deflate). The compression can be enabled via an .htaccess file. To enable Brotli compression on your website for HTML, SSI, PHP, Perl, Ruby, Python, CGI, CSS, JavaScript, and text files, you need to place the following code block inside an .htaccess file in the root folder of your website:<IfModule brotli_module>    AddOutputFilterByType BROTLI_COMPRESS text/css text/csv text/html text/plain text/richtext text/sgml text/tab-separated-values application/javascript application/x-javascript httpd/unix-directory</IfModule>To get Deflate compression enabled on your website for HTML, SSI, PHP, Perl, Ruby, Python, CGI, CSS, JavaScript and text files, you should add the following lines to your website's .htaccess file:<IfModule deflate_module>    AddOutputFilterByType DEFLATE text/css text/csv text/html text/plain text/richtext text/sgml text/tab-separated-values application/javascript application/x-javascript httpd/unix-directory    AddOutputFilter DEFLATE html htm shtml php php4 pl rb py cgi css js txt    BrowserMatch ^Mozilla/4 gzip-only-text/html    BrowserMatch ^Mozilla/4\.0[678] no-gzip    BrowserMatch \bMSIE !no-gzip !gzip-only-text/html</IfModule> How to set custom error pages? With an .htaccess file you can display custom error pages to your website visitors when the server returns an error. This is possible with the ErrorDocument directive. The syntax you should use is:ErrorDocument error_number custom_errorYou should replace error_number with the exact number of the error that you wish to set a custom error page for. The custom_error can be replaced with a single word, quoted text message with HTML support, a local file, or a URL. Here is sample .htaccess code that will display a single word/string without intervals (e.g. Error!) in the body of the page to the visitor when they try to open a page that does not exist and the server returns error 404:ErrorDocument 404 Error!If you wish to display a more helpful message that is longer than one word/string, you should surround the message text in quotes. HTML is also supported, so you can define a custom 403 error message by using the following line in your website's .htaccess file:ErrorDocument 403 "<html><title>Forbidden!</title><body>You don't have permission to access this resource.</body></html>"The ErrorDocument directive also allows you to direct visitors to a local file (e.g. /path_to/custom_404_error_page.php) when they encounter a specific error (e.g. 404). You can achieve this by adding the following line to your .htaccess file:ErrorDocument 404 /path_to/custom_404_error_page.phpYou can also redirect visitors to a remote website/page (e.g. http://another_domain.com/custom_500_error_page.html) when they encounter an error on your website (e.g. 500). Here is the exact line that you need to add to the .htaccess file of your website for this:ErrorDocument 500 http://another_domain.com/custom_500_error_page.html How to change the default browser behavior for specific files/types? Browsers can handle files differently based on their extension. By default, most modern browsers can be used to directly view PDF files or view and listen to music and video files. The default behavior may be altered within the browser's settings in some cases which is from the perspective of a website visitor. However, as a website owner, you can also change this behavior and instruct the browser how to handle specific files (e.g. display download prompt for MOV, MP3, MP4, and PDF files, so they cannot be viewed directly in the browser) by adding a code block like the following in the .htaccess file of your website:<FilesMatch "\.(mov|mp3|mp4|pdf)$">    ForceType application/octet-stream    Header set Content-Disposition attachment</FilesMatch> How to enable directory listing? Directory listing is disabled by default on our servers for security concerns, and it can be enabled only for directories without an index file. So, to enable directory listing for a specific location, you need to remove any index files and add the following code block to an .htaccess file within the directory location on the server:Options +IndexesNote: Please enable directory listing with care as this will allow anyone (including visitors with malicious intentions) to view your files and directory structure. How to hide specific files from directory listing? If you have enabled directory listing as explained above but wish to prevent visitors from viewing specific files (e.g. PHP and JS files), you can add the following line to your .htaccess file:IndexIgnore *.php *.html How to disable directory listing? Directory listing is disabled on our servers by default. If it is enabled for some reason (e.g. it is enabled for an upper directory), you can disable it by creating/uploading an index file to the said directory or create an .htaccess file with the following line in it:Options -Indexes How to prevent hotlinking of your images? The term "hotlinking" refers to the use of elements (mostly images) from one website on another website. Hotlinking was very popular in the past as traffic limits were pretty restrictive, and it allowed website owners to display images on their website without taking a hit on their traffic usage. However, this was causing issues for the websites where the images were actually hosted as they would generate traffic quickly without actually having any visitors. Nowadays hotlinking is not so popular, but it is possible to experience its negative effect. If you wish to prevent third parties from using images of your website, you can add the following code block to an .htaccess file inside the root directory of your website (e.g. your_domain.com):RewriteEngine OnRewriteCond %{HTTP_REFERER} !^http://(www\.)?your_domain\.com/ [NC]RewriteCond %{HTTP_REFERER} !^$RewriteRule \.(jpeg|JPEG|jpe|JPE|jpg|JPG|gif|GIF|png|PNG|tif|TIF|tiff|TIFF)$ - [F]If you have domains parked to your account, you should use the following code block in your website's .htaccess file, so that not only the main domain (e.g. your_domain.com), but also the parked domains (e.g. your_first_parked_domain.com and your_parked_domain_2.com) can display the images as well:RewriteEngine OnRewriteCond %{HTTP_REFERER} !^http://(www\.)?your_domain\.com/ [NC]RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_first_parked_domain\.com/ [NC]RewriteCond %{HTTP_REFERER} !^http://(www\.)?your_parked_domain_2\.com/ [NC]RewriteCond %{HTTP_REFERER} !^$RewriteRule \.(jpeg|JPEG|jpe|JPE|jpg|JPG|gif|GIF|png|PNG|tif|TIF|tiff|TIFF)$ - [F] How to add Content-Type headers? You can instruct the browsers of your website's visitors to use a specific character set for your website with the AddDefaultCharset .htaccess directive. For example, you can define the default character set (e.g. UTF-8) for your website in an .htaccess with the code listed below, so browsers will automatically use this character set:AddDefaultCharset UTF-8 How to make URLs case-insensitive? Our servers run Linux, which is a case-sensitive system. For example, if you have a page named "test.html" on the server, browsing a page named "Test.html" will result in a 404 (Not Found) error. The case sensitivity can be disabled with the mod_speling Apache module on our servers. To do this, simply add the following code block to the .htaccess file of your website:<IfModule mod_speling.c>    CheckSpelling on    CheckCaseOnly on</IfModule>If your server does not support mod_spelling, you can refer to the .htaccess solution for rewriting all URLs to lower case at www.askapache.com. How to trim the extensions of pages/files? There are multiple ways to hide the extensions of your website's files. For example, to hide the ".php" extension of PHP files, you can add the following line to your website's .htaccess file:Options +FollowSymLinksRewriteEngine OnRewriteCond %{REQUEST_METHOD} !POSTRewriteCond %{THE_REQUEST} ^[A-Z]{3,}\s([^.]+)\.php [NC]RewriteRule ^ %1 [R=302,L,NE]RewriteCond %{REQUEST_FILENAME}.php -f [NC]RewriteRule ^ %{REQUEST_URI}.php [L]Another method to hide the extension of your files is the Multiviews option which is supported by default on our servers. If a visitor of your website tries to open up a page that doesn't exist (e.g. a "page" without an extension), but there is a file with that name (e.g. "page.html'), the web server will serve the existing file to the visitor as if the existing file was requested (e.g. "page.html"). Please note that with this method, visitors will still be able to access the original file if they open it directly. If Multiviews is not enabled for your website, you can enable it by adding the following line to your website's .htaccess file:Options +MultiViews How to insert a comment in an .htaccess file? Lines in .htaccess files that begin with a shebang (#) symbol are considered comments and will be ignored by the web server. So, to insert a comment or comment a specific directive in an .htaccess file, all you need to do is add a shebang symbol at the start of the line. For example, here are two valid .htaccess comments:#This is a comment.      #Options +MultiViews - This directive is correctly commented out.Here is one invalid comment example that will most likely cause your website to return a 500 Internal Server Error:Options +MultiViews #This is an invalid comment.

What is an .ftpaccess file? .ftpaccess files allow you to alter the default FTP server configuration settings. The name of the file begins with a dot (.) symbol. You can create .ftpaccess files via the File Manager section of the hosting Control Panel. If you wish to edit an .ftpaccess file with a text editor of your choice, you can download the file via an FTP client. You can find step-by-step instructions on how to set up the most popular FTP clients in the Uploading files category from our online documentation. Some FTP clients do not show configuration/hidden files (starting with a dot (.) symbol) by default, so please refer to the official documentation of your FTP client of choice for instructions on how to show/display hidden files. The .ftpaccess Limit directive You can use the Limit directive in .ftpaccess files to limit access to a specific or a group of FTP commands in a particular directory. If you wish to limit access to specific FTP commands in multiple directories/subdirectories, you need to add an .ftpaccess file to each directory/subdirectory as .ftpaccess files do not work recursively. A list of the command groups and the most widely used FTP commands with a brief overview is available below: ALL includes the READ, WRITE, and DIRS command groups (all FTP commands). This command group has the lowest precedence, so if there is a Limit directive configured for a command or command group, the ALL command group limit will not have any effect. READ includes the following FTP commands related to file reading (directory reading FTP commands are not included in this command group): RETR (RETRieve) allows the FTP client to download files from the server. SITE CHMOD (CHange MODe) allows the FTP client to change file/directory permissions. SIZE allows the FTP client to view file size information. STAT (STATus) allows the FTP client to view the FTP server/connection status. WRITE includes the following FTP commands used for writing, creating, and deleting files/directories: APPE (APPEnd) allows the FTP client to append the content of one file to another. DELE (DELEte) allows the FTP client to delete a file/directory. MKD/XMKD (MaKe Directory) allows the FTP client to create a new directory. RMD/XRMD (ReMove Directory) allows the FTP client to remove a directory. RNTO (ReName TO) allows the FTP client to rename a file/directory. This FTP command is used in combination with the RNFR FTP command. STOR (STORe) allows the FTP client to upload files to the server. DIRS includes the following FTP commands associated with directory listing: CDUP/XCUP (Change Directory UP) allows the FTP client to navigate up one directory level. CWD/XCWD (Change Working Directory) allows the FTP client to change the current working directory. LIST/NLST (LIST/Name LiST) allows the FTP client to list the files in a directory. MDTM (MoDification TiMe) allows the FTP client to view the date when a file was last modified. PWD/XPWD (Print Working Directory) allows the FTP client to display the current working directory. RNFR (ReName FRom) allows the FTP client to rename a file/directory. This FTP command is used in combination with the RNTO FTP command. More details about the Limit directive are available in the official ProFTPD documentation. Protecting .ftpaccess files By default, configuration files (starting with a dot (.) symbol) are visible for all FTP users. This includes .ftpaccess files. We would recommend that you add the following code block at the beginning of your .ftpaccess files to allow only specific FTP users to view and manage your configuration files: HideFiles (\.ftpaccess|\.htaccess|\.htpasswd)$ user !alloweduser<Limit ALL>IgnoreHidden on</Limit> Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to each directory where you wish the custom FTP configuration to take effect. For increased security, and to prevent public access (over HTTP) to your .ftpaccess files, we would recommend that you change their permissions to 0600 via the File Manager in your hosting Control Panel. Examples You can find examples for the most common uses of .ftpacess files listed below: Blocking FTP access• from specific IP addresses/networks• from everywhere• from everywhere except for specific IP addresses/networks Restricting file and directory deletion Restricting file uploads and directory creation• for everyone except for specific FTP users• mixed setup Allowing only file uploads Restricting access to specific FTP users Allowing access only to specific FTP users Allowing file deletion only from specific IP addresses/networks Restricting file/directory permission changes to specific FTP users 1. Blocking FTP access from specific IP addresses/networksTo block FTP access to a directory from specific IP addresses (e.g. 1.2.3.4) and networks (e.g. all IP addresses starting with 5.6.7), add the following code block to an .ftpaccess file in that directory:<Limit ALL>Order allow,denyDeny from 1.2.3.4Deny from 5.6.7.</Limit> Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect. from everywhereYou can completely block FTP access to a directory by adding the following code block to an .ftpaccess file in that directory: <Limit ALL>Order allow,denyDeny from all</Limit> Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect. from everywhere except for specific IP addresses/networksIf you wish to block FTP access to a directory for everyone except for specific IP addresses (e.g. 1.2.3.4) and networks (e.g. all IP addresses starting with 5.6.7), add the following code block to an .ftpaccess file in that directory:<Limit ALL>Order allow,denyAllow from 1.2.3.4Allow from 5.6.7.Deny from all</Limit> Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect. 2. Restricting file and directory deletion You can prevent the deletion of files and directories in a directory for all FTP users except for one (e.g. allowed_user) by adding the following code block to an .ftpaccess file in that directory: <Limit DELE RMD XRMD>AllowUser allowed_userDenyAll</Limit> Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect. 3. Restricting file uploads and directory creation for everyone except for specific FTP usersIf you wish to allow all FTP users to view the contents of the current directory, but prevent file uploads and directory creation for all except two FTP users (e.g. allowed_user_1 and allowed_user_2), you should add the following code block to an .ftpaccess file in that directory:<Limit WRITE>AllowUser allowed_user_1,allowed_user_2DenyAll</Limit>Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect. mixed setupYou can assign FTP access to different commands for different FTP users allowing you to configure custom configurations like the following:- one user (e.g. allowed_user_1) with access to file reading and directory listing without writing access- another user (e.g. allowed_user_2) without access to file reading but with directory listing and file/directory uploading access- third user (e.g. allowed_user_3) with full accessAdd the following code block to an .ftpaccess file in the directory where you wish to achieve the setup listed above:<Limit READ>AllowUser allowed_user_1,allowed_user_3DenyAll</Limit><Limit WRITE>AllowUser alloweduser_2,allowed_user_3DenyAll</Limit> Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect. 4. Allowing only file uploads To prevent file reading and directory listing access and allow file uploads to a directory for all FTP users (overwriting of existing files will be possible), add the following code block to an .ftpaccess file in that directory: <Limit ALL>DenyAll</Limit><Limit CDUP CWD XCWD XCUP PWD>AllowAll</Limit><Limit STOR STOU>AllowAll</Limit> Important: The directory containing the .ftpaccess file will not be visible so, to access it, you will need to establish a connection directly to it by either of the following: Entering the path to the directory containing the .ftpaccess file manually in your FTP client. Configuring the directory containing the .ftpaccess file as the default remote directory in your FTP client. Setting the directory containing the .ftpaccess file as the (root) Directory for the FTP users via the FTP Manager section of the hosting Control Panel. You can find more details about this section in our FTP Manager article. Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect. 5. Restricting access to specific FTP users You can prevent access to a directory for specific FTP users (e.g. restricted_user_1 and restricted_user_2) by adding the following code block to an .ftpaccess file in that directory: <Limit ALL>DenyUser restricted_user_1,restricted_user_2</Limit> Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect. 6. Allowing access only to specific FTP users To grant access to a directory only for specific FTP users (e.g. allowed_user_1 and allowed_user_2), you should add the following code block to an .ftpaccess file in that directory: <Limit ALL>AllowUser allowed_user_1,allowed_user_2DenyAll</Limit> Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect. 7. Allowing file deletion only from specific IP addresses/networks Should you wish to allow the deletion of files in a directory only from specific IP addresses (e.g. 1.2.3.4) and networks (e.g. all IP addresses starting with 5.6.7), add the following code block to an .ftpaccess file in that directory: <Limit DELE>Allow from 1.2.3.4Allow from 5.6.7.DenyAll</Limit> Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect. 8. Restricting file/directory permission changes to specific FTP users You can grant access for changing file and directory permissions in a specific folder only to specific FTP users (e.g. allowed_user_1 and allowed_user_2) by adding the following code block in an .ftpaccess file in that directory: <Limit SITE_CHMOD>AllowUser allowed_user_1,allowed_user_2DenyAll</Limit> The FTP users (allowed_user_1 and allowed_user_2) will be able to change the permissions of files and folders that they own, while all other FTP users will be unable to change the permissions of any files and folders (even if they own them). Note: Since .ftpaccess files do not work recursively, you will need to add a separate .ftpaccess file to all directories where you wish the custom FTP configuration to take effect.

What is a robots.txt file? Robots.txt files allow you to inform search engine crawlers and bots what URLs of your website should or should not be accessed via the Robots Exclusion Protocol. You can use it in combination with a sitemap.xml file and Robots meta tags for more granular control over what parts of your website get crawled. The robots.txt file should be located at the root directory of the website. Important: The rules in the robots.txt file rely on voluntary compliance of the crawlers and bots visiting your website. If you wish to fully block access to specific pages or files of your website or prevent specific bots from accessing your website, you should consider using an .htaccess file instead. Various examples on applying such restrictions are available in our How to use .htaccess files article. How to create a robots.txt file? Some applications, like Joomla, will come with a robots.txt file by default, while others, like WordPress, may generate the robots.txt file dynamically. Dynamically generated robots.txt files do not exist on the server, so editing them will depend on the specific software application you are using. For WordPress, you can use a plugin that handles the default robots.txt file or manually create a new robots.txt file. You can create a robots.txt file for your website via the File Manager section of the hosting Control Panel. Alternatively, you can create a robots.txt file locally in a text editor of your choice, and after that, you can upload the file via an FTP client. You can find step-by-step instructions on how to set up the most popular FTP clients in the Uploading files category from our online documentation. What can you use in the robots.txt file? The rules in the robots.txt file are defined by directives. The following directives are supported for use in a robots.txt file: User-agent - defines the User-Agent of the bot/crawler that the rule is for. Multiple User-Agents can be listed one after the other if they should be allowed or disallowed to access the same directories. The * (asterisk) character can be used as a wildcard character. Allow/Disallow - defines if the above User-Agent/s are allowed or disallowed to access a specific directory of the domain. It is possible to set the access limitations for multiple directories by adding a separate line for each directory. The * (asterisk) character can be used as a wildcard character. The $ (dollar sign) character can be used to define the end of a directory/URL. Crawl-delay (optional) - instructs crawlers and robots to delay their crawl rate. The directive accepts numbers as values from 1 to 30 which indicate the delay in seconds. This optional directive can help prevent aggressive crawling of the website as long as the bot is obeying the Crawl-delay directive. Sitemap (optional) - provides the location of the sitemap to search engine crawlers. If there are separate websites located in subdirectories of the main domain, a separate Sitemap directive can be provided for each subdirectory. The values for the directives are case-sensitive, so you need to make sure you enter them with the correct capitalization. For example, two different bots will be targeted if you use "Googlebot" and "GoogleBot" as User-Agents in your robots.txt file. Comments in the robots.txt file You can use the # (hashtag) character to add comments for better readability by humans. Characters after a # character will be considered a comment if the character is at the start of a line or after a properly defined directive followed by an interval. Examples of valid and invalid comments can be found below:# This is comment on a new line.User-agent: * # This is a comment after the User-agent directive.Disallow: / # This is a comment after the Disallow directive. // This is not a valid comment.User-agent: Bot# This is not a valid comment as it is not separated with an interval after the User-agent. The matched User-Agent will be "Bot#" and not "Bot".The robots.txt file should be in UTF-8 encoding. The Robots Exclusion Protocol requires crawlers to parse robots.txt files of at least 500 KiB. Since Google have set their bots to not crawl robots.txt files bigger than 500 KiB, you should try to keep the size of your robots.txt file below that size. What is the default content of the robots.txt file? The content of the robots.txt file will depend on your website and the applications/scripts you are using on it. By default, all User-Agents are allowed to access all pages of your website unless there is a custom robots.txt file with other instructions. Joomla You can find the default content of the robots.txt for Joomla in its official documentation. It looks like this:User-agent: *Disallow: /administrator/Disallow: /api/Disallow: /bin/Disallow: /cache/Disallow: /cli/Disallow: /components/Disallow: /includes/Disallow: /installation/Disallow: /language/Disallow: /layouts/Disallow: /libraries/Disallow: /logs/Disallow: /modules/Disallow: /plugins/Disallow: /tmp/ WordPress The default WordPress robots.txt file has the following content:User-agent: *Disallow: /wp-admin/Allow: /wp-admin/admin-ajax.phpSitemap: https://YOUR_DOMAIN.com/wp-sitemap.xml Examples You can find sample uses of robots.txt files listed below: allow full access disallow full access allow full access except for one directory and one file allow full access except for a single crawler allow full access only to a single crawler disallow access to specific file types block access to URLs with a dollar sign How to inform robots they can fully access your website? If there is no robots.txt file available for your website, the default rule for your website will be to allow all User-Agents to access all pages of your domain:User-Agent: *Allow: / The same can be achieved by specifying an empty Disallow directive:User-Agent: *Disallow: How to inform all robots they should not access your website? To disallow all robots access to your website, you can use the following content in your website's robots.txt file:User-Agent: *Disallow: / How to inform robots they can fully access your website except for a specific directory/file? You can inform bots to crawl your website with the exception of a specific directory or a file using this code block in your robots.txt file:User-agent: *Disallow: /directory/User-agent: *Disallow: /directory/file.html How to allow full access to your website to all robots except for a specific one? If you would like to allow all robots except just one to crawl your website, you can use this code block in your website's robots.txt file:User-agent: NotAllowedBotDisallow: /Make sure you replace the NotAllowedBot string with the name of the actual bot you want the rule to apply for. How to allow full access to your website only to a single robot? To instruct all bots but one to not crawl the website, use this code block: User-agent: AllowedBotAllow: /User-agent: *Disallow: /Make sure you replace the AllowedBot string with the name of the actual bot you want the rule to apply for. How to disallow robots from accessing specific file types? Adding the following code block to your robots.txt file will instruct compliant robots to not crawl .pdf files:User-agent: *Disallow: /*.pdf$ How to disallow robots from accessing URLs with a dollar sign? The $ (dollar sign) character has a special meaning in robots.txt files - it defines the end of a matching value in the Allow/Disallow directive. To add a rule that takes effect for URLs that contain the $ character, you can use the following pattern in the Allow/Disallow directive:User-agent: *Disallow: /*$*If you add the value without the ending wildcard character:User-agent: *Disallow: /*$all bots will be prevented from accessing the full website, and this could seriously affect your website's SEO ranking.

Note: FastCGI is deprecated on our servers. We do not recommend using FastCGI anymore. Instead, you should use FPM with OPcache. FPM can be easily enabled through the PHP Settings section of the Control Panel. Information is available in our PHP Version article. If you are already running FastCGI, information on how to transition to FPM with OPcache is available in our Transitioning from FastCGI to FPM article.   To properly enable FastCGI+OPcache, in the instructions below, you need to replace: USERNAME with your actual hosting account username (you can find your username listed in the upper left corner of your Control Panel) FastCGI is a way to accelerate frequently accessed pages on the site. FastCGI works in a way that a single process can handle many requests before being terminated. This reduces the overhead of starting a new PHP process every time there is a new page request. It also allows OPcache to work - it caches precompiled script bytecode, thus PHP does not need to compile bytecode again and again of the same PHP scripts. FastCGI with OPcache is the fastest solution for processing a lot of requests and boosting your website's overall performance. For accounts with FastCGI support, you can enable the technology for your main website (www.domain.com) in three simple steps: Step 1) Create the /home/USERNAME/www/www/.ht-fcgi-php-wrapper file through the "File Manager" section in your hosting Control Panel. Please make sure the file has executable permissions (we recommend that you set its permissions to 775). The file should contain the following code: #!/bin/bash# memory limit in kbytesulimit -v 573440# do not lower this limit or you may start getting sporadic 500 server errorsexport PHP_FCGI_MAX_REQUESTS=10000# disable PHP child process managementexport PHP_FCGI_CHILDREN=0exec /usr/local/bin/php74.cgi -c /home/USERNAME/www/www/php.ini Note: If the /home/USERNAME/www/www/php.ini file does not exist, you should create it using the hosting Control Panel -> "File Manager" section and add the default content of php.ini files on our servers to it for compatibility reasons. In this first step, it is important to note that you choose the PHP version on which the code will be running by specifying the path to the CGI script (i.e. php74.cgi). This is done in the last line of the above-mentioned piece of code. You can choose from the following options, depending on the preferred PHP version: PHP 8.2: exec /usr/local/bin/php82.cgi -c /home/USERNAME/www/www/php.ini PHP 8.1 (recommended): exec /usr/local/bin/php81.cgi -c /home/USERNAME/www/www/php.ini PHP 8.0: exec /usr/local/bin/php80.cgi -c /home/USERNAME/www/www/php.ini PHP 7.4: exec /usr/local/bin/php74.cgi -c /home/USERNAME/www/www/php.ini PHP 7.3 (obsolete): exec /usr/local/bin/php73.cgi -c /home/USERNAME/www/www/php.ini PHP 7.2 (obsolete): exec /usr/local/bin/php72.cgi -c /home/USERNAME/www/www/php.ini PHP 7.1 (obsolete): exec /usr/local/bin/php71.cgi -c /home/USERNAME/www/www/php.ini PHP 5.6 (obsolete): exec /usr/local/bin/php56.cgi -c /home/USERNAME/www/www/php.ini PHP 5.3 (obsolete): exec /usr/local/bin/php53.cgi -c /home/USERNAME/www/www/php.ini Note: Make sure to replace USERNAME with your hosting account username, which is listed under the information panel in the upper left corner of your hosting Control Panel. Step 2) Create an /home/USERNAME/www/www/.htaccess file and add the following code to it, or add the code to your existing .htaccess file: <IfModule mod_fcgid.c><FilesMatch "\.php$">AddHandler fcgid-script .phpFcgidWrapper /home/USERNAME/www/www/.ht-fcgi-php-wrapper .php</FilesMatch></IfModule> Note: Make sure to replace USERNAME with your hosting account username, which is listed under the information panel in the upper left corner of your hosting Control Panel. Also, check your .htaccess file for other AddHandler directives and comment/delete them. Step 3) Enable OPcache by adding the following piece of code to the main php.ini file for your website via the "PHP Settings" section in your hosting Control Panel: ;Enabling OPcache[opcache]zend_extension = opcache.soopcache.enable = 1opcache.memory_consumption = 128opcache.max_accelerated_files = 10000opcache.revalidate_freq = 60   Note: If you want to enable FastCGI for a subdomain (example.domain.com), you need to create the /home/USERNAME/www/example/.ht-fcgi-php-wrapper file, update the last line in it to use the subdomain's php.ini file (e.g. /home/USERNAME/www/example/php.ini), and create or edit the file /home/USERNAME/www/example/.htaccess. The path to .ht-fcgi-php-wrapper specified in your .htaccess file should also be correct. In case you are experiencing any difficulties with FastCGI, you can contact our support team for assistance.

General information about FastCGI and PHP-FPM What are you missing if you use FastCGI instead of FPM? FastCGI deprecation How to transition from FastCGI to FPM General information about FastCGI and PHP-FPM FastCGI FastCGI for PHP is a significant update of the traditional CGI PHP execution mechanism, and it was introduced on our VPS plans back in 2016. Unlike traditional CGI, the FastCGI execution mechanism allows a single process to handle many requests before being terminated. Reducing the overhead of starting a new PHP process with each new request to the web server brings significant speed improvement and lower resource usage. Due to its improved technology, FastCGI improves website loading times and allows more requests to be handled at once. It also supports OPcache - a caching system that further improves PHP performance by keeping pre-compiled script bytecode in the server memory, thus bringing additional speed and resource-usage optimization. PHP-FPM FPM (FastCGI Process Manager) is a newer version of the FastCGI implementation, bringing further improvements to FastCGI, specifically for heavily-loaded sites. PHP-FPM is one of the most efficient and stable technologies for running PHP, and it's currently supported on all our servers - shared hosting servers and VPS. As PHP-FPM uses the FastCGI protocol, it has all the benefits of the FastCGI PHP execution mechanism, but it also maintains the FastCGI workers which handle PHP requests. This results in even faster execution of PHP scripts. If necessary, PHP-FPM will spawn additional workers to handle all incoming requests on time. PHP-FPM comes paired with OPcache by default and uses OPcache resources more efficiently than FastCGI, as the OPcache pool is shared among PHP-FPM child processes. What are you missing if you use FastCGI instead of FPM? Here are some of the benefits that FPM has over FastCGI: FPM processes requests faster (more than 30%) compared to FastCGI, which also allows it to process more than 30% more requests at a time than FastCGI. FPM helps improve visitor experience and search engine ranking due to its 5+ times shorter TTFB (Time To First Byte). This is possible mostly due to the workers being maintained by FPM, while FastCGI has to spawn a new worker if there are no currently active/available workers. FPM is supported on all our servers, while FastCGI can be enabled only on certain VPS plans. FastCGI can be enabled only manually, while FPM can be enabled with a single click via the Control Panel's PHP Settings section. OPcache is enabled by default for FPM; for FastCGI, it has to be enabled manually. FPM has better support and is tested more thoroughly by the PHP project. FastCGI deprecation Since there are no drawbacks of the FPM implementation on our servers compared to the FastCGI implementation, we will gradually stop supporting FastCGI. For this reason, we advise switching to FPM as soon as possible. Transitioning from FastCGI to FPM Switching from CGI/FastCGI to FPM on our servers is very simple. All you need to do is change the PHP handler for the specific domain/subdomain from CGI to FPM with OPcache via the Control Panel > PHP Settings section. More information on how you can change the PHP handler is available in the PHP version and handler article. Although this is optional, we would encourage you to revert the steps taken to enable FastCGI in the first place (as outlined in our Using FastCGI + OPcache article) by removing: the <IfModule mod_fcgid.c> code block from your website's .htaccess file; the .ht-fcgi-php-wrapper file from your website folder; the [opcache] code block from the main php.ini file for your website. Important: The FPM execution mechanism has proven to work correctly with a plethora of web applications; however, we would recommend that your check your website thoroughly for issues after switching the PHP execution mechanism for your website from FastCGI to FPM, as a specific web application or script may be incompatible with FPM. In such a case, please change the PHP execution mechanism for the website to CGI. If you encounter any problems or need any assistance with the transition from FastCGI to FPM, feel free to contact our support team.

Mod_security2 is an Apache2 module which blocks requests to the web server based on a list of server-side rules, also known as a Web Application Firewall (WAF). Rules include blocks against common server attacks, and they filter requests to vulnerable software. This additional security feature is activated by default on our servers in order to provide maximum protection from hacker attacks for the websites of our customers. However, it is possible for certain legitimate requests/scripts to match a rule and be blocked. When this happens, the error message returned by the server is 412 Request Blocked (Precondition failed). You can disable certain blocking rules, or completely disable mod_security2, by using an .htaccess file. Disabling mod_security2 for XML-RPC files The XML-RPC protocol is used by some WordPress modules to communicate with external resources, most notably - the Jetpack plugin and the official WordPress mobile apps. All Jetpack IP addresses are whitelisted on our servers, so you do not need to disable mod_security2 to use the Jetpack plugin. To read more on how to allow access to this file through the WordPress Manager in the Control Panel, please check our Enabling access to XML-RPC article.If your website is using an xmlrpc.php file, but it is not WordPress-based, you can still disable mod_security2 for it with an .htaccess file – it should contain the following piece of code:<IfModule security2_module>SecRuleRemoveById 114</IfModule>The .htaccess file can be easily created using the File Manager in the hosting Control Panel. The settings in this file apply to the directory in which it is located and recursively to its subdirectories. Finding which mod_security2 rule triggers error 412 If you encounter an error 412 when browsing a specific page, you can easily find which mod_security2 rule triggers the error by inspecting the server error logs for your website. Here is how to do this: Navigate to the hosting Control Panel > Logs section > Live HTTP logs subsection. Allow about a minute for the Live HTTP logs subsection to start displaying the logs in near real time. Open the page of your website where you get the 412 error. Check the Error log screen from the Live HTTP logs subsection, where you should find an entry like this one:example.com [Fri Aug 13 14:46:30 2021] [error] [pid 9179] apache2_util.c(273): [client YOUR_IP_ADDRESS:59893] [client YOUR_IP_ADDRESS] ModSecurity: Access denied with code 412 (phase 2). Match of "ipMatchFromFile /apache/conf/includes/mod-security-jetpack-ip-whitelist.txt" against "REMOTE_ADDR" required. [file "/apache/conf/includes/mod_security2.conf"] [line "42"] [id "114"] [hostname "example.com"] [uri "/xmlrpc.php"] [unique_id "YRZblp0P33pV7fcztwccfAAAAQE"] The exact mod_security2 rule and file that trigger the error will be listed in the id and uri fields in the error message. The Match part of the mod_security2 message will contain more information about the triggered security rule. In the given example, access to the xmlrpc.php file was blocked by the mod_security2 rule with id 114 as access to the file is allowed only from JetPack IP addresses. Disabling a specific rule By default, a number of abusive bots are blocked from visiting customer websites with specific mod_security2 rules. These are the currently blocked bots, as well as their mod_security2 IDs: "Havij" id:350 "^BOT/0.1" id:354 "^Mozilla\/4\.0 \(compatible; MSIE 6\.0; Windows NT 5\.1;?( SV1)?;?\)$" id:373 "^Mozilla\/3\.0 \(compatible; Indy Library\)$" id:392 "sqlmap" id:398 "DatabaseDriverMysql" "id:401" "BUbiNG" id:406 "MauiBot" id:407 "MJ12bot" id:408 "BLEXBot" id:409 "DotBot" id:410"MegaIndex" id:412 If you need to allow any of the above bots to access your website, you can disable the specific mod_security2 rule with an .htaccess file in the main folder of your website. Just use the SecRuleRemoveById directive followed by the ID of the specific rule. For example, to allow access to your website from the DotBot bot (which is blocked in mod_security2 with rule ID 410), you should add this code to your website's .htaccess file: <IfModule security2_module>SecRuleRemoveById 410</IfModule> Disabling mod_security2 altogether Completely disabling the mod_security2 module would decrease the security of your website considerably, so we strongly advise against doing that. Instead, follow the steps above to check the logs and find which mod_security2 rule blocks the execution of your script, then disable the specific rule. If you are certain about disabling the mod_security2 module, you can create an .htaccess file (or edit the existing one) in the directory where you want to disable it. The file should contain the following piece of code:<IfModule security2_module>SecRuleEngine OffSecRequestBodyAccess Off</IfModule>

Default IP address Third-party DNS services IP address changes on the server Default IP address The primary IP address of the hosting server is displayed on the left pane of the hosting Control Panel, section IP addresses: The primary server IP address is used: for outgoing email. As such, if you are using our email server for outgoing email, then any SPF records for the domain should include the primary server IP address as well. for outgoing connections from the server. If you are using software on your account to connect to remote services, and these services are restricted by IP address, you might have to whitelist it. if your account does not have any additional IP addresses assigned, then your domain's A records will be pointed to this IP address. In some cases, your account may have additional IP addresses assigned to it - for example, if you have purchased a dedicated IP address for an SSL installation. The account IP address is the (default) IP address to which your domain names should resolve to. That's why, DNS records for the domains on the account should be pointed to this IP address. If the domain is using our DNS service, then its DNS records are controlled from the DNS Manager in the hosting Control Panel. If more than one IP address is assigned to your account (eg. for multiple SSL installations), one of the IP addresses will be marked as "default". This is the IP address to which all DNS records will be pointed to, in case you use the option "Restore default configuration" on the DNS Manager page. Third-party DNS services If your domain is using a DNS service not maintained by us, you should remember: your domain should be pointed to the default account IP address, if such is assigned. If not, it should point to the primary server IP address. if your domain has an SPF record, and our server is used for outgoing email, then the SPF record should include the primary server IP address. IP address changes on the server Although the IP addresses on the server are static, it is possible IP addresses to change from time to time. The usual procedure to change an IP address on the server would be: we will assign new IP addresses, that will work along with the old IP addresses. Thus, no service will be disrupted. аn information box will appear at the DNS Manager and System Information sections of the Control Panel, listing the IP addresses that are going to be changed. we will notify our customers about the IP changes and will give them enough time to start using the new IP addresses, if they access some services by IP address. If a domain is using a foreign DNS service (not ours), the customer will have to update the IP addresses in the remote DNS service. we will announce the dates on which old IP addresses will stop working. Customers should have started using the new IP addresses prior to that date. In case your domains are using our DNS servers, and you are not using an IP address in a program/connection setting, then such IP address changes will be completely transparent to you, and there are no actions you need to take.

The icons folder is predefined by the Apache web server. Any content you store in it will not be accessible in a web browser, as the web server will open up its default icons folder instead. You will be able to reach the files stored in your icons folder only via FTP.

In order to maintain the stability and performance of the servers, there is a limit on the maximum concurrent processes a hosting account can run. If a hosting account reaches its process limit and then tries to start a new process, the following message will be displayed on the website:The page will reload automatically every 10 seconds in an attempt to start a new process.To prevent such messages, you should optimize your applications and scripts so their execution time is reduced as much as possible.

In case you wish to track or log POST requests handled by the Apache web server, you can do that on our servers with the help of mod_security. All you need is a log file and specific content in an .htaccess file. More details on this method is available on this website. To enable the logging of POST requests on our servers, follow these steps: Create a log file in your website's directory. For a WordPress installation, you can create the file in the wp-content folder (e.g. ~/www/www/wp-content/post.log) using this SSH command:touch "/home/$USER/www/www/wp-content/post.log" Set the permissions of the file to 777:chmod 777 "/home/$USER/www/www/wp-content/post.log"Important: If you do not set the file permissions to 777, your website will return an internal server (500) error. Add the following content to your website's .htaccess file (e.g. ~/www/www/.htaccess) with the following SSH command:echo -e "\nSecAuditEngine On\nSecRequestBodyAccess On\nSecAuditLogParts ABCIJDEFHZ\nSecRule REQUEST_METHOD "POST" \"id:17,phase:2,t:none,pass,log,auditlog,msg:'Log POST data'\"\nSecAuditLog /home/$USER/www/www/wp-content/post.log" >> "/home/$USER/www/www/.htaccess"Alternatively, you can use the hosting Control Panel > File Manager section to add the following code manually to your website's .htaccess file:SecAuditEngine OnSecRequestBodyAccess OnSecAuditLogParts ABCIJDEFHZSecRule REQUEST_METHOD "POST" "id:17,phase:2,t:none,pass,log,auditlog,msg:'Log POST data'"SecAuditLog /home/$USER/www/www/wp-content/post.logNote: With the File Manager method, you need to make sure you replace $USER with your hosting account's username. POST requests may contain sensitive or confidential information, and the log file where the requests will be stored will now be public. You can restrict public access to the log file by running the following SSH command:echo -e "\nRedirectMatch 403 ^/wp-content/post.log$" >> "/home/$USER/www/www/.htaccess"The command will add the following line of code to your website's .htaccess file, which will redirect visitors of the /wp-content/uploads/post.log file on your website to a 403 error page:RedirectMatch 403 ^/wp-content/post.log$ That is it. All POST requests of the website will now be stored in the log file you created.