Setting up Reverse Proxies for Subfolder WordPress Blogs (e.g., app.com/blog)

Serving your blog at app.com/blog instead of blog.app.com keeps every article on the same domain as the product, so internal links, backlinks and brand signals pile up in one place. A reverse proxy is what makes that possible without jamming WordPress into your application stack. The plumbing takes an hour or two if you prepare the WordPress side before touching a single line of Nginx.

Why the Subfolder Is Worth the Extra Plumbing

Google handles a subdomain and a subdirectory as distinct URL patterns, and while both can rank, consolidating content under one hostname simplifies canonicalisation, analytics and crawl budget. Google’s own guidance on consolidating duplicate URLs is a useful reminder that signal splitting is the real risk, not the hostname itself.

There is a second, less discussed reason teams pick app.com/blog: the marketing site and the product usually run on different stacks. A React or Next.js app on Vercel has no business running PHP, and WordPress runs badly on infrastructure built for stateless frontends. The proxy lets each side stay where it belongs while the visitor sees one coherent site.

Proxy Versus Reverse Proxy in One Paragraph

A forward proxy sits in front of the client and hides the user from the internet, which is what a corporate VPN or a privacy proxy does. A reverse proxy sits in front of the server and hides the origin from the user, accepting the request at app.com and quietly fetching the response from the WordPress host. Everything below assumes the reverse direction.

Configure WordPress Before You Touch the Proxy

Most failed setups fail here, not in Nginx. WordPress needs to believe it already lives at the public path, otherwise it will generate origin URLs in menus, canonical tags and the REST API. Add this to wp-config.php above the “stop editing” line:

define('WP_HOME', 'https://app.com/blog');
define('WP_SITEURL', 'https://app.com/blog');

if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
 $_SERVER['HTTPS'] = 'on';
}

if (!empty($_SERVER['HTTP_X_FORWARDED_FOR'])) {
 $_SERVER['REMOTE_ADDR'] = explode(',', $_SERVER['HTTP_X_FORWARDED_FOR'])[0];
}

The HTTPS block prevents the classic infinite redirect: the proxy terminates TLS, WordPress sees plain HTTP on the back end, forces a redirect to HTTPS, and the loop never ends. The forwarded-IP block keeps comment moderation, rate limiting and security plugins from seeing every visitor as the same address.

Install the WordPress files in a /blog subdirectory on the origin too, so paths match on both sides. Rewriting / to /blog/ inside the proxy works, but every mismatch becomes something you have to patch later in sitemaps, feeds and admin-ajax calls.

The Nginx Reverse Proxy Block

On the server that owns app.com, add a location block that passes anything under /blog/ to the WordPress origin. The trailing slashes matter on both the location and the proxy_pass target.

Related reading: How to Set Up Multi-Language WordPress Sites (WPML) for Fast Global Loading.

location /blog/ {
 proxy_pass https://wp-origin.example.net/blog/;
 proxy_http_version 1.1;
 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-Proto $scheme;
 proxy_set_header Accept-Encoding "";
 proxy_read_timeout 60s;
 proxy_buffering on;
}

Passing Host $host is what tells WordPress which domain it is answering for. The Nginx proxy module documentation covers the buffering and timeout directives in detail, and a 60 second read timeout is usually enough for an admin save on a busy editorial site.

Three paths need separate attention once the basic Nginx reverse proxy responds:

• /blog/wp-admin/ and /blog/wp-login.php, which must not be cached by the edge at all.
• /blog/wp-json/, if your frontend pulls posts through the REST API for a homepage feed.
• /blog/wp-content/uploads/, which is worth caching aggressively for 30 days or longer.

Doing It Without Server Access: Cloudflare and Edge Workers

If app.com runs on a platform where you cannot edit a web server config, the proxy moves to the edge. A Cloudflare Worker bound to the route app.com/blog* can rewrite the hostname and forward the request, and Vercel or Netlify rewrites do the same job with a few lines of JSON. The logic is identical: keep the public path, swap the origin host, preserve the forwarded headers.

Edge proxies add two quirks worth planning for. Worker CPU limits can bite on large uncached responses, and some platforms strip or rename headers, which breaks the HTTPS detection shown above. Test a logged-in editor session, not just an anonymous page view, before you call it done.

The Failures We See Most Often

Redirect loops top the list, and they are nearly always the HTTPS detection problem or a WP_SITEURL that still points at the origin. Past that, a handful of issues show up again and again on proxied subfolder blogs:

1. Hard-coded origin URLs in the database from before the move. A search-replace across wp_posts and wp_options clears them, including serialized theme options.
2. Double caching, where the proxy caches a page the WordPress cache already served, so purges appear to do nothing for 10 to 30 minutes.
3. The origin staying publicly reachable, which creates a duplicate copy of every post at wp-origin.example.net. Blocking everything except the proxy IPs, as described in our guide to restricting WordPress access by IP address, is the clean fix.
4. Sitemaps and robots.txt living at the origin root. Proxy /blog/wp-sitemap.xml explicitly and reference it from the main robots.txt file.
5. Slow admin screens, because every dashboard request now makes an extra network hop. Our notes on diagnosing slow WP-Admin dashboards apply directly once latency between proxy and origin exceeds roughly 50ms.

Media is the other quiet tax. Large galleries and hero images travel through the proxy on every miss, so pair the setup with a CDN rule on the uploads directory and the techniques in our piece on optimizing high-resolution image galleries.

Choosing the Origin Host

The origin does the actual work, so its performance sets the ceiling for the whole arrangement. Publishing teams running dozens of writers and heavy archives get more out of a platform built for magazine-scale WordPress hosting than a shared box with a 1GB memory limit. Product companies gating content behind logins should check that session handling survives the proxy, which is where membership-focused hosting earns its keep.

Keep the origin geographically close to the proxy. A blog origin in Frankfurt behind an app server in Virginia adds about 90ms to every uncached request, and editors feel that on every autosave.

Frequently Asked Questions

How Do You Configure a Reverse Proxy?

You add a location or route rule on the public host that forwards matching requests to a private origin, typically 10 to 15 lines of Nginx config. The required pieces are the target URL, a preserved Host header, and the X-Forwarded-Proto and X-Forwarded-For headers so the application knows the original scheme and client IP.

What Is the Difference Between a Proxy and a Reverse Proxy?

A forward proxy acts on behalf of the client and hides the user, while a reverse proxy acts on behalf of the server and hides the origin. In a subfolder blog setup you always want the reverse kind, because the goal is to present one public domain while two separate back ends do the work.

When Should You Use a Reverse Proxy?

Use one whenever two or more applications must share a single domain, which covers roughly every app.com/blog, /docs or /help deployment. It also helps with TLS termination, edge caching, load balancing across multiple WordPress containers, and shielding an origin IP from direct attack.

Is There a Free Reverse Proxy Service Available?

Yes, Cloudflare’s free plan includes Workers with a 100,000 request per day allowance, which is enough for most small blogs. Nginx, Caddy and Traefik are free open source options if you control a server, and both Vercel and Netlify include rewrite rules on their free tiers.

Get Your Subfolder Blog on Hosting Built for the Job

We set up proxied WordPress origins for app.com/blog deployments every week, including the IP allowlisting, cache rules and header handling that keep them stable. Talk to our team at WebVibo and we will configure the origin side with you before launch day.