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 NGINX Open Source). 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.
This Apache rule adds the www prefix to the URL:
RewriteCond %{HTTP_HOST} example.orgRewriteRule (.*) 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 CONVERSIONserver {
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 RECOMMENDEDserver {
listen 80;
server_name www.example.org example.org;
if ($http_host = example.org) {
rewrite (.*) http://www.example.org$1;
}
# ...
}
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.comRewriteCond %{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<.htmla>.
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;
}
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.
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:
DocumentRoot
directive specifies the local disk directory where content is stored.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;
}
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."