Nextcloud-AIO mit Docker und HTTPS LAN-only

[>|Sh4d0w|<]

Hallo zusammen,
ich bin noch recht neu in der Linux Welt. Ich habe mir mal zum Test einen Proxmox aufgesetzt, auf dem ich eine Ubuntu-VM installiert habe. Auf dem Ubuntu läuft Docker und darüber habe ich eine Nextcloud-AIO deployed.

Ich habe den Domain-Check deaktiviert und nutze als hostname nextcloud.local.
Beim Aufruf von https://nextcloud.local erhalte ich eine ERR_SSL Meldung und es hat wohl was mit einem ungültigen Zertifikat für https zu tun. Ich habe darufhin ein selbstsigniertes Zertifikat erstellt:

openssl req -x509 -newkey rsa:4096 -nodes -keyout nextcloud.key -out nextcloud.crt -days 365     -subj "/CN=nextcloud.local"

und beide .crt und .key Dateien nach /var/lib/docker/volumes/nextcloud_aio_mastercontainer/_data/certs/ kopiert und ersetzt.
Anschließend den nextcloud_aio_mastercontainer Container neugestartet. Das Problem besteht weiterhin.

Mein Compose sieht folgendermaßen aus:

sudo docker run -d \
  --init \
  --sig-proxy=false \
  --name nextcloud-aio-mastercontainer \
  --restart always \
  --publish 8080:8080 \
  --env NEXTCLOUD_TRUSTED_DOMAINS="nextcloud.local" \
  --env SKIP_DOMAIN_VALIDATION="true" \
  --volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config \
  --volume /var/run/docker.sock:/var/run/docker.sock:ro \
  ghcr.io/nextcloud-releases/all-in-one:latest

Einen normalen Nextcloud Container habe ich schon erfolgreich zum Laufen gebracht (http). Ich wollte mir aber gerne mal die AIO Variante genauer ansehen, da sie gleich mehrere sinnvolle Dinge mitbringt.

Und ja LAN-Only. Ich möchte nichts nach außen freigeben und greife von außerhalb bereits per VPN auf mein LAN zu (Wireguard).

 

[andy_m4]

Ich habe darufhin ein selbstsigniertes Zertifikat erstellt

Du musst das Zertifikat natürlich auch auf dem Client (Browser) "installieren". Das kennt es ja sonst nicht.

Oder was war jetzt Deine Frage?

 

[DiabloJulian]

Ich würde hier Mal anfangen, kann etwas Tricky sein: https://github.com/nextcloud/all-in-one?tab=readme-ov-file#how-can-i-access-nextcloud-locally

 

[madmax2010]

• SSL aus lassen
• Domain besorgen, mit DNS challenge wildcard cert holen und lokal ausrollen
• Self signed Cert erstellen und auf allen clients installieren

sind so deine gaengigen moeglichkeiten

 

[>|Sh4d0w|<]

Guter Einwand. Das Zertifikat (crt, öffentlicher Teil) habe ich auf meinem PC installiert und es funktioniert trotzdem nicht. Im Browser erscheint der Fehlercode "SSL_ERROR_INTERNAL_ERROR_ALERT".

Ohne SSL, also http://nextcloud.local funktioniert es ebenfalls nicht. Eine Domain wollte ich nicht besorgen, da es ja nur lokal laufen soll.

Wenn ich den Nextcloud Client mit der https://nextcloud.local Adresse versuche zu connecten, kann ich ein Zertifikat auswählen (pkcs12) und es hochladen? Ich ahbe aber nur eine .key im nicht-binärformat und kein Passwort

 

[empower]

es gibt gute scripte für proxmox, auch um nextcloud zu installieren https://community-scripts.github.io/ProxmoxVE/scripts?id=nextcloud-vm

 

[prayhe]

Eine Domain wollte ich nicht besorgen, da es ja nur lokal laufen soll.

Das schließt sich nicht aus. Hab auch ne günstige Domain, die auf eine lokale IP-Adresse bei mir im Netzwerk zeigt. Per DNS challenge wird dann regelmäßig ein passendes Zertifikat bei Let's Encrypt besorgt und automatisch im reverse proxy hinterlegt.

 

