nginx Reverse Proxy in Front of Apache

Why put nginx in front of Apache at all

Run Apache on 127.0.0.1:8080, let nginx own ports 80 and 443, and forward requests to Apache with proxy_pass. Send X-Forwarded-For and X-Forwarded-Proto so Apache and WordPress see the real visitor and HTTPS, then reload both services and test the headers.

The point is not to replace Apache. It is to let each do the job it is better at: nginx terminates TLS and serves static files quickly, while Apache keeps the .htaccess rules and PHP setup a site already depends on.

• nginx handles slow clients, keep-alive and TLS with a small memory footprint.
• Apache keeps mod_rewrite, .htaccess, and any module the application expects.
• Static files can be served by nginx directly, never reaching PHP.
• One nginx instance can front several Apache backends on the same box.

The cost is one more moving part. Two services to restart, two sets of logs to read, and a class of bug where the application thinks it is on HTTP while the browser is on HTTPS.

Architecture: who listens on which port

Only nginx accepts traffic from the internet. Apache listens on loopback, so nothing reaches it except through the proxy.

Check what is already listening with ss -ltnp before you change anything. Two services fighting over port 80 is the most common first failure.

Move Apache to loopback first

Change Apache before nginx, so there is never a moment when both want port 80.

1. On Ubuntu or Debian, edit /etc/apache2/ports.conf and change Listen 80 to Listen 127.0.0.1:8080. On RHEL-family systems the same line lives in /etc/httpd/conf/httpd.conf.
2. Update any VirtualHost that names a port, so it reads <VirtualHost 127.0.0.1:8080>.
3. Restart Apache: sudo systemctl restart apache2 (or httpd).
4. Confirm with curl -I http://127.0.0.1:8080 and with ss -ltnp | grep 8080. You know it worked when Apache answers on loopback and nothing answers on port 80.

The nginx server block

One server block per site, in /etc/nginx/sites-available/, symlinked into sites-enabled. The proxy headers are the part people omit.

1. Create /etc/nginx/sites-available/example.com.conf with a server block on port 80 that sets server_name to the domain.
2. Add a location / block containing proxy_pass http://127.0.0.1:8080; and the four headers: Host, X-Real-IP, X-Forwarded-For and X-Forwarded-Proto.
3. Optionally add location ~* \.(css|js|jpg|png|webp|svg|woff2)$ with a root and expires 30d, so nginx serves static files itself.
4. Symlink it into sites-enabled, then run sudo nginx -t. A syntax error here stops the reload, which is the safe failure.
5. Reload with sudo systemctl reload nginx, and add TLS afterwards with certbot --nginx so the certificate lands on the proxy, not on Apache.

Keep proxy_read_timeout at 60s unless you know a request needs longer. A short timeout turns a slow report into a 504 that looks like an application bug.

Make Apache and WordPress believe the visitor is on HTTPS

Behind the proxy, Apache sees a plain HTTP request from 127.0.0.1. Without the forwarded headers, WordPress builds http:// links on an https:// page and the browser blocks them as mixed content.

• Set X-Forwarded-Proto $scheme in nginx, so Apache can tell the original request was HTTPS.
• In WordPress, add a check on HTTP_X_FORWARDED_PROTO in wp-config.php, or let the host's proxy configuration set HTTPS=on.
• Map the real client IP with mod_remoteip in Apache, so logs and rate limits see the visitor, not 127.0.0.1.

The failure to watch for is a redirect loop: WordPress forces HTTPS, Apache reports HTTP, the browser is sent back and forth. If the loop starts, disable the force-HTTPS plugin or rule until the forwarded header is correct.

Verify it, then read the logs in the right order

Two commands tell you which service answered and what it believed about the request.

1. curl -I https://example.com and read the Server header. If it says nginx, the proxy is answering.
2. curl -I http://127.0.0.1:8080 and confirm Apache answers directly on loopback.
3. Load a page and check the nginx access log for the real client IP; if it shows 127.0.0.1 in the Apache log, mod_remoteip is not configured.
4. Request a URL that depends on .htaccess, such as a permalink. A 404 here means the rewrite did not survive the proxy, usually because AllowOverride is off in the proxied VirtualHost.

Read nginx's error log first and Apache's second. When nginx reports an upstream timeout, the Apache log tells you whether the request arrived at all.

Where this belongs on WebJi®

This layout needs root and two services, so it belongs on a VPS rather than a shared plan. WebJi® VPS plans give root access on KVM with NVMe storage, and the nginx and LiteSpeed comparison covers the case where you would rather replace Apache than proxy to it.

Email support@webji.services with the nginx -t output and the two log lines if the proxy will not settle. Support is 24/7 by email in Hindi and English, average first reply under 60 minutes, and the office phone is not a support line.