Correctly proxying a PHP (Wordpress) site from a subdomain to a primary domain path

Support
,
1

Hi

I have a site at https://www.upgrade-hub.com. My server at www.upgrade-hub.com is pointing at https://upgrade-hub-web.netlify.app via a CNAME DNS configuration. All good!

Now, we have installed a blog site (PHP/WordPress) at /blog on our server which is served from the subdomain https://blog.upgrade-hub.com

As you would have guessed, what we really need is serve it from the same www domain without a redirection. So in Netlify, I have a proxy/rewrite set up like this in a _redirects root file:

/blog/*     https://blog.upgrade-hub.com/:splat     200

And this works! e.g.: https://www.upgrade-hub.com/blog

However, this doesn’t work, throws a 502: https://www.upgrade-hub.com/blog/wp-login.php (while as this does: https://blog.upgrade-hub.com/wp-login.php )

What’s the solution in this case?

Thanks!

2

Hi @jdvivar :wave:t6: ,

Thanks for reaching out to Netlify support forums! :netliconfetti: I am not sure if this thread but give this a read and see if it helps. Redirect proxy domain/path to subdomain/path not working

3

Thanks for your message @SamO

That thread is addressing a different issue. The person who opened the topic only set up a proxy through a path and pages on that path required resources on sibling paths. They needed to add additional rules for those uncovered paths.

I’ve also reviewed the guide at [Support Guide] Making redirects work for you - troubleshooting and debugging

But my issue is different: the proxy mainly works. Only it won’t work when the communication needs to be transactional. i.e. for security reasons, the server needs to identify a user correctly, such as when logging in. It probably is due to some missed custom header configuration that I’ve not been able to unravel myself.

4

Hi, can you share your repo?

5

The original one is private, but I’ve left a copy here for you: https://github.com/jdvivar/upgrade-hub-web

6

This doesn’t sound like a Netlify issue. Netlify is proxying correctly, it’s the target URL that’s returning a 502. You should try contacting that server to ask for more details on why that’s failing.

1 Like
9

Actually, the target URL returns 403 to Netlify when proxying. And Netlify is carrying that as a user-facing 502. I was wondering that, since all regular pages are working, maybe there was something wrongly setup in Netlify and other people might be in the same position, hence why asking in the forum. Thanks.

10

Hi, @jdvivar. This statement is not correct:

Actually, the target URL returns 403 to Netlify when proxying.

The proxy target does return a 502 to Netlify (not a 403). I can even test this URL myself using cURL:

$ curl --compressed -svo /dev/null https://blog.upgrade-hub.com/wp-login.php  2>&1 | egrep '^(<|>)'
> GET /wp-login.php HTTP/2
> Host: blog.upgrade-hub.com
> user-agent: curl/7.79.1
> accept: */*
> accept-encoding: deflate, gzip
>
< HTTP/2 502
< server: nginx
< date: Wed, 25 Jan 2023 08:34:28 GMT
< content-type: text/html
< content-length: 150
<

That is a 502 status above. The third-party system is returning the 502 which Netlify then proxies unchanged. If you want to fix these 502s, they must be fixed on the third-party system which is not controlled by Netlify.

1 Like
11

Nope, they’re 403 errors:

image
image3224Ă—582 51.1 KB

12

By the way, thanks so much for double checking from your client, I think I know what happens now, see what happens from my IP:

$ curl --compressed -svo /dev/null https://blog.upgrade-hub.com/wp-login.php  2>&1 | egrep '^(<|>)'
> GET /wp-login.php HTTP/2
> Host: blog.upgrade-hub.com
> user-agent: curl/7.85.0
> accept: */*
> accept-encoding: deflate, gzip
> 
< HTTP/2 200 
< server: nginx
< date: Wed, 25 Jan 2023 10:27:29 GMT
< content-type: text/html; charset=UTF-8
< vary: Accept-Encoding
< expires: Wed, 11 Jan 1984 05:00:00 GMT
< cache-control: no-cache, must-revalidate, max-age=0
< x-frame-options: SAMEORIGIN
< set-cookie: wordpress_test_cookie=WP+Cookie+check; path=/; secure
< x-microcache: True
< server-timing: BYPASS , rt;dur=1.113;desc=Process-Time
< content-encoding: gzip
<
14

Hi, @jdvivar. They are not 403s because the access logs don’t matter at all. The only thing that matters is what the server sends to the client and the server is only sending the 502.

I know you see a 403 in your logs. However, that URL doesn’t return a 403. It is returning a 502 to the client. I just tested again now:

$ curl --compressed -svo /dev/null https://blog.upgrade-hub.com/wp-login.php  2>&1 | egrep '^(<|>)'
> GET /wp-login.php HTTP/2
> Host: blog.upgrade-hub.com
> user-agent: curl/7.79.1
> accept: */*
> accept-encoding: deflate, gzip
>
< HTTP/2 502
< server: nginx
< date: Fri, 27 Jan 2023 00:59:25 GMT
< content-type: text/html
< content-length: 150
<

It is beyond dispute that the status code is a 502 above. The access logs don’t matter because no client can see the access logs. The only status the client (“the client” meaning my curl command, a web browser, or Netlify’s proxy service) can see is the 502. The 403 is never shown to the client. That is an internal status code but not what reaches the client.

So, the server is returning a 502 and Netlify is simply proxying that 502 along. This issue will continue until you can fix the target so it no longer returns a 502.

I see it is returning a 200 for you. Do you possibly have a firewall or other access controls that only send a 200 response for specific IP addresses?

16

Thanks, yes, I’m assuming there’s server configuration at the host provider level that’s letting some IPs pass and blocking others. Thanks to your input I realised that was the root cause, in fact.

17

HI @jdvivar :wave:t6: ,

Thanks for coming back and sharing your solution. We appreciate the feedback.

1 Like