Convert Apache Rewrite Rules to NGINX Rewrite Rules | NGINX

Original: https://www.nginx.com/blog/converting-apache-to-nginx-rewrite-rules/

Last week we published a blog about Creating NGINX Rewrite Rules. In this complementary blog, we’ll discuss how to convert Apache HTTP server rewrite rules to NGINX Plus syntax (the conversions are the same for the open source NGINX software). You need to convert to NGINX rewrite rules when you place NGINX Plus in front of your Apache servers to take over as the reverse proxy or load balancer, or when you replace Apache web servers with NGINX Plus web servers. Keep in mind that NGINX and NGINX Plus do not support per‑directory configuration files (Apache’s .htaccess files), so you need to convert them in particular.

We’ll assume you’re familiar with Apache rewrite rules and with how NGINX Plus processes URLs. For a review of the return, rewrite, and try_files directives in NGINX Plus and NGINX, see Creating NGINX Rewrite Rules.

Converting a Rule that Adds the www Prefix

This Apache rule adds the www prefix to the URL:

RewriteCond %{HTTP_HOST} example.org
RewriteRule (.*)         http://www.example.org$1

The following NGINX Plus configuration is the correct conversion. The first server block matches requests to example.org and redirects them permanently to www.example.org. The second server block matches the rewritten URL (and all other requests to www.example.org).

# USE THIS CONVERSION
server {
    listen      80;
    server_name example.org;
    return      301 http://www.example.org$request_uri;
}
 
server {
    listen      80;
    server_name www.example.org;
    # ...
}

The following might seem like a natural way to convert the Apache rule to an NGINX rewrite rule, but we don’t recommend it. Compared to the recommended conversion, it requires two extra processing stages: NGINX Plus must first check the if condition, and then evaluate the regular expression in the rewrite directive (simple as it is).

# NOT RECOMMENDED
server {
    listen      80;
    server_name www.example.org example.org;
    if ($http_host = example.org) {
        rewrite (.*) http://www.example.org$1;
    }
    # ...
}

Converting an “Is Not” Rule

This Apache rule matches URLs that are “not example.com and not www.example.com” (you could call this “upside‑down” logic) and rewrites them to www.example.com:

RewriteCond %{HTTP_HOST} !example.com
RewriteCond %{HTTP_HOST} !www.example.com
RewriteRule (.*)         http://www.example.com$1

For the NGINX Plus conversion, we explicitly define a server block that combines the “positive” versions of the Apache RewriteCond directives (that is, it matches URLs that start with example.com or www.example.com), and another server block that matches what is now better characterized as “everything else.” For an explanation of how the second server block works, see “Redirecting All Traffic to the Correct Domain Name” in Creating NGINX Rewrite Rules.

server {
    listen      80;
    server_name example.com www.example.com;
    # ...
}
 
server {
    listen      80 default_server;
    server_name _;
    return      301 http://www.example.com$request_uri;
}

Converting Rules that Enable WordPress Pretty Permalinks

WordPress.org distributes a basic default .htaccess file with the following Apache directives that enable pretty permalinks:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Here’s the NGINX Plus equivalent:

location / {
    try_files $uri $uri/ /index.php?$args;
}

For more information about enabling pretty permalinks for WordPress with NGINX, see WordPress permalinks at nginxlibrary.com.

Converting Rules that Forward Dynamic Requests to an App Server

Administrators often use Apache rewrite rules like the following to serve static assets directly if they exist and forward dynamic requests to an application server.

DocumentRoot /var/www/myapp.com/current/public
 
RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ %{DOCUMENT_ROOT}/system/maintenance.html [L]
 
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*)$ $1 [QSA,L]
 
RewriteCond %{REQUEST_FILENAME}/index.html -f
RewriteRule ^(.*)$ $1/index.html [QSA,L]
 
RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.*)$ $1.html [QSA,L]
 
RewriteRule ^/(.*)$ balancer://app-server_cluster%{REQUEST_URI} [P,QSA,L]

Specifically, the blocks of rules perform these functions:

Here’s the conversion for NGINX Plus. The root directive corresponds to the Apache DocumentRoot directive. The try_files directive replaces the remaining rules, using a named location (@app-server_cluster) as the final rewrite and defining a corresponding location block that proxies requests to the application server:

location / {
    root       /var/www/myapp.com/current/public;
 
    try_files /system/maintenance.html
              $uri $uri/index.html $uri.html
              @app-server_cluster;
}
 
location @app-server_cluster {
    proxy_pass http://app-server;
}
Retrieved by Nick Shadrin from nginx.com website.