Editorial 1462209280nginxserver.png

Published on May 2nd, 2016 | by Sunit Nandi


Standalone Nginx servers and WordPress – you decide?


I have been blogging at Techno FAQ for the past 3 years, but you might have noticed that most of my articles revolve around reviews, apps or hardware. In my work life, however, I’m a student and a freelancing consultant for servers, Linux administration and web development. So, as a change to my usual style of writing, I’ll focus on what I know and do best in everyday life, that is, web servers.

So today, in the midst of performing plugin updates, I noticed that the developers (Red Sand Media Group) of RS Feedburner plugin for WordPress has a cool blog. As I’m pretty much always interested in reading stuff, I started scrolling through their blog. One of the articles titled “Standalone Nginx Servers and WordPress Don’t Mix” by Scott Allen caught my eye. I read the article fully and found several discrepancies that I think I should point out to the Internet community. Before I proceed to expressing my thoughts, I’d suggest you to go through their article first by clicking here. After you read and return here, you’ll have sufficient background of the topic and will understand better what I’m referring to.

While the article does serve to clearly drive in the fact that Nginx is not a drop-in replacement for Apache, the failed logic and fear-mongering it uses throughout the entire article is appalling. I do understand you’re trying to educate the public, Mr. Allen, but trying to bust a myth with more misinformation is not a noble job, my man.

The Rebuttal

In my classical debate style, I’d like to point out where the discrepancies in the article are quote by quote.

Quote: “Nginx as a standalone server is not ready for primetime. That may sound harsh, but it is absolutely the truth. It is especially true when it comes to self-hosted WordPress sites. However, using an Apache/Nginx hybrid setup — with Nginx as a reverse proxy in front of Apache — has the speed benefits and allows all the functionality of Apache. (In real-world applications, this setup is actually faster than either standalone Nginx or standalone Apache servers.)

We don’t recommend standalone Nginx server setups for WordPress…in fact, we highly discourage it! Instead, we recommend the Apache/Nginx hybrid setup: Apache as the actual server that runs everything, with Nginx in front of it as a reverse proxy/cache/load balancer. (This has incredible performance…and things work perfectly. Perfectly.)”

Rebuttal: I don’t really believe in your claims unless you back it up with proper data. If only you had made a test site with proper server response time tests, and made the configurations public, I’d be more than happy to accept what you claim after verifying it myself. I have run Techno FAQ on standalone Apache, Apache + Varnish, Apache + Nginx as proxy, and standalone Nginx and in my personal tests, standalone Nginx is the winner in CPU load, RAM usage and response time. Whereas in the past, I had to shell around $30 for a VPS for a site of this traffic, today it runs smoothly on a $10 instance with standalone Nginx. I am saving a lot for the past few months and my traffic has doubled as well.

Quote:Having pure Nginx disables the ability to use .htaccess files, which are required by many WordPress plugins, including WordPress itself. If you’re not familiar, .htaccess is a very important configuration file used on Apache servers. Nginx claims that allowing .htaccess files in subdirectories is a resource hog, but this simply doesn’t line up with the results of true performance tests because it is offset by other factors.
Considering that WordPress powers 26%+ of the web, we don’t consider standalone Nginx a practical server config for any kind of open source or commercial web software. (You won’t be able to use any of the WordPress caching plugins, security plugins, or minification plugins.) However, the Apache/Nginx hybrid setup is awesome and overcomes all of the potential issues. If Nginx would allow .htaccess, it would be great. The advertised speed improvements of Nginx over Apache have been greatly reduced in recent years, and with a hybrid setup, it’s nonexistent, and you get the best of both worlds.”

Rebuttal: Granted Nginx doesn’t support .htaccess and isn’t an exact replacement for Apache but it doesn’t make it any less of a webserver by itself. There are good configs for WordPress and plugins available for use with Nginx and they work perfectly. If Nginx isn’t supported by a plugin, then it isn’t Nginx developers’ fault, clear and simple. Its just the reluctance or stepmotherly attitude of plugin developers that Nginx is treated as a second grade citizen in the WordPress world. If your plugin can generate and place .htaccess files, they can also be coded to generate Nginx configs. No big deal. I’ll discuss on how to deploy shared Nginx configs from plugins later. Also, this is the third time you’re emphasizing the hybrid setup, which I feel is unnecessary.

Quote: “Be cautious of web hosts that advertise “WordPress Optimized Hosting” on “Nginx”. Make sure that it is the Apache/Nginx hybrid, not standalone Nginx. If it’s on standalone Nginx, then it’s a sham…steer clear of that web host because they clearly do not know what they are doing. Good web hosts know how to do it right, and set things up with Nginx as a reverse proxy in front of Apache.

