Reverse Proxy – SSL to http and back! | wp internal / external urls *

How the Reverse Proxy Handles HTTP to HTTPS

When you set up a reverse proxy, here’s how it works:

1. External HTTPS Request:

   • A user visits https://spiffynasty.com/blahblahblah/ (secured with HTTPS).
   • The reverse proxy (on spiffynasty.com) receives this request over HTTPS.

2. Internal Forwarding to HTTP:

   • The reverse proxy forwards this request internally to your NAS using HTTP, like http://192.168.1.30/blahblahblah/.
   • The connection between spiffynasty.com and 192.168.1.30 (your NAS) is happening over your local network, so it’s secure in the sense that it’s not exposed to the outside world.

3. Response from NAS:

   • Your NAS (192.168.1.30) serves the requested content back to the reverse proxy over HTTP.

4. Secure Response to the Client:

   • The reverse proxy then encrypts the response (via HTTPS) and sends it back to the user as https://spiffynasty.com/blahblahblah/.

Why It’s Safe:

The critical point is that the public-facing side (what users interact with) is over HTTPS, secured by the certificate you set up on spiffynasty.com. The internal communication between spiffynasty.com and 192.168.1.30 happens over HTTP because:

• It’s within your local network (e.g., 192.168.x.x range), which isn’t accessible to the public.
• For most local network setups, this is considered secure, as it’s unlikely anyone can snoop on traffic inside your private LAN.

Key Role of the Reverse Proxy:

The reverse proxy acts as the "translator":

• It terminates the SSL (HTTPS) connection, meaning it handles the encryption and decryption for the public-facing side.
• It communicates with your NAS using HTTP, which doesn’t require SSL because it's inside your private network.

Internal and External urls w/ Wordpress

Using http://192.168.1.30 in the WordPress database for the site URL (both the siteurl and home options) might seem like a convenient way to ensure the site works locally even if the reverse proxy goes down, but there are a few important considerations and trade-offs:

1. Internal URL vs. External URL

If you set the siteurl and home in the WordPress database to http://192.168.1.30 (the internal IP of the NAS), WordPress will generate links and assets (like CSS, JavaScript, and images) using this internal IP address, which could cause issues when accessing the site externally via the reverse proxy (https://spiffynasty.com).

Why this is a problem:

• Broken Links for External Visitors: All URLs (like posts, media files, etc.) would point to http://192.168.1.30, which is not accessible from the outside world. Visitors going to https://spiffynasty.com will see these internal links, causing content to fail to load.
• Mixed Content Warnings: If your reverse proxy is serving the site over HTTPS, but assets are still loaded from http://192.168.1.30 (HTTP), browsers will block these resources or show "mixed content" warnings, making the site appear insecure.

2. How to Handle Local Access

There are better ways to ensure that the site works locally and externally without hardcoding http://192.168.1.30 into the database:

a. Use spiffynasty.com as the Site URL

Keep https://spiffynasty.com/blahblahblah in the database as the site URL. This ensures that all URLs and assets are correctly served for external visitors, but also works fine for local access through the reverse proxy.

When you access the site locally via http://192.168.1.30, the reverse proxy can still forward requests correctly, so your site will load as expected, with the links pointing to spiffynasty.com. Since the NAS serves the content locally, it will work.

b. Use a Conditional in wp-config.php for Local and External Access

You can set up WordPress to detect whether you're accessing it locally or through the reverse proxy and adjust the site URL accordingly. Here's how:

In wp-config.php, add a conditional statement like this:

if ($_SERVER['REMOTE_ADDR'] == '192.168.1.30') {
    define('WP_HOME', 'http://192.168.1.30/blahblahblah');
    define('WP_SITEURL', 'http://192.168.1.30/blahblahblah');
} else {
    define('WP_HOME', 'https://spiffynasty.com/blahblahblah');
    define('WP_SITEURL', 'https://spiffynasty.com/blahblahblah');
}

This way, if you're accessing the site from the local network, WordPress will use http://192.168.1.30, and if you're accessing it from anywhere else, it will use the public https://spiffynasty.com URL.

3. Handling Media and Assets

One potential issue with switching URLs dynamically is that WordPress stores absolute URLs for media files in the database. If you use the internal IP (192.168.1.30), media links will be stored using this address, which can cause broken links when accessing the site externally.

To avoid this:

• Keep the site URLs as the public-facing ones (e.g., https://spiffynasty.com).
• Access the site locally through the reverse proxy as much as possible.

4. Database Considerations

If you decide to switch the URLs between local/internal and external, you may also need to replace URLs in the database whenever you change the setup (for example, using search-and-replace tools like Better Search Replace). This isn't ideal for dynamic environments where both internal and external access is required regularly.

Conclusion

It’s generally best to keep the public-facing URL (https://spiffynasty.com) as the site URL in the WordPress database. This avoids external visitors encountering issues with internal IPs and ensures proper SSL and link handling.

However, you can use conditionals in wp-config.php to allow for local access using http://192.168.1.30 if needed.