[RedPanda05]

Einen normalen Nextcloud Container habe ich schon erfolgreich zum Laufen gebracht (http). Ich wollte mir aber gerne mal die AIO Variante genauer ansehen, da sie gleich mehrere sinnvolle Dinge mitbringt.

Und ja LAN-Only. Ich möchte nichts nach außen freigeben und greife von außerhalb bereits per VPN auf mein LAN zu (Wireguard).

Genau hier hast du dir selbst die Lösung geliefert. Der Nextcloud AIO Container ist gar nicht darauf ausgelegt, dass dieser nicht im Internet hängt (die genaue Konfig habe ich mir auch nie angesehen). Verwende einfach normales Nextcloud, das ist fur den Einsatzzweck geeigneter

 

[>|Sh4d0w|<]

den AIO Container muss man doch irgendwie zum Laufen bekommen, gibt ja sicherlich "Tricks"

@prayhe Wie genau funktioniert das dann (Einrichtung)?

 

[madmax2010]

1. domain kaufen
2. Beim provider A Record auf bspw. 192.168.1.123 oder CNAME auf nextcloud.local. setzen
3. certbot installieren
4. sudo certbot certonly --manual --preferred-challenges=dns --email user@example.com --server https://acme-v02.api.letsencrypt.org/directory --agree-tos -d *.sh4d0wcl0ud.de
5. cert nutzen

oder so.

ABer schon witztig..
Als ich damit angefangen habe, war es schmerzhaft richtige Zertifikate zu bekommen und zu nutzen. Jetzt ist der weg oft der einfachere. In so wenigen Jahren

 

[>|Sh4d0w|<]

@madmax2010 Ich kann also jeden x-beliebige Domainnamen für wenige € kaufen, der keinen Bezug auf mein LAN hat...

Von der Ablauf funktioniert das dann so:
- Die Anfrage prüft, ob der Hostname sh4d0wcl0ud.de enthält und bekommt per A-Record zurück, dass es sich um den Namen nextcloud.local (oder eine lokale IP) handelt --> Somit korrekt beim Aufruf einer https Seite ?

Habe damit noch keine Praxiserfahrung, daher meine Bonusfrage =)

 

[madmax2010]

So kann das mit einer normalen Domain aussehen.

Das dir die Domain gehört, wird mit dem certbot Befehl verifiziert. Während der durchläuft wirst du gebeten einen txt Eintrag beim Domain Anbieter zu setzen. Der wird gelesen und dann bekommst du das cert.
Die dns challenge ist da, damit du deinen Webserver nicht öffentlich erreichbar habe musst.
Es gibt Tools wie Lego, die das ganze noch vereinfachen
Ich habe dafür noch einen kleinen wrapper gebaut, der das noch einfacher macht. Poste ich dir morgen mal

 

[bergprinzess]

ich nutze wenn ich lokal was testen will (ohne SSL) schnell mal den Container https://github.com/nextcloud/docker . Der ist in wenigen Minuten erstellt und einsatzbereit. Ich hatte vor der Dockernutzung Nextcloud On Premise normal installiert und per integriertem Apache Zertifikat das Snakeoil Zertifikat https laufen gehabt. Seitdem ich meine Instanz online im Internet habe nutze ich nur noch den AOI Container. Die Nutzung und Wartung ist um längen einfacher und kostet mich nicht gleich wieder Stunden wenn ein Update mal was will ;-)

 

[Astorek86]

Es gibt auch von den sog. Linuxserver-Leuten eine Variante von Nextcloud, die von Haus aus ein (selbstsigniertes) Zertifikat, und generell mMn. gute Vorkonfiguration mitbringt:

https://docs.linuxserver.io/images/docker-nextcloud

Nutze ich pers. seit ca. einem halben Jahr ohne Probleme in Kombination mit einem ReverseProxy, um ein "richtiges" (Lets Encrypt-)Zertifikat zu erhalten.

 

[>|Sh4d0w|<]

@madmax2010
ich habe mir jetzt günstig eine Domain gekauft

