✓ Solved

Redirecting subdomain to marketplace NextCloud

Hey there,

I've previously installed NextCloud via the Marketplace, and gotten it setup and running; that was using (example) https://123-123-123-123.ip.linodeusercontent.com/. At the same time, I had Nginx serving my static website on www.example.com. The setup was working fine, and I was able to access both sites via their respective URLs.

I'm now trying to set up a subdomain, such that next.example.com will redirect to the running NextCloud instance. However, in my Nginx sites-available config file, I'm not sure what I should be using for my root and proxy-pass variables specifically since, if I'm not mistaken, NextCloud installed via the Marketplace is running in a Docker container.

Is such a setup, with a subdomain redirecting to my (containerised) NextCloud instance, possible? And if so, what values should I be using in my Nginx config?

Not even sure this kind of specific setup is possible, but any advice is appreciated.

🙏

3 Replies

✓ Best Answer

Okay, I think I've fixed it up. I'd followed the steps in the reverse proxy guide well enough, but had one more thing to do. The last required step was to log into the NextCloud container itself using:
sudo docker exec -it nextcloud-aio-nextcloud sh

Then, I had to edit the following file & replace every instance of the default rDNS with my new domain name:
/var/www/html/config/config.php

I think that was everything. I've since rebooted the machine & container, and now my subdomain is correctly redirecting to my NextCloud instance.

You don't actually need to set up a reverse proxy to change the domain of your NextCloud instance. I followed the directions found in this comment on the NextCloud Github page and was able to change my domain from the default rDNS to my custom domain name.

Essentially, what you need to do is edit the configuration.json file with your new domain, then reboot your instance.

However, if you'd like to set up a reverse proxy for your NextCloud instance, again, the NextCloud Github page is a great resource. They have extensive examples for reverse proxy configs such as this one for Nginx:

map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}

server {
    listen 80;
    listen [::]:80;            # comment to disable IPv6

    if ($scheme = "http") {
        return 301 https://$host$request_uri;
    }

    listen 443 ssl http2;      # for nginx versions below v1.25.1
    listen [::]:443 ssl http2; # for nginx versions below v1.25.1 - comment to disable IPv6

    # listen 443 ssl;      # for nginx v1.25.1+
    # listen [::]:443 ssl; # for nginx v1.25.1+ - keep comment to disable IPv6

    # http2 on;                                 # uncomment to enable HTTP/2        - supported on nginx v1.25.1+
    # http3 on;                                 # uncomment to enable HTTP/3 / QUIC - supported on nginx v1.25.0+
    # quic_retry on;                            # uncomment to enable HTTP/3 / QUIC - supported on nginx v1.25.0+
    # add_header Alt-Svc 'h3=":443"; ma=86400'; # uncomment to enable HTTP/3 / QUIC - supported on nginx v1.25.0+
    # listen 443 quic reuseport;       # uncomment to enable HTTP/3 / QUIC - supported on nginx v1.25.0+ - please remove "reuseport" if there is already another quic listener on port 443 with enabled reuseport
    # listen [::]:443 quic reuseport;  # uncomment to enable HTTP/3 / QUIC - supported on nginx v1.25.0+ - please remove "reuseport" if there is already another quic listener on port 443 with enabled reuseport - keep comment to disable IPv6

    server_name <your-nc-domain>;

    location / {
        proxy_pass http://127.0.0.1:11000$request_uri;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Port $server_port;
        proxy_set_header X-Forwarded-Scheme $scheme;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Accept-Encoding "";
        proxy_set_header Host $host;

        client_body_buffer_size 512k;
        proxy_read_timeout 86400s;
        client_max_body_size 0;

        # Websocket
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
    }

    ssl_certificate /etc/letsencrypt/live/<your-nc-domain>/fullchain.pem;   # managed by certbot on host machine
    ssl_certificate_key /etc/letsencrypt/live/<your-nc-domain>/privkey.pem; # managed by certbot on host machine

    ssl_session_timeout 1d;
    ssl_session_cache shared:MozSSL:10m; # about 40000 sessions
    ssl_session_tickets off;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers on;

    # Optional settings:

    # OCSP stapling
    # ssl_stapling on;
    # ssl_stapling_verify on;
    # ssl_trusted_certificate /etc/letsencrypt/live/<your-nc-domain>/chain.pem;

    # replace with the IP address of your resolver
    # resolver 127.0.0.1; # needed for oscp stapling: e.g. use 94.140.15.15 for adguard / 1.1.1.1 for cloudflared or 8.8.8.8 for google - you can use the same nameserver as listed in your /etc/resolv.conf file
}

Thanks for this breakdown, I've been trying to work through these instructions (and the linked guides) for a few days now. In the end, I think I do want to use the reverse proxy method, since I'll also be running a few other services (with associated subdomains) on the compute instance (this is a personal server, so I'm not worried about overuse).

I think I'm getting close, working through your linked reverse proxy guide. However, when I try to connect to next.example.com or next.example.com:8443, I get the following errors in /var/log/nginx/error.log (respectively):

next.example.com:

[error] 3698144#3698144: *16957 connect() failed (111: Unknown error) while connecting to upstream, client: 24.212.246.7, server: next.example.com, request: "GET / HTTP/2.0", upstream: "http://127.0.0.1:11000/", host: "next.example.com"

next.example.com:8443:

[error] 3698144#3698144: *16953 connect() failed (111: Unknown error) while connecting to upstream, client: 24.212.246.7, server: next.example.com, request: "GET / HTTP/2.0", upstream: "http://127.0.0.1:11000/", host: "next.example.com:8443"
[error] 3698144#3698144: *16953 connect() failed (111: Unknown error) while connecting to upstream, client: 24.212.246.7, server: next.example.com, request: "GET /favicon.ico HTTP/2.0", upstream: "http://127.0.0.1:11000/favicon.ico", host: "next.example.com:8443", referrer: "https://next.example.com:8443/"

[EDIT: oh, I should also mention that when I try to access these sites, I get a "502 Bad Gateway" error in-browser]

I'm using the Nginx config listed here, with the appropriate lines commented out (the instance is running Nginx 1.18.0). It seems like Nginx is struggling to send traffic on to 127.0.0.1:11000? Is there some way to verify that NextCloud is indeed running & configured properly to match the Nginx conf? I ran the NC container using the listed startup command, and didn't see any errors.

As a little secondary question, I have a Let's Encrypt cert on this instance, and I want to follow the guide to use that same certificate when accessing my next.example.com subdomain publicly. According to the guide, I need to edit my Caddyfile… but I'm not sure where to find that file. Should it be accessible, or are Caddyfiles only for different configurations?

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct