Wildcard-DNS (*.domain.de) einrichten: Cloudflare, Pangolin & Coolify

Das letzte Update war vor 5. November 2026 von Benedikt Schächner

Wildcard-DNS einrichten: Mit *.example.com leitest du viele Subdomains auf ein gemeinsames Ziel. Hier legst du den Eintrag bei Cloudflare an und verbindest anschließend konkrete Dienste mit Pangolin, Coolify oder einem Cloudflare Tunnel.

Das Ergebnis: Du kannst A- und CNAME-Einträge prüfen, verstehst den Unterschied zwischen DNS-Wildcard und TLS-Wildcard und weißt, warum eine DNS-Auflösung noch keine funktionierende App-Route erzeugt.

Stand: 3. November 2026. Die Schritte basieren auf den aktuellen Cloudflare-, Coolify- und Pangolin-Dokumentationen. Alle verwendeten Serveradressen und Domains in Beispielen sind Platzhalter. Ändere DNS produktiver Dienste erst nach Bestandsaufnahme, damit vorhandene Cloud-, Mail- und Webangebote erreichbar bleiben.

1. DNS, Reverse Proxy und Webserver: drei unterschiedliche Aufgaben

Bei einem Aufruf von https://photos.example.com laufen mehrere technische Schritte ab: Das DNS löst den Hostnamen auf, der Browser baut eine verschlüsselte Verbindung zum zuständigen Endpunkt auf, und ein Reverse Proxy entscheidet anhand des Hostnamens beziehungsweise einer Routing-Regel, welcher interne Container oder Server die Anfrage bekommt. Erst dieser Zielserver liefert die Website.

Ein einzelner Server kann deshalb viele Subdomains auf einer öffentlichen IP und denselben Ports 80/443 bedienen. Du musst bei DNS nicht den Docker-Port 3000 oder 8123 angeben. Diesen legt der Reverse Proxy im internen Target fest.

https://photos.example.com
          |
          v
     DNS A / CNAME
          |
          v
       Gateway
  Cloudflare / Traefik / Pangolin
          |
          +--> Host photos.example.com --> 192.168.1.50:2283
          +--> Host ha.example.com     --> 192.168.1.60:8123

2. Welche DNS-Einträge brauche ich?

• A: Hostname auf eine IPv4-Adresse, zum Beispiel app → 203.0.113.20.
• AAAA: Hostname auf eine IPv6-Adresse. Nur setzen, wenn der Dienst wirklich über IPv6 erreichbar ist.
• CNAME: Hostname als Alias zu einem anderen Namen, beispielsweise zu einer Cloudflare-Tunnel-Adresse.
• TXT: Textnachweis, zum Beispiel für ACME-DNS-01 oder E-Mail-Authentifizierung.
• MX: Mailserver-Zustellung. DNS-Änderungen für Webhosting dürfen bestehende MX-/SPF-/DKIM-/DMARC-Einträge nicht versehentlich ersetzen.

Die Hauptdomain heißt technisch auch Zone Apex und wird bei vielen Anbietern als @ angezeigt. www, blog und app sind Hostlabels innerhalb der Zone.

3. Wildcard-DNS: Was bedeutet *.example.com genau?

*.example.com ist ein Wildcard-DNS-Eintrag. Wenn kein spezifischerer Eintrag oder eine andere DNS-Regel greift, kann er Anfragen an viele Subdomains auf dasselbe Ziel auflösen. Das spart Verwaltungsaufwand bei Dutzenden selbst gehosteten Diensten.

Typ: A
Name: *
IPv4: 203.0.113.20
TTL: Auto

Damit können beispielsweise photos.example.com, ha.example.com und notes.example.com die gleiche IP erhalten. Nicht enthalten ist die Hauptdomain example.com; dafür benötigst du einen eigenen @-Eintrag.