Recently, I received a support request from a small website hosting company that offered just such a thing. They advertise “WordPress Optimized Hosting”…on standalone Nginx. I wanted to slap myself. They couldn’t understand why their customers were having so many issues. I had to spend some time educating the owner on what they are doing wrong, and exactly what kind of effects this will have on WordPress and plugins. Ugh. Don’t buy into the marketing hype, folks! Nginx is not a magic bullet for speed. (It’s actually quite the opposite.)

Rebuttal: Granted Nginx doesn’t make a good webserver because of centralized config system and lack of .htaccess, but that makes sense for the case of shared hosting only, running cPanel, Plesk or whatever. For WordPress optimized hosting, Nginx does the job fine. Your idea reverse proxy isn’t the only correct way of implementing it. And again, since Nginx is not Apache, do not expect that it will magically solve everything like a traditional configuration. Those who run Nginx as a hosting platform should know the ins-and-outs of the webserver, otherwise they simply shouldn’t use it. Instead of putting a blanket blame on Nginx, its better that the owner should be educated about how Nginx works instead of making him buy your reverse proxy idea that you preach over and over again.

Quote: “And that’s where they are missing the big picture: .htaccess provides a LOT more functionality than redirection/rewrites.

.htaccess provides a mechanism for:

  • Complex security directives – Protecting any specified combination of files, directories, etc.
  • Caching directives – Server-side(server caching), surrogate(proxy caching) and client-side(browser caching) such as setting/modifying expiration dates, setting far-future cache headers, setting/removing Etags, etc.
  • SEO directives – Rewriting and redirection that overrides server defaults, blocking and allowing certain files, adding/removing X-Robots tags, and much more.

These are all things that need to be done at a directory level.

Yes, Nginx can provide rewrites and redirection in its configuration at a server level, but it cannot be done at a directory level…so this is not the same at all.

So let’s be very clear, by using a standalone Nginx setup with WordPress, you can actually damage your site in the following areas:

  • Security
  • Speed (“Wait, what? But I thought that Nginx was fast?” Yes, speed! We’ll get to that in a moment.)
  • Search Engine Optimization (SEO)

Rebuttal: So here is where the real fallacy begins. You claim that .htaccess is more magical and has more features than Nginx’s config files.

Complex security directives? “allow” and “deny” are possible in the location block:

