Quando Ghost installato con Bitnami reindirizza su localhost, il problema quasi mai è Ghost “rotto”. Di solito sta leggendo un indirizzo sbagliato come URL canonico, oppure il reverse proxy non sta passando a Ghost le informazioni giuste sulla richiesta esterna. Il risultato è sempre lo stesso: il sito sembra vivo, ma ogni click porta dentro la macchina locale, oppure la dashboard si comporta in modo incoerente dietro HTTPS.
La correzione va fatta con ordine: prima si verifica quale layer sta imponendo il redirect, poi si corregge il valore canonico nel file di configurazione, infine si controllano proxy, certificato e header. Saltare direttamente alla modifica “a sentimento” è il modo più rapido per cambiare un problema con un altro.
Perché Ghost finisce su localhost
Ghost usa un URL pubblico canonico per generare link, redirect e cookie. Se in configurazione compare localhost, 127.0.0.1 o un hostname interno, Ghost considera quello come indirizzo valido e lo usa anche verso i visitatori. In un’installazione Bitnami questo capita spesso dopo una migrazione, un restore, una clonazione della VM o un cambio di proxy front-end.
Il punto importante è distinguere tra tre casi diversi: Ghost ha il valore sbagliato nel file di configurazione; Apache/Nginx davanti a Ghost non inoltra correttamente X-Forwarded-Proto e X-Forwarded-Host; oppure il DNS o il virtual host pubblicano un nome diverso da quello atteso. La sintomatologia può sembrare identica, ma la correzione cambia molto.
Controllo rapido del layer che sta imponendo il redirect
Prima di modificare i file, conviene vedere cosa risponde davvero il server. Da una macchina esterna, o almeno dalla stessa rete del client, esegui una richiesta verbosa e osserva il campo Location.
curl -I https://tuodominio.tldSe l’output mostra un Location: http://localhost:2368/ o simile, il redirect è già stato deciso dall’applicazione o dal proxy. Se invece il primo salto è corretto ma il problema compare dopo il login o entrando nel pannello admin, il difetto può essere nel canonical URL o nei cookie generati dietro proxy.
Un secondo controllo utile è guardare la configurazione effettiva di Ghost. Nelle installazioni Bitnami il file è spesso qui:
/opt/bitnami/ghost/content/config.production.jsonDentro devi cercare il blocco url. Se trovi http://localhost:2368 o un nome interno, hai già trovato il colpevole principale.
sudo grep -n '"url"' /opt/bitnami/ghost/content/config.production.jsonAtteso: un URL pubblico completo, ad esempio https://blog.tuodominio.tld. KO: qualsiasi riferimento a localhost, IP privato o hostname non pubblicato nel DNS.
Configurazione corretta del base URL in Bitnami Ghost
Il fix più frequente è allineare il valore canonico di Ghost con il dominio reale. Prima di toccare il file fai una copia, così il rollback è immediato se qualcosa non torna.
sudo cp /opt/bitnami/ghost/content/config.production.json /opt/bitnami/ghost/content/config.production.json.bak.$(date +%F-%H%M)Apri il file e correggi il valore url. Esempio:
{
"url": "https://blog.tuodominio.tld",
"server": {
"host": "127.0.0.1",
"port": 2368
}
}Qui il punto critico è non confondere l’indirizzo di ascolto locale con l’URL pubblico. Ghost può benissimo ascoltare su 127.0.0.1:2368 dietro proxy, ma il valore url deve restare quello esposto agli utenti. Se imposti il dominio pubblico su localhost, tutto il sistema si auto-referenzia.
Dopo la modifica, riavvia il servizio Ghost gestito da Bitnami. Il nome del servizio può variare leggermente in base alla versione, ma spesso il controllo passa da systemd o dallo script di Bitnami.
sudo /opt/bitnami/ctlscript.sh restart ghostSe preferisci verificare prima lo stato, usa:
sudo /opt/bitnami/ctlscript.sh statusAtteso: Ghost in esecuzione, senza errori di bind o di configurazione. KO: log che indicano parsing fallito del JSON o porta già occupata.
Reverse proxy: il secondo colpevole più comune
Anche con url corretto, Ghost può comportarsi male se Apache o Nginx davanti non trasmettono gli header giusti. Questo è tipico quando il sito è servito in HTTPS dal proxy, ma Ghost vede la richiesta come HTTP locale e costruisce redirect o cookie con schema e host sbagliati.
Con Apache, la configurazione del virtual host deve includere almeno il passaggio del nome host originale e del protocollo. Un esempio concettuale è questo:
ProxyPreserveHost On
RequestHeader set X-Forwarded-Proto "https"
ProxyPass / http://127.0.0.1:2368/
ProxyPassReverse / http://127.0.0.1:2368/Con Nginx il principio è lo stesso: Ghost deve sapere che la richiesta pubblica arriva in HTTPS e con il dominio reale. In pratica servono intestazioni come X-Forwarded-Host e X-Forwarded-Proto.
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Real-IP $remote_addr;Se il proxy non è coerente, Ghost può generare URL assoluti errati anche quando il file di configurazione sembra corretto. In questi casi il test più veloce è aprire la homepage, fare un refresh forzato e osservare se il redirect cambia tra HTTP e HTTPS, oppure se il dominio viene sostituito da localhost solo dopo il primo salto.
Certificato e dominio: quando il problema sembra Ghost ma non lo è
Se il certificato TLS non corrisponde al dominio reale, alcuni browser reagiscono con comportamenti che l’operatore interpreta come redirect anomali. Non è Ghost a decidere localhost, ma il client che rifiuta il nome presentato dal server e segue un flusso di fallback confuso. Per questo conviene verificare anche il certificato e il virtual host.
Controlla che il certificato servito corrisponda al nome pubblico:
openssl s_client -connect blog.tuodominio.tld:443 -servername blog.tuodominio.tld Atteso: nel certificato compare il SAN corretto per il dominio usato dagli utenti. KO: SAN mancante, certificato emesso per un altro host o catena incompleta. Se il certificato è errato, correggere il redirect nel CMS non basta.
Procedura pratica: correzione minima e reversibile
La sequenza più sicura è questa: prima si cambia il valore canonico di Ghost, poi si verifica il proxy, infine si controlla il comportamento esterno. Così limiti il blast radius alla configurazione applicativa e al solo front-end web, senza toccare dati o contenuti.
- Salva una copia del file di configurazione attuale in
/opt/bitnami/ghost/content/config.production.json.bak.TIMESTAMP. - Imposta
urlcon il dominio pubblico reale, ad esempiohttps://blog.tuodominio.tld. - Verifica che Ghost ascolti localmente su
127.0.0.1:2368e non su un IP pubblico, se è dietro proxy. - Controlla il virtual host del proxy e assicurati che inoltri host e protocollo corretti.
- Riavvia il servizio Ghost e poi ricarica la pagina con un test esterno, non dalla stessa macchina.
Se vuoi un controllo rapido dopo il riavvio, usa di nuovo una richiesta HEAD e guarda il redirect finale.
curl -I https://blog.tuodominio.tldAtteso: nessun Location verso localhost, nessun loop, risposta 200 o redirect coerente verso HTTPS e il dominio pubblico. KO: catena di redirect ripetuta, schema sbagliato, host interno nel campo Location.
Quando Ghost è dietro CDN o WAF
Se davanti c’è una CDN o un WAF, il problema si complica di poco ma abbastanza da far perdere tempo. Il proxy esterno può terminare TLS e inoltrare verso l’origine con host diverso, oppure può riscrivere header e cookie in modo non compatibile con Ghost. In questi casi non basta guardare il server origin: serve verificare anche ciò che arriva all’origine dal layer edge.
La prova minima è confrontare la risposta diretta all’origine con quella passata dal dominio pubblico. Se l’origine risponde bene ma il dominio pubblico no, il colpevole sta tra CDN/WAF e virtual host. Se invece l’origine risponde già con localhost, il problema è interno a Ghost o al reverse proxy locale.
In presenza di CDN conviene anche verificare che il certificato lato origine sia valido per il nome usato dal proxy e che l’host header non venga normalizzato in modo inatteso. Questo è uno dei casi in cui il sintomo “va su localhost” è solo la punta dell’iceberg: sotto c’è una catena di indirizzi incoerente.
Verifiche finali che evitano il falso positivo
Dopo la correzione, non fermarti alla homepage. Ghost può sembrare risolto ma continuare a generare link interni errati nel pannello admin, nei feed o nelle email transazionali. Vale la pena controllare almeno tre punti: homepage, login admin e link canonico del sito.
- Apri la homepage e verifica che il dominio resti quello pubblico anche dopo refresh e navigazione interna.
- Accedi all’area admin e controlla che l’URL non cambi in
localhosto in un host privato dopo il login. - Se usi feed o newsletter, verifica che i link generati siano assoluti e corretti nel sorgente HTML o nel feed XML.
Un buon controllo aggiuntivo è leggere i log del servizio subito dopo il riavvio. Se il file di configurazione è malformato, Ghost di solito lo dice chiaramente. Se invece i log sono puliti ma il redirect resta sbagliato, allora il responsabile è quasi sempre il proxy o il layer edge.
sudo journalctl -u ghost -n 50 --no-pagerAtteso: nessun errore di parsing, nessun crash loop, nessun riferimento a URL interni. KO: messaggi che indicano configurazione non valida, permessi errati sul file o dipendenze non raggiungibili.
Rollback se il fix peggiora la situazione
Se dopo la modifica il sito non torna stabile, il rollback è semplice perché hai conservato una copia del file precedente. Ripristina il backup, riavvia Ghost e ripeti il test esterno. Questo ti consente di tornare allo stato iniziale senza toccare contenuti, database o permessi globali.
sudo cp /opt/bitnami/ghost/content/config.production.json.bak.TIMESTAMP /opt/bitnami/ghost/content/config.production.json
sudo /opt/bitnami/ctlscript.sh restart ghostSe il rollback riporta il comportamento precedente, hai confermato che il problema sta nella modifica applicata o in un’incoerenza tra proxy e URL pubblico. A quel punto conviene fermarsi e correggere la catena completa, non fare altri tentativi casuali.
In pratica, il fix corretto per Bitnami Ghost che reindirizza su localhost è quasi sempre un allineamento tra url, reverse proxy e dominio reale. Il punto non è “far sparire localhost”, ma fare in modo che ogni layer veda e annunci lo stesso indirizzo pubblico. Quando questo succede, i redirect si normalizzano, i cookie diventano coerenti e il sito smette di comportarsi come se fosse ancora in laboratorio.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.