Ciao,
Ho appena migrato a R2 e tutto è andato alla perfezione. Tutte le immagini utilizzano il link CDN S3. Tuttavia, ho notato un problema: gli avatar impiegano molto tempo a caricarsi. In media, ci vogliono circa 3-4 secondi, sia che si faccia clic sull’avatar di un utente, sia che si guardi all’interno di un post. È normale?
Mmm, sospetto che il problema possa essere uno di tre diversi, ma il più probabile per me è il ridimensionamento dinamico.
quando hai migrato i tuoi upload su R2, sono state spostate anche le immagini originali; tuttavia, Discourse utilizza molte dimensioni diverse di avatar (ad esempio 45px per i messaggi, 120px per la scheda utente).
se quelle dimensioni ottimizzate specifiche non sono state migrate perfettamente, o non sono state ancora generate, Discourse deve generarle in modo sincrono nel momento in cui l’utente le clicca:
per verificare: aggiorna forzatamente la pagina: se l’avatar impiega 3-4 secondi la prima volta, ma si carica istantaneamente la seconda volta, è esattamente ciò che sta accadendo.
per risolvere: il problema si risolverà naturalmente man mano che gli utenti navigano e le dimensioni vengono generate. Ma puoi risolverlo immediatamente forzando il server a pre-generare tutti gli avatar in background accedendo al server tramite SSH ed eseguendo:
./launcher enter app
rake avatars:refresh
se gli avatar impiegano 3-4 secondi ogni volta, anche dopo più aggiornamenti, probabilmente stanno incontrando un timeout di rete.
Gli endpoint API di Cloudflare R2 sono dual-stack, ovvero utilizzano sia IPv4 che IPv6. Se il tuo droplet del server ha un indirizzo IPv6 assegnato, ma il gateway IPv6 dell’host non è instradato correttamente, la connessione interna di Ruby al bucket R2 tenterà prima IPv6, rimarrà in attesa per 3 secondi (questo è il timeout TCP predefinito di Linux), fallirà e quindi avrà successo istantaneamente utilizzando IPv4.
per verificare: accedi al server tramite SSH ed esegui:
curl -I -6 https://cloudflare.com
se rimane in attesa per alcuni secondi e fallisce, l’IPv6 del server non funziona correttamente, causando un ritardo di 3 secondi in ogni controllo interno dell’API S3.
per risolvere: dovrai oppure correggere il routing IPv6 nel pannello di controllo dell’host o forse disabilitare completamente IPv6 sul droplet.
se il tuo sito è configurato per controllare gli aggiornamenti di Gravatar, potrebbe contattare i server esterni di Gravatar prima di visualizzare l’avatar. Se il server ha una connessione in uscita lenta (spesso correlata anche a DNS o IPv6), potrebbe bloccare il rendering dell’avatar.
per verificare: esegui questo comando sul server
curl -I -6 https://gravatar.com
se rimane in attesa per 3 secondi, l’IPv6 non funziona correttamente (vedi sopra)
soluzione relativa a Gravatar: nelle impostazioni di Discourse, vai su scarica automaticamente i gravatars, disattivala temporaneamente e vedi se questo risolve il problema. Non penso che sia questo il problema, ma se lo è, puoi lasciare l’impostazione disattivata, oppure correggere il routing IPv6 come descritto al punto 2, oppure cambiare il resolver DNS.
Grazie per la tua rapida risposta. Credo di aver già provato prima ‘rake avatars:refresh’, ma non ne sono assolutamente sicuro.
Quello che funzionava per me per far apparire immediatamente l’avatar era cliccarci una prima volta; al secondo clic, si apriva istantaneamente. Ma probabilmente è dovuto alla cache. Inoltre, ho appena testato il tuo secondo suggerimento e restituisce un “HTTP/2 301”, con diverse altre righe. La stessa cosa per il suggerimento 3. Eseguiò di nuovo avatars:refresh tra qualche giorno, poiché ho dovuto ripristinare un’istantanea. Grazie ancora!
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
Sì, dato il tuo messaggio, sono quasi certo che si tratti del problema n. 1, poiché i risultati del comando curl per Cloudflare e Gravatar sembrano essere quelli attesi. Prova rake avatars:refresh quando ti fa comodo e fammi sapere se funziona.
Ciao Lilly, ho ancora lo stesso problema. Anche dopo aver eseguito rake avatars:refresh. Il problema si presenta anche con /latest. Ho provato a svuotare la cache dal browser e da Cloudflare, ma senza successo. Forse devo aspettare un po’? Lo sto testando su un forum con 4500 utenti.
non svuotare più la cache del browser o di Cloudflare: quando esegui rake avatars:refresh per un gran numero di utenti, l’operazione non è istantanea. Vengono invece inseriti migliaia di lavori in Sidekiq da elaborare in background, il che può richiedere diverse ore a seconda della CPU del tuo server. Scusate per questo, avrei dovuto menzionare Sidekiq e che ci vuole un po’ di tempo a seconda di quanti utenti ci sono.
Vai a your-forum.com/sidekiq/queues e osserva la coda. Attendi che si svuoti completamente. Una volta terminato Sidekiq, tutte le dimensioni dovrebbero essere permanentemente nel tuo bucket R2 e, penso, la velocità di caricamento degli avatar dovrebbe tornare alla normalità.
Ok, penso che stia succedendo qualcos’altro. Non ho nulla nelle mie code. Ma se faccio clic sull’avatar di qualsiasi utente, questo appare in ‘tail -f log/production.log’: File inviato /var/www/discourse/tmp/avatar_proxy/3689d91eb5e1013beef831c585b5e62edeeecbd6.jpeg (0,2 ms)
Wow, ok. Questo è probabilmente l’indizio decisivo e indica un problema diverso.
avatar_proxy nei log di solito significa che Discourse si rifiuta di servire l’avatar direttamente dal CDN Cloudflare R2. Invece, Discourse intercetta aggressivamente la richiesta e scarica l’immagine da R2 nella cartella /tmp del server locale, per poi utilizzare Ruby per servirla al browser. Quindi penso che questo stia aggirando completamente il CDN e spiega il ritardo di 3 secondi: sospetto che il server stia recuperando e caricando manualmente il file ad ogni singola richiesta 
Discourse utilizza avatar_proxy in alcuni scenari molto specifici e di solito è un’impostazione di privacy o sicurezza che forza il server a mascherare l’URL esterno.
Controlla queste impostazioni in Amministrazione > Impostazioni sito:
Trova external system avatars url - se c’è qualcosa in quella casella (come /letter_avatar_proxy/v4/...), cancellalo in modo che sia vuoto. Questo dovrebbe impedire a Discourse di fare il proxy degli avatar predefiniti a lettere. Vale anche la pena controllare uploaded avatars allowed groups e assicurarsi che indichi TL_0.
Forse ricontrolla DISCOURSE_S3_CDN_URL per assicurarti che sia corretto, senza barra finale o errori di battitura?
Rimappa gli avatar personalizzati:
Sembra probabile che il tuo database contenga ancora gli URL grezzi del bucket R2 invece del tuo nuovo URL CDN; poiché non corrispondono, il tuo forum sta probabilmente facendone il proxy per motivi di sicurezza.
Controlla nella console Rails per vedere esattamente con cosa sta lottando Discourse:
./launcher enter app
rails c
Scegli un nome utente con un avatar a caricamento lento
u = User.find_by_username("the_selected_username")
u.user_avatar.custom_upload.url
Se l’output restituisce un URL grezzo del bucket, le tue precedenti rimappature non hanno colto tutto (forse potrebbe aver mancato un sottodominio o uno schema).
Per risolvere, accedi via SSH al tuo server, torna nel tuo container (non Rails) (./launcher enter app) ed esegui di nuovo lo strumento di rimappatura (ancora lol) per sostituire l’URL grezzo con il tuo URL CDN:
discourse remap "https://<il-tuo-url-grezzo-cloudflare>.r2.cloudflarestorage.com" "https://cdn.tuo-dominio.com"
Poi eseguilo una seconda volta usando // invece di https:// solo per sicurezza.
A proposito, per semplice curiosità, che servizio di hosting stai usando? Ho la stessa configurazione generale della tua e non ho ancora riscontrato questo problema. Quindi sono anche interessato alla tua configurazione e voglio provare a riprodurla in qualche modo.
L’URL che ottengo mostra l’URL CDN di S3 e riesco ad aprire l’immagine nel browser.
Per ora mi fermo a S3, perché non ne ho davvero bisogno in questo momento.
E uso Advinservers da molto tempo.
grazie per il tuo aiuto, è molto apprezzato