Mastodon mit unterschiedlichen Domains einrichten

Was die beiden Werte bedeuten

Wert	Beispiel	Aufgabe
LOCAL_DOMAIN	example.com	Steht in den Adressen, also @name@example.com
WEB_DOMAIN	social.example.com	Dort läuft Mastodon, dort melden sich alle an

Andere Server kennen zunächst nur die Adresse und fragen deshalb bei example.com nach. Dein Webserver auf der Hauptdomain muss diese Anfragen an social.example.com weiterleiten. Mehr ist es nicht.

Wichtig: Lege beide Werte vor dem ersten Start fest. Sobald deine Instanz mit anderen Servern gesprochen hat, lassen sie sich nicht mehr ändern, ohne die Föderation zu beschädigen.

Schritt 1: DNS

Lege die Subdomain für Mastodon bei deinem DNS-Anbieter an:

Name	Typ	Wert
social	A	IPv4-Adresse des Mastodon-Servers
social	AAAA	IPv6-Adresse des Mastodon-Servers, falls vorhanden

Die Einträge der Hauptdomain und deine MX-Einträge bleiben unverändert. Die Hauptdomain braucht nur ein gültiges HTTPS-Zertifikat, denn die Weiterleitung muss per HTTPS erreichbar sein.

Schritt 2: Mastodon

Trage beide Werte in .env.production ein:

LOCAL_DOMAIN=example.com
WEB_DOMAIN=social.example.com

Der Webserver von Mastodon selbst und sein Zertifikat laufen nur auf der WEB_DOMAIN.

Schritt 3: Weiterleitung auf der Hauptdomain

Die Einstellungen gehören auf den Server, auf dem example.com läuft, nicht auf den Mastodon-Server. Ersetze social.example.com durch deine eigene Adresse.

nginx

Im server-Block für Port 443:

location ~ ^/\.well-known/(webfinger|host-meta|nodeinfo)$ {
    add_header Access-Control-Allow-Origin "*" always;
    return 301 https://social.example.com$request_uri;
}

Danach prüfen und neu laden: nginx -t && systemctl reload nginx

Apache 2

Im VirtualHost für Port 443. Für die Header-Zeile muss mod_headers aktiv sein (a2enmod headers):

<LocationMatch "^/\.well-known/(webfinger|host-meta|nodeinfo)$">
    Header always set Access-Control-Allow-Origin "*"
</LocationMatch>
Redirect 301 /.well-known/webfinger https://social.example.com/.well-known/webfinger
Redirect 301 /.well-known/host-meta https://social.example.com/.well-known/host-meta
Redirect 301 /.well-known/nodeinfo https://social.example.com/.well-known/nodeinfo

Danach prüfen und neu laden: apachectl configtest && systemctl reload apache2

Apache 2 mit .htaccess, zum Beispiel bei WordPress

Hast du keinen Zugriff auf die Server-Konfiguration, geht es auch in der .htaccess. Die Regel muss vor dem Block # BEGIN WordPress stehen:

RewriteEngine On
RewriteRule ^\.well-known/(webfinger|host-meta|nodeinfo)$ https://social.example.com/.well-known/$1 [R=301,L]

Schritt 4: Testen

Rufe die Adresse so ab, wie es ein anderer Mastodon-Server tun würde. Ersetze dabei Domain und Name:

curl -sI -A 'http.rb/5.2.0 (Mastodon/4.7.5)' \
  'https://example.com/.well-known/webfinger?resource=acct:name@example.com'

So soll die Antwort aussehen. Das ?resource=… muss in der Weiterleitung erhalten bleiben:

HTTP/2 301
location: https://social.example.com/.well-known/webfinger?resource=acct:name@example.com

Läuft Mastodon schon, folgst du der Weiterleitung bis zum Ende. Du bekommst dann JSON mit deinem Konto zurück:

curl -sL -A 'http.rb/5.2.0 (Mastodon/4.7.5)' \
  'https://example.com/.well-known/webfinger?resource=acct:name@example.com'

Zum Schluss suchst du von einer anderen Instanz aus nach @name@example.com. Taucht dein Konto auf, ist alles richtig eingerichtet.

Wenn es nicht klappt

• Im Browser geht es, beim Test nicht: Eine Bot-Sperre, Web Application Firewall oder ein CDN blockt Server-Anfragen, oft mit 403 oder 418. Teste deshalb immer mit dem Mastodon-User-Agent wie oben, und nimm die drei Pfade von der Sperre aus.
• nginx antwortet trotz Weiterleitung mit der Sperre: Ein if mit return direkt im server-Block greift vor jedem location-Block. Verschiebe die Sperre in location / oder nimm die Pfade dort aus.
• nginx antwortet mit 404: Ein Block location ^~ /.well-known/ hat Vorrang vor der Weiterleitung. Trage die Weiterleitung dort ein oder grenze den Block enger ein, zum Beispiel auf /.well-known/acme-challenge/.
• Konto wird nicht gefunden: Prüfe, ob das ?resource=… erhalten bleibt. Fehlt es, kann Mastodon die Anfrage nicht beantworten.
• Fehler beim Zertifikat: Die Hauptdomain braucht ein gültiges Zertifikat. Andere Server folgen keiner Weiterleitung von einer Adresse mit ungültigem Zertifikat.
• Auf der Hauptdomain läuft schon etwas mit Fediverse-Anbindung, zum Beispiel das ActivityPub-Plugin für WordPress: Dann belegt es dieselben Pfade. Entscheide dich für eins von beiden, zwei Dienste können unter derselben Domain nicht gleichzeitig antworten.

Mehr dazu steht in der Mastodon-Dokumentation.