Bei Cloudflare ist ein *.example.com-DNS-Wildcard standardmäßig sogar auf tiefere, ansonsten nicht belegte Namen erweiterbar. Das heißt aber nicht, dass ein TLS-Zertifikat für *.example.com ebenfalls dev.app.example.com schützt. DNS-Matching und Zertifikatsabdeckung sind strikt getrennte Themen. Außerdem haben bestehende exakte DNS-Einträge Vorrang und können Wildcard-Matching für darunterliegende Namen beeinflussen.

4. Einen Wildcard-A-Eintrag bei Cloudflare erstellen

• Cloudflare öffnen und die richtige Domainzone auswählen.
• Unter DNS → Records → Add record gehen.
• Als Type A auswählen und im Feld Name ein einzelnes * eingeben.
• Als IPv4-Adresse die öffentliche IP des richtigen Reverse-Proxys eintragen, im Beispiel 203.0.113.20.
• Für die anfängliche Einrichtung ohne Cloudflare als HTTP-Proxy DNS only wählen; für den späteren Cloudflare-Proxy-Modus kann die orange Wolke bewusst aktiviert werden.
• Speichern, DNS-Auflösung prüfen und im eigentlichen Reverse Proxy mindestens eine passende Ressourcenroute anlegen.

Screenshot-Quelle: RunTipi-Dokumentation zur Cloudflare-DNS-Konfiguration. Die Beispiel-IP und Oberfläche stammen aus der Quelle und sind nicht die Daten eines Lesers.

Setze bei einem echten produktiven Server keine private Adresse wie 192.168.x.x in einen öffentlich nutzbaren A-Eintrag, sofern du nicht bewusst Split-DNS für ein ausschließlich internes Netz betreibst. Für den normalen Internetzugriff benötigt ein direkter A-Eintrag eine öffentlich erreichbare Adresse. Cloudflare Tunnel ist die Alternative ohne direkten öffentlichen Origin-Zugriff.

5. Eine einzelne Subdomain trotz Wildcard anders routen

Ein häufiger Fall: Alle neuen Dienste sollen über Pangolin laufen, aber cloud.example.com soll zunächst über den bereits vorhandenen Cloudflare Tunnel zu Nextcloud führen. Dann bleibt ein eigener expliziter DNS-Eintrag für cloud bestehen. Er hat gegenüber dem allgemeinen Wildcard-Eintrag Vorrang.

Typ     Name       Ziel                              Modus
A       *          203.0.113.20                      DNS only
CNAME   cloud      TUNNEL-UUID.cfargotunnel.com      Proxied
A       @          203.0.113.30                      optional

So kannst du Dienste schrittweise migrieren, statt alle Subdomains auf einmal umzurouten. Kontrolliere dazu immer den tatsächlichen DNS-Anbieter, die vorhandenen A/AAAA/CNAME-Einträge und die Cloudflare-Tunnel-Published-Application-Routen. Ein neuer Wildcard-Eintrag sollte nie ohne Analyse die produktive Web- oder Mail-Infrastruktur ersetzen.

6. Domain konkret mit Pangolin verbinden

• Pangolin auf einem dafür vorgesehenen, erreichbaren Gateway installieren und das Dashboard unter einem festen Hostnamen wie pangolin.example.com einrichten.
• Den Dashboard-Host und optional * mit der Gateway-IP per A/AAAA auflösen lassen.
• In Pangolin eine Organisation und eine Site anlegen und den privaten Server per Pangolin Site/Newt verbinden.
• Eine Ressource mit dem Hostnamen photos.example.com erstellen.
• Als Target die vom Connector erreichbare private Ziel-IP und den Dienstport festlegen, beispielsweise 192.168.1.50:2283.
• HTTPS-Zertifikat und Zugriffskontrolle konfigurieren. Den Browseraufruf testen.

Wichtig: Pangolin-Ressourcen erhalten nicht automatisch für jede durch Wildcard-DNS aufgelöste Subdomain eine funktionierende Route. Der Hostname muss zu einer definierten öffentlichen Ressource passen.