Ich habe den A Record auf nextcloud.local und als lokale IP die 192.168.0.192 gesetzt (TTL 5 Min)

Bei der Challenge via:

sudo certbot certonly --manual --preferred-challenges=dns --email meinemail@gmx.de --server https://acme-v02.api.letsencrypt.org/directory --agree-tos  -d *.blablabla.xyz

habe ich noch den TXT Record mit dem Wert _acme-challenge.blablabla.xyz und den erzeugten Key reinkopiert (TTL 1Min).

Die Challenge scheitert mit der Begründung:

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
  Domain: blablabla.xyz
  Type:   dns
  Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.blablabla.xyz - check that a DNS record exists for this domain

Hint: The Certificate Authority failed to verify the manually created DNS TXT records. Ensure that you created these in the correct location, or try waiting longer for DNS propagation on the next attempt.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

Er kann also den Txt Record nicht prüfen ... Einmal habe ich nach Eingabe des Values sofort Enter gedrückt und einmal mind. zwei Minuten gewartet. Beides klappte nicht.

Die Cloud soll ausschließlich lokal laufen und nicht per Port-Forwarding nach außen hin offen sein.

Ach und irgendwo habe ich noch ein "IP Problem". Wenn ich auf dem Host den Host mit nextcloud.local anpinge erhalte ich 127.0.1.1 zurück (nicht 127.0.0.1). Wenn ich von einer Windows Maschine anpinge, dann erhalte ich eine Fehler, da 0.0.0.0 nicht erreicht werden kann. Ich habe also mal auf die "schnelle die IP in die hosts Datei eingetragen. Woran kann das liegen

 

[madmax2010]

mit dig kannst du checken ob der record gesetzt ist

dig @192.168.178.1 -t txt _acme-challenge.lablabla.xyz
@192.168.178.1 -> schau auf der frizbox nach, ob sie den txt eintrag sieht
@8.8.8.8 schaut zum beispiel auf den DNS servern von google

Ergänzung (Samstag um 04:51)

welchen domainanbieter hast du genommen?

#!/usr/bin/env bash
# lego-cert-ui.sh — interactive terminal UI to refresh only the certificates you choose.
#
# REQUIREMENTS:
#   * whiptail   (Debian/Ubuntu:  apt-get install whiptail)
#   * lego       (binary placed at /usr/local/bin/lego or tweak LEGO_BIN)
#
# USAGE:
#   sudo ./lego-cert-ui.sh        # run, tick the domains, hit OK ➜ only those are issued/renewed+deployed
#   Put it in cron/systemd timer if you wish; script exits quietly if nothing chosen.
#
#
set -euo pipefail

############################################
# 1) GLOBAL CONFIGURATION
############################################
EMAIL="admin@example.com"                 # ACME contact e‑mail
LEGO_BIN="/usr/local/bin/lego"          # path to lego binary
LEGO_CERT_DIR="/root/.lego/certificates" # where lego stores issued certs
LIVE_DIR_BASE="/etc/letsencrypt/live"    # final Let’s‑Encrypt‑style tree

# ---- API credentials --------------------------------------------------
export SPACESHIP_API_KEY="wertyuoiuytr5e6uoi"
export SPACESHIP_API_SECRET="fertyuipoiuytdsfghjkli7986r"
export HETZNER_API_KEY="sssssssssssssss"

# ---- Domains ----------------------------------------------------------
#  Edit these arrays. Either may be empty; unlimited domains per provider.
spaceship_domains=(example1.com example2.com)      # e.g.  spaceship_domains=(site1.com site2.com)
hetzner_domains=(example3.com)                 # e.g.  hetzner_domains=(example.net)

############################################
# 2) HELPER FUNCTIONS
############################################
issue_cert() {
  local provider="$1" domain="$2"
  echo "\n▶️  Issuing/renewing ${domain} via ${provider}…"
  "${LEGO_BIN}" --email "${EMAIL}" \
                --dns "${provider}" \
                --domains "${domain}" --domains "*.${domain}" \
                run
}

