The topic of .htaccess is an advanced one. The .htaccess file can alter the entire server configuration and minor typos can bring down your whole website. Do not change the .htaccess file unless you know what you are doing. Our servers are running Apache 2.4.x. You can read the full .htaccess documentation here.
Our default server configuration provides a solid setup that is tuned for scalability and performance.
.htaccess file for WordPress
If you are running a WordPress site, then make sure that you add a .htaccess file as well. See the standard WordPress .htaccess documentation here.
The .htaccess is a distributed configuration file, and is how Apache handles configuration changes on a per-directory basis. WordPress uses this file to manipulate how Apache serves files from its root directory, and subdirectories thereof. Most notably, WP modifies this file to be able to handle pretty permalinks.
Bad Advice
Many plugins, modules, and even default .htaccess shipped with applications provide bad advice on how to configure your server. For example, using Magento 1.9’s default .htaccess file will slow down your shop significantly on our servers.
Bad Advice 2 – PHP Memory Limit
You should always keep the PHP Memory Limit as small as possible, 128M will do for most applications 256M should be sufficient for anyone. Many developers trade scalability for convenience by setting the PHP memory limit to 512M or even 1G, which is a very bad idea. Maxing the PHP Memory Limit to make the application work is the simplest way to limit or completely unable scalability of your web application.
Keep .htaccess lightweight
Because the .htaccess file is loaded, parsed and executed on every page load, a large .htaccess file will actually slow down your website. A common example is redirects from outdated URLs. It is OK to use .htaccess for this if you have a few of them, but if you have dozens of redirects you may be better off by leaving the job to your database and web application.
Important stuff to know – Reverse Proxy
Our servers run nginx as the front-end webserver and Apache as the backend servers. Because Apache is behind a reverse proxy, some directives need other specifications than if you were running directly from Apache.
Testing if HTTPS is enabled
This won’t work because Apache is behind the reverse proxy:
RewriteCond %{HTTPS} !^on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]The correct way to do this is:
RewriteCond %{REQUEST_URI} !/\.well\-known/?.*
RewriteCond %{HTTP:X-Forwarded-Proto} !=https
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R,L]Block specific IP
You can add the following to block a specific IP from accessing your website:
<RequireAll>
Require all granted
Require not ip 192.168.0.1
</RequireAll>