Skip to main content

360 ICT, reliability guaranteed

Reverse proxy with Nextcloud

So we wanted to migrate our OwnCloud environment to Nextcloud. As we want to use all kinds of new features of Nextcloud, we decided we want to have both environments available and migrate little by little. As we have a limited number of public IP addresses, we are using load balancing based on host headers. This is an old technique being used a lot at website hosters and it can be done on a webserver level but also by a reverse proxy. We have some luxury as we we use all the products we are selling and we have a Sophos UTM and Kemp Loadbalancers in our offiice environment, and both can handle traffic based on host headers. We decided to do this on the Kemp, as it has much lower load than the Sophos UTM firewall.

We expect this will be a common customer question, so that’s the reason for this blogpost. If you want to know more about routing traffic based on host headers, there is an  in depth manual for content rules at the Kemp website. If that goes to deep for you, I recommend Michael’s blogpost which is more practical.

So we start out with this scenario;

So this can be configured by creating 2 content rules and 2 Nextcloud instances by creating a Virtual Service (VS) and subVS. This seams a mouthfull, but it’s actually not that much to configure and it’s all in the below picture;

However, there are some details in this picture which I want to mention;

  • You have to enable content switching in the main VS.
  • Turn the SSL acceleration on with the reencypt option and select a certificate which contains both domains (SAN certificate) or use a wildcard certificate (*.customer.com).
  • You have to create some content rules. In the Kemp this is based on Perl Compatible Regular Expressions (PCRE)
    • owncloud.customer.com –> / ^owncloud.customer.com.*/
      nextcloud.customer.com –> / ^nextcloud.customer.com.*/
    • The content rules need to be assigned to the SubVS. So nextcloud.customer.com has the content rule / ^nextcloud.customer.com.*/ assigned (thats the 1 onder the column Rules in the row Id 347/351)
  • Set the gateway of your Nextcloud instances to the Kemp gateway.
  • I added the IP of the VS to the trusted domains of Nextcloud, but I don’t think it’s necessary here.
  • Be sure to use HTTP 1.1 health checks, Didier has an excellent post on this, so I won’t go in detail.

But after testing we had some weird behaviour, the login page would load but the login would fail, but it would work after a refresh. Also, a background refresh in Chrome did some weird things, look at this picture;

Also, the webdav connection wouldn’t work. On Linux it gave me “corrupt header” and on Windows it said “error 59”.

So after some troubleshooting I found out it to be the technique for forwarding the HTTP headers was set to “Legacy Operation (X-ClientSide);

After setting this to “X-Forwarded-For”, everything worked fine. It’s actually being mentioned at the Nextcloud documentation;

“In the event that a load balancer is in place there will be no issues as long as it sends the correct X-Forwarded-Host header”

I saw some support threads on the forum about issues with reverse proxies, so I hope I saved someone some time with configuring Nextcloud with reverse proxies..😉

Request Information

Do you want to know more about Reverse proxy with Nextcloud? Easily request more information.

More Blog Items