deploy_cert() {
  local domain="$1"
  local src="${LEGO_CERT_DIR}/${domain}"
  local dst="${LIVE_DIR_BASE}/${domain}"

  mkdir -p "${dst}"
  cp  "${src}.crt"         "${dst}/cert.pem"
  cp  "${src}.key"         "${dst}/privkey.pem"
  cp  "${src}.issuer.crt"  "${dst}/chain.pem"
  cat "${src}.crt" "${src}.issuer.crt" > "${dst}/fullchain.pem"

  chown root:root "${dst}"/*.pem
  chmod 600 "${dst}/privkey.pem"
  chmod 644 "${dst}"/{cert,chain,fullchain}.pem
  echo "✅ Deployed → ${dst}"
}

############################################
# 3) TERMINAL UI (whiptail checklist)
############################################
if ! command -v whiptail &>/dev/null; then
  echo "Error: whiptail command not found.  Install it (Debian/Ubuntu: apt-get install whiptail)" >&2
  exit 1
fi

options=()
for d in "${spaceship_domains[@]:-}"; do
  options+=("spaceship:${d}" "Spaceship    ${d}" off)
done
for d in "${hetzner_domains[@]:-}"; do
  options+=("hetzner:${d}"   "Hetzner      ${d}"   off)
done

if (( ${#options[@]} == 0 )); then
  echo "No domains configured.  Edit spaceship_domains / hetzner_domains arrays." >&2
  exit 1
fi

selected=$(whiptail --title "Lego certificate refresh" \
  --checklist "Select the domains to refresh (Space = mark, Tab = next, Enter = OK)" \
  20 78 12 \
  "${options[@]}" \
  3>&1 1>&2 2>&3 ) || exit 1

# whiptail returns e.g.:  "spaceship:site1.com" "hetzner:example.net"
read -ra list <<<"${selected}"
if (( ${#list[@]} == 0 )); then
  echo "Nothing selected – exiting."
  exit 0
fi

############################################
# 4) PROCESS SELECTION
############################################
for item in "${list[@]}"; do
  item=${item//\"/}         # strip any surrounding quotes
  provider=${item%%:*}
  domain=${item#*:}

  issue_cert "${provider}" "${domain}"
  deploy_cert "${domain}"

done

echo "\n All requested certificates processed successfully."

habe da dieses halbfertige bashscript mit 2 beispiel hosts und terminal userinterface gebautr - das nutzt LEGO und die API des jeweiligen anbieters um komfortabel fuer X domains automatisch die txt records zu setzen

 

[>|Sh4d0w|<]

Mit meinem Pihole DNS kann er die Infos abrufen:

; <<>> DiG 9.20.18-1~deb13u1-Debian <<>> @192.168.0.5 -t txt _acme-challenge.blablabla.xyz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58668
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 15 (Blocked): (regex)
;; QUESTION SECTION:
;_acme-challenge.blablabla.xyz.  IN      TXT

;; Query time: 4 msec
;; SERVER: 192.168.0.5#53(192.168.0.5) (UDP)
;; WHEN: Sat Feb 21 04:57:27 CET 2026
;; MSG SIZE  rcvd: 68

Mit dem Fritzbox Router DNS habe erhalte ich noch die AUTHORITY SECTION:

; <<>> DiG 9.20.18-1~deb13u1-Debian <<>> @192.168.0.1 -t txt _acme-challenge.blablabla.xyz
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53058
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_acme-challenge.blablabla.xyz.  IN      TXT

;; AUTHORITY SECTION:
blablabla.xyz.           3258    IN      SOA     dns1.registrar-servers.com. hostmaster.registrar-servers.com. 1771645708 43200 3600 604800 3601

;; Query time: 16 msec
;; SERVER: 192.168.0.1#53(192.168.0.1) (UDP)
;; WHEN: Sat Feb 21 04:59:07 CET 2026
;; MSG SIZE  rcvd: 130

Ich habe die Domain bei namecheap.com. Das Ändern des DNS in der /etc/resolv.conf brachte bei der Challenge keine Änderung.

 

[madmax2010]

Quick fix
Lass certbot da laufen wo pihole läuft und kopier das cert rüber

 

[>|Sh4d0w|<]

hat leider auch nicht funktioniert

EDIT:
Festgestellt, dass unter "email-services" ein forwarding eingerichtet war, obwohl ich dort keine mailbox habe. Das war auch ein Txt Eintrag, den ich mit einem Online Txt Abfrage Tool gesehen habe. Jetzt ist er gelöscht, aber der gesetzte Txt Eintrag erscheint auch online nicht. Als wäre er nicht veröffentlicht worden. Ich schaue nochmal in einigen Stunden rein. Wäre ja krass, wenn so ein langer Delay existiert.

EDIT2:
So nach einigen Stunden Abwarten und dem neuen Challengen plus Warten von 5 Minuten konnte ich die Zertifikate nun erzeugen. Ich habe auch mal geschaut, wie lange das so dauert, bis es an genügend DNS Servern ankommt:

https://dnschecker.org/#TXT/
https://www.whatsmydns.net/#TXT/


Die Certs liegen nun unter /etc/letsencrypt/live/domain/... An welcher Stelle müssen die Certs nun abgelegt werden, damit ich das Webinterface nextcloud.blablabla.xyz erreichen kann?

 

[>|Sh4d0w|<]

Ich habe nochmal einen neuen Versuch mit nginx als Reverseproxy davor versucht und folgender Anleitung:

YouTube

An dieser Stelle steht ein externer Inhalt von YouTube, der den Forumbeitrag ergänzt. Er kann mit einem Klick geladen und auch wieder ausgeblendet werden.

YouTube-Embeds laden

Ich bin damit einverstanden, dass YouTube-Embeds geladen werden. Dabei können personen­bezogene Daten an YouTube übermittelt werden. Mehr dazu in der Datenschutzerklärung.

YouTube-Embeds laden

Datenschutzerklärung

nginx -t (mal ignoriert):

2026/02/21 19:15:40 [warn] 17983#17983: conflicting server name "nextcloud.blablabla.xyz" on 0.0.0.0:80, ignored
2026/02/21 19:15:40 [warn] 17983#17983: conflicting server name "nextcloud.blablabla.xyz" on [::]:80, ignored

und die default Config unter /etc/nginx/sites-available gelöscht, da die obige Meldung sonst x2 erschien (Server Lauschen auf Port 80). Die default hatte ich ja kopiert und weiter editiert

Er macht das mit certbot --nginx, was bei mir nicht funktionierte, weil er irgendwas nicht fand. Auch die Erweiterung für certbox-nginx habe ich installiert gehabt, aber das klappte nicht. Ich rief dann die --manual variante auf:

sudo certbot certonly --manual --preferred-challenges=dns --email meinemail@gmx.de --server https://acme-v02.api.letsencrypt.org/directory --agree-tos  -d *.blablabla.xyz

Ich habe dann die Parameter, die sonst per --nginx gesetzt wären manuell in die nextcloud.blablabla.xyz nginx config übertragen.

EDIT: mittlerweile vorhanden ! - Dieser Punkt erledigt
Dort habe ich festgestellt, dass es zwei Verzeichnisse nicht gibt:
/etc/letsencrypt/options-ssl-nginx.conf --> auskommentiert
/etc/letsencrypt/ssl-dhparams.pem --> auskommentiert
EDIT: mittlerweile vorhanden ! - Dieser Punkt erledigt

server {
        listen 80;
        listen [::]:80;

        root /var/www/html;

        # Add index.php to the list if you are using PHP
        index index.html index.htm index.nginx-debian.html;

        server_name nextcloud.blablabla.xyz;

        location / {
        proxy_pass http://localhost:11000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ =404;
        }

    listen [::]:443 ssl ipv6only=on; # wäre sonst von certbot erstellt worden
    listen 443 ssl; # wäre sonst von certbot erstellt worden
    ssl_certificate /etc/letsencrypt/live/blablabla.xyz/fullchain.pem; # wäre sonst von certbot erstellt worden
    ssl_certificate_key /etc/letsencrypt/live/blablabla.xyz/privkey.pem; # wäre sonst von certbot erstellt worden
    include /etc/letsencrypt/options-ssl-nginx.conf; # wäre sonst von certbot erstellt worden
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # wäre sonst von certbot erstellt worden

}
server {
    if ($host = nextcloud.blablabla.xyz) {
        return 301 https://$host$request_uri;
    } # wäre sonst von certbot erstellt worden


        listen 80;
        listen [::]:80;

        server_name nextcloud.blablabla.xyz; # wäre sonst von certbot erstellt worden
    return 404; # wäre sonst von certbot erstellt worden

Das Docker Compose sieht bei mir so aus:

name: nextcloud-aio # Add the container to the same compose project like all the sibling containers are added to automatically.
services:
  nextcloud-aio-mastercontainer:
    image: ghcr.io/nextcloud-releases/all-in-one:latest # This is the container image used. You can switch to ghcr.io/nextcloud-releases/all-in-one:beta if you want to help testing new releases. See https://github.com/nextcloud/all-in-one#how-to-switch-the-channel
    init: true # This setting makes sure that signals from main process inside the container are correctly forwarded to children. See https://docs.docker.com/reference/compose-file/services/#init
    restart: always # This makes sure that the container starts always together with the host OS. See https://docs.docker.com/reference/compose-file/services/#restart
    container_name: nextcloud-aio-mastercontainer # This line is not allowed to be changed as otherwise AIO will not work correctly
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config # This line is not allowed to be changed as otherwise the built-in backup solution will not work
      - /var/run/docker.sock:/var/run/docker.sock:ro # May be changed on macOS, Windows or docker rootless. See the applicable documentation. If adjusting, don't forget to also set 'WATCHTOWER_DOCKER_SOCKET_PATH'!
    network_mode: bridge # This adds the container to the same network as docker run would do. Comment this line and uncomment the line below and the networks section at the end of the file if you want to define a custom MTU size for the docker network
    # networks: ["nextcloud-aio"]
    ports:
      # - 80:80 # Can be removed when running behind a web server or reverse proxy (like Apache, Nginx, Caddy, Cloudflare Tunnel and else). See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
      - 8080:8080 # This is the AIO interface, served via https and self-signed certificate. See https://github.com/nextcloud/all-in-one#explanation-of-used-ports
      # - 8443:8443 # Can be removed when running behind a web server or reverse proxy (like Apache, Nginx, Caddy, Cloudflare Tunnel and else). See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
    # security_opt: ["label:disable"] # Is needed when using SELinux. See https://github.com/nextcloud/all-in-one#are-there-known-problems-when-selinux-is-enabled
    environment: # Is needed when using any of the options below
      APACHE_PORT: 11000 # Is needed when running behind a web server or reverse proxy (like Apache, Nginx, Caddy, Cloudflare Tunnel and else). See https://github.com/nextcloud/all-in-one/blob/main/reverse-proxy.md
      SKIP_DOMAIN_VALIDATION: true # This should only be set to true if things are correctly configured. See https://github.com/nextcloud/all-in-one#how-to-skip-the-domain-validation

volumes: # If you want to store the data on a different drive, see https://github.com/nextcloud/all-in-one#how-to-store-the-filesinstallation-on-a-separate-drive
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer # This line is not allowed to be changed as otherwise the built-in backup solution will not work

Die Container sind alle gepullt und laufen, sowie eingerichtet. Beim Aufruf der Nextcloud erhalte ich den Fehler 404 Not Found - nginx

Folgende Adressen im Browser habe ich probiert.
https://nextcloud.blablabla.xyz
https://192.168.0.195

Die Adresse nextcloud.blablabla.xyz kann von meinen PC nicht aufgelöst werden. Ich habe es mal schnell in meine host Datei geschrieben. Die lokale IP 192.168.0.195 der Debian VM mit Nextcloud AIO ist bereits öffentlich aufrufbar und der A-Record verweist von der Domain nextcloud.blablabla.xyz auf diese IP.

Woran kann es liegen?


EDIT:
Ich habe den Mist endlich zum Fliegen gebracht Ein Problem war wohl die try_files in meiner nginx Konfig, der sonst nach lokalen Dateien suchte, die es nicht gab.