Hallo,
ich bin gerade zu R2 migriert und alles hat perfekt geklappt. Alle Bilder haben den S3-CDN-URL-Link. Allerdings ist mir ein Problem aufgefallen: Avatare laden sehr lange. Im Durchschnitt dauert es etwa 3 bis 4 Sekunden, egal ob ich auf den Avatar eines Benutzers klicke oder in einen Beitrag schaue. Ist das normal?
Hmm, ich vermute, es könnte eines von drei verschiedenen Problemen sein, aber das Wahrscheinlichste ist für mich das Echtzeit-Resizing.
Als du deine Uploads auf R2 migriert hast, wurden die Originalbilder verschoben. Discourse verwendet jedoch viele verschiedene Avatar-Größen (z. B. 45 Pixel für Beiträge, 120 Pixel für die Benutzerkarte).
Wenn diese spezifischen, optimierten Größen nicht perfekt migriert wurden oder noch nicht generiert wurden, muss Discourse sie synchron generieren, sobald der Benutzer auf sie klickt:
Zur Überprüfung: Aktualisiere die Seite hart (Hard-Refresh). Wenn der Avatar beim ersten Mal 3–4 Sekunden benötigt, beim zweiten Mal aber sofort lädt, ist dies genau das, was passiert.
Zur Behebung: Dies wird sich von selbst beheben, während Benutzer browsen und die Größen generiert werden. Du kannst es jedoch sofort beheben, indem du den Server anweist, alle Avatares im Hintergrund vorab zu generieren. Dazu verbindest du dich per SSH mit deinem Server und führst folgenden Befehl aus:
./launcher enter app
rake avatars:refresh
Wenn die Avatares jedes Mal, auch nach mehrfachen Aktualisierungen, 3–4 Sekunden benötigen, liegt wahrscheinlich ein Netzwerk-Timeout vor.
Die Cloudflare-R2-API-Endpunkte sind Dual-Stack, das heißt, sie verwenden sowohl IPv4 als auch IPv6. Wenn dein Server-Droplet eine IPv6-Adresse zugewiesen hat, das IPv6-Gateway des Hosts jedoch nicht richtig geroutet ist, versucht die interne Verbindung von Ruby zum R2-Bucket zuerst IPv6, hängt für 3 Sekunden (dies ist das Standard-TCP-Timeout von Linux), schlägt fehl und gelingt dann sofort über IPv4.
Zur Überprüfung: Verbinde dich per SSH mit dem Server und führe folgenden Befehl aus:
curl -I -6 https://cloudflare.com
Wenn er einige Sekunden lang hängt und fehlschlägt, ist die IPv6-Verbindung des Servers defekt, was dazu führt, dass jede interne S3-API-Abfrage eine Verzögerung von 3 Sekunden erfährt.
Zur Behebung: Du musst entweder das IPv6-Routing in deinem Host-Steuerpanel reparieren oder IPv6 auf dem Droplet möglicherweise vollständig deaktivieren.
Wenn deine Site so konfiguriert ist, dass sie auf Gravatar-Updates überprüft, wird sie möglicherweise Gravatars externe Server anpingen, bevor der Avatar gerendert wird. Wenn der Server eine langsame ausgehende Verbindung hat (was oft auch mit DNS oder IPv6 zusammenhängt), wird das Rendern des Avatars wahrscheinlich blockiert.
Zur Überprüfung: Führe folgenden Befehl auf deinem Server aus:
curl -I -6 https://gravatar.com
Wenn er 3 Sekunden lang hängt, ist IPv6 defekt (siehe oben).
Behebung im Zusammenhang mit Gravatar: Gehe in deinen Discourse-Einstellungen zu Gravatars automatisch herunterladen, schalte es vorübergehend aus und prüfe, ob dies das Problem behebt. Ich denke nicht, dass dies das Problem ist, aber wenn doch, kannst du die Einstellung ausgeschaltet lassen, das IPv6-Routing wie in Punkt 2 oben reparieren oder den DNS-Resolver ändern.
Vielen Dank für Ihre schnelle Antwort. Ich glaube, ich habe den Befehl rake avatars:refresh bereits zuvor versucht, bin mir aber nicht absolut sicher.
Was bei mir früher funktionierte, um das Avatar-Bild sofort zu sehen, war ein erster Klick darauf; beim zweiten Klick öffnete es sich sofort. Das liegt aber wahrscheinlich am Caching. Außerdem habe ich gerade Ihren zweiten Tipp getestet, und er ergibt eine „HTTP/2 301“-Antwort mit mehreren weiteren Zeilen. Gleiches gilt für Tipp 3. Ich werde avatars:refresh in ein paar Tagen erneut ausführen, da ich zuvor ein Snapshot wiederherstellen musste. Nochmals vielen Dank!
Gravatar
server: nginx
date: Mon, 22 Jun 2026 19:29:00 GMT
content-type: text/html; charset=utf-8
content-length: 0
content-language: en
expires: Wed, 11 Jan 1984 05:00:00 GMT
cache-control: no-cache, must-revalidate, max-age=0
x-redirect-by: Gravatar
location: https://en.gravatar.com/
alt-svc: h3=":443"; ma=86400
strict-transport-security: max-age=31536000; includeSubdomains; preload
CF
HTTP/2 301
date: Mon, 22 Jun 2026 19:27:00 GMT
content-type: text/html
content-length: 167
location: https://www.cloudflare.com/
cache-control: max-age=3600
expires: Mon, 22 Jun 2026 20:26:59 GMT
set-cookie: __cf_bm=eBP2aJ7Eg30nHPuvMMNxxKrgNtcNwKs0WDgnYyONeus-1782156420-1.0.1.1-sXpW27iuhGDF615cOfwNFybH4IMxgvZy3uA_3X_o..402T_3KSgT7CSymipL5RjdpGe3raWEqsVxQFFLPKRoDjfoT7B.0rqyDt.osbkOF98; path=/; expires=Mon, 22-Jun-26 19:57:00 GMT; domain=.cloudflare.com; HttpOnly; Secure; SameSite=None
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v4?s=QfYqSekEDPJHC2k%2BMjHN0cGjz172tmUWe2GSR8EgwNLh3TGjFYkQ0vwPxlzY1NcBcKFOMaAi4FlgjqjhETOOtHf%2BH9KdQSvqN3OME2Uh1i4nHIw%2Fy1qkvSpf4jxDchM7CaDW80tJkjBV4OqF"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
strict-transport-security: max-age=15780000; includeSubDomains
server: cloudflare
cf-ray: a0fda5d8ecd6b26d-LAX
alt-svc: h3=":443"; ma=86400
Ja, angesichts deiner Antwort bin ich fast sicher, dass es sich um Problem Nr. 1 handelt, da die Ergebnisse des curl-Befehls für Cloudflare und Gravatar wie erwartet ausfallen. Probiere rake avatars:refresh einfach aus, wann immer es dir passt, und lass mich wissen, ob es funktioniert.