iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Put Nginx in front of WordPress when you want it to terminate HTTPS, serve one public hostname, and forward requests to Apache or another WordPress web server. The reliable pattern is an HTTPS Nginx server block, a location / that uses proxy_pass for an HTTP backend, and forwarding headers that preserve the original host, scheme, and client IP. If Nginx serves WordPress itself, use a PHP-FPM location ~ .php$ with fastcgi_pass instead; proxy_pass is not interchangeable with fastcgi_pass.
The details that prevent most failures are consistent HTTPS detection in WordPress, administrator-managed rewrite rules (Nginx does not read .htaccess), and a cache policy that excludes logged-in and state-changing requests. The procedure below covers both architectures, validation, and the symptoms that point to each misconfiguration.
What Nginx is doing in front of WordPress
A reverse proxy accepts the browser’s request, sends it to an upstream server, receives the upstream response, and returns that response to the browser. In a WordPress deployment, the upstream can be Apache (running WordPress over HTTP), another HTTP server, or PHP-FPM when Nginx serves the site directly.
In a common split setup, the public flow is:
Browser --HTTPS--> Nginx --HTTP or HTTPS--> WordPress web server --PHP--> PHP-FPMNginx owns the public TLS certificate and hostname. The backend must still receive enough context to know which host and scheme the visitor used. Without that context, WordPress may generate links for an internal hostname, treat secure requests as HTTP, or redirect indefinitely.
#1 Best Overall
WordPress can run behind Nginx even when Apache remains the application server. Many installations described as “Nginx sites” use exactly this arrangement. A standalone Nginx installation has no directory-level .htaccess equivalent, so administrators must write the permalink fallback and any other rewrite rules themselves.
Choose the deployment pattern before changing DNS
| Pattern | Request path | Strengths | Operational trade-offs |
|---|---|---|---|
| Nginx reverse proxy to Apache or another HTTP WordPress server | Nginx HTTPS listener to proxy_pass http://backend; |
Preserves an existing Apache/WordPress configuration while adding Nginx TLS, edge headers, and optional caching. | Two web-server configurations must agree on host, scheme, rewrites, timeouts, and logging. A 502 can originate at either layer. |
| Nginx directly serves WordPress with PHP-FPM | Nginx serves files; PHP requests use fastcgi_pass to a PHP-FPM socket or TCP address. |
Fewer HTTP layers and direct control of static files, rewrites, and FastCGI settings. | Nginx cannot consume Apache .htaccess rules. Every WordPress fallback, security rule, and plugin-specific exception must be managed in Nginx. |
| TLS termination at Nginx | HTTPS from visitor to Nginx; HTTP may be used on a private backend network. | Simpler certificate management and lower backend configuration overhead. | The proxy-to-backend hop is unencrypted. Restrict it to a trusted network or use end-to-end TLS where the threat model requires it. |
| End-to-end TLS | HTTPS from visitor to Nginx and from Nginx to the backend. | Encrypts traffic across separate hosts or untrusted network segments. | Backend certificates, names, trust, and renewal become additional failure points. |
| FastCGI cache enabled | Nginx may serve a stored response without contacting PHP for every request. | Can reduce PHP and database work for cacheable public pages. | Requires precise bypass rules and a purge process; otherwise edits, comments, or personalized pages can remain stale. |
| Uncached operation | Requests reach the backend normally. | Easiest to reason about while deploying or troubleshooting. | More backend work under load; performance depends on Apache, PHP-FPM, and database capacity. |
Prerequisites and a safe cutover plan
- A DNS record for the public WordPress hostname that will point to Nginx.
- A TLS certificate and private key installed on Nginx for that hostname.
- The backend address and protocol: for example, an Apache listener at
127.0.0.1:8080or a private HTTPS URL. - Administrative access to WordPress and to the Nginx host.
- The PHP-FPM socket path if Nginx will serve WordPress directly. Socket names vary by distribution and PHP version; use the path that exists on your server.
- A maintenance window or rollback plan. Keep the old web server available until the public hostname, login, permalinks, uploads, and assets have been tested.
Do not point DNS at Nginx until its certificate, upstream connectivity, and configuration syntax are ready. If you are using separate machines, firewall the backend so that only Nginx can reach its HTTP or HTTPS port.
Configure Nginx as a proxy to Apache or another HTTP backend
1. Define the upstream
An upstream group gives the proxy a stable name and makes later changes easier. This example assumes Apache listens on a private HTTP port:
upstream wordpress_backend {
server 127.0.0.1:8080;
}
For a different host, replace the address with the backend’s private IP or resolvable name. Use an https:// URL in proxy_pass only when the backend is actually serving TLS; do not use an HTTP proxy directive for a PHP-FPM socket.
2. Create the HTTPS server block
Place the certificate paths and public name in the Nginx configuration for the site. The following block forwards all paths to the upstream:
server {
listen 443 ssl http2;
server_name example.com www.example.com;
ssl_certificate /etc/ssl/example.com/fullchain.pem;
ssl_certificate_key /etc/ssl/example.com/privkey.pem;
location / {
proxy_pass http://wordpress_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Host $server_name;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_redirect off;
}
}
Host keeps the public hostname visible to Apache and WordPress. X-Real-IP and the appended X-Forwarded-For chain carry the visitor’s address. X-Forwarded-Host records the public host, and X-Forwarded-Proto records that the browser used HTTPS. proxy_redirect off prevents Nginx from rewriting backend redirect headers unexpectedly; WordPress should generate the correct public URL once its URL and HTTPS settings are consistent.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match3. Add an HTTP-to-HTTPS redirect
Use a separate port-80 block when every public request should be secure:
server {
listen 80;
server_name example.com www.example.com;
return 301 https://example.com$request_uri;
}
Choose one canonical hostname. If both the bare domain and www are valid certificates, redirect one to the other rather than allowing WordPress to alternate between them.
4. Preserve the original host at the backend
Apache virtual hosts often select a site by the Host header. Omitting proxy_set_header Host $host; can make the backend choose a default virtual host, issue redirects to an internal name, or produce the wrong site. If your public host includes a nonstandard port, use a deliberate host value that matches the backend’s virtual-host configuration.
5. Reload only after a syntax check
- Run
sudo nginx -t. Continue only when it reports that the configuration test is successful. - Apply the validated configuration with
sudo systemctl reload nginx. A reload lets existing connections finish while workers adopt the new configuration. - Check the Nginx error log and the backend access log immediately after the first request. A request reaching neither log indicates a DNS, listener, or firewall problem; a request in Nginx but not Apache indicates an upstream problem.
Configure Nginx to serve WordPress directly with PHP-FPM
This pattern removes Apache from the HTTP path. Nginx serves images, CSS, JavaScript, and other files, then passes PHP scripts to PHP-FPM over a Unix socket or TCP address.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Example server block
server {
listen 443 ssl http2;
server_name example.com www.example.com;
root /var/www/wordpress;
index index.php index.html;
ssl_certificate /etc/ssl/example.com/fullchain.pem;
ssl_certificate_key /etc/ssl/example.com/privkey.pem;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ .php$ {
try_files $uri =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param HTTPS $https if_not_empty;
fastcgi_pass unix:/run/php/php8.2-fpm.sock;
}
location ~* /.ht {
deny all;
}
}
Replace /var/www/wordpress and the socket path with the actual installation values. The socket may be named for another PHP version, or PHP-FPM may listen on a TCP address such as 127.0.0.1:9000. Verify the service is running and that the Nginx worker can access a Unix socket before blaming WordPress.
The try_files fallback is the key WordPress permalink rule: an existing file or directory is served directly; an unknown path is sent to index.php with its query string. Without it, the home page may work while posts and pages return 404. The PHP location should reject nonexistent scripts and set SCRIPT_FILENAME to the real file path.
Why .htaccess instructions do not transfer automatically
Apache reads .htaccess files in directory context. Nginx does not. WordPress therefore cannot write Nginx rewrite rules when you change the permalink setting. Copying an Apache rule into an Nginx file verbatim is unsafe: directives, matching order, and variables differ. Translate only the behavior you need, test it with nginx -t, and keep custom plugin rewrites documented beside the site configuration.
Make WordPress understand the public HTTPS URL
Keep the site and home URLs consistent
In the WordPress dashboard, open Settings > General and make sure both WordPress Address (URL) and Site Address (URL) use the canonical public scheme and hostname, such as https://example.com. If the fields are locked in wp-config.php, update the constants there instead:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsdefine('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
Do not set these values to an internal backend name. A mismatch causes canonical redirects and asset URLs to point away from the public site.
Tell WordPress that a proxied HTTPS request is secure
When TLS terminates at Nginx, the backend connection may be plain HTTP even though the visitor used HTTPS. WordPress must trust the forwarded scheme for this deployment. Add the following before WordPress loads, normally in wp-config.php:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
&& $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
Only accept this signal from a proxy you control. If the backend is directly reachable from the internet, an attacker could supply a forged forwarding header; firewall the backend or configure trusted-proxy handling so that only Nginx can set it.
Do not mix proxy and application redirects
Choose one place to enforce the canonical host and HTTPS policy. A port-80 redirect at Nginx plus a different host redirect in Apache can create unnecessary hops. After changing the settings, clear browser and page caches and test a fresh private-window session.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Rank #3
Forward client identity safely
Nginx’s default proxy behavior changes the upstream Host and Connection headers. The explicit header set shown earlier restores the public context. The backend application, access logs, rate limits, and security tools must also know which proxy addresses are trusted before they use X-Forwarded-For as the real client address.
- Use
$remote_addrfor the address that connected to Nginx. - Use
$proxy_add_x_forwarded_forto append that address to an existing forwarding chain instead of overwriting it. - Configure Apache, WordPress security software, or the operating-system firewall to trust forwarding headers only from your Nginx address range.
- Keep the public host and scheme headers aligned with the URL that users actually entered.
If logs show only Nginx’s private address, the header may not be forwarded or the backend may not be configured to interpret it. If logs show arbitrary addresses supplied by clients, the backend is trusting an untrusted proxy path.
Handle caching without serving private data
Nginx can use FastCGI cache for direct PHP-FPM deployments, and it can also cache responses from an HTTP upstream. A typical design defines a cache zone, a cache key, and rules that bypass or do not store sensitive requests. WordPress-specific purge integration can be provided by an Nginx-aware helper plugin, but the purge behavior must be tested for the plugins and authentication cookies used by the site.
Requests that should bypass full-page cache
- Logged-in sessions and administrator pages such as
/wp-admin/. - Login and preview requests, including requests carrying authentication or preview cookies.
- POST, PUT, PATCH, DELETE, and other state-changing methods.
- WooCommerce-style carts, checkout flows, account pages, and any plugin-defined personalized endpoint.
- Requests with a query string when the application uses it to vary content, unless the cache policy explicitly handles that variation.
Define the purge process before enabling full-page caching. Publishing, updating menus, changing widgets, approving comments, and editing theme files can all require invalidation. A fast cache with no reliable purge is worse than an uncached site because visitors receive an old page while administrators see the new one.
Start uncached, verify the proxy and WordPress behavior, then enable caching for anonymous GET and HEAD requests in a controlled scope. Record the bypass conditions and test both a logged-out browser and a logged-in administrator session.
Validate the public site in a fixed order
- DNS and certificate: Resolve the hostname to Nginx and confirm the certificate covers the exact name. Check both the bare and
wwwforms if both are published. - Home page: Request the HTTPS URL and inspect the response for a single canonical host and no HTTP asset URLs.
- Pretty permalink: Open an existing post or page, not just the front page. A 404 here usually means the Nginx fallback is missing or the request is reaching the wrong server.
- Static assets: Load an image, stylesheet, JavaScript file, and an upload from the media library. Confirm paths are public and not being sent to the wrong upstream.
- Administration: Open
/wp-admin/, sign in, and confirm that the dashboard remains on HTTPS without repeated redirects. - Login flow: Sign out and back in from a private window. Test password reset or another form that sets cookies if the site uses one.
- Client IP: Compare Nginx and backend logs. The backend should record the visitor address through a trusted forwarding configuration, not merely Nginx’s private address.
- Cache behavior: Publish a harmless change, verify it appears for an anonymous visitor after the documented purge, and verify that an administrator never receives a cached page.
Troubleshoot by symptom
Redirect loop or links that remain HTTP
Check that Nginx sends X-Forwarded-Proto $scheme, that the WordPress HTTPS detection code is present when TLS ends at Nginx, and that both WordPress URL fields use the public HTTPS URL. Inspect the first Location response header with a command such as curl -I https://example.com/ and identify which layer issued the redirect.
Redirects to an internal hostname or the wrong domain
Verify proxy_set_header Host $host; and, where needed, X-Forwarded-Host $server_name. Check the backend virtual-host selection and WordPress’s site/home values. A default Apache virtual host can produce this symptom even when Nginx itself is correct.
Real client IP is missing
Confirm that Nginx sends both X-Real-IP and X-Forwarded-For. Then configure the backend or logging layer to trust only the Nginx addresses. Forwarding a header alone does not make an application safe to trust every value in it.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Pretty permalinks return 404
For direct Nginx/PHP-FPM, confirm try_files $uri $uri/ /index.php?$args; is in the active server block. For an Nginx-to-Apache proxy, confirm the request reaches the intended Apache virtual host and that Apache’s WordPress rewrite configuration is active. Reload after nginx -t succeeds.
Rank #4
502 Bad Gateway
For an HTTP proxy, verify the upstream address, listening port, protocol, firewall, and whether the backend service is running. For PHP-FPM, verify the socket or TCP address, PHP-FPM service status, socket ownership and permissions, and that the Nginx worker user can connect. Use proxy_pass only for an HTTP upstream and fastcgi_pass only for FastCGI.
Stale pages after an edit
Inspect cache bypass rules for cookies, methods, administrator paths, and query strings. Confirm that publishing and comment actions trigger the chosen purge mechanism. Temporarily disable full-page caching to separate a cache problem from a WordPress or proxy problem.
Assets, uploads, or large requests fail
Check the Nginx error log for file-permission errors, incorrect document roots, request-size limits, and upstream timeouts. In a split setup, confirm whether Nginx is serving the file itself or forwarding it; the responsible layer must have access to the same upload path or a deliberate file-serving strategy.
Recommended Free Tools
Operational practices after the cutover
- Keep Nginx configuration in version control and document the canonical hostname, backend address, PHP-FPM socket, trusted proxy addresses, and cache bypass policy.
- Renew the TLS certificate before expiry and reload Nginx only after testing the resulting configuration.
- Monitor Nginx access and error logs together with Apache or PHP-FPM logs. Correlating a request ID or timestamp across layers shortens diagnosis.
- Apply security updates to Nginx, WordPress, plugins, themes, Apache, and PHP-FPM according to your maintenance policy.
- Back up the WordPress database and
wp-contentbefore changing rewrites, URL constants, or cache rules. - Re-test the home page, a permalink, media, login, and an administrator page after certificate renewal, DNS changes, PHP upgrades, or plugin changes.
Frequently Asked Questions
Can Nginx reverse-proxy WordPress while Apache remains installed?
Yes. Nginx can terminate HTTPS and use proxy_pass to an Apache HTTP or HTTPS listener. Preserve the public Host, forwarded scheme, and client-IP headers, and ensure Apache’s virtual host matches that host.
Why does the WordPress home page work while posts return 404?
Standalone Nginx does not read .htaccess. Add the WordPress try_files $uri $uri/ /index.php?$args; fallback in the active server block, then test and reload Nginx.
Should I use proxy_pass or fastcgi_pass?
Use proxy_pass for an HTTP application server such as Apache. Use fastcgi_pass for PHP-FPM, with the required FastCGI parameters and the correct socket or TCP address.
How do I stop an HTTPS redirect loop behind Nginx?
Send X-Forwarded-Proto $scheme, make WordPress’s site and home URLs HTTPS, and enable the WordPress HTTPS detection logic for the trusted proxy when TLS terminates at Nginx.
Is FastCGI caching required?
No. Deploy and validate the proxy uncached first. Enable caching only with bypass rules for logged-in users, administrator pages, state-changing methods, personalized endpoints, and a tested purge process.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