7. Domain konkret mit Coolify verbinden

• In Coolify den Server wählen, auf dem die Anwendung tatsächlich läuft, und dort den integrierten Proxy prüfen.
• Beim DNS-Anbieter app.example.com oder einen entsprechenden Wildcard-Eintrag auf diesen Server zeigen lassen.
• In der Ressource unter Domains → Add domain die Domain mit Protokoll HTTPS einrichten.
• Den internen Zielport korrekt auswählen; :3000 in Coolify meint einen Container-Zielport, nicht den öffentlichen Besucherport.
• Speichern, Redeploy ausführen und per Browser HTTPS und Zielanwendung prüfen.

In Coolify unter Servers → Server → General → Wildcard Domain eine Basisdomain wie https://apps.example.com speichern, wenn automatisch generierte Subdomains unter *.apps.example.com entstehen sollen. Dazu gehört ein passender DNS-Wildcard-Eintrag *.apps mit der richtigen Serveradresse. Die Basisdomain-Einstellung legt nicht selbst den DNS-Record an.

8. Pangolin und Coolify gleichzeitig: Wie teilt man Domains auf?

Wenn Pangolin und Coolify getrennte Gateway- oder Hostsysteme verwenden, eignet sich eine Aufteilung nach Subdomain-Bereichen. In einer fiktiven Zone example.com könnten sichere interne Zugänge auf *.secure.example.com zu Pangolin und Webprojekte auf *.apps.example.com zu Coolify zeigen.

A    *.secure   203.0.113.10    # Pangolin-Gateway
A    *.apps     203.0.113.20    # Coolify-App-Server
A    pangolin   203.0.113.10    # Pangolin-Dashboard
A    coolify    203.0.113.20    # Coolify-Dashboard

Das bedeutet nicht, dass beide auf demselben Linux-Host gleichzeitig TCP 80 und 443 binden dürfen. Entweder die Proxys laufen auf unterschiedlichen IPs/Hosts, oder ein einziger äußerer Proxy nimmt den Webtraffic an und leitet anhand der Hostnamen intern weiter. Auch die Zertifikatszuständigkeit muss dabei eindeutig sein.

9. Cloudflare Tunnel: Ohne A-Record zur Heim-IP veröffentlichen

Mit einem Cloudflare Tunnel stellt cloudflared eine ausgehende Verbindung zum Cloudflare-Netz her. Deine öffentliche Subdomain wird üblicherweise per proxied CNAME auf <TUNNEL-ID>.cfargotunnel.com gelegt. Im Cloudflare-Dashboard legst du unter Networking → Tunnels → Routes → Add route → Published application den öffentlichen Hostnamen und die lokale Origin-Service-URL fest.

Öffentlicher Hostname: photos.example.com
DNS-Typ: CNAME
DNS-Ziel: <TUNNEL-ID>.cfargotunnel.com
Proxy: Proxied
Tunnel-Service: http://192.168.1.50:2283

Bei einem lokal verwalteten Tunnel sind auch Wildcard-Ingress-Regeln möglich. Das folgende Beispiel zeigt erst eine konkrete Anwendung und dann einen Wildcard-Host, der zu einem lokalen Reverse Proxy weiterleitet. Nutze deine echte Tunnel-ID und den tatsächlichen Credentials-Dateipfad:

tunnel: DEINE-TUNNEL-UUID
credentials-file: /etc/cloudflared/DEINE-TUNNEL-UUID.json
ingress:
  - hostname: "photos.example.com"
    service: http://192.168.1.50:2283
  - hostname: "*.example.com"
    service: http://192.168.1.20:80
  - service: http_status:404

