keepcalculator

06 Numbers and Powers

Fix Nginx Rewrite Rules for WordPress

Card No. 06·36181 · Updated · Standard formula, shown below

Nginx rewrite problems can make WordPress pages return 404 errors, send visitors to the wrong address, or break links after a permalink change. Use the steps below to check the site configuration, restore WordPress’s front-controller routing, and test changes safely. You’ll need access to the server configuration and a way to reload Nginx; if your site is hosted, your provider may need to make the change.

What You’ll Need

  • SSH or other authorized access to the server, or access to your hosting provider’s Nginx configuration tools.
  • The WordPress site’s document root and the active Nginx server-block configuration file.
  • A recent copy of the configuration file, plus permission to run Nginx configuration tests and reload the service.
  • The correct PHP-FPM socket or address already used by your site, if you need to inspect PHP routing.

Step-by-Step

  1. Identify what is failing. Open the homepage, a WordPress post, a category page, and /wp-admin/. Note which URLs fail and the exact response: a 404, a 403, a redirect loop, or a PHP-related error. Check whether the issue affects every page or only particular paths. This distinction helps separate rewrite problems from file permissions, PHP, or plugin issues.
  2. Confirm Nginx is actually serving the site. Nginx does not read Apache’s .htaccess files. WordPress rewrite instructions in .htaccess will not fix routing on an Nginx-only server. Find the active server block for the site’s hostname, rather than editing a sample or an unused configuration file. On many Linux systems, configuration is included from directories such as sites-enabled or conf.d, but paths vary by distribution and hosting setup.
  3. Back up the active configuration. Before editing, copy the relevant server-block file to a safe location or use your hosting control panel’s backup facility. Record the current document root, PHP handler, and redirect rules. Avoid replacing the whole server block with a generic example: production configurations may contain important TLS, caching, security, or PHP settings.
  4. Check the document root and hostname. Confirm that the server block’s root points to the directory containing WordPress’s index.php, and that the request’s hostname matches the block’s server_name. If Nginx looks in the wrong directory, a correct rewrite rule cannot find WordPress. Also verify that the intended HTTP-to-HTTPS redirect or canonical hostname is not sending requests between conflicting server blocks.
  5. Restore the WordPress front-controller rule. In the correct server block, WordPress commonly needs a location rule like location / { try_files $uri $uri/ /index.php?$args; }. This tries a real file, then a real directory, and sends other requests to WordPress’s index.php while preserving the query string. Check for another location / in the same server block; duplicate or conflicting location rules can change which rule handles a request. Do not add the example blindly if your host manages rewrites through a panel or include file.
  6. Review PHP handling without changing it unnecessarily. The rewrite sends missing paths to index.php, but Nginx still needs a working PHP-FPM configuration to execute that file. Check that the PHP location passes requests to the correct socket or upstream already configured on the server. Do not copy a socket path from another machine: PHP versions and hosting layouts differ. A PHP error after fixing a 404 may indicate a separate handler or service problem.
  7. Check for conflicting rules and redirects. Look through the active server block and included files for other rewrite directives, nested locations, or redirects affecting WordPress paths. A broad rule can intercept requests before they reach the front controller, while a redirect that changes HTTP to HTTPS or adds/removes a slash can create a loop if paired with another rule. Make one targeted change at a time.
  8. Test the configuration before applying it. Run sudo nginx -t where supported, or use the validation command provided by your host. Do not reload Nginx if the test reports a syntax error. Follow the reported file and line number, correct the issue, and test again. If you lack command-line access, use the host’s configuration validation feature or ask support to validate the change.
  9. Reload Nginx and retest URLs. After a successful test, reload Nginx using the service manager or hosting panel appropriate to the server. A reload applies valid configuration without the usual full stop/start. Then test the homepage, a post permalink, a page, a missing URL, and the admin area in a private browser window. Confirm that query strings and expected HTTPS redirects still work.
  10. Refresh WordPress permalinks only if needed. If the server rule is correct but WordPress routes still behave as though old permalink settings are in use, open Settings → Permalinks in the dashboard and click Save Changes without changing the structure. This refreshes WordPress’s rewrite configuration; it does not edit Nginx. Recheck the site afterward and avoid repeatedly saving settings as a substitute for fixing the server block.

Common Mistakes

One frequent mistake is adding Apache directives such as RewriteRule to .htaccess and expecting Nginx to process them. Another is putting the WordPress rule in the wrong server block, editing a disabled file, or overlooking a configuration include that takes precedence.

It is also easy to replace try_files with a redirect. WordPress needs internal routing to index.php for non-file URLs; redirecting every request can expose the wrong URL or create a loop. Avoid copying an entire server configuration from an unrelated guide, and never reload before a configuration test passes.

Tips

Keep the change minimal and preserve the existing PHP-FPM, TLS, and security settings. Use a text editor that does not introduce unusual formatting, and retain a backup until the site has been checked. If a host manages Nginx centrally, make changes through its supported interface or ask support rather than editing generated files that may be overwritten.

When investigating, test one failing permalink and one known working file. Check the Nginx error log and access log around the request time; their locations depend on the server configuration. A 404 for a permalink often points to routing, while a PHP upstream or permission message suggests another layer of the request is failing.

Troubleshooting

Nginx test fails: Do not reload. Check the exact file and line reported, look for missing semicolons or braces, and ensure location blocks are placed inside the correct server block. Re-run the test after each correction.

Permalinks still return 404: Verify the request reaches the intended server block and that its document root contains WordPress’s index.php. Check for duplicate location rules and confirm the front-controller rule is active. If static files work but post URLs do not, ask the host to inspect the effective Nginx configuration.

You see a 502 or PHP error: The rewrite may now be working, but PHP-FPM may be unavailable or its configured socket may be incorrect. Check the relevant service and logs, or contact the administrator; do not guess a socket path.

Redirect loop or wrong canonical URL: Review redirects across Nginx, WordPress, and any proxy or hosting layer. Ensure HTTPS and hostname redirects agree, then clear any relevant cache and test again. If the site is behind a proxy, have the provider verify how the original scheme and host are forwarded.

The change breaks the site: Restore the backup or revert the single edit, test the configuration, and reload only after validation succeeds. If the server will not accept the rollback, contact the host’s support team.

Frequently Asked Questions

Does WordPress use .htaccess with Nginx?
Nginx does not process .htaccess. Its equivalent routing must be configured in the active Nginx server configuration or through a host-managed tool.

What is the usual Nginx rule for WordPress permalinks?
A common front-controller rule is try_files $uri $uri/ /index.php?$args; inside the appropriate location /. The surrounding server and PHP configuration still matters.

Do I need to restart Nginx after editing a rewrite rule?
Apply the change with the service or hosting method your provider recommends, usually a reload. Always validate the configuration first; exact commands vary by system.

Why do WordPress permalinks work on the homepage but not on posts?
The homepage can load directly from index.php, while post URLs need Nginx to route nonexistent paths to that front controller. Check the active location rule and server block.

Will saving the Permalinks page fix Nginx?
No. Saving can refresh WordPress’s permalink settings, but it cannot change Nginx configuration. The server must route requests correctly first.

Can I use a generic WordPress Nginx configuration?
Use examples only as a reference. Adapt them to the site’s document root, PHP-FPM handler, TLS setup, and host-managed includes, or ask the server administrator to review them.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →