The Ultimate Guide to Secure, Harden and Improve Performance of Nginx Web Server

If You Appreciate What We Do Here On TecMint, You Should Consider:

  1. Stay Connected to: Twitter | Facebook | Google Plus
  2. Subscribe to our email updates: Sign Up Now
  3. Use our Linode referral link if you plan to buy VPS (it starts at only $10/month).
  4. Support us via PayPal donate - Make a Donation
  5. Support us by purchasing our premium books in PDF format.
  6. Support us by taking our online Linux courses

We are thankful for your never ending support.

Gabriel Cánepa

Gabriel Cánepa is a GNU/Linux sysadmin and web developer from Villa Mercedes, San Luis, Argentina. He works for a worldwide leading consumer product company and takes great pleasure in using FOSS tools to increase productivity in all areas of his daily work.

Your name can also be listed here. Got a tip? Submit it here to become an TecMint author.

RedHat RHCE and RHCSA Certification Book
Linux Foundation LFCS and LFCE Certification Preparation Guide

You may also like...

13 Responses

  1. woody says:

    anyone know how to create rewrite rules below from apache to nginx?

    RewriteEngine On
    RewriteRule ^([^\.]+)/([^\.]+)/?$ index.php?route=$1&sub=$2 [QSA,NC,L]
    RewriteRule ^([^\.]+)/?$ index.php?route=$1 [QSA,NC,L]

  2. Joe Duarte says:

    There are lots of compiler options that are relevant for nginx and any webserver, that you’d want to use to achieve a real difference in security. All the stuff you’re talking about are user configs and settings after it has already been compiled. That stuff won’t do anything for most of the threats out there. Compiling with fortify source, ASLR-related, and memory-related security options is what will harden an nginx server.

    • @Joe,
      You’re absolutely right. We will update this article and include your suggestion. Thanks for taking the time to comment and share your feedback with us and the rest of the community.

  3. borys says:

    In section ‘TIP #3’ on photo You have ‘Server_tokens off;’ <- capital letter, should by lowercase.

  4. Patrick H Wood says:

    #4 doesn’t add much security. As you can see from the test you ran to verify it’s working, spoofing the user agent string is pretty trivial.

    • @Patrick,
      While it is true that #4 does not add security per se, it helps to avoid wasting resources depending on certain user agents. Yes, you can spoof the user agent string but you can also build some sort of smart blacklist to add to when you detect an undesired user agent (one with an unusual string).

  5. Alex says:

    PCI Compliance will fail due to using TLSv1.0

  6. v6ak says:

    1. This one is OK in general, but the main reason for keeping software up-to-date is IMHO security updates. This goal can be usually achieved even by using Debian stable repository. If one wants up-to-date version of Nginx, there are prepared packages for Debian, RHEL, CENTOS and some derivates: .

    On the other hand, compiling Nginx from sources complicates applying security updates, as it is extra manual work that has to be done by somebody.

    2. This is cost/benefit issue. I would maybe get few free RAM at cost of compiling Nginx myself and having harder times with security updates. I don’t think it is worth the cost except some few special deployments.

    3. Great, I did not know this one! +1

    4. Might be good to know, but I don’t know much use cases.

    5. Not sure why should I bother with that. What do I get for the work?

    6. Might have some performance impact, but I doubt in having positive security impact. Theoretically, there might be some undocumented assumptions of the configuration (e.g. assumption that buffer#1 ≥ buffer#2) which you might break by reconfiguring those. So, you are IMHO more likely to open a new security issue than to prevent some issue.

    7. There are some large DNATs. I don’t think that number of connections per IP is something I would like to configure unless I absolutely must.

    8. IMHO obvious, but OK.

    9. Might be useful, but not so much. One might simply turn the referer off, see . Rejecting requests with no referer might be somewhat controversial.

    10. Good, but there is more to configure. I would rather recommend .

    11. I don’t think that self-signed certificates are very useful. In fact, you can get a trusted one for free, even for a commercial website. See .

    12. IMHO trivial, but OK. But I would suggest adding HSTS in such case.

  7. Mark Pinecone says:

    Redirecting http to https is not wise IMO because it makes easier to steal your passwords with sslstrip.

    • @Mark,
      Good point – but would you mind giving it a try and get back to us? I haven’t used sslstrip but I don’t think if you can actually steal passwords if no credentials are entered while in http. Note that we are not talking about having a login form on a http connection and then redirecting to a secure area, but the other way around.

Got something to say? Join the discussion.

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

Join Over 300K+ Linux Users
  1. 177,942
  2. 8,310
  3. 37,548

Are you subscribed?