HAproxy redirects to localhost

I am running Raspbian on a Raspberry Pi at home, hosting my own Nextcloud instance using Apache2 as the webserver. In order to make it accessible from outside and look “professional” with my own URL without any port numbers attached, I am using the following setup:

  • My domain (let’s call it iyassin.de) is attached to my CentOS-based managed webspace (Uberspace, if anyone knows them)
  • Subdomain cloud.iyassin.de is created as a folder in the webroot, containing a .htaccess with the following code in order to direct all traffic to HAproxy:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Server} ^$
RewriteRule (.*) http://localhost:12345/$1 [P]
  • Managed webspace is running an HAproxy instance listening on port 12345, pointing to nextcloud.mydyndnsservice.eu:443
  • Apache2 on Raspberry Pi answers the request using a VirtualHost configuration matching cloud.iyassin.de and serving the correct Letsencrypt SSL certificate that I have copied to the Pi from the managed webspace. It also has its own certificate when accessed directly through nextcloud.mydyndnsservice.eu:443, so that the connection to HAproxy is also encryped.

This used to work perfectly for over a year, redirecting my browser to https://cloud.iyassin.de/index.php/login. A few days ago, it failed - when I access https://cloud.iyassin.de, it’ll redirect now my browser to https://localhost:12345/index.php/login which of course fails.

What could this be caused by? The Apache rewrite is still working, as I can change the port number. The HAproxy is working, as killing it will produce an 503 error instead of the wrong redirection. Also it establishes the connection to my Raspberry Pi as it gets the correct login path, but it just fails to correctly rewrite the URL.

Here’s my haproxy.cfg as well:

global

frontend HTTP
	bind			127.0.0.1:63847
	mode			http
	timeout client		5000
	
	acl			a_example hdr(X-Forwarded-Host) -i cloud.iyassin.de
	use_backend		b_example if a_example

	default_backend		uberspace_81

backend uberspace_81
	mode	http
	timeout connect		3000
	timeout server		3000
	server	uberspace 123.456.789.123:81

backend b_example
	mode	http
	timeout connect		5000
	timeout server		7200000
	server	server1-a nextcloud.mydyndnsservice.eu:443 ssl ca-file /etc/ssl/certs/ca-bundle.trust.crt

Did you update anything at all?

Nextcloud maybe?

It just reminds me of an issue I had trying to reverse proxy vmware vsphere web client, I found myself needing to do more than just a normal re-write because location headers were being written in replies(or something like that). I wonder if Nextcloud might have updated their way of doing things, maybe we need to rewrite some headers or something similar.

Actually I recently updated Nextcloud to version 15, yes! I’m not sure if that coincided with when the problem first occured, but it was definitely still working when I was still running Nextcloud 14. Also the Raspberry Pi’s Let’s Encrypt certificate recently self-renewed. Otherwise, the Raspberry Pi’s OS as well as everything running on the managed webspace stayed untouched.

How can I check if Nextcloud is handling something differently since the version 15 upgrade?