One of the Apache features that Nginx chose not to replicate is the support for the so-called .htaccess files. Those files were invented as a way to easily configure access control for individual virtual hosts in a virtual hosting environment where clients are only able to see their own subfolders via the magic of chroot (often called from ftpd). The implementation is rather simple; this is an autoincluded piece of configuration that Apache constantly monitors for changes. Not every possible Apache configuration directive is allowed in .htaccess (but many of them are, essentially, all that do not require a restart).

This feature was (ab)used as a convenient way to distribute the relevant web server configuration inside the source code for a website or a web application. Although the idea is still relevant, the Apache implementation with a silent change monitoring and transparent reconfiguration is not considered well designed. So, instead of the proper .htaccess support, Nginx suggests to explicitly include site-specific configuration files and then reload the configuration.

If your website source directory contains some .htaccess files, chances are that you will need to manually convert the directives into either a section inside the main nginx.conf or a separate file, which is to be included from nginx.conf.

One particular case is the proliferation of Apache mod_rewrite directives inside the .htaccess files. This will give you a hard time in the general case because Nginx uses a very different language for the URL rewriting functionality. One especially difficult case is the web apps that modify their own rewrite rules in .htaccess as part of their normal workload. Unfortunately, you have to either run an instance of Apache for them or order the rewrite of the relevant parts of their code altogether.

Here is an example of some old Apache rewrite rules:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www.)?example.com/.*$ [NC]
RewriteRule .(gif|jpg|png)$ http://www.example.com/dummy.gif [R,L]

The idea here was to break the so-called hotlinking – a practice when images were directly embedded in external documents, and this web host sent the bytes without getting any real users.

The same logic could be implemented for Nginx using these directives:

location ~ .(jpe?g|png|gif)$ {
   if ($http_referer ~ "^$") {
       return 301 http://www.example.com/dummy.gif;
   }
   if ($http_referer !~ "^http://(www.)?example.com") {
       return 301 http://www.example.com/dummy.gif;
   }
}

Although Nginx actually contains a special module for referrer checking, it will do the same job in a much more elegant way. Refer to the following:

    valid_referers none blocked example.com *.example.com;
    if ($invalid_referer) {
        return 301 http://www.example.com/dummy.gif;
    }

The logic of long chains of the Apache mod_rewrite rules poorly translates into Nginx. You should rethink the tasks and try to implement the solutions using more elegant ways that Nginx provides, such as try_files or special modules. See also http://nginx.org/en/docs/http/converting_rewrite_rules.html.

There are several tools to help convert static sets of the Apache mod_rewrite directives into the Nginx syntax. In our practice, they are all only partially useful and always require human fixes in the end. You may look at http://winginx.com/en/htaccess.

By the way, this tool does not handle the earlier-mentioned example with the HTTP Referrer properly.