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
Ho completato ulteriori test e posso confermare che il problema non è legato a R2. Lo stesso comportamento (avatar che si caricano lentamente nei post e quando si clicca su un nome utente) persiste anche con un AWS S3 configurato correttamente. Non si tratta nemmeno di un problema del firewall, poiché “ufw status” conferma che il firewall è attualmente disabilitato. Ho intenzione di eseguire più test questo fine settimana in un ambiente di staging, dove posso tenere il forum in esecuzione per periodi più lunghi e metterlo offline se necessario, senza alcun problema.
Hai configurato sia il CDN del sito che quello di S3?
Sì, sto usando entrambi. Il bucket è collegato a CloudFront per l’URL CDN di S3, e lo stesso vale per l’URL CDN di Discourse.
Per i test su R2, non stavo utilizzando l’URL CDN di Discourse.
Tranne che su quello che non funziona?
E il problema che stai riscontrando è proprio con R2 senza il CDN di Discourse?
Non pretendo di capire esattamente qual è il tuo problema o il funzionamento esatto delle immagini degli avatar, ma ti consiglio di configurare il CDN prima di fare altri test. Potrebbe essere che il problema sia legato al passaggio a un nuovo bucket e al fatto che quelle immagini debbano essere rigenerate.
Gli avatar qui vengono caricati da quello che sembra essere un CDN di Discourse: https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/lilly/48/555832_2.png
I profili utente si caricano più velocemente dopo il primo caricamento?
Ancora una volta, non prometto di aver capito tutto e non ho esaminato il codice, ma la mia ipotesi è che questi vengano serviti dal CDN di Discourse e che Discourse si affidi alle richieste successive per prelevare i dati dal CDN. Credo che questo spieghi perché non funziona (o funziona lentamente) sulla versione R2 che non utilizza il CDN di Discourse.
forse non sto afferrando quello che intendi qui, ma ho 2 siti che eseguono lo storage R2 che non riscontrano questo problema. 
Non hanno i CDN di Discourse? Se non li hanno, ho torto. Se li hanno, allora potrebbe essere che non avere un CDN di Discourse (quando si ha un bucket S3?) causi questo problema.
Ma sembra strano che gli avatar si comportino diversamente con S3 rispetto a quando non si usa.
In realtà, ho testato questa configurazione con 4 diverse impostazioni:
R2 senza Discourse CDN
R2 con Discourse CDN
AWS S3 con Discourse CDN
AWS S3 senza Discourse CDN
In tutti i casi, ho utilizzato l’URL del CDN S3: files.mydomain.com.
Per i casi con Discourse CDN, ho usato: cdn.mydomain.com.
Il problema è che in ogni scenario il caricamento degli avatar è sempre molto lento.
Se apro un argomento, vedo gli avatar che si caricano uno alla volta. Tuttavia, questo accade solo una volta. Ad esempio, se vado su admin/users, vedo solo i nickname e poi gli avatar iniziano a caricarsi uno alla volta.
Se clicco su un nickname, si apre la scheda utente e l’avatar appare dopo 3-4 secondi. Anche questo accade solo una volta; se clicco di nuovo, l’avatar appare immediatamente, probabilmente a causa della cache.
PS: Durante ogni test, ripristino lo snapshot del momento in cui non utilizzavo S3/R2, elimino il bucket e ricomincio da capo.
Direi che non ha nulla a che fare con la configurazione dello storage degli oggetti. Penso che i tuoi avatar siano lenti in tutte e quattro quelle configurazioni perché il collo di bottiglia non è il provider di storage; piuttosto è la latenza di rete tra il tuo droplet del sito e il tuo bucket, oppure la CPU del tuo server fa fatica a ridimensionare le immagini al volo. Non so nulla della tua configurazione server/CDN e delle distanze coinvolte qui. Ma penso che una volta che la cache edge sarà stata costruita, non dovrebbe importare quale storage usi, purché tu ne scelga uno e lasci che la cache si costruisca da sola. Tuttavia, al momento sto solo facendo delle ipotesi perché non ho altre idee. 
Non so più cosa pensare. Per R2, utilizzavo la regione Western Europe (WEUR), e per S3, utilizzavo eu-north-1. Queste sono le specifiche del mio VPS:
Processore AMD Turin (4 vCore) 8GB di memoria DDR5 ECC 256GB di storage NVMe SSD 5TB di larghezza di banda (10 Gbit) Situato a Los Angeles, CA
Forse dovrei testare con una regione negli Stati Uniti la prossima volta? Non credo di poterlo fare con R2.
È quello che mi aspettavo. La generazione di tutte le avatar è lenta. I task rake lo faranno accadere, ma ci vogliono molto tempo, soprattutto se ci sono molti utenti. La prima volta che accedi a un utente, l’avatar viene generato e ci vogliono alcuni secondi per eseguire un programma esterno che elabora i dati dell’immagine in varie dimensioni. Dopo di che, tutto va bene. Penso che tu debba solo eseguire il task rake e aspettare che generi tutte le avatar nelle varie dimensioni?
sì, immagino che fosse quello che intendevo dire qui, ma forse non mi sono spiegato bene:
[quote=“Lilly, post:2, topic:405827”]
per verificare: esegui un aggiornamento forzato della pagina (hard-refresh) - se la prima volta l’avatar impiega 3-4 secondi, ma la seconda volta si carica istantaneamente, significa che è esattamente quello che sta succedendo.
per risolvere: il problema si risolverà naturalmente man mano che gli utenti navigano e le dimensioni vengono generate. Ma puoi risolverlo istantaneamente costringendo il server a pre-generare tutti gli avatar in background connettendoti al server via SSH ed eseguendo:
[/quote]\nma penso che tu abbia detto che si caricava lentamente ogni volta. 
penso che ogni volta che modifichi la configurazione S3 o svuoti la cache tu ricominci da capo. Se hai molti avatar degli utenti, ci vorrà molto tempo.
