Using WebLinguist with WP Engine: Required Configuration & Why It Matters
If your website is hosted on WP Engine and you’ve chosen the Full Domain (Subdirectory) DNS setup, there are a few additional configuration steps required to make everything work correctly. This guide explains what those steps are, why each one is necessary, and exactly how to get them done.
This is not a limitation of WebLinguist — it’s a consequence of how WP Engine’s infrastructure is architected, and it affects all reverse proxy services that sit in front of WP Engine sites, not just ours.
Why WP Engine Requires Special Handling
WP Engine is not a standard web host. Their platform runs on top of Cloudflare’s enterprise network, which continuously monitors and validates that your domain’s DNS is pointing to WP Engine’s own infrastructure. When you point your domain to WebLinguist’s proxy instead, WP Engine’s Cloudflare layer detects the DNS change and can deactivate hosting for your domain — producing a Cloudflare Error 1001 and taking your site offline.
The solution is to configure WebLinguist’s proxy to fetch your site content directly from WP Engine’s backend install URL (yoursite.wpengine.com) rather than routing back through WP Engine’s public Cloudflare edge. This bypasses the validation layer entirely and goes straight to your WordPress installation on WP Engine’s servers.
There are then two additional nginx-level rules that need to be added to your WP Engine environment to ensure visitor IP addresses are handled correctly and that WordPress generates correct URLs when content passes through our proxy. Both are standard, documented configurations that WP Engine’s support team handles routinely.
Let’s go through each one.
Step 1: Enter Your WP Engine Install URL as Your Origin During Setup
What it is
During WebLinguist’s DNS setup wizard, you are asked to provide your origin URL — the address our proxy uses to fetch your original site content on the backend. This value is stored in your WebLinguist account and never exposed publicly.
For most standard hosting environments (plain VPS, shared hosting), this is simply your current server IP address or hosting domain. For WP Engine, this value must be your WP Engine install URL — the direct backend address of your WordPress installation.
Why it’s needed
Your domain’s DNS record points to WP Engine’s public Cloudflare IPs (141.193.213.10 / 141.193.213.11 for Advanced Network, or their CNAME wp.wpenginepowered.com). If WebLinguist’s proxy fetches content from those addresses, it hits WP Engine’s Cloudflare edge network — which expects your domain to be registered as a custom hostname in their system. Since you’ve moved DNS away from their infrastructure, your domain is no longer registered there, and the request fails.
By entering your WP Engine install URL as the origin, our proxy connects directly to your WordPress installation on WP Engine’s servers — completely bypassing the Cloudflare validation layer.
How to find your WP Engine install URL
Your install URL follows this format:
yourinstallname.wpengine.comYou can find your exact install name in the WP Engine User Portal:
- Log in to your WP Engine dashboard at
my.wpengine.com - Click on Sites in the left navigation
- Click on the environment name for your website
- Your install name is displayed at the top of the environment overview page — it’s also visible in the URL of your dashboard page
Your full install URL will be: [installname].wpengine.com
Where to enter it
When the WebLinguist setup wizard asks for your origin URL, enter your WP Engine install URL instead of your current domain or IP address:
yourinstallname.wpengine.comIf you have already completed setup and entered the wrong origin value, you can update it from your WebLinguist dashboard under Settings → DNS Setup → Origin URL. No DNS changes are required — this is purely a backend configuration update on our side.
Step 2: Add the Real IP Header Rule to Your WP Engine Environment
What it is
An nginx configuration rule that tells WP Engine’s server to read the real visitor’s IP address from the request headers sent by WebLinguist’s proxy, rather than treating WebLinguist’s server as the visitor.
The rule looks like this:
real_ip_header X-Forwarded-For;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/13;
set_real_ip_from 104.24.0.0/14;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;Why it’s needed
When traffic reaches WP Engine through WebLinguist’s proxy, every request appears to WP Engine’s server as coming from a single IP address — our proxy server’s IP. Without this rule, WP Engine’s nginx has no way of knowing the actual IP address of the visitor who made the original request.
This matters for several reasons:
IP-based access rules stop working correctly. If you have Web Rules in your WP Engine dashboard that block specific IP addresses, allow only certain IPs to access wp-admin, or restrict access by country — all of those rules would be applied against WebLinguist’s proxy IP rather than the real visitor’s IP. An IP block you set up to stop a bad actor would have no effect. A restriction on wp-admin access would potentially block all visitors, or none of the ones you intended.
Country-based rules stop working correctly. Any Web Rules using country conditions would see your proxy server’s country (wherever our infrastructure is located) rather than the visitor’s actual country. A rule allowing only US traffic would block all visitors, because every request appears to come from our data center.
WP Engine’s logging and analytics become inaccurate. WP Engine’s access logs would show our proxy IP for every request rather than real visitor IPs, making traffic analysis, security auditing, and support troubleshooting much harder.
WordPress itself may behave incorrectly. Some WordPress plugins use the visitor IP for rate limiting, spam detection, personalization, or security purposes. Without the real IP being passed through correctly, those plugins operate on the wrong data.
Why the rule uses Cloudflare’s IP ranges
WebLinguist’s proxy infrastructure sits behind Cloudflare’s network (the orange cloud). This means that when our proxy makes a request to your WP Engine origin, the connection appears to come from one of Cloudflare’s IP addresses rather than our own server’s IP. The IP ranges listed in the rule above are Cloudflare’s complete published IP ranges — both IPv4 and IPv6. By telling WP Engine to trust those ranges and read the X-Forwarded-For header from them, WP Engine correctly identifies the real end visitor’s IP for every request.
This also means your actual server IP is never exposed in this configuration — which is the correct and intended behavior.
How to get this rule added
This rule cannot be added through WP Engine’s Web Rules dashboard — it requires a direct nginx configuration change. You will need to contact WP Engine’s support team and ask them to add it.
How to contact WP Engine support:
- Log in to your WP Engine dashboard at
my.wpengine.com - Click the Help icon or navigate to the support chat from any page in your dashboard
- WP Engine offers 24/7 live chat support — this is the fastest path
What to say to WP Engine support:
You can copy and paste the following message:
“I’m using a reverse proxy service in front of my WP Engine environment. I need the following nginx rule added to my environment [your install name] so that the real visitor IP is correctly read from the X-Forwarded-For header rather than the proxy IP. This is a standard reverse proxy configuration per WP Engine’s own documentation.”
real_ip_header X-Forwarded-For; set_real_ip_from 173.245.48.0/20; set_real_ip_from 103.21.244.0/22; set_real_ip_from 103.22.200.0/22; set_real_ip_from 103.31.4.0/22; set_real_ip_from 141.101.64.0/18; set_real_ip_from 108.162.192.0/18; set_real_ip_from 190.93.240.0/20; set_real_ip_from 188.114.96.0/20; set_real_ip_from 197.234.240.0/22; set_real_ip_from 198.41.128.0/17; set_real_ip_from 162.158.0.0/15; set_real_ip_from 104.16.0.0/13; set_real_ip_from 104.24.0.0/14; set_real_ip_from 172.64.0.0/13; set_real_ip_from 131.0.72.0/22; set_real_ip_from 2400:cb00::/32; set_real_ip_from 2606:4700::/32; set_real_ip_from 2803:f800::/32; set_real_ip_from 2405:b500::/32; set_real_ip_from 2405:8100::/32; set_real_ip_from 2a06:98c0::/29; set_real_ip_from 2c0f:f248::/32;
This is a well-documented, routine request. WP Engine’s support team handles this type of configuration regularly and will typically complete it within one business day, often much faster via live chat.
Step 3: Add the X-Forwarded-Proto Header Rule
What it is
A second nginx rule that tells WP Engine’s server that the original request arrived over HTTPS, even though the connection between WebLinguist’s proxy and WP Engine’s origin may be perceived differently at the server level.
This is typically handled by WP Engine automatically for sites on the Advanced Network, but if you encounter any of the symptoms described below after setup, adding this rule resolves them.
The rule:
proxy_set_header X-Forwarded-Proto https;Or as a Web Rule in your WP Engine dashboard, you can set a response header:
X-Forwarded-Proto: httpsWhy it’s needed
WordPress stores your site’s URL in its database and uses it to generate all internal links, asset URLs, and redirects. If WordPress believes the incoming request arrived over HTTP rather than HTTPS — even for a moment — it can generate links with http:// instead of https://, trigger redirect loops as it tries to enforce its own HTTPS settings, or produce mixed-content warnings in browsers.
When traffic passes through a proxy chain, the original protocol information (HTTPS) can get lost or misrepresented by the time the request reaches WP Engine’s origin server. This header explicitly preserves that information.
Symptoms that indicate you need this rule
- Your site is redirecting visitors in an infinite loop after setup
- Pages load but images, CSS, or JavaScript appear broken (mixed content errors in browser console)
- WordPress is generating
http://links instead ofhttps://links on translated pages - The browser shows a “Not Secure” warning even though your domain has a valid SSL certificate
If you experience any of these after completing your WebLinguist DNS setup, contact WP Engine support and request the rule above be added to your environment alongside the real IP rule from Step 2.
Step 4 (Optional): Verify Your Web Rules Still Work Correctly
Once the nginx rules from Steps 2 and 3 are in place, any existing Web Rules you have configured in your WP Engine dashboard should function correctly again. However, it’s worth a quick verification pass — particularly for any rules that use IP address or country conditions.
To verify:
- Log in to your WP Engine dashboard
- Navigate to your environment and click Web Rules in the left navigation
- Review any active Access Rules that use IP address or country conditions
- Test those conditions by accessing your site from the expected IP or location and confirming the rule behaves as intended
If a rule is not behaving as expected after the nginx changes are in place, contact WP Engine support referencing the real IP header configuration and ask them to confirm it was applied correctly to your environment.
Summary: Complete WP Engine Configuration Checklist
| Step | Action | Where | Required? |
|---|---|---|---|
| 1 | Enter yourinstallname.wpengine.com as your origin URL |
WebLinguist setup wizard (or dashboard Settings) | ✅ Always required |
| 2 | Add real_ip_header + set_real_ip_from nginx rule |
WP Engine support (live chat) | ✅ Always required |
| 3 | Add X-Forwarded-Proto: https rule |
WP Engine support or Web Rules | ⚠️ Required if HTTPS/redirect issues occur |
| 4 | Verify existing Web Rules behave correctly | WP Engine dashboard | ✅ Recommended |
What About the Subdomain Setup?
If you chose the Subdomain DNS setup instead of the Full Domain setup, none of the above steps are required. Because the subdomain approach leaves your root domain record pointing directly at WP Engine’s infrastructure, WP Engine’s Cloudflare validation never detects a DNS change. Their platform continues to operate exactly as it did before. WebLinguist’s proxy only handles traffic to the language-specific subdomains you’ve set up, and WP Engine’s origin is fetched directly without any special configuration.
The steps in this guide apply only to the Full Domain (Subdirectory) setup.
Still Having Trouble?
If you’ve completed the steps above and are still experiencing issues, here are the most common culprits:
Error 1001 is still appearing — Double-check that your origin URL in WebLinguist is set to your WP Engine install URL (e.g., yourinstallname.wpengine.com) and not your old A record value or WP Engine’s public Cloudflare IPs. You can verify and update this from your WebLinguist dashboard under Settings → DNS Setup → Origin URL. Also confirm that DNS propagation has completed — changes can take up to 24 hours to fully propagate, though most providers update within a few minutes.
Site loads but wp-admin is inaccessible — This is typically an IP access rule in WP Engine’s Web Rules that is now matching against WebLinguist’s proxy IP rather than your IP. Confirm with WP Engine support that the real_ip_header rule has been applied, then check your Web Rules for any access restrictions on /wp-admin/ or /wp-login.php/.
Images or styles are missing — This usually indicates an HTTPS/mixed content issue. Add the X-Forwarded-Proto: https rule from Step 3 and clear all caches in both WP Engine’s dashboard and your browser.
WP Engine dashboard shows an SSL warning about your domain — This is expected. Because your domain’s DNS now points to WebLinguist’s proxy rather than WP Engine’s infrastructure, WP Engine’s dashboard will flag your domain’s SSL as unmanaged on their side. This is correct — your domain’s SSL is now managed by WebLinguist’s Cloudflare layer. Your site visitors see a valid, secure HTTPS connection. The warning in WP Engine’s dashboard can be safely disregarded.
If you’ve worked through all of the above and are still stuck, reach out to our support team via live chat in your WebLinguist dashboard and we’ll work through it with you directly.
