Reverse Proxy Setup

Pagely can support reverse proxy setups on single instance WordPress sites (non-multisite) for VPS and Enterprise level plans for an additional $200 monthly subscription fee. This is to account for the added support costs associated with ongoing debugging, that wouldn't happen when directly pointing DNS records to Pagely.

At this time, we only support IPv4 networking. However, in regards to proxied traffic, the X-Forwarded-For header can contain a valid IPv4 or IPv6 address.

Reverse proxy setups are ideally suited for sub-directory access to a WordPress installation on the same domain and not an external domain. The setup you'd typically see with a reverse proxy would be blog.example.com resolving to example.com/blog.

Note: Since WordPress installations reside at the top level of the web root, you'll see the domain listed in our system as blog.example.com. Content will be served from example.com/blog.

Before we start configuring your reverse proxy, we must first obtain enough information about the remote endpoints you will be sending traffic from in order to ensure it will be viable. The most common and easiest scenario is if you have a static IP address or IP address range on the other end that you can easily obtain and share with Pagely. Besides source IP information, the web server or content network being used can also impact viability of a properly working reverse proxy configuration:

VBurst-2 plans must first upgrade to VPS-1 or higher in order to use any of the reverse proxy configurations listed above where the fee is listed as required.

Note: There may be additional fees if there are multiple types of proxy configurations required. If you are looking to set up multiple sites but using the same reverse proxy implementation, this counts as a single fee. However, if you have two sites with two different types of remote endpoints, the fee would be assessed individually. Please contact support if you're not sure.

If the solution you are intending to use is not listed above, please contact our support team in advance to discuss further.

Setting it up requires manual setup on our end, so a support ticket needs to be submitted in order to get it working properly.

Required information

We will need from the Proxy doing to forwarding:

• The solution you are using on the other end.
• The "X-Forwarded-For" headers has to be passed with visitors real IP.
• The "X-Forwarded-Proto" headers has to be passed to send HTTP/HTTPS information.
• The single IP address or all the IP addresses CIDR blocks that will be proxying the traffic.

These 2 headers and IP's sending the traffic are required, or it will not work.

The ticket should contain:

• Confirmation X-Forwarded-For is forwarding the visitors IP
• Confirmation X-Forwarded-Proto is sending the correct protocol.
• A list of the IP or all IP's that will be sending traffic.
• Which WordPress blog is to be forwarding & if it's to a subdirectory or not
• (If something isn't working, the full config contents of the reverse proxy helps us debug the issuer quicker)

Otherwise our rate-limiting that blocks spamming & abusive requests will detect that all traffic is coming from a single IP and will block it. So no visitors will be able to visit the blog if it is not setup correctly.

Example Nginx config for a proxy doing the forwarding:

• Use case is a sub-directory WordPress install like: http://example.com/blog

location /blog/ {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass $scheme://52.0.102.250;
}

• Red text being the existing domain with the subdirectory that will be proxied.
• Blue text being the Pagely IP of were traffic is to be forwarded to. (Or the VPS IP)

If you are on our ARES gateway and want the connection between your reverse proxy and Pagely VPS to be encrypted (you should do this!), then the config should look something like this:

location /blog/ {
    resolver 8.8.8.8 8.8.4.4;
    proxy_pass https://blog.example.com/blog/;
    proxy_ssl_protocols TLSv1.2;
    proxy_ssl_server_name on;
    proxy_ssl_name "blog.example.com";
    proxy_set_header Host "blog.example.com";
    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;
}

• Red text being the existing domain with the subdirectory that will be proxied.
• Blue text being the Pagely application name (not IP address or staging hostname) of were traffic is to be forwarded to.

Can I use Pagely as the sending reverse proxy endpoint?

This article has guided you through the process to configure Pagely as the receiving endpoint for a reverse proxy, meaning there is an off-site server that is sending traffic to Pagely for a specific subdirectory, such as /blog. To do things in the other direction - where a URL hosted at Pagely is proxying traffic from a remote URL - requires using NGINX-only mode for the site in question. Our Support Team can help gather your requirements and help you switch.

The monthly Reverse Proxy Support fee applies in this situation as well, since there are components outside of our direct control that will require ongoing support.

Can I use Pagely as both sending and receiving endpoints?

In cases where you want to proxy traffic from one Pagely app to another, and if both sites are hosted at Pagely, we certainly can help you get that working. In this case, there is no fee if both apps are hosted at Pagely. However, this is still considered an advanced configuration. Our team will first work with you to qualify this as an appropriate option for your goals. In some situations, a subdirectory Multisite app may work better than proxying multiple applications.