GoToSocial mit unterschiedlichen Domains einrichten

Was die beiden Werte bedeuten

Wert	Beispiel	Aufgabe
account-domain	example.com	Steht in den Adressen, also @name@example.com
host	social.example.com	Dort läuft GoToSocial, dort melden sich Apps an

Andere Server fragen zuerst bei example.com nach. Dein Webserver auf der Hauptdomain leitet diese Anfragen an social.example.com weiter.

Wichtig: Lege beide Werte vor dem allerersten Start fest. Sobald deine Instanz mit anderen Servern gesprochen hat, lässt sich das nicht mehr ändern. Du müsstest die Datenbank neu aufbauen, und die Betreiber aller verbundenen Instanzen müssten ihre Daten anpassen.

Schritt 1: DNS

Lege die Subdomain bei deinem DNS-Anbieter an:

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

Die Einträge der Hauptdomain bleiben unverändert. Sie braucht nur ein gültiges HTTPS-Zertifikat. Mehr dazu steht in der Anleitung Eigene Domain verbinden.

Schritt 2: GoToSocial

Trage beide Werte in die config.yaml ein:

host: "social.example.com"
account-domain: "example.com"

Bei Docker geht das auch über Umgebungsvariablen:

GTS_HOST=social.example.com
GTS_ACCOUNT_DOMAIN=example.com

Schritt 3: Weiterleitung auf der Hauptdomain

Die Einstellungen gehören auf den Server, auf dem example.com läuft. 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

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]

Nur diese drei Pfade weiterleiten: Leite /api/ nicht weiter. Das verwirrt manche Apps beim Anmelden.

Schritt 4: Testen

curl -sI -A 'gotosocial' \
  'https://example.com/.well-known/webfinger?resource=acct:name@example.com'

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

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

Läuft GoToSocial schon, folgst du der Weiterleitung. Du bekommst dann JSON mit acct:name@example.com zurück:

curl -sL -A 'gotosocial' \
  'https://example.com/.well-known/webfinger?resource=acct:name@example.com'

Zum Schluss suchst du von einer anderen Instanz aus nach @name@example.com.

Wenn es nicht klappt

• Im Browser geht es, beim Test nicht: Eine Bot-Sperre, Firewall oder ein CDN blockt Server-Anfragen, oft mit 403 oder 418. Nimm die drei Pfade davon aus.
• nginx antwortet trotz Weiterleitung mit der Sperre: Ein if mit return direkt im server-Block greift vor jedem location-Block.
• nginx antwortet mit 404: Ein Block location ^~ /.well-known/ hat Vorrang. Grenze ihn enger ein, zum Beispiel auf /.well-known/acme-challenge/.
• Konto wird nicht gefunden: Prüfe, ob das ?resource=… erhalten bleibt.
• Apps melden sich nicht an: In der App trägst du social.example.com ein, nicht die Hauptdomain.