When You Need This Tool
Moving a website from Apache to Nginx can be frustrating because .htaccess rewrite rules don't work directly. One webmaster spent half a day manually converting 50 URL redirects—with our converter, you just paste them in and get the Nginx config instantly. This tool handles Apache mod_rewrite rewrite rules, RewriteCond conditions, 301/302 redirects, and common access control directives, ensuring a smooth transition.
Quick Reference: Common .htaccess Rules and Their Nginx Equivalents
The table below lists some of the most common .htaccess directives and their converted Nginx configurations. You can paste the .htaccess rules from the left column directly into the converter to verify the results.
| .htaccess 规则 | Nginx 配置 |
|---|
RewriteRule ^old$ /new [R=301,L] | rewrite ^/old$ /new permanent; |
RewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC] RewriteRule ^(.*)$ http://example.com/$1 [R=301,L] | if ($host = 'www.example.com') { rewrite ^/(.*)$ http://example.com/$1 permanent; } |
RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] | try_files $uri $uri/ /index.php?$args; |
<FilesMatch "\.(htaccess|htpasswd)$"> deny from all </FilesMatch> | location ~* \.(htaccess|htpasswd)$ { deny all; } |
How to Use This Converter
Open the converter page and you'll see two main areas: the input box on the left and the output box on the right. Here's how to use it:
- In the left input box, paste your .htaccess file content, or type a few rules manually. For example, enter
RewriteRule ^about$ /about-us.html [R=301,L]. - Click the "Convert" button in the middle (or the page may auto-convert, depending on the tool implementation).
- The right output box will immediately show the corresponding Nginx config. For the example above, you'll see
rewrite ^/about$ /about-us.html permanent;. - If the original .htaccess contains multiple rules, the converted results will be listed in order, each on its own line.
- You can click the "Copy" button to paste the converted Nginx config into your server configuration file.
If the converter encounters unsupported directives, a warning message will appear at the top of the output box, indicating which lines were skipped or need manual adjustment.
Real-World Example: WordPress Permalinks
Suppose you have a WordPress site with typical permalink rules in .htaccess:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
Paste it into the left input box and click "Convert". The Nginx config output on the right will be:
# WordPress permalinks
location / {
try_files $uri $uri/ /index.php?$args;
}
The converter recognizes that the core intent of these rules is “if the requested file or directory doesn't exist, pass it to index.php,” and automatically merges them into the efficient Nginx try_files directive, avoiding inefficient if blocks. You can use this config directly in your Nginx server block to achieve the same pretty permalink effect.
More Conversion Examples
Scenario 1: 301 redirect old page
Input:
RewriteRule ^old-page\.html$ /new-page.html [R=301,L]
Output:
rewrite ^/old-page\.html$ /new-page.html permanent;
Scenario 2: Domain-based conditional redirect
Input:
RewriteCond %{HTTP_HOST} ^olddomain\.com$ [NC]
RewriteRule ^(.*)$ http://newdomain.com/$1 [R=301,L]
Output:
if ($host = 'olddomain.com') {
rewrite ^/(.*)$ http://newdomain.com/$1 permanent;
}
Scenario 3: Block access to specific files
Input:
<FilesMatch "\.(htaccess|htpasswd|ini|log|sh)$">
Order Allow,Deny
Deny from all
</FilesMatch>
Output:
location ~* \.(htaccess|htpasswd|ini|log|sh)$ {
deny all;
}
You can test all these examples directly in the converter—paste and see the result instantly.
Common Pitfalls When Converting
- RewriteBase is ignored: The RewriteBase directive in .htaccess has no direct equivalent in Nginx. The converter tries to merge it into rule paths, but if your rules rely on RewriteBase and directory context, you may need to manually check path prefixes after conversion.
- Complex nested conditions: When multiple RewriteCond and RewriteRule combinations are involved, the converter generates if blocks. However, Nginx's if directive inside certain locations can cause unexpected behavior; deeply nested ifs inside location are not recommended. The conversion results are for reference only, and we suggest using location and try_files where possible.
- Sequential rewrite chains: Multiple RewriteRule directives in .htaccess execute in order, and Nginx's rewrite directive also executes sequentially, but the behavior of the last flag differs (last means restart matching, break stops). The converter attempts to map them correctly, but we recommend testing redirect chains in Nginx.
- Access control syntax differences: .htaccess Allow/Deny and Order directives have a different parameter order from Nginx's allow/deny. The converter handles common patterns, but custom complex IP access control may need manual adjustment.
- RewriteCond combinations with the [OR] flag: The converter translates such conditions into logical OR in if statements, but Nginx's support for if is limited. Please check the comments in the output; optimization may be needed.
Frequently Asked Questions
- Why does the converted Nginx config contain if statements, and will they affect performance?
- Nginx official documentation states that if statements inside location can cause unexpected behavior, but if blocks at the server level for rewriting are acceptable. The ifs generated by the converter are typically used for domain redirects and have minimal performance impact. If you see many ifs in your config, consider optimizing with map or multiple location blocks.
- Does the converter support all .htaccess directives?
- Currently it supports mod_rewrite rewrite rules, RewriteCond, 301/302/307 redirect flags, and common FilesMatch and deny/allow directives. Directives from mod_auth, mod_headers, and other modules are not supported; you'll need to manually find the Nginx equivalents (e.g., auth_basic, add_header).
- Where should I place the converted config in Nginx?
- Typically inside the server block, or within a location / block. If the conversion result contains location blocks, place them in the appropriate section of the server block. Do not replace the entire nginx.conf; extract the relevant parts.
- Why was my RewriteRule commented out?
- When the converter encounters a rule that cannot be safely converted (e.g., rules with the [P] proxy flag), it adds a comment in the output and keeps the original rule for your reference. You'll need to modify it manually to achieve the same functionality.
Important Notes
- This tool is intended to assist conversion; it does not guarantee that the converted config will work in all environments. Use the results as a starting point and always verify on a test server before deploying to production.
- The tool does not handle the dynamic directory-context inheritance of .htaccess. Nginx has no directory-level config inheritance; you need to apply the converted results under the appropriate location blocks based on your actual directory structure.
- Directives from third-party modules (e.g., mod_security) used in .htaccess cannot be converted, as Nginx has no equivalent module.
- The converter uses common pattern matching and may produce deviations for unconventional regex nesting or edge cases. We recommend backing up your original .htaccess file before conversion.
Now, paste your .htaccess rules into the converter above, get your Nginx config instantly, and start your seamless migration.