502 Error on some websites

[nebulon]

Seems like nginx being the proxy here on Cloudron side, tries to access the origin by IP after resolving and since that page is behind a cloudflare proxy, which does not allow direct IP access, it fails with this error message:

2023/11/28 19:12:38 [error] 419125#419125: *65780 SSL_do_handshake() failed (SSL: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:SSL alert number 40) while SSL handshaking to upstream, client: 2a02:810d:c0:9ef1:372a:20b8:38ac:ffa3, server: foo.nebulon.space, request: "GET / HTTP/2.0", upstream: "https://104.21.0.239:443/", host: "foo.nebulon.space"

Not yet sure how to solve this correctly.

[robi]

Yes, interesting!

There should be a way to make nginx either allow remote proxying, separating the cert from the IP, or stop checking for the page by IP since only the domain can deliver the page data.

[nebulon]

Still investigating, but to take a step back, is this just a random test or an actual use-case to put Cloudron in front of a public page served up by Cloudflare?

[girish]

I think this behavior is expected. When designing the App Proxy we had to decide what use case it is for. It is designed to front apps with a certificate and subdomain managed by Cloudron. We have thus configured nginx to set the Host header to the Cloudron App Proxy name (i.e downloader.demo.cloudron.io) when making the proxy request. The target/destination (since this is an app that is in the control of the admin trying to front the app) has to be configured accordingly.

In this case, trying to mirror a 3rd party website is not going to work. The 3rd party site will see that the request is intended for downloader.demo.cloudron.io and the TLS SNI verification will fail.

[girish]

I remember researching this topic about mirroring back then. See https://github.com/NginxProxyManager/nginx-proxy-manager/issues/127#issuecomment-485977281 and especially https://github.com/NginxProxyManager/nginx-proxy-manager/issues/127#issuecomment-485986744 . We tried to mimic nginx proxy manager as the default behavior.

Some more recent discussion here - https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2675 . There's actually many issues there on this very topic

[robi]

@nebulon random.

@girish would it be best to serve a custom error message to that effect? Reveal the mystery, so to speak.

[girish]

I remember trying to play around with this long ago. Issue was some apps respond with 502 and an error page. We want the error page to pass through in that case. I didn't find a way to distinguish "cannot contact upstream" vs "upstream caused 502" and give different error pages.

[robi]

@girish ok, then it stays as it is. Add a note in the docs?

[nebulon]

@robi just for my understanding, did you have a specific use-case for this or was it more like a test?

[girish]

Added a note in docs.

[robi]

@nebulon test, as in previous testing proxying across cloudrons, and to other search engines worked just fine, and these tools sites, didn't.