Subdomain, Unterverzeichnis oder separate Domain? So wählen Sie eine URL-Struktur für eine selbst gehostete Anwendung
Die Wahl des Standorts einer selbst gehosteten Anwendung beeinflusst die Reverse-Proxy-Konfiguration, Cookies, Authentifizierungs-Callbacks, Webhooks, TLS, Migrationsaufwand und administrative Grenzen. Nutzen Sie diesen Leitfaden, um eine URL-Struktur auszuwählen und sie vor dem Start zu validieren.
Warum die URL-Struktur eine betriebliche und nicht nur eine Branding-Entscheidung ist
Eine URL ist Teil des öffentlichen Vertrags einer Anwendung. Nutzer speichern sie, Browser wenden Origin- und Cookie-Regeln darauf an, Identitätsanbieter können sie registrieren, Webhook-Absender liefern an sie aus, und API-Clients oder eingebettete Inhalte können sie speichern. Eine spätere Änderung der URL kann daher mehr als nur Lesezeichen und Suchlinks beeinflussen.
Die drei häufigsten Muster sind eine dedizierte Subdomain wie https://app.example.com, ein Unterverzeichnis hinter einer bestehenden Website wie https://example.com/app und eine separate Domain wie https://exampleapp.com. Welche Option am besten ist, hängt vom dokumentierten Bereitstellungsmodell der Anwendung und von Ihren betrieblichen Anforderungen ab – nicht nur davon, welche Adresse am kürzesten aussieht.
Ein zentraler technischer Unterschied ist die Origin. Eine Web-Origin basiert auf Schema, Host und Port; der Pfad ist kein Teil der Origin. Daher teilt https://example.com/app eine Origin mit anderen Inhalten auf https://example.com, während https://app.example.com einen anderen Host und damit eine andere Origin verwendet. Dieser Unterschied kann für das Browserverhalten, das Integrationsdesign und Erwartungen an die Isolation relevant sein.
- Wählen Sie die öffentliche URL, bevor Sie Nutzer einladen, einen Identitätsanbieter verbinden oder Webhook-Endpunkte veröffentlichen.
- Behandeln Sie die kanonische URL der Anwendung als Konfiguration, die dokumentiert und gepflegt werden muss.
- Gehen Sie nicht davon aus, dass ein Reverse Proxy jede Anwendung unterhalb eines Pfadpräfixes korrekt betreiben kann.
Die drei Muster im Überblick
Eine dedizierte Subdomain platziert die Anwendung unter einer Adresse wie https://crm.example.com. Für viele selbst gehostete Anwendungen ist dies die unkomplizierteste öffentliche Anordnung, da die Anwendung / in der Regel als Basispfad behandeln kann. Der Reverse Proxy routet anhand des Hostnamens, und generierte Links, statische Assets und Weiterleitungen müssen kein zusätzliches öffentliches Pfadpräfix enthalten.
Ein Unterverzeichnis platziert die Anwendung unter einem bestehenden Hostnamen, beispielsweise https://example.com/analytics. Dadurch kann eine einheitliche öffentliche Website entstehen; zudem kann dies nützlich sein, wenn ein Unternehmen nur einen Hostnamen präsentieren muss. Allerdings setzt es voraus, dass sowohl der Reverse Proxy als auch die Anwendung den Basispfad /analytics korrekt verstehen.
Eine separate Domain platziert die Anwendung unter einem eigenständigen Namen wie https://example-portal.com. Dadurch können Produkt-, Kunden-, Geschäftsbereichs- oder Governance-Grenzen klarer werden. Gleichzeitig entsteht eine separate Fläche für DNS, TLS, Domaininhaberschaft und Lebenszyklus, die verwaltet werden muss.
- Dedizierte Subdomain: in der Regel die weniger komplexe Standardwahl für eine Anwendung mit eigenem Login und Integrationen.
- Unterverzeichnis: erst dann geeignet, wenn die offizielle Dokumentation der Anwendung und eine Staging-Bereitstellung die Unterstützung relativer URLs bestätigen.
- Separate Domain: sinnvoll, wenn eine klare öffentliche, administrative oder organisatorische Grenze wichtiger ist als die Zuordnung der Anwendung zur primären Markendomain.
Beginnen Sie mit der Anwendung: Dokumentierte Unterstützung für Basis-URL und Reverse Proxy prüfen
Beginnen Sie mit der Installations- und Reverse-Proxy-Dokumentation der Anwendung selbst. Suchen Sie gezielt nach unterstützten Einstellungen mit Bezeichnungen wie Basis-URL, externe URL, Website-URL, Root-URL, relative URL, Webroot, öffentliche URL, vertrauenswürdiger Proxy, Forwarded Headers oder einem ähnlichen Begriff. Die Terminologie unterscheidet sich je nach Produkt, und die Unterstützung ist produktspezifisch.
Ein Proxy kann ein öffentliches Präfix entfernen, bevor er eine Anfrage weiterleitet. Beispielsweise kann ein Proxy /app annehmen und die Anfrage an ein Backend weiterleiten, das auf / lauscht. Das StripPrefix-Middleware von Traefik führt diese Art der Präfixentfernung durch und stellt das entfernte Präfix in X-Forwarded-Prefix bereit. Das Entfernen eines Pfads im Proxy macht die Anwendung jedoch nicht automatisch darauf aufmerksam, dass ihre öffentliche Adresse diesen Pfad enthält.
Die Anwendung muss öffentliche Links, Asset-URLs, Weiterleitungen, Formularziele und Callback-URLs weiterhin mit dem korrekten Präfix generieren. Die offizielle Dokumentation kann auch Einschränkungen aufzeigen. GitLab dokumentiert beispielsweise eine Installation mit relativer URL als Alternative, empfiehlt unter normalen Umständen jedoch eine eigene Domain oder Subdomain und beschreibt Einschränkungen. Dies erinnert daran, das Verhalten eines Produkts nicht auf andere Produkte zu verallgemeinern.
- Lesen Sie die Bereitstellungsdokumentation des Anbieters, bevor Sie sich für ein Unterverzeichnis entscheiden.
- Bestätigen Sie, dass die Anwendung eine relative URL oder einen Webroot unterstützt – nicht nur einen generischen Reverse Proxy.
- Ermitteln Sie die erforderlichen Proxy-Header und Einstellungen für vertrauenswürdige Proxys.
- Dokumentieren Sie die exakte kanonische externe URL in der Bereitstellungsdokumentation.
- Führen Sie einen Staging-Test mit der vorgesehenen öffentlichen URL durch, nicht nur mit einer direkten Container- oder internen Adresse.
Authentifizierung und Integrationen: Callback-URLs, E-Mail-Links, eingebettete Inhalte und Webhooks
Authentifizierung macht eine URL-Migration häufig sichtbar. OAuth-Integrationen können verlangen, dass Weiterleitungsendpunkte beim Autorisierungsserver registriert werden. Wenn eine vollständige Redirect-URI registriert ist, verlangt OAuth 2.0 einen einfachen Stringvergleich der angeforderten URI. Ein Wechsel von https://example.com/app/callback zu https://app.example.com/callback kann daher eine Konfigurationsänderung beim Identitätsanbieter erfordern, selbst wenn die Anwendung selbst funktioniert.
Erfassen Sie jeden externen Dienst, der die öffentliche URL speichert oder anzeigt. Dazu zählen üblicherweise Single-Sign-On-Einstellungen, E-Mails zur Passwortzurücksetzung und Einladungen, extern eingebettete Seiten, API-Client-Konfigurationen, Mobil- oder Desktop-Clients sowie Webhook-Absender. Ein alter Wert wird möglicherweise erst bemerkt, wenn ein Nutzer einem selten verwendeten E-Mail-Ablauf folgt oder eine Hintergrundintegration eine Zustellung versucht.
Webhooks verdienen einen eigenen Validierungsschritt, weil ihr Absender ein externer HTTP-Client ist. Die konfigurierte Payload-URL muss bei Bedarf aktualisiert und die Zustellung nach Aktivierung der neuen Adresse getestet werden. Bei Diensten, die TLS-Zertifikate validieren, stellen Sie sicher, dass der Endpunkt das erwartete gültige Zertifikat bereitstellt und auf der erforderlichen Route öffentlich erreichbar ist.
- Listen Sie vor dem Start oder der Migration jede OAuth- oder SSO-Redirect-URI auf.
- Senden Sie echte Testeinladungen, Passwortzurücksetzungen und Benachrichtigungs-E-Mails an ein kontrolliertes Postfach.
- Testen Sie eingebettete Inhalte über die Website oder das Produkt, die beziehungsweise das sie tatsächlich einbinden wird.
- Erfassen Sie eingehende Webhook-Absender, aktualisieren Sie deren Endpunktkonfiguration und lösen Sie eine Testzustellung aus.
- Prüfen Sie API-Clients und Automatisierungstools auf fest codierte Basis-URLs.
DNS, TLS-Zertifikate und Routing für jedes Muster
Die Wahl eines Hostnamens schafft Arbeit für DNS und Zertifikate. Zertifizierungsstellen validieren die Kontrolle über die in einem Zertifikat enthaltenen Domainnamen; der gewählte Hostname muss daher so aufgelöst und geroutet werden, dass die ausgewählte Validierungsmethode unterstützt wird. Die HTTP-01-Validierung von Let’s Encrypt ruft eine Challenge unter /.well-known/acme-challenge/ auf Port 80 ab. DNS und öffentliches Routing sind daher Teil der Startbereitschaft einer Anwendung und keine Aufgabe, die erst nach der Anwendungskonfiguration erledigt werden sollte.
Eine Subdomain benötigt normalerweise einen DNS-Eintrag für diesen Hostnamen und ein Zertifikat, das ihn abdeckt. Eine separate Domain erfordert dieselbe Arbeit für einen anderen Domainnamen. Ein Unterverzeichnis fügt keinen Hostnamen hinzu, verlangt jedoch präzise Regeln für das Pfad-Routing und ein konfliktfreies Zusammenspiel mit den Routen, Weiterleitungen und der Challenge-Behandlung der primären Website.
Wildcard-Zertifikate sind eine separate Entwurfsentscheidung. Let’s Encrypt dokumentiert, dass HTTP-01 keine Wildcard-Zertifikate ausstellen kann; für die Ausstellung von Wildcards ist die DNS-01-Validierung erforderlich. Wählen Sie einen Wildcard-Ansatz nicht allein deshalb, um die Planung einzelner Hostnamen zu vermeiden, sofern Sie den erforderlichen DNS-Validierungsprozess nicht sicher betreiben können.
- Bestätigen Sie die DNS-Inhaberschaft und wer die relevanten Einträge ändern kann.
- Prüfen Sie vor der Zertifikatausstellung und dem öffentlichen Start, ob der vorgesehene Hostname aufgelöst wird.
- Stellen Sie bei Verwendung der HTTP-01-Validierung sicher, dass Port 80 und die ACME-Challenge-Route erreichbar sind.
- Definieren Sie Routing-Prioritäten, damit Hauptseite, Anwendungsrouten und Challenge-Pfade nicht kollidieren.
- Wenn Docker eingesetzt wird, legen Sie nur die Ports nach außen offen, die externen Zugriff benötigen; ein Reverse Proxy kann Dienste über das Host- oder Docker-Netzwerk erreichen, ohne jeden Container-Port öffentlich freizugeben.
Daten und Governance: Entscheiden Sie, wem die Grenze gehört
Die Domainstruktur sollte sowohl die betriebliche Zuständigkeit als auch die Nutzererfahrung widerspiegeln. Berücksichtigen Sie, wer die Domainregistrierung, DNS-Einträge, zertifikatsbezogene Änderungen, Anwendungsadministration, Abrechnungskontakte und Notfallzugriff kontrolliert. Eine technisch bequeme URL kann zu einem betrieblichen Risiko werden, wenn sie von einem persönlichen Konto oder dem DNS-Zugriff eines nicht zugehörigen Teams abhängt.
Eine separate Domain kann nützlich sein, wenn ein Kunde, ein übernommenes Unternehmen, eine regulierte Einheit oder ein eigenständiges Produkt eine klarere öffentliche und administrative Grenze benötigt. Eine dedizierte Subdomain kann innerhalb einer zentral verwalteten übergeordneten Domain eine praktikable Grenze schaffen. Ein Unterverzeichnis ist häufig am besten Fällen vorbehalten, in denen ein gemeinsamer Hostname tatsächlich erforderlich ist und die Unterstützung der Anwendung geprüft wurde.
Keine dieser Entscheidungen löst die Zugriffs-Governance automatisch. Definieren Sie, wer die Anwendung administriert, wer DNS-Zugriff besitzt, wer Integrationsänderungen genehmigt, wo Backups geregelt sind und wie der Zugriff bei Personal- oder Lieferantenwechseln übertragen wird.
- Dokumentieren Sie den rechtlichen und betrieblichen Eigentümer jeder Domain und DNS-Zone.
- Vermeiden Sie die Kontrolle über Registrar, DNS und Anwendungsadministratorzugang durch nur eine Person.
- Weisen Sie Verantwortliche für Einstellungen des Identitätsanbieters, Webhook-Konfigurationen und Wiederherstellungsverfahren zu.
- Nutzen Sie eine separate Domain, wenn ein unabhängiger Lebenszyklus oder eine unabhängige Eigentumsgrenze eine zentrale Anforderung ist.
Für die Migration planen: Weiterleitungen helfen, aktualisieren aber nicht jede Abhängigkeit
Eine Subdomain lässt sich oft leichter ändern als eine Bereitstellung in einem Unterverzeichnis, weil die Anwendung üblicherweise unter / verbleiben kann. Das bedeutet nicht, dass Änderungen am Hostnamen folgenlos sind. Der neue Hostname ändert die Browser-Origin, kann ein neues Zertifikat und einen neuen DNS-Eintrag erfordern und Aktualisierungen registrierter Callbacks, Webhook-Ziele, API-Clients, E-Mail-Vorlagen und Allowlist-Einträge notwendig machen.
Ein Wechsel vom Unterverzeichnis zur Subdomain kann die künftige Proxy-Konfiguration vereinfachen, ändert jedoch weiterhin die kanonische URL. Die dokumentierte Migrationsanleitung von GitLab ist ein nützliches konkretes Beispiel: Durch die Änderung der URL ändern sich Remote-Repository-URLs, die Nutzer möglicherweise manuell aktualisieren müssen. Weiterleitungen können alte, über den Browser erreichbare Links erhalten, schreiben aber keine Remote-Konfigurationen um, die bei jedem Nutzer oder Drittsystem gespeichert sind.
Testen Sie Weiterleitungen entsprechend den tatsächlichen Anfragearten, die Ihre Anwendung empfängt. HTTP-Weiterleitungen sind Client-Verhalten und keine Garantie dafür, dass alle Clients gleich reagieren. Die HTTP-Semantik unterscheidet außerdem das Verhalten von Methoden: Bei 301 und 302 kann aus einem POST ein GET werden, während 307 und 308 die Methode beibehalten. Gehen Sie nicht davon aus, dass eine im Browser getestete Weiterleitung beweist, dass ein API-Client oder Webhook-Absender korrekt funktioniert.
- Erstellen Sie vor der Änderung der kanonischen Adresse ein Inventar alter URLs.
- Aktualisieren Sie Anwendungskonfiguration, Identitätsanbieter, Webhook-Absender, API-Clients, Dokumentation und Nutzerkommunikation.
- Erstellen Sie einen bewussten Weiterleitungsplan für Browser-Traffic, einschließlich eines Abschaltdatum und eines Monitoring-Ansatzes.
- Testen Sie POST-basierte Abläufe und externe Clients getrennt von der normalen GET-Navigation.
- Informieren Sie Nutzer, wenn sie gespeicherte Remotes, Lesezeichen, Client-Einstellungen oder Allowlists manuell aktualisieren müssen.
Häufige Fragen
Ist eine Subdomain oder ein Unterverzeichnis besser für eine selbst gehostete Anwendung?
Eine dedizierte Subdomain ist in der Regel die einfachere Standardwahl, da die Anwendung unter / betrieben werden kann. Wählen Sie ein Unterverzeichnis nur dann, wenn Sie einen gemeinsamen Hostnamen benötigen und die offizielle Dokumentation der Anwendung sowie ein Staging-Test eine zuverlässige Unterstützung relativer URLs oder eines Webroots bestätigen.
Kann ein Reverse Proxy jede Anwendung in einem Unterverzeichnis betreiben?
Nein. Ein Reverse Proxy kann ein öffentliches Pfadpräfix entfernen, bevor er Anfragen weiterleitet, die Anwendung muss jedoch Assets, Weiterleitungen, Links und Integrationen weiterhin mit dem öffentlichen Präfix generieren. Proxy-Routing allein bietet keine Unterstützung der Basis-URL auf Anwendungsebene.
Machen Cookies Unterverzeichnisse unsicher?
Der Cookie-Pfad begrenzt, wann ein Browser ein Cookie sendet, er ist jedoch keine Sicherheitsgrenze. Anwendungen unter einem Hostnamen benötigen eine bewusste Cookie-Konfiguration und sollten sich nicht auf die Pfadtrennung als Schutz zwischen unabhängig verwalteten Diensten verlassen.
Was muss sich ändern, wenn eine Anwendung auf einen neuen Hostnamen umzieht?
Prüfen Sie die kanonische Anwendungs-URL, DNS, TLS-Zertifikat, OAuth- oder SSO-Redirect-URIs, Links zur Passwortzurücksetzung und zu Einladungen, Webhook-Payload-URLs, API-Clients, eingebettete Inhalte, Dokumentation, Allowlists und nutzerkonfigurierte Clients. Weiterleitungen können bei Browser-Links helfen, aktualisieren jedoch keine externen Konfigurationen automatisch.
Wie kann Airbip bei URL-Routing für eine verwaltete Anwendungsbereitstellung helfen?
Airbip stellt Kataloganwendungen als Docker-Workloads auf Airbip-Cloud-Servern bereit und automatisiert Routing sowie TLS-Zertifikate über Traefik und Let’s Encrypt. Außerdem umfasst es DNS-Prüfungen, Service-Lifecycle-Management sowie konfigurierbare tägliche, wöchentliche und monatliche Backups. Kunden können eine Airbip-Subdomain oder eine kompatible eigene Domain nutzen. Der Kunde muss weiterhin die geeignete Anwendungs-URL auswählen, die Unterstützung der Basis-URL auf Anwendungsebene prüfen, Identität und Integrationen konfigurieren sowie die relevanten Entscheidungen zu Daten, Zugriff und Governance treffen.
Quellen und weiterführende Literatur
- Traefik StripPrefix middleware documentation — Traefik Labs
- GitLab: Install under a relative URL — GitLab
- GitLab: Migrate from a relative URL to a subdomain — GitLab
- Nextcloud Server Administration Manual — Nextcloud GmbH
- RFC 6265: HTTP State Management Mechanism — IETF
- RFC 6749: The OAuth 2.0 Authorization Framework — IETF
- RFC 6454: The Web Origin Concept — IETF
- RFC 9110: HTTP Semantics — IETF
- Challenge Types — Let’s Encrypt / Internet Security Research Group
- Docker networking overview — Docker