htaccess on NGINX, a performance issue on high traffic sites. Why you should use NGINX. - ­čĆć Managed Server


August 30 2019

htaccess on NGINX, a performance issue on high traffic sites. Why you should use NGINX.

The alternative to Apache for performing sites.

There are situations such as those of high traffic sites (sites with millions of visitors per day to be clear) in which the ideal recipe is sought at a technological and systemic level in order to offer maximum performance at the lowest possible computational cost. If we look at all the projects of high traffic sites based on open source technologies (and therefore not Microsoft's .net for example) we will find that we will have as the only constant and denominator a webserver we talked about in this article: Nginx.

Among the countless PRO NGINX also has an apparent "against", namely that of not have htaccess support such as the more well-known Apache Web Server.

What is htaccess?

The .htaccess file (Hypertext Access) is a configuration file through which you can change the settings of a specific directory (that is, of a specific folder). By specific directory, in this context, we mean that all the settings chosen for that specific directory also apply to all subdirectories (or subfolders). An .htaccess file can only be used with compatible NCSA servers, such as Apache servers that support modules like mod_rewrite. This type of file is an integral part of the server configurations and any changes to it are automatically reflected on the site.

NGINX does not support htaccess


Someone mistakenly believes that the reason is in a position taken by the developer related to the "laziness" of implementing a feature that is certainly convenient on Apache.

But as we have learned from the world of Formula 1 and speed in general, if we want to run fast and be competitive we must make some sacrifices in order to lighten the weight of the vehicle or the webserver.

In this case precisely the lack of htaccess support is not a defect, but rather a feature. Or more specifically one of those rare cases in which not having something is not a defect but a virtue.

If you want to use .htaccess at all costs, you are probably wrong and you shouldn't.


This is a very good question. To begin with, to get .htaccess to work Apache must check EVERY directory in the path required for an .htaccess file to exist and, if it exists, it reads EVERY one and analyzes it. This happens for EVERY request. In fact, remember that when you change that single file, the change goes immediately without having to restart the web server, precisely because Apache reads it every time.


Let's say we are not making any aliases and the file system is the path. This case is a common scenario with most of the sites out there.

There is the / directory, so site /, files /, images / and layout /. This is equivalent to 5 directories that might have an .htaccess file. Let's say you have added an .htaccess in /, files / and images /. There are three .htaccess files. It is quite typical.

Now the numbers, which is 6 file system stat and 4 file system read. Including one for the requested file. This happens for every reading. We will ignore the parsing time because both NGINX and Apache have to do this and we will consider the time difference for this to be negligible.

Requests / Hour NGINX stats NGINX FS readings Apache stat Apache FS readings Comment
1 1 1 6 4 Single request [practically no load]
10 10 10 60 40 Ten requests [practically no load]
3.600 3.600 3.600 21.600 14.400 1 req / sec [very low load]
144.000 144.000 144.000 864.000 576.000 40 req / sec [Moderate traffic - nothing very big]
324.000 324.000 324.000 1,944,00 1.296.000 90 req / sec [Higher traffic site - not massive]
576.000 576.000 576.000 3.456.000 2.304.000 160 req / sec [Rather high traffic, although not yet massive]


Even more numbers and slowness

The default for Apache is to use AllowOverride All. Let's take a look at this for a Drupal website. An image for the theme. If your DocRoot website is on, /var/www/drupal6/we just added more file system statistics. This adds 3 stats per request. This is an incredibly common Apache / Drupal installation. It is the end result of countless guides out there.


Two .htaccess files will be in this path unless you create them. I assume you have added one in / var / www / because this is common.

Requests / Hour NGINX stats NGINX FS readings Stats Apache FD Apache FS readings Comment
144.000 144.000 144.000 1.296.000 576.000 40 reqs/sec
324.000 324.000 324.000 2.916.000 1.296.000 90 reqs/sec
576.000 576.000 576.000 51.840.000 2.304.000 160 reqs/sec

Interpretation of the data

To be very straightforward without too many words and diplomacy, Apache at worst does 100 times I / O accesses compared to NGINX, at best the example above does 10 times as many.

And we wanted to propose a common case that is not too optimal or bad, but let's think of those nested directories that go deep for 20 or 30 nodes. Do you have any idea what it becomes? Apache does 1000 more operations than NGINX single one. Much too much for even the most hardcore Apache and htaccess support fanboy.

Practical performance feedback

Real performance feedback implies that there will be really important disk I / O when we have a very busy site and a lot of requests per second. Imagine you bought the latest 1Gbit / s nVME SSD solid state drive to guarantee performance and I / O throughtput on your high-performance WordPress server and then go and put Apache there. In some cases you will degrade performance and I / O so much even at the kernel level that you will get the same performance as a mechanical SATA HDD.

Apache is therefore good for classic sites but not for high performance sites.

Are you from Apache do you want to migrate to NGINX but do you necessarily need htaccess?

One of the reasons why you are not reluctant to convert to NGINX is the habit with which you have grown professionally to use Apache provided by default on panels like cPAnel or Plesk. If you are born, grow up with a technology, it is normal and peaceful to die even with the exact same technology. It takes a bit of curiosity and self-criticism to question some false beliefs and try to do better by using a technological solution that is still mounted on most high-traffic sites.

The main problem is to keep using .htaccess on a system that doesn't actually support .htaccess. Concept that if read quickly makes you want to close the page and continue with the good old Apache, but wait maybe we didn't understand there is more you should know and that you will surely like.

Not reading htaccess doesn't mean you can't use rewrite rules

We have written so far that NGINX does not read htaccess files but not that he can't take advantage of the rewrite features. htaccess is a proprietary format used essentially only by Apache and therefore to say that NGINX does not read htaccess is a bit like saying that NGINX does not read a proprietary format of Apache but not that it can have the same functionality in its own way, according to its own rules. better than htaccess.

The only problem is trying to understand how you can convert a project from APACHE htaccess to NGINX rewrite.

Rewrite Rules on NGINX

NGINX as we said supports the rewrite rules in its own way. It does so according to its own syntax completely different from that of htaccess, it does so according to its philosophy which is to match the rules when the webserver starts and only at that moment. Therefore, the rewrite rules unlike Apache will be written in the virtual host configuration and will be valid for the entire duration of the webserver. There is no possibility to create an .htaccess file (or any NGINX equivalent) and have it digested by the webserver without restarting the service.

On NGINX if you want to insert a new rewrite rule such as a trivial 301 redirect from an old deleted page to a new one, you have to edit the configuration file of the vhost in question such as sitename.conf add the rewrite rule and then reload and restart the webserver according to the syntax service nginx reload or service nginx restart to reload the new rule inserted and make it work correctly.

Commercial and organizational problems

One of the important problems of NGINX's lack of diffusion as well as the lack of .htaccess support is the fact that to write new rewrite rules in the vhost you must necessarily go to the vhost and restart the webserver. Both operations require superuser privileges or root. In a shared hosting environment where the average user is not a system engineer, putting his hand to these tasks would have been completely impossible, thus undermining the sale of low cost hosting services or for the average user.

Only lately some control panels like Plesk and cPanel have implemented through the usual point and click interface the possibility to choose which webserver to use between NGINX and Apache (and also a mix of the two solutions via reverse proxy) but despite this many webmasters, developers and SEOs continue hard to use the same old Apache.


Convert htaccess to NGINX

We could do the phenomena and say that basically converting an .htaccess to NGINX is not very complex as the syntax itself is quite simple (in our opinion even easier than the native htaccess one), but then what we will tell you when you need to convert those 500 rewrite lines from htaccess to NGINX? 3 or 4 days to convert all the rules? No thanks.

There are faster and more immediate solutions made available by companies that have decided to make publicly available online converters that allow you to convert the rewrite rules from htaccess to NGINX.

Unfortunately, since there is nothing official and effective, most tend to produce rules that either don't work or work but approach with wrong syntax.

However, the best in circulation that allows in 99% of cases to convert medium-complex rules (such as rewrite 301 and the like) is the one you find at this link

It is in fact as the name implies a htaccess converter which allows you to convert htaccess to NGINX rules. Here is for example a real use of tonight which served us to bring a new customer site from Apache to NGINX for performance reasons.

htaccess convert nginx

Going to paste the .htaccess rules in the htaccess section and pressing the "convert" button we will return the respective NGINX syntax that we will copy and paste in the NGINX virtual host configuration and then restart the webserver to test the correctness.


If you have sites of the butcher or pizzeria under your house with a few visits a month go well with Apache and .htaccess, if you manage sites with high traffic and high performance use NGINX as do all sites with very high traffic.

We use NGINX and leave Apache to amateurs.



Do you have doubts? Don't know where to start? Contact us!

We have all the answers to your questions to help you make the right choice.

Chat with us

Chat directly with our presales support.


Contact us by phone during office hours 9:30 - 19:30

Contact us online

Open a request directly in the contact area.


Managed Server Srl is a leading Italian player in providing advanced GNU/Linux system solutions oriented towards high performance. With a low-cost and predictable subscription model, we ensure that our customers have access to advanced technologies in hosting, dedicated servers and cloud services. In addition to this, we offer systems consultancy on Linux systems and specialized maintenance in DBMS, IT Security, Cloud and much more. We stand out for our expertise in hosting leading Open Source CMS such as WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart and Magento, supported by a high-level support and consultancy service suitable for Public Administration, SMEs and any size.

Red Hat, Inc. owns the rights to Red Hat┬«, RHEL┬«, RedHat Linux┬«, and CentOS┬«; AlmaLinuxÔäó is a trademark of AlmaLinux OS Foundation; Rocky Linux┬« is a registered trademark of the Rocky Linux Foundation; SUSE┬« is a registered trademark of SUSE LLC; Canonical Ltd. owns the rights to Ubuntu┬«; Software in the Public Interest, Inc. holds the rights to Debian┬«; Linus Torvalds holds the rights to Linux┬«; FreeBSD┬« is a registered trademark of The FreeBSD Foundation; NetBSD┬« is a registered trademark of The NetBSD Foundation; OpenBSD┬« is a registered trademark of Theo de Raadt. Oracle Corporation owns the rights to Oracle┬«, MySQL┬«, and MyRocks┬«; Percona┬« is a registered trademark of Percona LLC; MariaDB┬« is a registered trademark of MariaDB Corporation Ab; REDIS┬« is a registered trademark of Redis Labs Ltd. F5 Networks, Inc. owns the rights to NGINX┬« and NGINX Plus┬«; Varnish┬« is a registered trademark of Varnish Software AB. Adobe Inc. holds the rights to Magento┬«; PrestaShop┬« is a registered trademark of PrestaShop SA; OpenCart┬« is a registered trademark of OpenCart Limited. Automattic Inc. owns the rights to WordPress┬«, WooCommerce┬«, and JetPack┬«; Open Source Matters, Inc. owns the rights to Joomla┬«; Dries Buytaert holds the rights to Drupal┬«. Amazon Web Services, Inc. holds the rights to AWS┬«; Google LLC holds the rights to Google CloudÔäó and ChromeÔäó; Microsoft Corporation holds the rights to Microsoft┬«, Azure┬«, and Internet Explorer┬«; Mozilla Foundation owns the rights to Firefox┬«. Apache┬« is a registered trademark of The Apache Software Foundation; PHP┬« is a registered trademark of the PHP Group. CloudFlare┬« is a registered trademark of Cloudflare, Inc.; NETSCOUT┬« is a registered trademark of NETSCOUT Systems Inc.; ElasticSearch┬«, LogStash┬«, and Kibana┬« are registered trademarks of Elastic NV Hetzner Online GmbH owns the rights to Hetzner┬«; OVHcloud is a registered trademark of OVH Groupe SAS; cPanel┬«, LLC owns the rights to cPanel┬«; Plesk┬« is a registered trademark of Plesk International GmbH; Facebook, Inc. owns the rights to Facebook┬«. This site is not affiliated, sponsored or otherwise associated with any of the entities mentioned above and does not represent any of these entities in any way. All rights to the brands and product names mentioned are the property of their respective copyright holders. Any other trademarks mentioned belong to their registrants. MANAGED SERVER┬« is a trademark registered at European level by MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italy.


Would you like to see how your WooCommerce runs on our systems without having to migrate anything? 

Enter the address of your WooCommerce site and you will get a navigable demonstration, without having to do absolutely anything and completely free.

No thanks, my customers prefer the slow site.
Back to top