Dazu muss es passende DNS-Zuordnungen zum Tunnel geben, zum Beispiel einen proxied Wildcard-CNAME * zum Tunnel-Hostname und bei Bedarf explizite CNAME-Records für Ausnahmen. Bei remote verwalteten Tunneln wird die Konfiguration über das Cloudflare-Dashboard gepflegt; schreibe nicht parallel eine konkurrierende lokale Konfigurationsdatei, deren Regeln dann möglicherweise gar nicht gelten.

Ganz wichtig: Der Cloudflare-Tunnel transportiert in dieser Standardkonfiguration HTTP/HTTPS zu einer Webanwendung beziehungsweise einem Reverse Proxy. Er ersetzt nicht automatisch Pangolins WireGuard-/UDP-Site-Tunnel und stellt keine beliebigen UDP-Dienste unter einer Website-Domain bereit.

10. Wildcard-SSL: Welche Zertifikate funktionieren für *.example.com?

Ein Wildcard-Zertifikat *.example.com schützt Namen wie blog.example.com und photos.example.com. Nicht automatisch enthalten sind example.com oder test.blog.example.com. Für Let’s Encrypt wird für ein Wildcard-Zertifikat DNS-01 verwendet: Der Zertifikatsdienst weist die Domain-Kontrolle anhand eines TXT-Eintrags unter _acme-challenge nach.

DNS-Wildcard:     *.example.com  -> ein DNS-Ziel
TLS-Wildcard:     *.example.com  -> Zertifikat für 1 Ebene
DNS-01-Challenge: _acme-challenge.example.com TXT ...

Für Coolify mit Traefik dokumentiert das Projekt eine DNS-Challenge sowie die Konfiguration eines dedizierten Wildcard-Zertifikats. Für Pangolin gilt ebenfalls: Wähle das zur vorhandenen Installation passende Zertifikatsverfahren, statt willkürlich einen bestehenden certResolver zu überschreiben. Gib einem DNS-API-Token nur die wirklich benötigten Berechtigungen und sichere ihn wie ein Passwort.

Cloudflare Universal SSL ist ein zusätzliches Zertifikat am Cloudflare-Edge, nicht automatisch dein Origin-Zertifikat. Bei einer vollständig bei Cloudflare verwalteten Zone deckt die kostenlose Universal-SSL-Variante in der Regel Apex und Subdomains der ersten Ebene ab; tiefere Hostnamen können zusätzliche Zertifikate benötigen. Bei DNS-only übernimmt dein eigener Server beziehungsweise dessen Proxy die HTTPS-Zertifikate.

11. Warum Redirect-Loops, 404, 502 und SSL-Fehler entstehen

ERR_TOO_MANY_REDIRECTS

Oft sprechen Cloudflare und der Origin unterschiedliche Protokolle. Beispiel: Cloudflare ruft den Origin unverschlüsselt auf, der Origin erzwingt HTTPS, und die gleiche Weiterleitung wiederholt sich. Konfiguriere den Cloudflare-Tunnel-Service als http:// oder https:// passend zur tatsächlichen lokalen Origin-Konfiguration. Bei Cloudflare-Proxy-Betrieb ist Full (strict) mit passendem gültigem Origin-Zertifikat in der Regel die sichere Wahl.

DNS funktioniert, die Website liefert aber 404

DNS zeigt nur zum Endpunkt; der Zielproxy braucht eine Hostname-Route beziehungsweise Ressourcen-Konfiguration. Überprüfe, ob photos.example.com in Pangolin, Coolify oder der Cloudflare-Tunnel-Route vorhanden ist und der Browser tatsächlich beim richtigen Proxy landet.

502 Bad Gateway / 504 Gateway Timeout

Die Weiterleitung zum internen Zielserver funktioniert nicht, das falsche Protokoll wurde gewählt oder der Dienst antwortet nicht rechtzeitig. Prüfe vom direkt vorgeschalteten Proxy aus die interne IP und den Port, Docker-Netze, Firewall, Hostheader sowie die Protokolle der betroffenen Dienste.

DNS liefert eine andere IP als erwartet