server {
 location /wp-admin/ {
 deny all;

You can block bots too 😉

map $http_user_agent $blockedagent {
        default         0;
        ~*malicious     1;
        ~*bot           1;
        ~*backdoor      1;
        ~*crawler       1;
        ~*bandit        1;

Prevent image hotlinking:

location /img/ {
  valid_referers none blocked;
   if ($invalid_referer) {
     return   403;

Even rate-limit access per IP address (click here to read the docs):

location /account/login/ {
 # apply rate limiting
 limit_req zone=login burst=5;

 proxy_pass http://myapp;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header Host $http_host;

I still do not understand what you’re trying to say by saying .htaccess is more powerful. The only thing we know is that while Apache follows XML-style syntax, Nginx uses C-style syntax. Both are equally powerful. Nginx’s compact syntax makes rule-writing and debugging easy. Apart from that I don’t see how .htaccess is syntactically more powerful.

Coming to caching directives, why not look at a part of the nginx.conf file generated by W3 Total Cache?

# BEGIN W3TC Page Cache cache
location ~ /wp-content/cache/page_enhanced.*html$ {
 expires modified 3600s;
 add_header Vary "Accept-Encoding, Cookie";
 add_header Pragma "public";
 add_header Cache-Control "max-age=3600, public";
location ~ /wp-content/cache/page_enhanced.*gzip$ {
 gzip off;
 types {}
 default_type text/html;
 expires modified 3600s;
 add_header Vary "Accept-Encoding, Cookie";
 add_header Pragma "public";
 add_header Cache-Control "max-age=3600, public";
 add_header Content-Encoding gzip;
# END W3TC Page Cache cache
# BEGIN W3TC Browser Cache
gzip on;
gzip_types text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon;
location ~ \.(css|htc|less|js|js2|js3|js4)$ {
 expires 86400s;
 add_header Pragma "public";
 add_header Cache-Control "max-age=86400, public";
location ~ \.(html|htm|rtf|rtx|svg|svgz|txt|xsd|xsl|xml)$ {
 expires 3600s;
 add_header Pragma "public";
 add_header Cache-Control "max-age=3600, public";
location ~ \.(asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|eot|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|json|mdb|mid|midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|otf|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|pptx|ra|ram|svg|svgz|swf|tar|tif|tiff|ttf|ttc|wav|wma|wri|woff|xla|xls|xlsx|xlt|xlw|zip)$ {
 expires 86400s;
 add_header Pragma "public";
 add_header Cache-Control "max-age=86400, public";
# END W3TC Browser Cache

I guess you should read the docs on the headers module.

Talking about SEO directives, I guess you should look up what things Nginx can do. Rewriting, overriding server defaults, blocking/removing header tags is all possible. It just that plugin devs have not given the attention Nginx deserves to get, while Nginx adoption is steadily on the rise.

While I accept that Nginx doesn’t have directory level configs, but there does exist a way it can be made to work with per site custom config with the help of the include statement (read the doc here). So lets say you have a WordPress site on your server with the files placed at /home/dave/wordpress . To implement per-site plugin config, we create a folder named nginxconf. So our Nginx configs reside in /home/dave/wordpress/nginxconf.

After that we can add the following to the server{} block in Nginx:

include /home/dave/wordpress/nginxconf/* ;
location /nginxconf {internal;}

The first line tells Nginx to read config information from the nginxconf directory. The second line tells Nginx not to allow nginxconf directory to be served by HTTP. Any plugin that wishes to change/override the webserver config simply needs to write a file to that directory. Simple! All we need after that is a webserver reload and we’re good to go.

Granted implementing the above in cPanel or any popular shared hosting panel is hard but people who provide custom optimized WordPress hosting can definitely implement it given enough time. Also, plugin developers can rewrite their plugins to take advantage of this method. Everything is possible, but who will bell the cat? W3 Total Cache generates an Nginx config as a nginx.conf file which can be included in the server{} block. Why aren’t other plugin devs not doing the same? And why we can’t all agree on a standard configuration path in Nginx? Simply because no one is f**king interested. This isn’t an Nginx technical issue. Period.

Quote: “Security plugins are unable to make hardening modifications only done by .htaccess, such as adding site-specific directives to protect certain files, or disable PHP execution in your uploads directory. (That’s just one example of many.) Plugins you will not be able to use: WordFence Security, Sucuri Security, iThemes Security, or literally ANY WordPress security plugins. (See below for more.) This means that site owners who are not security experts have to hire a security expert to lock down their site, instead of being able to use off-the-shelf free plugins.

Backup plugins like UpdraftPlus Backup, WP-DBManager and others cannot protect the backup directory by placing an .htaccess file that blocks browser access to your database and website files. An attacker can then download your database and website files (including your wp-config.php which contains the secure database keys for your WordPress site!) and can potentially use the info gleaned to compromise your site. This forces a plugin to consider a backup option such as changing file permissions, but is not as reliable or secure.

  • For this very reason hackers LOVE standalone Nginx servers!!
  • Now you can’t use any of WordPress’ site backup plugins! Good luck if your site gets hacked! Restoring things will be a nightmare.

Because of these quite serious flaws, any Nginx standalone server setup needs to be reviewed by a security expert before launching a WordPress website on it, whereas this is not necessarily the case with an Apache/Nginx hybrid. (Although it is a good idea to have any site reviewed by security expert before launch.)”

Rebuttal: The entire argument you have placed forward has zero logic or backing facts. This is plain fear-mongering in order to drive potential adopters away from Nginx. Instead of convincing users that ‘Nginx is bad. You will face nightmare.’, code your plugins to help Nginx users deploy them. If you cannot decide how to apply the rules automatically, make the plugin show a guide for Nginx users to configure it by themselves. W3TC does it, why can’t the others do the same? Also, see my previous point for site-specific configs.

Here is a sample Nginx config for disabling PHP execution in uploads directory:

# Deny access to any files with a .php extension in the uploads directory
# Works in sub-directory installs and also in multisite network
# Keep logging the requests to parse later (or to pass to firewall utilities such as fail2ban)
location ~* /(?:uploads|files)/.*\.php$ {
	deny all;

Its just a two-line rule for god’s sake (leaving the comments).

Also, you want to block access to wp-config.php?

location /wp-config.php { deny all;}

Get plugin authors to either guide Nginx users interactively with the plugin or install the config to a path specified by an include directive, and we won’t need to worry about any of this anymore.

Also, you don’t need a security expert. You need someone who understands Nginx well.

Quote: “Any speed improvement provided by this only has value in a testing environment, not in real-world website development. A lot of things work in theory, or in a laboratory environment, but don’t work the same way in real-world applications. This is one of them. This small and marginal speed benefit is greatly offset by a number of other flaws that are introduced by not allowing .htaccess files (or similar directory-level config files).”

Rebuttal: Do you have any data to back your claim? And what has speed got to do with .htaccess?

Quote: “One major reason why this wouldn’t improve site load speed is browser caching. If a site is properly set up to serve files that can be cached in a browser, then there is no repeat request sent to the server. Except…and here is the gotcha…with standalone Nginx and WordPress, if there is no .htaccess file, then you can’t properly setup the server for browser caching (because, again, for optimum performance, this type of directive has to be allowed on a directory-level), which will actually result in more requests sent to the server. So, what Nginx developers aren’t telling you is that using a standalone Nginx setup will result in more requests to the server! Ouch.”

Rebuttal: So how is W3 Total Cache working on my site then with browser caching? Here’s the secret sauce. Ouch!

Quote: “.htaccess is a standard and important feature in PHP/Apache web development. Removing features to gain marginal, lab-only speed benefits is not good practice. Sure, we can also make PHP faster by hamstringing some of its key features, but that’s a terrible idea.”

Rebuttal: Your analogy is like saying “Linux is bad because it doesn’t support .exe files, which are essential in running/installing apps in Windows. One shouldn’t dump Windows just to gain speed and reliability benefits.” It only confirms that developers are simply reluctant to try something out of their comfort zone. And again, read up on my previous point of per-site custom config.

Quote: “This specific issue is almost completely negated if the web host is using SSD drives. You will get far more benefit from using a web host with SSD drives, than simply switching to a standalone Nginx setup.”

Rebuttal: SSDs will speed up any application irrespective of what you use, simply because disk seek time is zero. This is not an excuse for bad practice. Its like saying I can write bad code and get away with it ‘cuz my CPU is very powerful.

Quote: “The number of CSS and JS files that are called from a site make a far bigger difference in how fast a site loads.
Plugins that minify and concatenate CSS and JS make a huge difference in website load speed. These require specific browser-caching configuration directives that only .htaccess can provide.
Standalone Nginx servers will not allow these plugins to work.
For all these reasons, you have to hire a website speed optimization expert to do it manually for you. Again, ouch!”

Rebuttal: HOW THE F**K IS W3TC WORKING? Also, what has minification got to do with browser caching? You need HTML Tidy, JSMin and CSS Tidy extensions in your PHP for minification, and concatenation and file path rewriting is done by PHP+libxml output buffering and string replacement. Headers can be passed as a custom Nginx site config. What misinformation are you trying to convey?

Quote: “A standalone Nginx server, by not having ability to use .htaccess files, effectively cripples a high percentage of the top plugins for WordPress. Let’s take a look at some of the top plugins you can’t use effectively on a standalone Nginx server:

  • Speed Optimization plugins:
    • Caching Plugins:
      • WP Super Cache – Rated 4.2 stars / #12 Most Downloaded Plugin
      • W3 Total Cache – Rated 4.3 stars / #15 Most Downloaded Plugin
      • WP Fastest Cache – Rated 4.8 stars / #94 Most Downloaded Plugin
      • WP Rocket
      • All other caching plugins
    • CSS & JS Minification and Concatenation plugins:
      • Autoptimize – Rated 4.7 stars / #103 Most Downloaded Plugin
      • Better WordPress Minify – Rated 4.3 stars
      • RS Head Cleaner Plus – Rated 4.2 stars
      • All other CSS/JS minification plugins
  • Security plugins:
    • WordFence Security – Rated 4.9 stars / #10 Most Downloaded Plugin
    • Sucuri Security – Rated 4.6 stars / #88 Most Downloaded Plugin
    • iThemes Security – Rated 4.7 stars / #25 Most Downloaded Plugin
    • All In One WP Security & Firewall – Rated 4.8 stars / #63 Most Downloaded Plugin
    • Bulletproof Security – Rated 4.7 stars
    • All other security plugins
  • Site backup plugins:
    • Database backup plugins:
      • WP-DBManager – Rated 4.4 stars / #83 Most Downloaded Plugin
      • All others
    • File & Database Backup plugins:
      • UpdraftPlus – Rated 4.9 stars / #27 Most Downloaded Plugin
      • BackWPup – Rated 3.9 stars / #42 Most Downloaded Plugin
      • Backup WordPress – Rated 4.7 stars / #73 Most Downloaded Plugin
      • Most others
  • SEO plugins:
    • All in One SEO Pack – Rated 4.4 stars / #4 Most Downloaded Plugin
    • Yoast SEO – Rated 4.0 stars / #3 Most Downloaded Plugin
    • Google XML Sitemaps – Rated 4.9 Stars / #6 Most Downloaded Plugin
    • All others
  • Anti-spam plugins:
    • Akismet – Rated 4.8 stars / #1 Most Downloaded Plugin, Included with WordPress
    • WP-SpamShield – Rated 4.9 stars / #87 Most Downloaded Plugin, Leading Alternative to Akismet
    • Many others
  • Ecommerce Plugins:
    • WooCommerce – Rated 4.6 stars / #8 Most Downloaded Plugin
    • WP eCommerce – Rated 3.5 stars
    • Easy Digital Downloads – Rated 4.9 stars
    • Most others


WP Super Cache: Works! See WordPress codex.

W3 Total Cache: Works! We use it here at Techno FAQ.

WP Fastest Cache: Works! Read their FAQ.

WP Rocket: Works! See this GitHub repo.

CSS and JS minification apps usually don’t need all that .htaccess magic, except of course RS Head Cleaner Plus, which is your plugin.

Backup plugins don’t need .htaccess magic, except to guard their backup directories (if at all) which can be inserted as a online liner in a server{} block or as a custom site config.

All-in-one SEO pack: Works! We use here at Techno FAQ. Needs no additional config.

Yoast SEO: Works! Here are the rewrite rules.

Google XML sitemaps: Works here at Techno FAQ, use the following config:

rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml$ "/index.php?xml_sitemap=params=$2" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.xml\.gz$ "/index.php?xml_sitemap=params=$2;zip=true" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html$ "/index.php?xml_sitemap=params=$2;html=true" last;
rewrite ^/sitemap(-+([a-zA-Z0-9_-]+))?\.html.gz$ "/index.php?xml_sitemap=params=$2;html=true;zip=true" last;

Akismet: Like are you serious? It works irrespective of webserver.

WordFence: Works! Have a look here.

WP-Spamshield: Oh, that’s your plugin. And I see you try to deter potential Nginx adopters here.

WooCommerce: Doesn’t need extra configuration unless you have a caching plugin. You can put the no-cache rules in the caching plugin, which in turn will generate the nginx config.

I’m not interested in looking up the others. But do you see, your statement is invalid in all respects? A simple search on Google with “<plugin name> nginx” search term will tell you they work on Nginx and how to configure them for the same.

Its 2016, and it seems most popular plugins already support Nginx. However, there are a few devs, including you, who are simply not interested in supporting standalone Nginx installations and standard Nginx directory paths.

Quote: “Take a look at how many of these are in WordPress’ Top 20 plugins…one, two, three…eight! 8 of the top 20 WordPress plugins are handicapped on a standalone Nginx server! That’s 40% of the top 20! And, I didn’t check every plugin in the top 20. I just did a spot check of some of the leading plugins. It’s likely that more of the top 20 would be crippled as well. If you go further and check the code of all the other plugins in the WordPress plugin directory, you will find a ton more. Therefore, using a standalone Nginx server effectively prevents you from using the best and most popular WordPress plugins. These plugins are free, and provide extraordinary functionality for websites. That means that to get the same functionality, you have to hire experts to write code specific to your site, making your website development costs astronomically higher than those using an Apache/Nginx hybrid setup or a standalone Apache server.”

Rebuttal: At this point I think your arguments have no weight. A lot of plugins can run on standalone Nginx.

Quote: “A Server that Cripples the Internet’s Top CMS and its Top Plugins, is NOT a Viable Replacement for Apache. WordPress is undisputedly the top Content Management System (CMS) in use by websites in 2016. It is used by over 60% of all the websites whose CMS we know. The next closest competitor is Joomla with just over 6% of the CMS market share – only a tenth of what WordPress has. This means that WordPress powers over 26% of the web. Think about that for a second…more than 1 in every 4 websites is powered by WordPress. This is why I make the strong point that standalone Nginx is not ready for primetime, and it is not yet a viable substitute for Apache.”

Rebuttal: No, its simply your attitude to change that cripples the Internet’s top CMS. Unless you’ve been living under a rock, you must know that 1/3rd of all websites run Nginx. What makes you think its not ready for primetime?

Quote: “Don’t get me wrong, Nginx is great…when used in an Apache/Nginx hybrid setup. If you set up Nginx as a reverse proxy in front of Apache, you will get better speed benefits than either Nginx or Apache alone, and you have all the functionality of Apache. That’s the winning combo. That’s what we use it, and what we recommend.”

Rebuttal: Finally coming to your hybrid setup, what makes you think it is very workable and secure compared to standalone Nginx? Let me speak about this is detail now.

You can configure your Nginx installation to serve static files directly while proxying dynamic requests to Apache which again references PHP. In this state, the Nginx server will serve static files from the WordPress root. To protect from unauthorized access to sensitive areas, you’d need to configure Nginx in exactly the same away as you’d configure Nginx in standalone mode or else it will leak your wp-config.php and whatnot?

The other way is a caching proxy server in front of Apache for all requests. So Nginx caches all content for a set period of time depending on what headers Apache passes to it. Now my question is, how do you deal with cache invalidation when you change files? Unlike Varnish, Nginx doesn’t have cache purge URLs by default. The Cache Purge option comes as a separate module for Nginx which needs to be added in during compilation. Someone installing Nginx from a Linux distribution’s package repositories won’t get that feature. So unless your sysadmin is skilled enough, he’ll have a hard time dealing with cache management.

All things considered, your winning combo is as difficult or even harder setting up compared to a standalone installation. And Apache is a RAM hog and needs increasing more memory for more number of requests. Makes no sense.

So going by your logic, if we are dealing with Nginx as a reverse proxy, it could be troublesome for an inexperienced user. It makes sense for shared hosts only.

Coming to speed benefits, we have no definite data or study from your side, so I’m having difficulties in believing your bold claims.


Now that I’ve pointed out the discrepancies in the article, I’d like to state that Nginx is equivalent to Apache. Its approach to the task differs with respect to Apache. It has a different syntax, different config style and different architecture, but is no way less powerful than Apache. Its all a matter of preference. The only group who will be affected by the lack of .htaccess is the shared hosting community. Apart from that, it serves its purpose in every other respect and works pretty well.

I’m in no way affiliated with Nginx. I simply wrote this article to point out how many misconceptions are floating around regarding this subject matter.

As for Red Sand Media Group and Mr. Allen, you guys need to:

  1. Research before you write.
  2. Stop spreading misinformation.
  3. Stop fear-mongering just to avoid handling support issues from Nginx users.
  4. Stop blaming a fully functional web-server design just because of your own incompetence.

As for me, I’ll simply move to a different plugin once you stop Nginx support.

For everyone else, I’d suggest you all to use the webserver that meets your needs and you’re the most comfortable with. If you plan to switch webservers, make sure to read the docs properly and study the paradigm of the new webservers. I won’t recommend Nginx for shared hosting companies, mainly because it is a pain to maintain. But if you are a VPS or a dedicated user who likes to tinker, trust me, Nginx is pretty stable enough to run WordPress the way it is. You may face a few rough edges after switching over from Apache, but with time, you’ll learn to love the simplicity.

What do you think about standalone Nginx and WordPress? Let us know in the comments below.

Like this post? Share with your friends.
Share on Facebook22Tweet about this on TwitterShare on Google+0Email this to someone

Tags: , , , , , , , , ,

About the Author

I'm the leader of Techno FAQ. Also an engineering college student with immense interest in science and technology. Other interests include literature, coin collecting, gardening and photography. Always wish to live life like there's no tomorrow.

7 Responses to Standalone Nginx servers and WordPress – you decide?

  1. Alok Negi says:

    I am a regular user of WordPress yet I have no basic knowledge of php and wordpress. But by reading your article I started learning more about wordpress. Thank you.

  2. Dave says:


    All your article does is show your inexperience and lack of understanding of Apache vs Nginx. You didn’t actually prove your points…you just state them as if we should accept they are true.

    Nginx and Apache are not equivalent.

    • Sunit Nandi says:

      Feature-wise they are equivalent. Its just that the configuration structure differs between them.

      In Nginx, you include every directory level config with the ‘include’ directive. Apache handles them automatically with .htaccess. WordPress plugin devs and shared hosting companies usually use this property of Apache to change local configs without touching the main configuration file.

      However, in Nginx, file includes can include another file and so on. So in theory, you can have per-directory config if you know how to manage them. It is, indeed, not recommended for shared hosting. But if you have a dedicated server or a VPS shared among a small group of workers or friends, then this is a non-issue.

      Also, across the article, I never tried to disprove his central point regarding per-directory configs. I merely gave a better solution to implement per-directory configs in an ordered manner. What I tried to disprove are his other points regarding deployment time, security and management workload. I also proved that the plugins that he considers non-usable with nginx officially support nginx. What do you think I didn’t prove? Please state them properly. I’ll try my best to put forward my arguments.

      BTW, this blog runs purely on nginx. Though nginx and Apache differ in their main goals, functionality-wise, they are pretty much similar. With dynamically loadable modules, the gap between the two webservers in terms of user functionality has reduced. Also, Apache has mpm_event, making it closer to nginx.

  3. wuboy says:

    I post this article link to the plugin forum

    However, he keeps saying that use his plugin in nginx environment is not recommended.
    The reason is that Nginx does not allow for a directory level configuration file.

    I am not an expert of nginx.
    what do you think about that response?

    • Sunit Nandi says:

      In Apache, you can insert per-level directory configs by placing a .htaccess in the required location. His plugin inserts a .htaccess and blocks and unblocks IP addresses by updating the .htaccess file. Since Apache checks .htaccess on every request, the rules are followed.

      Nginx, on the other hand, requires you to ‘include’ a per-directory config, like you ‘include’ in C/C++ or ‘import’ in Python. Once the file has been edited, you need to send a ‘reload’ signal to nginx and it applies the new rules without restarting. W3TC uses that option. His plugin doesn’t. That’s the only difference.

      Nginx is not suited to shared hosts because editing the main config and sending reload signals is not allowed by individual users. A solution exists, see http://ajenti.org for a shared hosting solution using nginx.

      But if you are a VPS or dedicated user, this is not an issue.

      The entire issue I have been trying to discuss is the fact that the article I’ve quoted mentions non-issues as issues, like security, plugin support, deployment time, rewrite rules, SEO damage.

      See this quote:

      “If there is no .htaccess file, then you can’t properly setup the server for browser caching (because, again, for optimum performance, this type of directive has to be allowed on a directory-level), which will actually result in more requests sent to the server. So, what Nginx developers aren’t telling you is that using a standalone Nginx setup will result in more requests to the server! Ouch.”

      Implies that you must need .htaccess (Apache) to use caching or headers. If this is not misleading the public, then what is it doing? Ouch.

  4. Scott Allen says:

    Hi Sunit,

    I see that you read my article, “Standalone Nginx Servers and WordPress Don’t Mix”. That is excellent to hear. However, I’m sorry that you took such a negative view of what I wrote.

    I have to say, was it really necessary to assail my character or imply that my intentions were to deceive people? Nothing could be further from the truth. Anyone who knows me, knows this.

    I’m quite an easy going person, so if you had questions, I would have been happy to answer them. (And I still will.)

    I see that you are a very enterprising and intelligent young man. I think that you’re going to go quite far in life.

    Unfortunately, in your response to my article, you’ve taken a lot of it out of context.

    You seem to think that I am arguing Apache vs. Nginx when that’s not my point at all. I’m showing how Nginx/Apache hybrid is the better way to go. You make it sound like it’s some strange new idea, when in fact it’s a very common and powerful setup. Also, you argue that the two servers are essentially identical…that simply isn’t true. They have similarities, but each has it’s unique strengths, and it’s unique weaknesses.

    You run one website (or perhaps a few). Freelancing in college is great, but it is not the same as doing it full time. You are using your experience with one site (or a limited number of sites) as your basis for arguing. Too many people argue based singularly on their individual experience, or on limited experience. That is meaningless. You have to look at the global scope of things. You’re looking at one speck of sand, while we’re looking at the entire beach. You’re focused on one site, and we’re looking at the big picture. You have to look at large sets of data. Small segments of data are always skewed.

    I’ve been doing this for over two decades, and have managed teams that have worked on tens of thousands of websites. We optimize websites for speed, day in and day out. We’ve worked on literally every type of server out there.

    While you may be very talented, you need to be really honest with yourself…You don’t have the experience or the knowledge to be making the arguments you are. You clearly have some basic knowledge about server management, SEO, and speed optimization, but you’re not an expert, and you simply aren’t familiar with the nuances of these and how they interact. You are still a college student, and have much to learn. At this point in your life, it would be wise to remain humble and learn from professionals who have more experience than you do.

    Instead of criticizing, you might consider learning from me. I’m willing to share some knowledge and skills you can add to your toolbelt, just like others did for me. For example…I realize you probably think your site is optimized for speed…but I did a quick speed optimization on your site, and there is quite a bit more that needs to be done. Suppose for a second…What if I really do know what I’m talking about, and I could show you ways to significantly increase your site speed? I’d be willing to share some tips with you. If you’re interested, email me back. If you’d like me to get into more detail about some of the points in my article, we can even set up a Skype call, and I’ll be happy to answer questions in more detail.

    Take care.

    – Scott

    • Sunit Nandi says:

      Dear Scott,

      This is me, Sunit here.

      First, my article was never meant to assail your character, but to present my viewpoint of what I thought after reading the article. I apologize that I was quite harsh with the criticism and I never meant to offend you. Infact, I was criticizing the manner the article was written and what wrong signals it was sending out to the people reading it.

      Second, coming to what you assumed about my skills and life is probably what everyone thinks about me, but that’s probably not the case. I might be a lot younger than you by age and may have spent lesser time in the industry, but I’m not a complete newbie to it. I started taking interest in coding and Linux at the age of 9. By 12, I was working at a hosting company operating servers after school time and fixing clients’ websites. By the time I was 16, I left the job and took up countless client website and web application coding projects. Some of them I even did at no cost because I didn’t have a tax ID as I was not an adult. At 18, I started working on a Linux-based OS project with some friends (find out which one it is? 😉 ) because I felt that my nation needed the move to open-source software (and now it has a stable saleable product). Right now I am incubating 5 startups and working with 20 other companies to manage their web assets and build automation. I also research on internet protocols and The reason why I am not able to go create a full-scale agency like yours is because university (yes I graduated from college) takes a lot of your time. Its a tradeoff you have to deal with if you plan to learn more to build better things. I do not like to talk about all these because I don’t feel the need for validation. And that’s why I mention myself as a college student who freelances. I only am writing this because you brought out that point on humility. However, whether I like it or not, the Web 2.0 doesn’t work with humility because advertising yourself and making your brand look large, somehow makes you appear more vald to others. If I dropped out of school and ran some big project, this would have been a different ball game. Anyway, that’s not the point of this discussion. All I wanted to say is, I atleast know what I am doing. The only thing now that differs for the both of us, is while you see the application side of things mostly, I see the system side of things.

      You speak of a dataset. For me, a dataset is something that is well-recorded and validated and is reproducible under similar conditions. If you have one, please mail it over to sunit (at) technofaq (dot) org and I’ll be happy to study it. Your blog post mentions no signs of such a dataset. All it was written on it were some statements, with no proof nor proper validation that I can accept without hesitation. You talked about the lack of per-directory config on nginx which I didn’t say was wrong, but I showed how a workaround is possible using nginx. There is even a shared hosting solution based on LEMP stack (http://ajenti.org). What I tried to disprove are the myths the article was sending around, like you cannot get good SEO practices, caching or performance with nginx. You probably know better about this than me. You even said certain plugins don’t work with WP with pure nginx. I merely presented some proper/official/working configs to the server {} block to get them working the way they are intended. Your plugin doesn’t work with the config and WP support forum requests answered by RS Media often aren’t helpful as intended to pure nginx users. You don’t support pure nginx fine (because your needs don’t match), but going the lengths to make it a Nginx v/s Apache v/s Nginx-Apache hybrid war is unnecessary. Your article does exactly that. Please read your article as a layman (or ask someone else to read it and explain the gist to you) and then try to analyse what you were trying to put across.

      For me, it all boils down to preferences, skill and management issues. Most WordPress devs write plugins keeping Apache in mind because it is the easiest to deploy and maintain for a shared hosting environment. Automattic’s core WP team and several plugin developers build with both Apache and Nginx in mind, so we do have plugins that work with Nginx and proper configs for them. If they were never interested in the first place, no one would be willing to run Nginx with WP on production sites at all.

      The actual issue we face is lack of the understanding of nginx. True, nginx has lot less support in the case of runtime variables, macro expansions and per directory config, but how many sites actually need it? You blog post never mentions the manner this matters to users. You instead focus of irrelevant stuff like speed, SEO, security, plugin issues, which can be attributed more to sysadmin incompetency rather than actual feature set loss. You don’t need “.htaccess” for caching like you mentioned. You just need to insert a relevant rule, that’s it. Yes, I might not know nginx (according to you) but the points you’ve put forward are absolute rubbish. In fact, if you had written the article without the unnecessary misinformation, mentioned the tendency of plugin devs preferring the Apache architecture and .htaccess, the convenience of Apache over Nginx when coming to managed/shared hosting, convenience of configuration of certain plugins, the lack of Nginx-trained staff and some other legit issues, I’d not have criticized you. But you chose to make some non-issues (which can be fixed by one-liners) look like big issues.

      Also, the debate regarding the difference between the webservers in terms of actual usage is like Fedora vs Ubuntu or Christianity vs Islam. No matter how much you like to point out architectural differences, they perform the exact same thing. Your obsession with Ubuntu doesn’t make Fedora any less Linux. Your ultimate intention is to serve pages or reverse proxy. That never changes.

      I am no newcomer to the Nginx reverse proxy usage. I have personally set it up many times for clients who do not have any knowledge about Nginx and prefer to stick to Apache. Some clients want instant cache purging, so I require to compile the cache purge module every time I install it for them in that manner. It works very well and I agree with that. I have even installed Varnish instead of Nginx for numerous clients and it works well too. But the latency of a pure Nginx setup is second to none. When you browse the WP admin panel on a site running pure Nginx vs a site running a Apache+Nginx/Varnish hybrid, the latency difference becomes more prominent. For the website, it doesn’t really make any sense to compare because most viewed pages are cached (reponse time ~20ms). It only begins to show up when you request an uncached page and then the MTBF and transfer time sees a huge spike (reponse time ~200ms). On a pure Nginx setup, this effect is much less pronounced (response time ~90ms). If you have lots of dynamic content, it starts to make a significant impact.

      The only case when pure Nginx-based setup goes south is when someone inexperienced tries their hand at it. In that case, not even the lord can save you.

      Coming to Techno FAQ, this is one site that I own and run myself as a community e-magazine but not the only one I run. I handle numerous client websites running Nginx on VPSes, aside from the ones I need to install the hybrid setup. Let me guess the issue of my site. It has lots of blocking JavaScript and uncompressed images and the HTML is not minified? Well, its again a tradeoff between site speed and monetization. I do not minify the HTML because I want to preserve comments that handle inline text ads boundary limits. I have blocking JavaScript because despite of having async code, if the ad networks doesn’t respond in adequate time to the user or sends bad code, then the site has to block. If I were to forget monetization completely, I could optimize till an 90+ score on PageSpeed and YSlow score and enjoy. Unfortunately, blogs with tight budgets don’t work that way. You need to earn something to pay the next bill. Techno FAQ isn’t optimized for user load time, but atleast is for server delivery speed and latency. The server responds in a record ~70 ms with a 512 MB VPS even for uncached pages. My last Apache+Varnish setup was taking ~800 ms to serve an uncached (non-cached, non-microcached) page even with LSAPI PHP. I have seen a similar trend with my client websites as well. If you have a proper dataset that sufficiently disproves my claim from experience, then please send it over.

      I’ll wait for your response.


Leave a Reply

Your email address will not be published. Required fields are marked *

Back to Top ↑
  • Latest posts

  • Advertisement

  • Browse by category

  • Recent comments

  • Advertisement

  • Subscribe to updates

    You can get the latest posts from Techno FAQ delivered to you via Email or RSS.

    Enter your email address:

  • Subscribe to our RSS feed
  • Forum activity

  • Find us on Facebook

  • Latest tweets

  • Advertisement