Cloudflare mit aktiviertem Proxied-Modus beantwortet DNS in vielen Fällen mit Cloudflare-IP-Adressen statt der Origin-IP. Bei einem Cloudflare-Tunnel-CNAME führt die öffentliche Auflösung ebenfalls über das Cloudflare-Netz. Das ist normal; relevant ist die dahinter konfigurierte Route.

12. Diagnosebefehle für DNS und HTTPS

# Öffentliche A-/AAAA-/CNAME-Abfrage:
dig @1.1.1.1 photos.example.com A +short
dig @1.1.1.1 photos.example.com AAAA +short
dig @1.1.1.1 photos.example.com CNAME +short

# TLS- und Redirect-Kette ohne automatisches Folgen:
curl -Iv https://photos.example.com
curl -sSI http://photos.example.com

# Auf dem Server: Wer belegt Port 80/443?
sudo ss -lntup | grep -E ":(80|443)\b"

So liest du die Ausgabe: Bei einem DNS-only-A-Eintrag erscheint die konfigurierte öffentliche IPv4-Adresse. Bei einem proxied-Eintrag von Cloudflare sind dagegen Cloudflare-Adressen normal. Ein DNS-Treffer bestätigt nur die Namensauflösung, nicht die Verfügbarkeit der Anwendung. curl -Iv zeigt TLS- und Zertifikatsfehler, curl -sSI die HTTP-Weiterleitung; 404 bedeutet häufig eine fehlende Hostroute am Reverse Proxy.

Bei internationalen Domainnamen wie münchen.example können Programme und DNS-Konfigurationen eine Punycode-Schreibweise erfordern. Gib in Tools möglichst den technisch aufgelösten Namen an und vermeide, unterschiedliche Schreibweisen als zwei separate Domains zu behandeln.

13. Empfohlene Reihenfolge für einen sicheren Umstieg

• Alle bestehenden DNS-Einträge, Tunnel-Published-Applications, Proxy-Konfigurationen und SSL-Zuständigkeiten dokumentieren.
• Neue Subdomain im Testsystem einrichten, zunächst ohne Wildcard-Änderung.
• Die Route von Cloudflare beziehungsweise dem öffentlichen Proxy bis zur internen Anwendung vollständig testen.
• Erst danach bei Bedarf ein Wildcard-DNS und ein passende Zertifikatslösung ergänzen.
• Bestehende Domains schrittweise migrieren und nach jeder Änderung Logs, DNS, Zertifikat und Webanwendung prüfen.

FAQ zu *.domain.de

Funktioniert *.domain.de für beliebig viele Subdomains?

Es erlaubt die Namensauflösung vieler passender Hostnamen, sofern keine konkreteren Records oder andere DNS-Regeln greifen. Das bedeutet nicht automatisch, dass jede URL einen aktiven Webdienst oder ein passendes Zertifikat hat.

Muss ich für jede Anwendung einen neuen Port freigeben?

Nein. Für typische HTTP-/HTTPS-Webanwendungen genügt häufig ein öffentlich erreichbarer Reverse Proxy auf 80/443, der die Anfragen intern an unterschiedliche Ports weiterleitet.

Kann ich die Hauptdomain weiter auf meiner alten Website lassen?

Ja. Ein separater @-Record kann die Hauptdomain zu einem anderen Ziel führen. Der Wildcard-Eintrag für Subdomains muss dafür nicht auf dieselbe IP zeigen.

Passende weiterführende Anleitungen

• Pangolin: Installation, Newt-Tunnel und DNS
• Coolify: Installation, eigene Domain und TLS
• GeoMetrikks: Zugriffe von Pangolin und Cloudflare analysieren

Offizielle Quellen und verwandte Anleitungen

• Cloudflare: Wildcard-DNS-Records
• Cloudflare: Wildcard-Ingress in lokal verwalteten Tunneln
• Cloudflare: Universal-SSL-Grenzen
• Coolify: Domains
• Pangolin: DNS & Networking